Do you also have startup performance metrics - I assume the numbers below are about peak performance?
What is the approximate % of language feature completeness of Topaz and do you think this aspect is relevant when comparing performance? Thanks, thomas Charles Oliver Nutter <head...@headius.com> hat geschrieben: 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@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
