26

If I am using Ruby on Rails, should I install MRI/YARV Ruby or JRuby? Which is faster?

Andrew Grimm
  • 78,473
  • 57
  • 200
  • 338
ses
  • 13,174
  • 31
  • 123
  • 226

6 Answers6

26

Recent benchmarks put JRuby in the lead, followed by MagLev, Rubinius, then MRI.

Benchmarking is tricky. The Ruby Benchmark Suite is what most use to benchmark Ruby. If you remove any benchmarks that fail across any implementation, you get the following graph.

RBS

Notice I used the geometric mean. This is a better indicator of average performance as it normalizes outliers and machine specs.

The best benchmark you can run will be specific to your app. If you are looking for overall performance, you'll likely want to use real threads, so Rubinius or JRuby are your only real choices.

Also, each implementation is fast at different things. MRI is very fast at starting up, so it's good for scripts. For longer-running applications (like a web application) Rubinius or JRuby will generally perform better than MRI.

jc00ke
  • 2,435
  • 1
  • 21
  • 14
  • 1
    A remark Headius (I think) made in one of his talks is meaningful. JRuby could just stay as-is and performance would still increase just because of improvements made to the JVM. And they also get many of the best garbage collection algorithms for free. Like Java or not, there are a lot of very smart people working on the JVM. – mrbrdo Oct 03 '13 at 16:04
  • Totally, and the same could be said for Rubinius from improvements to the VM and to LLVM. Exciting times! – jc00ke Dec 06 '13 at 00:58
  • +1 for using a geometric mean. I looked up geometric mean on wikipedia and it really is an amazing way to reduce dimensionality. – seo Jul 03 '14 at 17:44
23

The answer depends on many variables.

But in general, Ruby 1.9 is faster than JRuby, but Ruby 1.8 is slower than JRuby.

e.g. according to the Computer Language Benchmarks Game:

Also, if your application is multi-threaded, JRuby may have some advantages over standard Ruby
(a.k.a. MRI)], depending on how many cores you have.

Community
  • 1
  • 1
Mikel
  • 24,855
  • 8
  • 65
  • 66
  • 2
    ruby 1.9 supports *concurrency* but not *parallelism*. If you want parallelism your two options are jruby and rubinius. – Vlad the Impala Jan 13 '14 at 19:24
  • The most important variable it depends on is the version. You didn't list a version of JRuby. These benchmarks change all the time as improvements are made. – bridiver Jan 15 '15 at 16:37
  • My answer was about Ruby 1.8 versus Ruby 1.9 almost four years ago. Ruby 1.8 was end of lifed in 2013. Of course you should retest. And of course the answer depends on your workload. – Mikel Jan 16 '15 at 05:02
3

Actually the answer above is not correct except mikel's answer ,if you observed any benchmark for JVM you'll find it's slow so imagine JRuby's performance compared to CRuby.

Personally I'm an MRI Ruby contributor and I think that the benchmark chart above is not true at all since the introduction of the YARV VM of MRI Ruby , this version became the fastest outthere and lots of benchmarks proved so "See Pat Shaughnessy's benchmarking and comments about the three famous Ruby interpreters MRI Ruby , JRuby and Rubinius". So in my opinion there is no point of comparison due to the following logical points:-

1- C is much faster than Java because it operates directly on Hardware and produces machine code. While JVM produces Bytecode which is considered intermediate code.

2- JRuby contains an additional interpretation step unlike MRI Ruby " Tokenization , Parsing , AST Parsing and generating YARV instructions "Code generation" and finally Code execution" While JRuby contains an additional stage.

3- Garbage collection in MRI Ruby is a lot faster than garbage collection in JRuby even it got better when they introduced some changes in the mark and sweep garbage collection technique.

4- If you surfed most of the companies and technologies used they always used MRI Ruby particularly ruby 1.9 , I rarely saw a company using JRuby or even saw lots of extensions or contributions to it unlike MRI Ruby.

Finally Ruby 1.8 yes it's slower because they were executing code on the AST itself so they used to parse the AST multiple times in order to execute the code.

If I'm wrong at anything I hope anyone corrects me.

Install MRI Ruby dude using RVM or from source. You'll find lots of gems and extensions to work with

