From: Charles O Nutter <headius@...>
Date: 2006-07-03T05:29:25+09:00
Subject: Re: Huge performance gap

------=_Part_29474_31599846.1151872161320
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 7/2/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
>
> 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.


Which VMs also benefit from when they compile to native code. Isn't that why
we compile, JIT or AOT, in the first place?

VMs also benefit from online profiling BEFORE compile to ensure the
generated code is closer to optimal. That runtime profiling allows a VM to
leverage the underlying processor *better* than you could by just guessing
at it up front, since it makes decisions based on realtime data, rather than
statistical averages. Yes, there are times it has to guess or go with a
"typical" model, but as execution proceeds it can adjust compilation
parameters to re-optimize code.

There's a body of research on this stuff online; I don't really need to
defend it.

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.
>

JVM discussions are fairly OT, but I have to knock this one down. Sun has
JVM implementations for x86, x86-64, Sparc, and Itanium, running Solaris,
Linux or Windows (except Linux on Sparc). IBM has JVMs for Linux on IA32,
AMD64, POWER 64-bit, and z-Series 31-bit and 64-bit. Apple has a JVM for OS
X on PowerPC and for x86. There's a whole slew of open source JVMs at
gnu.org/software/classpath/stories.html and bunches of other commercial JVMs
for everything from absurdly small devices (like aJile's native Java chips,
ajile.com) to absurdly large ones (Azul Systems network-attached processing,
azulsystems.com).

Fighting the VM tide seems a little silly to me. YARV is on the right track.

-- 
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ www.jruby.org
Application Architect @ www.ventera.com

------=_Part_29474_31599846.1151872161320--