** sorry for the last incomplete post, I accidentally hit the wrong button **

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 adversary effect on performance due to the increases size of the
memory image.

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

From all I can see in current developments in CS the trend seems to go
towards virtual machines as they provide a lot of advantages over
traditional compiled code.  I personally prefer to implement in Java
over C++ for example. YMMV though.

Kind regards

robert

--