On Wed, Sep 4, 2013 at 3:35 AM, Igor Stasenko <siguctua@gmail.com> wrote:
i think you can feel the difference while running interpreter. With JIT it makes little sense to have special selectors imo.
There are two advantages. Space; special selectors encode a message send in 1 byte, instead of 1 byte for the send bytecode + 4 bytes for the literal selector. Optimization; the JIT (as does the interpreter) inlines +,-,*,/ etc for SmallInteger and then does even more inlining for
,<,>=,<=,== when they're followed by a jump.
As far as space goes, now that the system is 32-bit, and especially if it is 64-bit there is an opportunity to add 256 special selectors and use a two-byte special selector bytecode, 2 < 1 + 4. VisualWorks does this. There are problems though; over time the most statically frequent selectors can change as the library changes (e.g. blockCopy: is no longer used).
On 4 September 2013 12:31, Nicolas Cellier < nicolas.cellier.aka.nice@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.denker@inria.fr>
On Sep 4, 2013, at 12:08 AM, Nicolas Cellier < nicolas.cellier.aka.nice@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.
-- best, Eliot