From: Chad Perrin Date: 2012-05-07T01:20:14+09:00 Subject: 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 ]