[Vm-dev] Making a Slower VM
bert at freudenbergs.de
Sun Feb 9 14:08:47 UTC 2014
On 09.02.2014, at 05:37, Sean P. DeNigris <sean at clipperadams.com> wrote:
> We often talk about making the VM faster. How about making it slower? In
> 1980, there were some optimizations that were needed for Smalltalk to be
> even usable, but now:
> - Moore's Law has theoretically given us 131072 more computing power
> - Cog runs up to 3x slower than C 
> - Ruby, which is widely accepted, seems to be much slower than Cog 
> For example, inlined functions can be baffling for new users. I just ran
> into this myself when writing an #ifNil:ifNotNil: that was not picked up by
> the system , and Ungar and Smith describe several cases in the History of
> Self (pg. 9-5).
> How many of these are premature optimizations that can be eliminated, or at
> least turned off by default until they're actually needed? I know Clement
> mentioned in  that some make a big difference, but it would certainly
> make the system more uniform and easy to understand.
This is not a VM problem. The compiler is doing the inlining, not the VM. The VM just executes what it is told to.
If the VM encounters an #ifNil:ifNotNil: send, it will faithfully do a method lookup and execute that. It will even do that if it sees an #ifTrue:. There is no short-circuiting of actual message sends in the VM.
What *does* happen is that the Compiler replaces an #ifNil:ifNotNil: send with "== nil ifTrue:ifFalse:" and then compiles the latter into jump bytecodes. That means the VM never sees the original #ifNil:ifNotNil: message.
It is pretty simple to turn off the Compiler's inlining of ifNil:ifNotNil:. It should also be pretty simple to make ifTrue:/ifFalse: be actual message sends, although I would expect a pretty big slow down since it will need real blocks. But at least their Smalltalk implementation is "executable". It's harder for whileTrue:/whileFalse: because if you wanted to implement them with real messages you would need tail call optimization, which Smalltalk VMs don't ususally do. Hence the implementation in the image that relies on compiler inlining.
- Bert -
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4142 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140209/12a7a8ef/smime.bin
More information about the Vm-dev