November 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] x4 difference between #to:do: and #timesRepeat - bug ?

by Igor Stasenko

2009/11/13 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: > > > >> No, please no more inilining hacks. :) >> If someone wants to run everything at light speed - just code in C, >> but leave smalltalk honoring the >> message passing. >> And besides, these tricks won't make any difference when having good >> inlining JIT. >> In bytecode, they just add a complexity to compiler and headache to >> developers. >> > > I agree but I asked beacause I'll make student use this method and wasn't > sure of the explanation. > > Also, some asked me about the performance of Pharo/Smalltalk in general. > > I did this counter in C++ and Smalltalk. > > I get a 10x difference between C++ and Pharo, the inlined version, and > therefore a 40x whith the other one. > > So does this number seems reasonnably true to you ? You are counting wrong numbers. Please count the time you have to spend to interpret closures in C++, and then using them run arbitrary code in the loop, then we will talk again when you done :) > What would be the order of magnitude with a JIT ? > > TIA, > > CÃ©drick > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 13, 2009

Re: [Pharo-project] x4 difference between #to:do: and #timesRepeat - bug ?

by CÃ©drick BÃ©ler

No, please no more inilining hacks. :) > If someone wants to run everything at light speed - just code in C, > but leave smalltalk honoring the > message passing. > And besides, these tricks won't make any difference when having good > inlining JIT. > In bytecode, they just add a complexity to compiler and headache to > developers. > > I agree but I asked beacause I'll make student use this method and wasn't sure of the explanation. Also, some asked me about the performance of Pharo/Smalltalk in general. I did this counter in C++ and Smalltalk. I get a 10x difference between C++ and Pharo, the inlined version, and therefore a 40x whith the other one. So does this number seems reasonnably true to you ? What would be the order of magnitude with a JIT ? TIA, CÃ©drick

Nov. 13, 2009

Re: [Pharo-project] x4 difference between #to:do: and #timesRepeat - bug ?

by CÃ©drick BÃ©ler

