March 2011 - Pharo-dev - lists.pharo.org

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

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

by Camillo Bruni

I am against non-transparent optimizations as well. However, I think special selectors like ifTrue: / class and so forth should still be used in the VM since its cheap way getting some performance improvements. But to make them work in a decent OO way they should also be able to deal with a non-standard implementation (like customized Boolean class). On 2011-03-25, at 17:26, Mariano Martinez Peck wrote: > Hi. I have to say that I hate that the compiler associates a special > bytecode for #class and that the VM don't even send the message. I want to > be able to overwrite #class in a proxy for example, or to debug it. > > ObjectsDo: [:each | each class]] timeToRun > -> aprox 17 miliseconds > > So...only 5 miliseconds more for asking the class to all the objects in the > system.....(done in a PharoCore 1.3) > > Considering (5 ms / 324535) asFloat 0,000015406 ms... of overhead 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...

March 25, 2011

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

by Marcus Denker

On Mar 25, 2011, at 5:26 PM, Mariano Martinez Peck wrote: > Hi. I have to say that I hate that the compiler associates a special bytecode for #class and that the VM don't even send the message. I want to be able to overwrite #class in a proxy for example, or to debug it. > > I did some benchmarks disabling such optimization by doing: > > (ParseNode classVarNamed: 'StdSelectors') removeKey: #class ifAbsent: []. > Compiler recompileAll. > > And the difference is NOTHING in my tests (maybe I am doing something wrong). > > With Standard VM and #class optimization > > [SystemNavigation default allObjectsDo: [:each | each class]] timeToRun -> aprox 50 miliseconds > What is the constant over head of doing just the iteration? [SystemNavigation default allObjectsDo: [:each | ]] timeToRun > > What do you think? I am for... for the JIT is is a monomorphic send to a primitive, so the IC will be very effective and should take care that the lookup is actually almost never done. (and the lookup is the only thing the #class bytecode saves, as the target method is a primitive). Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 25, 2011

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

by Mariano Martinez Peck

Hi. I have to say that I hate that the compiler associates a special bytecode for #class and that the VM don't even send the message. I want to be able to overwrite #class in a proxy for example, or to debug it. I did some benchmarks disabling such optimization by doing: (ParseNode classVarNamed: 'StdSelectors') removeKey: #class ifAbsent: []. Compiler recompileAll. And the difference is NOTHING in my tests (maybe I am doing something wrong). With Standard VM and #class optimization [SystemNavigation default allObjectsDo: [:each | each class]] timeToRun -> aprox 50 miliseconds With Standard VM and WITHOUT #class optimization [SystemNavigation default allObjectsDo: [:each | each class]] timeToRun -> aprox 60 miliseconds So...only 10 miliseconds more for asking the class to all the objects in the system.....(done in a PharoCore 1.3) With Cog VM and #class optimization [SystemNavigation default allObjectsDo: [:each | each class]] timeToRun -> aprox 13 miliseconds With Cog VM and WITHOUT #class optimization [SystemNavigation default allObjectsDo: [:each | each class]] timeToRun -> aprox 17 miliseconds So...only 5 miliseconds more for asking the class to all the objects in the system.....(done in a PharoCore 1.3) Considering (5 / 324535) asFloat 0,000015406... of overhead What do you think? Mariano

March 25, 2011

Re: [Pharo-project] Issue 3876 in pharo: SqNumberParserTest>>testFloatGradualUnderflow has an odd condition

by pharo＠googlecode.com

Comment #3 on issue 3876 by da...(a)teleport.com: SqNumberParserTest>>testFloatGradualUnderflow has an odd condition http://code.google.com/p/pharo/issues/detail?id=3876 aha, now it makes sense:)

March 25, 2011