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

[Alexander Turner]

Charlse,

I would not worry too much either. Tracing VMs usually do very will on
micro and small benchmarks. The time to worry is if the same difference
persist when running real world code.

All the best - AJ


On 9 February 2013 17:19, Charles Oliver Nutter <headius at headius.com> wrote:

> 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
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20130209/fb5045f7/attachment.html