Thanks all. Interesting. I saw by using tallySends that: timesRepeat: This simulation took 6.0 seconds. **Tree** 1 SmallInteger(Integer)>>timesRepeat: **Leaves** 100001 UndefinedObject>>DoIt 1 SmallInteger(Integer)>>timesRepeat: 1 UndefinedObject>>DoIt to:do: This simulation took 3.0 seconds. **Tree** **Leaves** 1 UndefinedObject>>DoIt I guess this is one consequence of being inlined. This makes ask another questions: -how to know what's inlined, what method have suche properties (a comment would be cool, so if we had to choose...) ? -how to add Compiler inlining rules (as it's easy ;) ) ? -why not inlining timesRepeat: (as I guess we don't really change it often) ? Thanks. ps: the result is slow because I used a 5 year old (at least) computer :). I think I got a 10x difference in a 2 year one... 2009/11/13 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > There is also a difference between: > > [self atEnd ifTrue: [^nil]. > self next. > true] whileTrue. > > and: > > [self atEnd ifTrue: [^nil] > self next] repeat. > > Warning: it's quite easy to add Compiler inlining rules, a bit tougher > to add corresponding Decompiler tricks. > > 2009/11/13 Marcus Denker <denker(a)acm.org>: > > > > On Nov 13, 2009, at 9:51 AM, CÃ©drick BÃ©ler wrote: > > > >> Hi, > >> > >> I noticed quite a difference between the two method who "looks" the same > to me. Is it normal ? > >> > > > > Normal. to:do: is lnlined (compiled as jumps in the bytecode), whereas > timesRepeat: is a message > > send with a closure activation. > > > > Marcus > > > > fun is the difference between: > > > > (1 to : 10000) do: > > and > > 1 to: 10000 do: > > > > one is compiled to jumps, the other not and in addition creates a temp > collection. > > > > Marcus > > > > > > > >> I use a rc image (haven't tested in squeak). And it's the same on > windows and linux. > >> > >> count := 0. > >> [1 to: 10000000 do: [:i | count :=count + 1]] timeToRun." 677" > >> count := 0. > >> [10000000 timesRepeat: [count := count + 1]] timeToRun" 2571" > >> > >> If not normal, I'll open a issue. > >> > >> Thanks > >> > >> -- > >> CÃ©drick > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- CÃ©drick

Nov. 13, 2009

Re: [Pharo-project] x4 difference between #to:do: and #timesRepeat - bug ?

by Igor Stasenko

No, please no more inilining hacks. :) If someone wants to run everything at light speed - just code in C, but leave smalltalk honoring the message passing. And besides, these tricks won't make any difference when having good inlining JIT. In bytecode, they just add a complexity to compiler and headache to developers. 2009/11/13 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > There is also a difference between: > > [self atEnd ifTrue: [^nil]. > self next. > true] whileTrue. > > and: > > [self atEnd ifTrue: [^nil] > self next] repeat. > > Warning: it's quite easy to add Compiler inlining rules, a bit tougher > to add corresponding Decompiler tricks. > > 2009/11/13 Marcus Denker <denker(a)acm.org>: >> >> On Nov 13, 2009, at 9:51 AM, CÃ©drick BÃ©ler wrote: >> >>> Hi, >>> >>> I noticed quite a difference between the two method who "looks" the same to me. Is it normal ? >>> >> >> Normal. to:do: is lnlined (compiled as jumps in the bytecode), whereas timesRepeat: is a message >> send with a closure activation. >> >> Â Â Â Â Marcus >> >> fun is the difference between: >> >> Â Â Â Â (1 to : 10000) do: >> and >> Â Â Â Â 1 to: 10000 do: >> >> one is compiled to jumps, the other not and in addition creates a temp collection. >> >> Â Â Â Â Marcus >> >> >> >>> I use a rc image (haven't tested in squeak). And it's the same on windows and linux. >>> >>> count := 0. >>> [1 to: 10000000 do: [:i | count :=count + 1]] timeToRun." 677" >>> count := 0. >>> [10000000 timesRepeat: [count := count + 1]] timeToRun" 2571" >>> >>> If not normal, I'll open a issue. >>> >>> Thanks >>> >>> -- >>> CÃ©drick >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 13, 2009

Re: [Pharo-project] x4 difference between #to:do: and #timesRepeat - bug ?

by Nicolas Cellier

There is also a difference between: [self atEnd ifTrue: [^nil]. self next. true] whileTrue. and: [self atEnd ifTrue: [^nil] self next] repeat. Warning: it's quite easy to add Compiler inlining rules, a bit tougher to add corresponding Decompiler tricks. 2009/11/13 Marcus Denker <denker(a)acm.org>: > > On Nov 13, 2009, at 9:51 AM, CÃ©drick BÃ©ler wrote: > >> Hi, >> >> I noticed quite a difference between the two method who "looks" the same to me. Is it normal ? >> > > Normal. to:do: is lnlined (compiled as jumps in the bytecode), whereas timesRepeat: is a message > send with a closure activation. > > Â Â Â Â Marcus > > fun is the difference between: > > Â Â Â Â (1 to : 10000) do: > and > Â Â Â Â 1 to: 10000 do: > > one is compiled to jumps, the other not and in addition creates a temp collection. > > Â Â Â Â Marcus > > > >> I use a rc image (haven't tested in squeak). And it's the same on windows and linux. >> >> count := 0. >> [1 to: 10000000 do: [:i | count :=count + 1]] timeToRun." 677" >> count := 0. >> [10000000 timesRepeat: [count := count + 1]] timeToRun" 2571" >> >> If not normal, I'll open a issue. >> >> Thanks >> >> -- >> CÃ©drick >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 13, 2009

Re: [Pharo-project] x4 difference between #to:do: and #timesRepeat - bug ?

by Peter Hugosson-Miller

Results for VisualAge (just FYI): | count | count := 0. [1 to: 10000000 do: [:i | count :=count + 1]] timeToRun. "151702" | count | count := 0. [10000000 timesRepeat: [count := count + 1]] timeToRun. "139971" (results are in microseconds) So maybe there's a case for inlining #timesRepeat: (or making a clear comment that it is much slower in Pharo) Just my $0:02 -- Cheers, Peter On Fri, Nov 13, 2009 at 9:59 AM, Marcus Denker <denker(a)acm.org> wrote: > > On Nov 13, 2009, at 9:51 AM, CÃ©drick BÃ©ler wrote: > > > Hi, > > > > I noticed quite a difference between the two method who "looks" the same > to me. Is it normal ? > > > > Normal. to:do: is lnlined (compiled as jumps in the bytecode), whereas > timesRepeat: is a message > send with a closure activation. > > Marcus > > fun is the difference between: > > (1 to : 10000) do: > and > 1 to: 10000 do: > > one is compiled to jumps, the other not and in addition creates a temp > collection. > > Marcus > > > > > I use a rc image (haven't tested in squeak). And it's the same on windows > and linux. > > > > count := 0. > > [1 to: 10000000 do: [:i | count :=count + 1]] timeToRun." 677" > > count := 0. > > [10000000 timesRepeat: [count := count + 1]] timeToRun" 2571" > > > > If not normal, I'll open a issue. > > > > Thanks > > > > -- > > CÃ©drick > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 13, 2009

