Chad Perrin wrote:
> On Mon, Sep 04, 2006 at 02:13:24AM +0900, Alex Young wrote:
>>> Speaking purely theorethically, Ruby can not be made as performant as 
>>> Java or C# could be made if they had ideally performing implementations. 
>>> Latent typing makes it almost impossible to do certain optimizations as 
>>> static typing does. That's pure fact. 
>> I remain unconvinced by this - and it's mainly JIT optimisation that 
>> keeps me on the fence.  Dynamic optimisations can beat static - but not 
>> in all cases.  I believe this is what one calls an "open research" question.
> 
> Unfortunately, JIT implementations haven't been subjected to the same
> long-term scrutiny and advancement as more traditional persistent binary
> executable compiling implementations.  As a result, I don't think the
> state of the art is there yet -- leaving JIT implementations effectively
> slower by nature until they get some more advancement over the years to
> come.  I really believe that gap will be closed rapidly in the near
> future.  Only time and experience will tell whether it can be made as
> fast or faster, though I have no doubt that it can at least be made
> close enough that most of us won't care.

In the "good old days", an assembly language programmer could turn out
code that was from 2 to 10 times as fast as that turned out by a
compiler, and a compiler could turn out code that was from 2 to 10 times
as fast as an interpreter.

The gap has narrowed. It's rare that an assembly language coder can beat
a compiler by more than a factor of 2 these days, and on some
architectures it's a dead tie -- there's only one way to do something
and the compiler always finds it. Interpreters are better now too,
mostly because today's languages have such a large component that has to
be dealt with at run time anyway that the "heavy lifting" is done by
compiled code.


I'm not sure JIT is "necessary" for efficient interpretation of Ruby
anyway. But you're right ... if the economics is there, the gap will get
closed, just like the compiler/assembler gap got closed.