On Fri, Mar 25, 2011 at 8:27 PM, Igor Stasenko <[email protected]> wrote:
> On 25 March 2011 19:22, Mariano Martinez Peck <[email protected]> > wrote: > > > > > > On Fri, Mar 25, 2011 at 7:08 PM, Toon Verwaest <[email protected]> > > wrote: > >> > >>>> 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). > >> > >> I think that programmers should have the illusion that the VM interacts > >> with the system through message sends. By being able to overwrite this > >> particular message you break this illusion. The VM will just fetch the > real > >> class; but the user doesn't get access to it anymore. Telling the system > >> that this particular message shouldn't be overwritten is probably a good > >> thing. > >> > >> If you want to overwrite the method class, maybe your tools should send > >> another message than class in the first place? > > > > Of course I can do that. I can also do > > > > (ParseNode classVarNamed: 'StdSelectors') removeKey: #class > ifAbsent: > > []. > > Compiler recompileAll. > > > > I don't care. I have it working for my "usage". This was just an example. > > > > And don't compare #class with all the boolean methods like #ifNil: and > > friends or the bytecodes for integer operations....I think #class is > sent > > far less times than those... > > > > Yes. and i predict that performance impact in macro benchmarks, where > you running normal code > (which not sending this message intentionally in a loop) will be at > the noise level magnitude. > So...what about doing something more real...for example, run all the testcases and compare time. Wouldn't that be a good "benchmark" ? BTW, can I run all test from code? (not using the TestRunner UI) > > > > >> > >> I do however agree that many other optimizations become slightly > >> superfluous, such as bytecodes for integer operations ... that somehow > seems > >> like compile-time inline-cached behavior without the ability to flush > the > >> cache :) > >> > >> cheers, > >> Toon > >> > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > >
