- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3715 in pharo: Workspace shouting after switching between shout/unshout

by pharo＠googlecode.com

Comment #9 on issue 3715 by stephane...(a)gmail.com: Workspace shouting after switching between shout/unshout http://code.google.com/p/pharo/issues/detail?id=3715 Benjamin you should talk with igor about using class new.

March 25, 2011

Re: [Pharo-project] Remove #class as a Compiler optimization

by Camillo Bruni

On 2011-03-25, at 18:12, Marcus Denker wrote: > > On Mar 25, 2011, at 5:51 PM, Marcus Denker wrote: > >> >> On Mar 25, 2011, at 5:46 PM, Camillo Bruni wrote: >>>> >>> >>> Arguing with absolute values is a bit dangerous: >>> >>> But it makes >>> 13ms / 17ms * 100% = 76% => 25% speed improvement! in COG >>> 50ms / 60ms * 100% = 83% => 17% faster > > So for Cog, you get this counter-intuitive result is because Cog > executes the overhead loop faster in combination with not jitting > what you wanted to test. I didn't run the benchmarks, I just listed the results mariano provided. Just to show that they do not provide a valid argument for removal of the method. So we have a nice Benchmarking framework on sqeaksource which we should use instead of relying on some pseudo valid results. I do not have to time right now to do so... but I expect the overhead to be neglectable in COG, since it should be fairly easy to JIT this in... > As the doit is *not* Jited, it executes as fast as in the intepreter case. > You see a higher percentage just because the base overhead loop > is executed faster and the thing you test gets a larger share of the > runtime. > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

March 25, 2011

Re: [Pharo-project] Issue 3715 in pharo: Workspace shouting after switching between shout/unshout

by pharo＠googlecode.com

Updates: Status: Closed Comment #8 on issue 3715 by stephane...(a)gmail.com: Workspace shouting after switching between shout/unshout http://code.google.com/p/pharo/issues/detail?id=3715 in 13110

March 25, 2011

Re: [Pharo-project] Remove #class as a Compiler optimization

by Marcus Denker

On Mar 25, 2011, at 5:51 PM, Marcus Denker wrote: > > On Mar 25, 2011, at 5:46 PM, Camillo Bruni wrote: >>> >> >> Arguing with absolute values is a bit dangerous: >> >> But it makes >> 13ms / 17ms * 100% = 76% => 25% speed improvement! in COG >> 50ms / 60ms * 100% = 83% => 17% faster So for Cog, you get this counter-intuitive result is because Cog executes the overhead loop faster in combination with not jitting what you wanted to test. As the doit is *not* Jited, it executes as fast as in the intepreter case. You see a higher percentage just because the base overhead loop is executed faster and the thing you test gets a larger share of the runtime. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 25, 2011

Re: [Pharo-project] Issue 3859 in pharo: Pluggin control

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3859 by stephane...(a)gmail.com: Pluggin control http://code.google.com/p/pharo/issues/detail?id=3859 in 13110

March 25, 2011

Re: [Pharo-project] Issue 3879 in pharo: Wipe out positional arguments cruft from compiler

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3879 by stephane...(a)gmail.com: Wipe out positional arguments cruft from compiler http://code.google.com/p/pharo/issues/detail?id=3879 13110

March 25, 2011

Re: [Pharo-project] Remove #class as a Compiler optimization

by Marcus Denker

On Mar 25, 2011, at 5:46 PM, Camillo Bruni wrote: >> > > Arguing with absolute values is a bit dangerous: > > But it makes > 13ms / 17ms * 100% = 76% => 25% speed improvement! in COG > 50ms / 60ms * 100% = 83% => 17% faster > > So the impact is still quite big. But indeed I would be in favor of a normal message send... > And are you sure that your Doit is actually JITed in Cog? 1) always take the overhead of the loop into acount. Especially if it is a large percentage, it can make you "slowdown" seem very small even though it is huge. e.g. the overhead of the loop in your case should be *very* high. 90% of the execution time? 2) always make sure that you actually JIT. -> put it in a normal method in a class -> execute it at least 2 times Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 25, 2011

Re: [Pharo-project] Issue 3881 in pharo: Problem with Inst var refs...

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3881 by stephane...(a)gmail.com: Problem with Inst var refs... http://code.google.com/p/pharo/issues/detail?id=3881 (No comment was entered for this change.)

March 25, 2011

Re: [Pharo-project] pharo closures

by Miguel CobÃ¡

El vie, 25-03-2011 a las 13:05 +0100, Henrik Johansen escribiÃ³: > On Mar 25, 2011, at 12:54 25PM, Igor Stasenko wrote: > > > On 25 March 2011 12:35, Stefan Marr <pharo(a)stefan-marr.de> wrote: > >> Hi: > >> > >> On 25 Mar 2011, at 11:01, Toon Verwaest wrote: > >> > >>> If you really win a lot of performance by doing so, this is justified (although I would still give it a different class than just Array ;)). I'm just trying to find out if that performance boost is really there. But I'm going to take this offline I think not to pollute the whole mailing list with our circular conversations, and I'll report back if we figure something interesting out ;) > >> Well, for what it is worth, I really enjoy such discussions. And they are much more than all the usual ones here on the list ;) > >> > >> If you do not feel that the Pharo mailing list is the right place, there is always an almost unused smalltalk research mailing list... > >> > > No, it is right place for such discussions. > > Come on, since when extra mail traffic in Pharo list became a problem? :) > > Agreed. > Interesting technical discussion is much better than all of the "Cool!" and "Me too!" posts we already get. (Which of course, ironically, this is one) +100 ;) he he! -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

March 25, 2011

Re: [Pharo-project] Issue 3881 in pharo: Problem with Inst var refs...

by pharo＠googlecode.com

Comment #1 on issue 3881 by stephane...(a)gmail.com: Problem with Inst var refs... http://code.google.com/p/pharo/issues/detail?id=3881 in 13110

March 25, 2011