Robert Klemme wrote:
> I'm not sure whether you read Charles excellent posting about the
> properties of a VM. All optimizations you mention are *static*, which
> is reflected in the fact that they are based on statistical
> information of a large set of applications, i.e. there is basically
> just one application that those optimizations can target. A VM on the
> other hand (and this is especially true for the JVM) has more precise
> information about the current application's behavior and thus can
> target optimizations better.
So, in fact, does a CISC chip with millions of transistors at its
disposal. :) Real machines are pretty smart too, at least the ones from
Intel are. The point of my comment was the emphasis on *statistical*
properties of applications. Since this is the area I've spent quite a
bit of time in, it's a more natural approach to me than, say, the
niceties of discrete math required to design an optimizing compiler or
interpreter.

In the end, most of the "interesting" discrete math problems in
optimization are either totally unsolvable or NP complete, and you end
up making statistical / probabalistic compromises anyhow. You end up
solving problems you *can* solve for people who behave reasonably
rationally, and you try to design your hardware, OS, compilers,
interpreters and languages so rational behavior is rewarded with
*satisfactory* performance, not necessarily optimal performance. And you
try to design so that irrational behavior is detected and prevented from
injuring the rational people.
>
> I'll try an example: consider method inlining. With C++ you can have
> methods inlined at compile time. This will lead to code bloat and the
> developer will have to decide which methods he wants inlined.  This
> takes time, because he has to do tests and profile the application.
> Even then it might be that his tests do not reflect the production
> behavior due to some error in the setup of wrong assumptions about the
> data to be processed etc. In the worst case method inlining can have
> an adversary effect on performance due to the increases size of the
> memory image.
Not to mention what happens with the "tiny" caches most of today's
machines have.
> A VM on the other hand profiles the running application and decides
> *then* which hot spots to optimize.  Even more so it can undo
> optimizations later if the behavior changes over time or new classes
> are loaded that change the game.  It has more accurate information
> about the application at hand and thus can react / optimize more
> appropriately.  The point is that there is not the single optimal
> optimization for a piece of code.  And a VM can do much, much better
> at picking this optimum than any compiled language can just because of
> the more accurate set of information it has about a running
> application.
>
> Another advantage of a VM is that it makes instrumentation of code
> much easier. Current JVM's have a sophisticated API that provides
> runtime statistical data to analysis tools. With compiled applications
> you typically have to compile for instrumentation. So you're
> effectively profiling a different application (although the overhead
> may be neglectible).
Don't get me wrong, the Sun *Intel x86* JVM is a marvelous piece of
software engineering. Considering how many person-years of tweaking it's
had, that's not surprising. But the *original* goal of Java and the
reason for using a VM was "write once, run anywhere". "Anywhere" no
longer includes the Alpha, and may have *never* included the MIPS or
HP-PARISC. IIRC "anywhere" no longer includes MacOS. And since I've
never tested it, I don't know for a fact that the Solaris/SPARC version
of the JVM is as highly tuned as the Intel one.

To bring this back to Ruby, my recommendations stand:

1. Focus on building a smart(er) interpreter rather than an extra
virtual machine layer.
2. Focus optimizations on the Intel x68 and x86-64 architectures for the
"community" projects. Leverage off of GCC for *all* platforms; i.e.,
don't use Microsoft's compilers on Windows. And don't be afraid of a
little assembler code. It works for Linux, it works for ATLAS
(Automatically Tuned Linear Algebra Subroutines) and I suspect there's
some in the Sun JVM.
3. Focus on Windows, Linux and MacOS for complete Ruby environments for
the "community" projects.

-- 
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com