Comparison of Nine Ruby Implementations

An anonymous reader writes "Zen and the Art of Programming published a new version of The Great Ruby Shootout, which was aimed at testing the performances of multiple Ruby implementations. On the benchmark table this time around are Ruby 1.8 (on GNU/Linux and Windows), Ruby 1.9 (aka Yarv), Ruby Enterprise Edition (aka REE), JRuby 1.1.6RC1, Rubinius, MagLev, MacRuby 0.3 and IronRuby. The results of this comprehensive comparison show that for this set of benchmarks, Ruby 1.9.1 is almost 5 times faster than the notoriously slow Ruby 1.8. Is Ruby finally going to be acceptably fast?"

Comments

Ruby 1.9.1 and JRuby

[mgkimsal2]

Ruby 1.9.1 and JRuby seem to be the 'winners' in most tests. Have a look at the PNG here: http://antoniocangiano.com/images/shootout3/main_time.png

I've heard a lot of good things about the JRuby project, and this test seems to demonstrate that it's probably the closest in terms of speed to the standard Ruby (canonical Ruby?)

Re:Ruby 1.9.1 and JRuby

[Foofoobar]

Well JRuby is an implementation of Ruby in Java which explains the speed but it is still quite slow as it has to 'interpret' everything into java. If you are a fan of Java and like Ruby, I'd suggest Groovy. It's blazingly fast and even puts these to shame. Plus works well Rails, Struts and most MVC frameworks.

Re:Ruby 1.9.1 and JRuby

[Foofoobar]

Um... I suffer from a rare disease known as sig blindness. :)

Re:Ruby 1.9.1 and JRuby

[K. S. Kyosuke]

"Ultimately what I want is an interpreted language that can be compiled. So for example, in python one rarely actually uses the introspective ability to modify ones self, or even takes advantage of duck typing. instead one usually calls functions with the same type arguments and so forth. So if one just had the ability to switch off the dynamic typing and self-modifying capabilities so that one could compile it it sure would be one sweet language."

I felt a great disturbance in the Force, as if millions of Common Lisp hackers suddenly cried out in terror and were suddenly silenced...

No Parrot?

[Ed Avis]

Is there a reason why they did not test Cardinal, the Ruby implementation for Parrot? I know it is not production-ready yet but it would be interesting to see how performance compares.

JRuby is the clear winner

[0xABADC0DA]

Look at how many 0.002 and similar instantaneous results there are. Tests were run 5 times and the best result used, so there probably wasn't even a single garbage collect that happened in many of the tests. You can't really say from such short benchmarks, but those tests probably did not include Java's strength of hotspot optimization over time.

There were a couple tests that were much slower in JRuby, but this is countered by the test that failed on Ruby 1.9.1; fast means nothing when you don't finish.

Re:JRuby is the clear winner

[JesseMcDonald]

There were a couple tests that were much slower in JRuby, but this is countered by the test that failed on Ruby 1.9.1; fast means nothing when you don't finish.

Ruby 1.9.1 failed two tests; JRuby failed three.

None of the VMs managed to complete all the tests. Other than Rubinius, which timed out frequently, Ruby 1.9.1 had the fewest errors.

Also, the input sizes for many of the tests numbered in the millions. If that's not enough repetition to take advantage of hotspot optimization, then I'd say they were right to exclude it.

Platform-based Ruby

[tcopeland]

I heard Rich Kilmer talk about the various Ruby implementations once; his take on them were that each would be used to leverage the underlying platform. In other words, if you want to use Java libraries, you'll use JRuby. If you want to use the Mac libraries (e.g., via Hot Cocoa), you'll use MacRuby. And if you want to use C extensions like RMagick and libxml2, you'll use MRI.

I thought that was an interesting way of looking at the various implementations... each one would be appropriate for a different scenario.

Re:Ruby gets faster while Python gets slower?

[setagllib]

It's true that JRuby has no overall GIL, but it definitely has plenty of internal fine-grained locks to maintain consistency and determinism. However thanks to Java 6 optimisations, almost all of those locks are completely elided while running a single-threaded program. That's just another way JRuby benefits from JVM technology, and yet another thing a C implementation cannot reasonably implement.