Re: [Pharo-project] x4 difference between #to:do: and #timesRepeat - bug ?

by Marcus Denker

On Nov 13, 2009, at 9:51 AM, CÃ©drick BÃ©ler wrote: > Hi, > > I noticed quite a difference between the two method who "looks" the same to me. Is it normal ? > Normal. to:do: is lnlined (compiled as jumps in the bytecode), whereas timesRepeat: is a message send with a closure activation. Marcus fun is the difference between: (1 to : 10000) do: and 1 to: 10000 do: one is compiled to jumps, the other not and in addition creates a temp collection. Marcus > I use a rc image (haven't tested in squeak). And it's the same on windows and linux. > > count := 0. > [1 to: 10000000 do: [:i | count :=count + 1]] timeToRun." 677" > count := 0. > [10000000 timesRepeat: [count := count + 1]] timeToRun" 2571" > > If not normal, I'll open a issue. > > Thanks > > -- > CÃ©drick > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 13, 2009

[Pharo-project] x4 difference between #to:do: and #timesRepeat - bug ?

by CÃ©drick BÃ©ler

Hi, I noticed quite a difference between the two method who "looks" the same to me. Is it normal ? I use a rc image (haven't tested in squeak). And it's the same on windows and linux. count := 0. [1 to: 10000000 do: [:i | count :=count + 1]] timeToRun." 677" count := 0. [10000000 timesRepeat: [count := count + 1]] timeToRun" 2571" If not normal, I'll open a issue. Thanks -- CÃ©drick

Nov. 13, 2009

Re: [Pharo-project] MailMessage

by Schmidt, Marco

I had a problem with Email and the character encoding. Sending mail with the character 'ÃÃÃ' inside the mail body killed the mail server. So - look at correct encoding of the message text. Marco Schmidt -----UrsprÃ¼ngliche Nachricht----- Von: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Im Auftrag von Schwab,Wilhelm K Gesendet: Freitag, 13. November 2009 01:29 An: Pharo-project(a)lists.gforge.inria.fr Betreff: [Pharo-project] MailMessage Hello all, I am looking for a way to format text in email. Html comes to mind (yes, I hate those emails too, but it would work and the recipients don't know any better<g>), as does attaching a file with the data. I recently had to switch smtp servers, and for whatever reason, can no longer send html email. The server says it accepted it, but the mail is never delivered; send plain text through it, and it works. It could simply be that the server wants no part of html email, but it would be nice to repeat the test with another client, and/or try attachments as a solution to my problem. I found MailMessage, and could not figure out how to set the recipient. After some searching, I found 151 on Mantis; it is a five year old fix from Frank Shearer for adding recipients. If I had to guess, things are still broken, but I will try it and see what happens. Sending this now while I'm thinking about it. If anybody knows a way around my current problems, please don't feel that you would be cheating me out of the fun of solving it myself :) Bill _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 13, 2009

Re: [Pharo-project] testing morphs

by Tudor Girba

Thanks Martin! Cheers, Doru On 13 Nov 2009, at 03:11, Martin McClure wrote: > Tudor Girba wrote: > >> >> This sounds interesting. Would it be possible to get a code sample >> (in >> particular of the waitUntil: method)? >> > > Sure. Here's the code we use in VW. I clearly didn't remember exactly > what we called it. :-) > We have a number of simpler methods that use this one, which is the > most > general case. Once you account for GemStone and VW-specific stuff, I > imagine this approach should work in Pharo. > > Regards, > > -Martin > > > gbtPauseUntil: validateBlock evaluatesReturning: expectedResult > maxWaitSeconds: maxWaitSeconds > "Evaluate validateBlock until it returns expectedResult or > maxWaitSeconds have passed, > pausing between evaluations. Return the last result of > validateBlock > value" > > | startTime result | > startTime := Time secondClock. > [result := validateBlock value = expectedResult] whileFalse: > [Time secondClock - startTime > maxWaitSeconds ifTrue: [^result]. > (GbxDelay forMilliseconds: 50) wait]. > ^result > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Be rather willing to give than demanding to get."

Nov. 13, 2009