From: Charles Oliver Nutter <charles.nutter@...>
Date: 2008-12-05T09:56:19+09:00
Subject: [ruby-core:20344] Re: Behavior: autoload calls rb_require() directly

Michael Selig wrote:
> Not being a "compiled to machine code" language, it seems impossible to 
> me that operations like Fixnum#+ will ever have "C-like performance". 
> But is is a nice goal I guess :)

JRuby, via the JVM, already does compile Ruby to machine code. The JVM 
takes the bytecode we generate and JIT compiles it into real machine 
code, inlining a significant amount of logic and optimizing everything 
together. I can certainly show you what the assembly looks like, if 
you're interested. Currently there's a few things we *don't* do that 
will make this JITing even more effective in the future:

* We don't have any special logic to optionally treat Fixnums as normal 
primitive ints under controlled conditions. Doing so would allow the JVM 
to JIT it straight down to optimized machine-level math operations.
* We don't make it possible to inline across dynamic calls. Doing so 
would allow many levels of calls in Ruby to be inlined together and 
optimized as a whole.

The optimizations that result from inlining include array boundscheck 
eliminations, escape analysis to eliminate object allocation cost, loop 
unrolling and elimination, and a lot more.

All these optimizations are predicated on arriving at a static view of 
the world at some point during execution. The ability to redefine 
Fixnum#+, for example, means that we'll always need (at minimum) a guard 
against + being overridden. If it's possible to eliminate the need for 
those guards, our the potential for a static worldview expands, the 
generated code gets smaller, and performance increases.

We plan to add both of the above changes in upcoming versions of JRuby, 
with all the appropriate guards in place to allow Ruby to remain Ruby. 
But I think it's useful to know what you sacrifice by having an 
infinitely mutable set of core classes.

> However there are other ways to achieve this sort of thing, by providing 
> higher-level specialized classes (like Matrix) which are (or could be) 
> coded in C. Such libraries can be used by, for example, numerical 
> analysis applications to (hopefully) provide the speed required.
> 
> IMHO for most Ruby applications, not doing things like numerical 
> analysis, it doesn't matter all that much if Fixnum#+ et al. don't have 
> "C-like performance".

Certainly true. But it would be nice if you could get that performance 
when you need it.

- Charlie