New Ruby impl based on PyPy...early perf numbers ahead of JRuby

[Charles Oliver Nutter]

So, that new Ruby implementation I hinted at was announced this week.
It's called Topaz, and it's based on the RPython/PyPy toolchain.

It's still very early days, of course, since the vast majority of Ruby
core has not been implemented yet. But for the benchmarks it can run,
it usually beats JRuby + invokedynamic.

Some numbers...

Richards is 4-5x faster on Topaz than JRuby.

Red/black is a bit less than 2x faster on Topaz than the JRuby with
the old indy impl and a bit more than 2x faster than the JRuby with
the new impl.

Tak and fib are each about 10x faster on JRuby. Topaz's JIT is
probably not working right here, perhaps because the benchmarks are
deeply recursive.

Neural is a bit less than 2x faster on Topaz than on JRuby.

I had to do a lot of massaging to get these benchmarks to run due to
Topaz's very-incomplete core classes, but you can see where Topaz
could potentially give us a run for our money. In general, Topaz is
already faster than JRuby, and still implements most of the
"difficult" Ruby language features that usually hurt performance.

My current running theory for a lot of this performance is the fact
that the RPython/PyPy toolchain does a better job than Hotspot in two
areas:

* It is a tracing JIT, so I believe it's specializing code better. For
example, closures passed through a common piece of code appear to
still optimize as though they're monomorphic all the way. If we're
ever going to have closures (or lambdas) perform as well as they
should, closure-receiving methods need to be able to specialize.
* It does considerably better at escape detection than Hotspot's
current escape analysis. Topaz does *not* use tagged integers, and yet
numeric performance is easily 10x better than JRuby. This also plays
into closure performance.

Anyway, I thought I'd share these numbers, since they show we've got
more work to do to get JVM-based dynamic languages competitive with
purpose-built dynamic language VMs. I'm not really *worried* per se,
since raw language performance rarely translates into application
performance (app perf is much more heavily dependent on the
implementation of core classes, which are all Java code in JRuby and
close to irreducible, perf-wise), but I'd obviously like to see us
stay ahead of the game :-)

- Charlie