From: MikkelFJ <mikkelfj-anti-spam@...>
Date: 2002-10-17T02:44:04+09:00
Subject: Re: Psyco


"Justin Johnson" <justinj@mobiusent.com> wrote in message
news:1034783660.29726.0@demeter.uk.clara.net...

> In Ruby, the '+' is a method call on a number which could be overridden at
> anytime, any number of times.  It's impossible for a compiler to predict
> just what '+' is going to do from one moment to the next.  JIT has a
better
> chance.

First the example (3 + 4) can always be optimized because the values are
constants. For constants such as (A + B) the problem is that they are not
really constant, but that is solved with a compiler switch allowing
optimizations of constants (with error on const assignment).

Second, a "real" compiler can inspect the active scope of an expression
using time consuming reachability analysis that a Jitter can not afford to
do. Having a Jitter recompile a function for every new call would be rather
expensive and space consuming, except for very long processes (which is the
only place where a see a sensible use of Jitters), both because the compile
time is small compared to runtime, and because you can gather statistics
before starting the compilation.

> You can generate bytecode but it's not going to give that much of a speed
> increase, IMHO, because it would still have to be doing dynamic method
> lookup etc.

Bytecode can cache lookups, getting benefits similar to JIT, but not quite
JIT. Isn't this what Ruby is already doing in AST?
Also, bytecode isn't necessarily slow when representing "thick" operators
such as Array::sort, which is also why there is a limit to the benefits of
native code. Inlining and type analysis is propably a more important
optimization strategy.

Mikkel