RE: GCC and Fortran eat GCJ for lunch at number crunching

["Erik Poupaert" <erik dot poupaert at chello dot be>]

>>>> My recollection is that escape analysis is hard and generally requires
>>>> full-program compilation.  There's an IBM "jalapeno" paper about this.

I've skimmed a bit through the paper:
http://www.research.ibm.com/jalapeno/papers/jvmOopsla99.ps

They're talking about up to 23% performance gains for escaping garbage
collection and thread synchronization overhead. Even though full escape
analysis looks indeed hard, partial escape analysis would probably bring
most of the benefits, while being much simpler. The more OO the program
style, the more the simple escapes would have an impact. For example, escape
analysis on iterators is usually ease; and one could happily resort to using
iterators instead of explicit loop variables while escaping their
performance penalty.

>>>> Sure.  We hope to get some nice type-based optimizations from the
>>>> tree-ssa work.

It looks like an effort to re-group and optimize existing backend
optimizations: http://gcc.gnu.org/projects/ast-optimizer.html

The analysis kicks off with a rather alarming statement:
"""
There is no single tree representation in GCC. Each front end defines its
own trees. This means that we would have to duplicate all this code for each
front end.
"""
It sounds like gcj may first need to conform to some common, further
unspecified, tree representation, before being allowed to benefit from the
effort; or else duplicate the effort. When they will finish, the work for
gcj would only start ...

>>>> In general, Java's rules are stricter than C's, yielding fewer
optimization opportunities.

The run-time facilities of garbage collection, synchronisation, and
exception handling seem to be the main culprits according to the
aforementioned papers; and behind the requirement for stricter rules.

Making it all optional, however, would throw us back to the C++ situation.
While the advantage would be a better potential for performance, the main
disadvantages would be the difficult interoperability as a result of
different choices made; with as icing on the cake, the deadly syntax and
other subtleties that must enable all these choices. Therefore, paying the
Java performance price, often makes sense; but if the cost can be reduced,
so much the better.

If I understand this right, there will always be a residual performance
penalty to pay, and Java will always be a bit slower than C++.