MRI, Rubinius, or JRuby?

Posted on June 20, 2015

I’ve been messing around with Ruby runtimes for the past few days in an attempt to find a way to do true mulithreaded processing. I did some quick tests of the three big ones: MRI, Rubinius 2.5, and the preview of JRuby.

Well first, let me say that I find it really interesting that people still use Ruby as much as they do, even though it is generally regarded as a slower language. (Somehow Ruby gets a pass on that, but PHP doesn’t.) Anyway, my basic testing setup was an m3.medium instance on AWS. In all cases, I used RVM to install the latest version.

To start, all I wrote was a one-line Ruby command that prints ‘hello world’, and somehow that was enough to set the stage. I found that MRI outperformed by a factor of about three. Both Rubinius and JRuby were slow to start and slow to print; MRI, by comparison, did just fine.

In further testing, I ran a program I have that spins up a pool of 5 threads using Celluloid, pulls a thousand records from Mongo across the threads, processes them, and stores them on S3. MRI did this more or less linearly, but it completed under a minute. Rubinius took at least two minutes to even get started, and once the threads started processing, it was still pretty slow. With JRuby, performance was basically the same.

A side note: both Rubinius and JRuby were surprisingly hard to set up. It was a tedious process to install another set of packages, run the install, and see if it fails again. Even with RVM – which was a lifesaver – it was a pain.

So I guess I’m stuck for now. I need to do some research to see why people say that Rubinius and JRuby do so well. Maybe I misconfigured something, but if it is, I don’t know what it is right now.

One response to “MRI, Rubinius, or JRuby?”

  1. Franklin Yu says:

    I have got the same confusion. I did my test on my OS X 10.10, where Rubinius 2.5.8 (running in 2.1.0 mode) is greatly slower than MRI 2.0.0 pre-installed on the system, not to mention latest MRI 2.2.3. Almost everybody claims that Rubinius is the choice for server; they value its parallelism and LLVM. I am not sure whether there is a switch for multi-threading, or my Ruby test codes do not favor Rubinius, but both reasons seem week. Since my App is not going to be CPU-bound, I guess the Global Interpreter Lock does not mean that much to me, so I will currently stay with MRI. (I/O is multithreaded by Puma.)

Leave a Reply

Your email address will not be published. Required fields are marked *