GCC and Fortran eat GCJ for lunch at number crunching

[Erik Poupaert]

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

"""
Another surprise was delivered by the weak showing of the GNU gcj compiler.
For numerical work, at least, there doesn't look to be any reason to use gcj
(which is only a partial Java implementation) unless you need a bit of extra
performance in your Pentium III-based Java code. Perhaps I'm missing
something obvious; clearly this result requires further investigation.
"""

About the bit "which is only a partial Java implementation", I couldn't care
less. Anything is only a partial Java implementation. You could look at the
space shuttle and say that it only "partially" implements Sun's APIs. Even a
reasonably sized trashcan can only implement part of them.

Since gcc and gcj share the same backend, I had thought that results should
be similar, but somehow, gcj seems to inject additional time wasters into
the backend ... Or is it the runtime that could do with less?

Is there any fundamental reason for gcj to be slower than equivalent
(garbage-collected) C++? The great French aviator and airplane designer,
Saint-Exupery, said that a design is truly finished when there is nothing
left that you can take out as well.