user3719235
  • 47
  • 2
  • 2
    1. JVM compiles the hottest methods to native machine code. It does profiled optimizations which allows it to agressively inline. If your C compiler makes the wrong choice then JVM ends up being faster than C. Typically barring String performance JVM and C end up being pretty close in terms of speed. – Thomas Enebo Jun 16 '14 at 18:15
  • 1
    Crud sorry I did not mean to end at 1 :) 2. JRuby and MRI both have an extra step after AST generation. in JRuby 9000 that last step is broken into substeps but is still basically the same. 3. GC in MRI is definitely not faster than ANY of Java's GCs. I have never ever seen anyone even make this claim before. 4. Most companies do in fact use MRI over JRuby. Most people we talk to who switch from MRI do it because of poor GC and moving to multi-threading ends up being a huge win. Most of our users effectively use us once MRI can no longer scale for their app. – Thomas Enebo Jun 16 '14 at 18:19
  • Actually you're claiming that GC in MRI is slower than JRuby because " Someone didn't agree with my opinion " Actually I'm speaking about versions higher than 1.9 the GC in MRI became better than that in JRuby. And believe me MRI is even expanding more than JRuby. Wait for JIT "Just in time" compilation :). – user3719235 Jun 17 '14 at 19:10
  • And MRI doesn't have an extra step in AST generation. The steps exactly in JRuby Ruby->Tokenizaion->Parsing->Code generation (Java byte code)-> machine language code. The step of converting to native code in Java is much slower than in MRI. Believe me Java is a slow language :). – user3719235 Jun 17 '14 at 19:19
  • I am claiming GC in MRI is slower because I have been talking to users of both MRI and JRuby for over 13 years and I have never ever seen anyone make this claim? MRI's GC even with 2.1 rbgenc is not even close to any GC available on the JVM. If you just print out time spent in GC using MRI API and using JVM GC profiling tools it is not a controversial opinion. Ask Koichi Sasada if he agrees. As to your second comment I agree the warmup time for JRuby and JVM is longer (I will even give you much longer) than in MRI. The code the JVM generates is very fast though. – Thomas Enebo Jun 23 '14 at 15:51
  • Modern JVM's can run well-written Java code very fast - comparable to well-written C, so point 1 is not necessarily true. Unfortunately this still require quite a bit of warm up time before getting there :-/ – Thorbjørn Ravn Andersen Dec 29 '15 at 03:47
2

Many users answered already in regards to the benchmarks. Your question is specifically for the usage with Rails.

I find it unusual as I don't see clearly the goal of the question. There are many out there using MRI and many using JRuby and many others. I'd go for stability and security and maintainability in that respect, not speed.

However, there is an important difference between MRI and JRuby.

MRI uses a GIL. This means, although you can have multiple threads, only one thread can be active at a time. Also implementation of threads can differ in different Ruby versions. Newer versions use OS threads (good step forward), older versions use green threads instead.

There is no real parallelism in MRI.

MRI is multi-threaded, not thread safe and not parallel.

JRuby is multi-threaded, not thread safe and parallel.

Parallelism can make a difference in speed. Both are not thread safe, so you will have to take care of that anyway. If you look for speed and can exploit parallelism, then I would give JRuby a definite Yes.

Again, I am not sure if speed is the most important factor when deciding between MRI and JRuby. It is the ecosystem. Since you asked for speed I won't get into this any further.

Ely
  • 10,860
  • 4
  • 43
  • 64
2

Honestly, it depends on your code. Install RVM or Pik on your machine, install a bunch of different versions of ruby, and try running your code in them.

For example: An application that frequently restarts is not a great candidate for JRuby since JRuby has some ramp-up time before Hotspot is able to effectively optimize your code. Likewise, an application that relies on threads is not a great candidate for Ruby 1.8.7 since Ruby 1.8.X cannot utilize more than 1 core on your processor and thus cannot execute on more than one thread at a time.

PatrickTulskie
  • 971
  • 1
  • 5
  • 4
2

There's a really great article done by the guys over at programmingzen.com that compares a lot of the different flavours of ruby. Was published in July last year so still reasonably recent ;) There page compares these:

* Ruby 1.8.7 p299
* Ruby 1.9.1 p378
* Ruby 1.9.2 RC2
* IronRuby 1.0 (Mono 2.4.4)
* JRuby 1.5.1 (Java HotSpot(TM) 64-Bit Server VM 1.6.0_20)
* MagLev (rev 23832)
* Ruby Enterprise Edition 2010.02
* Rubinius 1.0.1

Might be able to find what you're looking for there

http://programmingzen.com/2010/07/19/the-great-ruby-shootout-july-2010/

2potatocakes
  • 2,240
  • 15
  • 20
  • 1) Those are no longer the latest versions. 2) Unfortunately many of the measurements are excluded from the summaries because one implementation timed out or had an error - that removes 10 out of 30. – igouy Feb 07 '11 at 19:00
  • thanks igouy.. trying to answer users question, thought it was a pretty good indication and what to expect. You can read the article how you like but I would have thought any timeouts and errors should definately be published when doing comparisons like these..? – 2potatocakes Feb 08 '11 at 22:00
  • >>but I would have thought<< Instead of guessing, I asked the author of the article - "which data made it into the summary – just data from rows which had no timeout or error?" and he answered "Yes." Read the comments. – igouy Feb 11 '11 at 19:10