In JIT, it makes sense because there are special handling for well known special selectors (#+ #at: #< etc...).
2013/9/4 Igor Stasenko <siguc...@gmail.com> > i think you can feel the difference while running interpreter. > With JIT it makes little sense to have special selectors imo. > > > On 4 September 2013 12:31, Nicolas Cellier < > nicolas.cellier.aka.n...@gmail.com> wrote: > >> Agree, >> My point was to ensure there was no speedup, so it's only a space >> optimization (1 slot saved from literals, times 5000 senders or so per >> selector plus maybe a byte for the send bytecode ?). >> However the arithmetic ops, comparisons, bit ops, at: at:put:, == and >> class special selectors still have some specific speed up, especially in >> COG, so we cannot get rid of specialSelectors alltogether... >> >> >> 2013/9/4 Marcus Denker <marcus.den...@inria.fr> >> >>> >>> On Sep 4, 2013, at 12:08 AM, Nicolas Cellier < >>> nicolas.cellier.aka.n...@gmail.com> wrote: >>> >>> > I note that #class was removed from specialSelectors (nilled entry) so >>> as to not use the VM hack which fetches the class without sending a message. >>> > Pharo prefers the regular message send. >>> > But next to that entry, there is #blockCopy: which was formerly used >>> for blue book BlockContext. >>> > BlockContext was removed from Pharo... >>> > So that makes two available slots for optimizing most used (sent) >>> messages... >>> > We might choose some candidates and test on some macro benchmark if >>> ever that really makes a difference. >>> >>> I am not sure if optimizations on that level make sense… >>> >>> Marcus >>> >> >> > > > -- > Best regards, > Igor Stasenko. >
