Well, #class slot is not really available because the trick is hardcoded in
the VM as well as == trick, so no lookup in specialSelectors
(specailObjectsArray at: 24) is attempted for these 2.
COG also optimize some arithmetic messages, comparisons, bit ops, and all
is hardcoded in the VM, so better not playing with those indices.
So I tried to just replace #blockCopy: 1 with #not 0, ran some tests but
saw no significative speed up.
Then I tried to run Kernel tests twice in a unmodified 3.0 image
[(Smalltalk allClasses
select: [:e | (e category beginsWith: 'KernelTests')
and: [e inheritsFrom: TestCase]])
do: [:e | e suite run]] timeToRun.
113342 114337
Then optimized the mosttly sent message during tests :
IRByteCodeGenerator>>specialSelectorsArray
^ #(#+ 1 #- 1 #< 1 #> 1 #<= 1 #>= 1 #= 1 #~= 1 #* 1 #/ 1 #\\ 1 #@ 1
#bitShift: 1 #// 1 #bitAnd: 1 #bitOr: 1 #at: 1 #at:put: 2 #size 0 #next 0
#nextPut: 1 #atEnd 0 #== 1 nil 0 #assert: 1 #value 0 #value: 1 #do: 1 #new
0 #new: 1 #x 0 #y 0)
Recompiled all:
IRBytecodeGenerator initializeSpecialSelectors.
Smalltalk specialObjectsArray at: 24 put: IRBytecodeGenerator
specialSelectorsArray.
OpalCompiler recompileAll.
Then tried the tests twice again:
[(Smalltalk allClasses
select: [:e | (e category beginsWith: 'KernelTests')
and: [e inheritsFrom: TestCase]])
do: [:e | e suite run]] timeToRun.
84328 83974
So it seems like it's not just a space optimization but also a speed one,
and I don't know why...
It would be better if someone could repeat these results...
Nicolas
2013/9/4 Camillo Bruni <[email protected]>
> that would actually be interesting on how much you win by doing so, and if
> you could run this dynamically (for instance reintroduce the #class
> optimization if you never override it in the image)...
>
>
> On 2013-09-03, at 19:07, Nicolas Cellier <
> [email protected]> 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.
>
>
