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?
Performance is not the only issue when selecting an interpreter.
We do use Jruby in a few places, but only when Jruby provides a
feature that is too difficult in the normal version.
Why don’t we use it everywhere?
- We dont want to heft around the massive JRE
- Some gems do not work with Jruby and the alternatives are awkward
- The performance improvement isn’t that great (network and database
latency tend to overshadow everything)
Even if Jruby was consistently twice as fast as the normal interpreter
it will only amount to a < 10% improvement in the overall application
performance for the sort of apps we create.
The biggest improvements in performance for our applications come from
better algorithms and caching 
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 H. 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.)
On Sun, May 6, 2012 at 11:20 AM, Chad P. [email protected] wrote:
- 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.
This is false. JRuby is licensed under three licenses, and you can
pick whichever you want to use: GPL, LGPL, and CPL. The CPL is a more
permissive license like Apache or BSD.
- 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.
Oracle is going after one alternative Java implementation (Android,
which Google tries to sell as not being Java) largely because they
(Oracle) failed to successfully come up with a way to recreate mobile
Java and want a piece of this pie. It will likely come to almost
nothing in the courts.
Sun/Oracle has also stated a few times that Android could or could
have used OpenJDK, and they encourage forking and experimentation on
top of the GPL-based OpenJDK codebase. This isn’t a fight about the
JRE…it’s just politics and greed.
- 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.
The fact that JRuby falls far from the tree is a good thing.
Implementations dependent on C extensions are going to always have
that cross to bear, for example, dealing with badly-behaving C code,
reduced parallelism, and GC complications. JRuby + JVM language-based
extensions have no such limitations.
- Charlie
On Sun, May 6, 2012 at 6:13 AM, ruby gem [email protected] 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?
I’ll give you the reasons people tell us they choose (and do not choose)
JRuby.
Pro:
- JVM features
** Solid parallelism and concurrency libraries that have been tested
for many years
** Excellent performance through JIT and the new invokedynamic features
** The best GCs in the world
** Wide selection of libraries that are also 100% managed, and don’t
impose restrictions like C extensions do
** Portability - JRuby works on any platform where the JVM is available - Existing JVM infrastructure
- Android applications
- Large datasets (JVM handles much better than e.g. MRI)
- Straight-line performance (JRuby should generally be the fastest
when running on JRuby 1.7 + Java 7 JVM)
Con:
- Slow startup (partially JVM’s fault and partially our fault…we
continuously improve here). - C extension support (we have partial support, but it’s not being
maintained). - Process size (we are larger, but you can often do more than MRI
without needing multiple processes). - Many POSIX features from Ruby aren’t or can’t be implemented (fork,
low-level sockets, process control). - Some people just hate Java or the JVM and anything associated with
them.
We’ve never had anyone say they’re not using JRuby because our licenses.
- Charlie
On Sun, May 6, 2012 at 6:39 AM, Peter H.
[email protected] wrote:
Why don’t we use it everywhere?
- We dont want to heft around the massive JRE
I’d hardly call it hefty… a typical JRE download is from 10 to 30MB.
Even if Jruby was consistently twice as fast as the normal interpreter
it will only amount to a < 10% improvement in the overall application
performance for the sort of apps we create.The biggest improvements in performance for our applications come from
better algorithms and caching
Probably the best argument for simply writing good Ruby code rather
than hoping for an implementation to solve all your problems, eh? 
FWIW, JRuby 1.7 on Java 7 JVMs will start to show significantly
improved performance…on some real-world benchmarks I’ve tested
things are anywhere from 2-10x faster. Of course, that will maybe
amount to an 18% improvement in your overall app performance, but that
might be desirable too…
- Charlie
On 20/05/12 01:00, Charles Oliver N. wrote:
I’ll give you the reasons people tell us they choose (and do not choose) JRuby.
Pro:
** Solid parallelism and concurrency libraries that have been tested
for many years
** Excellent performance through JIT and the new invokedynamic features
- Large datasets (JVM handles much better than e.g. MRI)
- Straight-line performance (JRuby should generally be the fastest
when running on JRuby 1.7 + Java 7 JVM)
These are the reasons we have JRuby running some of our system routines
which would otherwise be runnable in any other Ruby implementation.Con:
- Process size (we are larger, but you can often do more than MRI
without needing multiple processes).- Many POSIX features from Ruby aren’t or can’t be implemented (fork,
low-level sockets, process control).
These represent frustrations we observe with running under JRuby. I’m
not a big fan of Java, but the phrase “horses for courses” comes to
mind.
Sam
On Sat, May 19, 2012 at 09:44:56PM +0900, Charles Oliver N. wrote: