Hmm... my timings are not reliable, I tried again with 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 nil 0 #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. and got a fast run 84446 too without optimizing assert: so it looks just like a space optimization. 2013/9/4 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>
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 <camillobruni@gmail.com>
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 < 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.