From: Charles O Nutter <headius@...>
Date: 2006-07-02T07:38:42+09:00
Subject: Re: Huge performance gap

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

On 7/1/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
>
> On Sun, 2 Jul 2006, 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.  Depending on application
> > performance of a Java app doesn't differ significantly from a C app but
> the
> > programming model is more convenient, more robust and thus more
> efficient.
> >
> > Kind regards
> >
> > robert
>
> how is this performance data available significantly different from that
> made
> transparent by gcc/gprof/gdb/dmalloc/etc - gcc can encode plenty of
> information for tools like these to dump reams of info at runtime.  or are
> you
> referring to a vm's ability to actually adapt the runtime code?  if so
> then it
> seems like even compiled languages can accomplish this if the language is
> a
> first class data type and the code segment can be manipulated as data
>
>
> http://64.233.167.104/search?q=cache:mNkjHYGIbE4J:tratt.net/laurie/research/publications/papers/tratt__compile-time_meta-programming_in_a_dynamically_typed_oo_language.pdf+lisp+compiled+metaprogramming&hl=en&gl=us&ct=clnk&cd=1
>
> is an interesting read.  if one accepts that compile time metaprogamming
> is
> useful that it's a small leap to execute compile time metaprogramming to
> enhance performance based on runtime characteristics.  but maybe i'm way
> off
> base here...
>

Ahhh, venturing into a domain I love talking about.

Runtime-modification of code is exactly what sets the JVM apart from static
compilation and optimization in something like GCC. The link Ara posted
above is another way to look at the same kind of runtime modification. The
JVM, because it JIT compiles code rather than AOT, can change the parameters
of that compilation whenever it likes. If a particular piece of JIT-compiled
code is heavier on integer math than on memory allocation, it may re-JIT to
avoid processor-intensive aspects of object creation and garbage collection.
If a piece of code is used heavily, there may be opportunities to
dynamically inline or reorder subroutines at runtime. All the tricks C
coders might have to do by hand or decide on at compile time can be done as
needed based on runtime performance profiling.

You could go through a gcc/gdb/gprof and so on cycle, but the point of the
JVM is that you don't have to burn those hours. You write the code once, and
the JVM gobbles it up, runs it interpreted for a (short) while, and then
starts generating native machine code that fits the runtime profile it has
gathered. As that profile changes, code can be regenerated, and indeed the
longer an application runs, the faster it gets.

It is for this reason that many algorithms running in the JVM run as fast as
C or C++ equivalents.

Ruby has great potential to make these same kinds of optimizations at
runtime, and as I understand it, YARV will do quite a bit of "smart"
optimization at runtime.

The JVM got a bad wrap because in versions 1.2 and earlier, it really was
slow. Since 1.3, however, it has increased tremendously in
performance. 1.3was many times faster than
1.2. 1.4 was twice as fast as 1.3. 1.5 and 1.6 are each another 20-25%
faster again. I think the JVM and the recent success of the .NET CLR have
shown that a VM approach is a great way to go.

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

------=_Part_22820_5124175.1151793518392--