From: Isaac Gouy <igouy2@...>
Date: 2007-08-30T03:28:47+09:00
Subject: Re: Ruby Vs. Java



On Aug 28, 5:59 pm, Charles Oliver Nutter <charles.nut...@sun.com>
wrote:
> Eliot Miranda wrote:
> > Lloyd Linklater wrote:
> >> Java's speed comes largely from its pre-compiling.  It was quite slow
> >> in the early days.  Is Ruby likely to get such a boon in the
> >> foreseeable future?  That would certainly be something that pointy
> >> haired managers could boldly hold forth in meetings for consideration.
>
> > Um, no.  Java's speed comes principally from
> > a) its non-object numeric types, and
> > b) from sophisticated VMs that do adaptive optimization (see Sun HotSpot
> > Server VM)
>
> > If by precompiling you mean compiling to bytecode then, no, this won't
> > of itself give great speed.  Java as always compiled to bytecode but the
> > early Sun reference VM - a bytecode interpreter - was still slow.  It's
> > easy to write slow bytecode interpreters.  YARV for Ruby is currently
> > also a slow bytecode interpreter.
>
> This is precisely why we've been able to get very good performance in
> JRuby. Though we still have an interpreted mode, which runs slower than
> Ruby 1.8, we also have a nearly complete Ruby-to-JVM-bytecode compiler
> that executes consistently faster than Ruby 1.8 and in some cases faster
> than Ruby 1.9. In general, the difficult task has been structuring the
> bytecode and the call pipeline in such a way as to allow HotSpot to do
> its optimization.
>
> This also means that Java and JRuby and similar adaptive optimizing
> runtimes require some "warm-up time". Java code will get faster as it
> executes, but for short benchmarks it will usually be much slower than
> its full potential. The same applies to JRuby, and as a result JRuby
> will be better for longer-running processes (unless, of course, you
> don't mind it being a little slow early on).



I'm a bit confused about what you might mean, help me understand.

Do you mean small benchmark programs will be "much slower" when run
once rather than run 100 times? How much slower - 0.1x 10x 1000x ?

Do you mean we should not assume small program performance is a
reasonable estimate of large program performance?


Incidentally, I don't think "warm-up time" works as a description of
adaptive optimization - it makes it sound like a one-time-thing,
rather than continual profiling decompilation recompilation adapting
to the current hotspot.