Re: break down of differences between interpreters?

On Sun, May 06, 2012 at 08:13:26PM +0900, ruby gem wrote:
> All I can ever find is performance comparisons, but it must be more than
> just this or else why wouldn't everyone use Jruby? Would someone who
> knows layout the differences between the major interpreters? Why
> shouldn't I always use Jruby considering it has so much better
> performance? What are the advantages and disadvantages of each
> interpreter?

In addition to the points Peter Hickman made, there are other things to
keep in mind as well:

* Better performance on microbenchmarks generally does not tell the whole
  performance story.  Some other implementations may be faster at some
  things.

* The JRE takes a while to spin up when starting a new process.  That
  means that for small programs that are occasionally run briefly to
  accomplish very small tasks, JRuby can actually be much slower than
  other implementations.

* In some cases, it is easier to get another implementation installed in
  your target deployment environment.

* Licensing concerns may come into play.  Rubinius, MIR/YARV, and
  (surprisingly) IronRuby are all distributed under more permissive
  licenses than JRuby these days.  This might turn out to be important
  for some deployment scenarios.

* The fact the JRE is tied to Oracle now, and Oracle has been going
  around rattling its litigation saber at anyone dealing with alternate
  Java implementations makes a lot of people wary about using the JRE
  where it is not strictly necessary.

* Rubyists in general tend to target MRI/YARV first and foremost, and
  other implementations are often treated as second-class citizens for
  purposes of compatibility testing.  My impression is that Rubinius will
  have the least problem with this long-term, because it will probably be
  the closest thing to MRI/YARV for purposes of compatibility.  JRuby is
  an apple that falls rather farther from the tree than that.

I make no judgments in this email about any of the above points; I'm just
explaining some reasons people might have for using other Ruby
implementations.  I'm sure someone could come up with some other reasons
one might want to choose a different Ruby implementation, too.  The
upshot is that performance benchmarks are not everything.

(By the way, with the number of Ruby implementations out there, I may
have overlooked something that would change some of the specifics of
things I said here.  I think the general message is pretty accurate,
though, regardless.)

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]