Ruby Implementation Shootout

An anonymous reader writes "Ruby has an ever growing number of alternative implementations, and many of these attempt to improve the suboptimal performance of the current mainstream interpreter. Antonio Cangiano has an interesting article in which he benchmarks a few of the most popular Ruby implementations, including Yarv (the heart of Ruby 2.0), JRuby, Ruby.NET, Rubinius and Cardinal (Ruby on Parrot). Numerical evidence is provided rather than shear opinions. The tests show that Yarv is the fastest implementation and that it offers a promising future when it comes to the speed of the next Ruby version."

Read the disclaimer...

[tcdk]

This being /. I don't expect anybody to actually read the acticel, but before you begin your rant^H^H^H^H ... post about how these tests are useless etc. etc. please, at least read the article disclaimer:

Don't read too much into this and don't draw any final conclusions. Each of these exciting projects have their own reason for being, as well as different pros and cons, which are not considered in this post. They each have a different level of stability and completeness. Furthermore, some of them haven't been optimized for speed yet. Take this post for what it is: an interesting experiment;

Now fell free to begin your rant about it being a slow news day...

Java not slow enough for you? Try Ruby!

[Jagasian]

Performance isn't everything, but then again, when you are 400 times slower than Java [debian.org]... performance starts to matter.

Re:Cardinal interesting

[archen]

Personally what annoys me more is that this is giving me no benchmark against how ruby in general is performing. Maybe something is twice as fast, but twice as fast as what? Slow as hell? My understanding is that ruby has always lagged a bit in the performance sector, although maybe that has improved over the last 2 years. I'd be more interested to see additional benchmarks against equivalent programs in Perl5 which is sort of the interpreter execution standard, or maybe something in C.

Any YARV experts

[Timesprout]

Can anyone comment on why the YARV implementation is so much faster than the standard implementation? I know for example the SUN VM was originally only intended as a reference VM and faster implementations were developed but not on the scale of the differences highlighted here.

Re:so... ruby?

[Anonymous Coward]

Ruby on Rails and is said to be an incredibly well-thought and efficient framework.

Well thought of is debatable as RoR is an "opinionated software": if you don't like the way DHH (the framework's creator) works you're going down fast.

Efficient, no damn way, Rails itself is not really fast and it's implemented on top of a very slow language (Ruby), unless you're talking about programmer time Rails is not efficient at all, and in the programmer-time-efficiency land it has a lot of competition (e.g. Django in Python-lang).

Other than that, Ruby's a nice language, takes many features from Smalltalk and makes them easier to use, I think it could be a nice stepping stone:

• from a statically typed language (Java) to the land of dynamically typed fully OO languages
• From anywhere to Smalltalk, as smalltalk would be fairly alien to anyone using "mainstream" languages (including but not limited to C, C++, Java, C#, Python, Visual Basic, PHP, ...)

Re:Java not slow enough for you? Try Ruby!

[arevos]

Performance isn't everything, but then again, when you are 400 times slower than Java... performance starts to matter.

Sure, if you're interested in generating mandelbrot fractals or the spectral norm of a matrix. However, Ruby typically isn't used for such computationally intensive tasks.

Re:Any YARV experts

[mo]

The standard 1.8.X Ruby interpreter is a single-pass interpreter, and YARV is a virtual machine implementation. You can expect big improvements when moving to a VM implementation from an interpeter. The reason Java has never had such big improvements is that it's always been based on a VM.

This rule isn't exactly hard and fast, as verying implementations of VMs and interpreters can have different performance characteristics. For example, while perl is still probably considered an interpreted language, it's quite fast due to the interpreter using many compiler tricks such as parse tree optimizations. The ruby interpreter however has been notoriously slow, which is why ruby people are so excited about it.

Re:so... ruby?

[Stamen]

Minor note, Ruby on Rails is the web development flavor of the month, not ruby. There are a lot of interesting things happening in plain ole ruby, plus there are other web frameworks than Ruby on Rails, such as Nitro, Camping, etc.

I find it amusing someone would say learn Python because it's used more. Python may be older, but it's still sitting in the programming language high chair right next to Ruby. People say the same thing about Python; "if you want a job learn Java, c#, c++"; and you know what they're right, if you want a job learn Java, period.

I like both Ruby and Python, and I think a programmer would do well to learn one or both. They aren't as popular yet, like Java or c#, but I think they will be. And if you understand the concepts in one, you'll understand the other. Like Gretzky said, "I skate where the puck is going to be, not where it is"; good advice.

I prefer Ruby, but that is just a preference.

Re:so... ruby?

[Anonymous Coward]

Don't be such a pure functional twit. A little 'state'-ment at the top of the page about how Ruby is an OO scripting language/interpreter of the curly-brace variety hailing from Japan would be nice. You may find state offensive, but it can save time.

Re:Java not slow enough for you? Try Ruby!

[TopSpin]

Performance isn't everything, but then again, when you are 400 times slower than Java..

400 times slower? Still too efficient. Consider a Ruby implementation on the JVM and multiply inefficiencies! Should be thousands of times slower for those same benchmarks.

About JRuby; Sun recently hired [slashdot.org] two (both?) of the JRuby developers and progress has accelerated [codehaus.org]. The promise is a highly capable Ruby implementation running on a JVM. This, coupled with very recent changes to the JVM [artima.com] to facilitate scripting languages could lead to an interesting future. Sun is also leveraging the JVM for other language projects such as Fortress [sunsource.net].

Apparently Sun isn't content to let Microsoft's CLR become the de facto standard bytecode runtime platform. I don't know whether it's possible to make Ruby performance on the JVM competitive with native implementations, but I am hoping.

Re:Ruby's Windows support

[Anonymous Coward]

I think this is just because of the age of the language, as the same was true for Perl and others when they were young.

Ruby has been around for 12 years. It's only 7 years younger than Perl, and just 4 years younger than Python.

Perl, for one, acquired decent Windows support in the late 1990s... at a time when it was younger than Ruby is today.

Re:Ruby's Windows support

[shmlco]

"As Ruby matures, so will things like performance and secondary OS support."

And when will that happen, exactly? I've been hearing about R/RoR for years now, and it's still distinctly in the low-performance category. Yet every time I go visit the site for updates all I see is talk about how they're adding feature X and Y in the next point release.

These guys need to stop dinking with the language, freeze it, and work on fixing bugs and increasing performance so people out here in the real world can actually use it.

Unfortunately, like most OSS projects it seems that it's cooler to add the feature-of-the-day, rather than do the actual work needed to make it a stable and solid development platform...

Re:Ruby's Windows support

[chromatic]

I think this is just because of the age of the language, as the same was true for Perl and others when they were young.

Ruby's almost 14 years old! By 2001, Perl had fantastic Windows support.

Now people may deploy Ruby or Perl or Python or PHP applications to Unix and Unix-like servers, but I know plenty of people who develop on Windows. Some of them even have a choice.

Re:Why not use C

[FrnkMit]

I worked briefly at a shop that used C and C++ for CGI. They were still struggling with memory errors in their in-house string libraries.

But really, Ruby's for more than just Web stuff. (As is Python and the rest.)

Re:Java not slow enough for you? Try Ruby!

[Rufty]

Yep, I agree. Ruby's slow. Probably slower than the rest at just about everything.
Except speed of code development.
So for my one-off scripts that run for 45s in ruby instead of 0.1s in perl, well
what's mattered to me is that it took 5 mins to write, rather than the 90mins +
a brain tumor that perl does*

* I last used perl at about 4.036, tried to get into "objects" with perl 5, and
jumped to ruby for the sake of my sanity.