- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] problem with obsolete classes in latest core

by Henrik Johansen

On Mar 25, 2011, at 4:12 02PM, Henrik Johansen wrote: > > On Mar 25, 2011, at 4:09 51PM, Henrik Johansen wrote: > >> >> On Mar 25, 2011, at 3:48 33PM, Marcus Denker wrote: >> >>> >>> On Mar 25, 2011, at 3:46 PM, Marcus Denker wrote: >>>> >>>>> fixObsoleteReferences only fixes CompiledMethods, doesn't it ? >>>>> >>>> >>>> yep. >>>> >>> >>> >>> And the trick to find them is to inspect >>> >>> SystemNavigation default obsoleteClasses first allInstances >>> >>> and then use the "explore pointers" on that. >>> >>> Marcus >>> >> >> >> Soooo... >> WordArrayForSegment in System-Object Storage is now a subclass of AnObsoleteWordArray? >> >> What on earth did that update try to do? ;) >> >> Cheers, >> Henry > > Oh, move it from one category to another. > > Figures that's so complicated an operation it would break all subclasses etc. > > Cheers, > Henry Why move them to begin with btw? Are they not arrayed? Isn't ByteArray "native" too, following whatever rationale was followed when moving Word/Float/IntegerArrays there? How about the rest of the variable Word/Byte subclasses? This way just looks silly, imho... Cheers, Henry

March 25, 2011

Re: [Pharo-project] Issue 3877 in pharo: Check reduced complexity for UI themes

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #1 on issue 3877 by marcus.d...(a)gmail.com: Check reduced complexity for UI themes http://code.google.com/p/pharo/issues/detail?id=3877 (No comment was entered for this change.)

March 25, 2011

Re: [Pharo-project] Issue 3878 in pharo: #enableTextChange selector name is misleading, i propose changing the name to #canChangeText

by pharo＠googlecode.com

Updates: Status: FixProposed Labels: Milestone-1.3 Comment #1 on issue 3878 by marcus.d...(a)gmail.com: #enableTextChange selector name is misleading, i propose changing the name to #canChangeText http://code.google.com/p/pharo/issues/detail?id=3878 (No comment was entered for this change.)

March 25, 2011

Re: [Pharo-project] problem with obsolete classes in latest core

by Henrik Johansen

On Mar 25, 2011, at 4:09 51PM, Henrik Johansen wrote: > > On Mar 25, 2011, at 3:48 33PM, Marcus Denker wrote: > >> >> On Mar 25, 2011, at 3:46 PM, Marcus Denker wrote: >>> >>>> fixObsoleteReferences only fixes CompiledMethods, doesn't it ? >>>> >>> >>> yep. >>> >> >> >> And the trick to find them is to inspect >> >> SystemNavigation default obsoleteClasses first allInstances >> >> and then use the "explore pointers" on that. >> >> Marcus >> > > > Soooo... > WordArrayForSegment in System-Object Storage is now a subclass of AnObsoleteWordArray? > > What on earth did that update try to do? ;) > > Cheers, > Henry Oh, move it from one category to another. Figures that's so complicated an operation it would break all subclasses etc. Cheers, Henry

March 25, 2011

Re: [Pharo-project] problem with obsolete classes in latest core

by Henrik Johansen

On Mar 25, 2011, at 3:48 33PM, Marcus Denker wrote: > > On Mar 25, 2011, at 3:46 PM, Marcus Denker wrote: >> >>> fixObsoleteReferences only fixes CompiledMethods, doesn't it ? >>> >> >> yep. >> > > > And the trick to find them is to inspect > > SystemNavigation default obsoleteClasses first allInstances > > and then use the "explore pointers" on that. > > Marcus > Soooo... WordArrayForSegment in System-Object Storage is now a subclass of AnObsoleteWordArray? What on earth did that update try to do? ;) Cheers, Henry

March 25, 2011

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

by pharo＠googlecode.com

Status: FixProposed Owner: Benjamin...(a)gmail.com Labels: Nautilus New issue 3881 by Benjamin...(a)gmail.com: Problem with Inst var refs... http://code.google.com/p/pharo/issues/detail?id=3881 If you click, the popup window have the good name, but if you choose to sort var names alphabetically, you have a stupid name Attachments: FixTitleIssueInInstVarBrowser.1.cs 748 bytes

March 25, 2011