[Vm-dev] Making a Slower VM

Clément Bera bera.clement at gmail.com
Sun Feb 9 10:07:15 UTC 2014


Hello Sean,

That's true that the ruby interpreter and CPython are around 20x slower
that Cog. Now the use cases are different.

Firstly, their tool suite is not written in ruby/python so they do not need
speed to have a good IDE. For example, see the new SqueakJS VM, as it is
slower Morphic is hardly usable, therefore they had to fall back on the old
and fast MVC UI. We do not want to have to do that in Pharo/Squeak.

In addition, Ruby/python work well due to their good integration with C,
because a ruby/python programmer needs to bind its performance critical
methods to C methods. In most cases, we do not bing performance critical
method in Pharo/Squeak with C method because we don't need to, and I don't
think we want to do that.

So I wouldn't say that we can have pharo/squeak running 20x slower and
still be happy.

One thing that you didn't mention is the Stack VM. This interpreter based
VM is less efficient than Cog (2x-10x slower) but much more flexible IMO.
For example, overriding each message send interpretation or adding new byte
codes is quite easy. So somehow we have already a slower VM more flexible.

In addition, the Opal's compiler options allows to disable some optimized
constructs as you mention, but this is static infos with pragmas.

Disabling conditions inlining would decrease by 2.5x the performance of
Pharo/Squeak according to Urs hozle phd, but recent attempts showed that
the speed problem is even worst due to the fact the kernel was optimized
knowing these constructs where inlined.

*Solution for this problem*

As you may have seen, in the Self VM, they do not have these optimized
constructs but not because they are slower but because they have an
adaptive recompiler. Currently I am working with Eliot on speculative
inlining and different optimizations for the Cog. You can see a description
of the project here:
http://clementbera.wordpress.com/2014/01/09/the-sista-chronicles-i-an-introduction-to-adaptive-recompilation/.
I wrote that article quickly so there might be some typos and English
errors but the overall should be OK. This is a big project, so we will have
a production ready result in several months, perhaps even in a few years.

This will allow to both increase Cog's performance and reduce the code
complexity due to optimizations with inlined constructs.

Precise solutions needs to be discussed and benchmarked, be we could have,
as their performance impact will be lowered:
- ifNil:/ifNotNil: not inlined.
- all the specific messages as regular message sends in all cases
(including #==): #(#+ 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 #blockCopy: 1 #value 0 #value: 1
#do: 1 #new 0 #new: 1 #x 0 #y 0)

Loops methods (whileTrue:, to:do:) are usually not a problem, the only
constraint is that you cannot override these 4 methods:
(SmallInteger>>to:do:, SmallInteger>>to:by:do:, BlockClosure>>#whileTrue:,
BlockClosure>>#whileFalse) but you can override these selectors in your
objects. If you want to override one of these methods, there's no simple
solution without performance cost (one solution is to rewrite them as
primitive and stop inlining them in the compiler but even there we'll have
some performance cost that needs to be checked.

ifTrue:ifFalse: is the most complex case. I know Eliot has a plan for it.
You can look at the video at the bottom of the sista article where in the
end Eliot explains AoSta (the ancestor of sista) and he mentions somethings
about mustBeBoolean.

Best,

Clément



2014-02-09 5:37 GMT+01:00 Sean P. DeNigris <sean at clipperadams.com>:

>
> 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
> (2^((2014-1980)/2))
> - Cog runs up to 3x slower than C [1]
> - Ruby, which is widely accepted, seems to be much slower than Cog [2]
>
> 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 [3], 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 [3] that some make a big difference, but it would certainly
> make the system more uniform and easy to understand.
>
> [1]
>
> http://lists.gforge.inria.fr/pipermail/pharo-project/2011-February/042489.html
> [2]
>
> http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=yarv&lang2=gcc
> [3] https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg11694.html
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/Making-a-Slower-VM-tp4742391.html
> Sent from the Squeak VM mailing list archive at Nabble.com.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140209/cabe6780/attachment.htm


More information about the Vm-dev mailing list