From: Robert Klemme <shortcutter@...>
Date: 2006-07-02T18:55:16+09:00
Subject: Re: Huge performance gap

2006/7/2, M. Edward (Ed) Borasky <znmeb@cesmail.net>:
> Robert Klemme wrote:
> > There's a significant difference between GCC and the JVM for example:
> > VM's can collect performance data while the application is running
> > whereas GCC has to optimize at compile time. This yields advantages
> > for the VM approach because it can better target optimizations.
> Ah, but at least for the multiprogramming case, so can (and *does*) the
> operating system! And the *interpreter* can "collect performance data
> while the application is running" and optimize just as easily -- maybe
> ever more easily -- than some underlying abstract machine.

As Charles pointed out the interpreter *is* a virtual machine and thus
equivalent to a JVM with regard to the runtime information it can
collect (AFAIK the current Ruby runtime does not, but it could).

> In any event:
>
> 1. The hardware is optimized to statistical properties of the workloads
> it is expected to run.
>
> 2. The operating system is optimized to statistical properties of the
> workloads it is expected to run and the hardware it is expected to run on.
>
> 3. Compilers are optimized to statistical properties of the programs
> they are expected to compile and the hardware the compiled programs are
> expected to run on.
>
> As a result, I don't see the need for another layer of abstraction. It's
> something else that needs to be optimized!

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.

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 advers

-- 
Have a look: http://www.flickr.com/photos/fussel-foto/