comparison between native gcj and bytecode

["Erik Poupaert" <erik.poupaert@chello.be>]

>>>> How is the speed performance of your executable vs. running the
classfiles on a modern VM?

There's a new and rather controversial comparison specifically comparing
number crunching capabilities between several C++ compilers, several JDK
versions, and gcj, the GNU native java compiler.

http://www.coyotegulch.com/reviews/almabench.html

The conclusions include:
* the JDK has become significantly slower from version 1.3 to 1.4 (!!!) (and
bigger!!!)
* IBM's implementation beats Sun again.
* The fastest number cruncher is still Fortran, with C++ barely catching up.
* By supplying the same optimizations to the GCC backend, the performance of
natively compiled Java already comes close to gcc/C++.

Even though the Java run-time facilities of garbage collection,
synchronisation, and exception handling reduce opportunities for
optimization and introduce stricter rules, several new aggressive efforts
should bring gcj's performance asymptotically close to gcc/C++:

* completing AST unification and optimization for all gcc front ends through
the tree-ssa project (http://gcc.gnu.org/projects/ast-optimizer.html)
* advanced escape analysis
* opportunities for global inlining

Further, the introduction of templates in 1.5. will remove the need to do
type checking whenever accessing an element of a collection, bringing gcj
yet closer to C++ performance.

There are reasons to believe that gcj already beats the JDK with regards to
performance. And the future outlook is that ahead of time compilation still
has very good potential left for optimization, while just in time
compilation may very well already have hit its limits.