GCC and Fortran eat GCJ for lunch at number crunching

[Tom Tromey]

>>>>> "Erik" == Erik Poupaert <erik.poupaert@chello.be> writes:

Erik> Is there anything in the front-end that prevents gcj from
Erik> benefiting from these back-end optimizations?

Nope.  However, whether a given flag will give a performance benefit
depends on the code.

Erik> Are there any typical front-end java-oriented optimizations
Erik> performed as well?

There are some minor ones.  We can inline some math functions, for
instance.

Erik> I was thinking, for example, of doing some involved call graph
Erik> analysis that allows a good share of the objects to be allocated
Erik> to stack, instead of burdening the heap and the garbage
Erik> collector

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

Erik> Maybe there are other front-end optimization strategies
Erik> possible?

Sure.  We hope to get some nice type-based optimizations from the
tree-ssa work.  Whether or when this will happen is anybody's guess.
There are probably other optimization ideas floating around, but I
don't have a list handy.

Erik> When tuning gcj-produced executables, what things should one
Erik> keep in mind?  Things, that may be different from gcc-produced
Erik> executables?

In general, Java's rules are stricter than C's, yielding fewer
optimization opportunities.  It is hard to measure the effect, though,
since there are also other differences that affect performance in the
real world (e.g., different memory allocation approaches).  How one
would translate this into a coding style I'm not sure.

There are also performance differences between gcj and other Java
implementations.  For instance, with gcj exceptions (from what I
recall) are more expensive.  On the other hand, if you use CNI, calls
to native methods are much cheaper.

Tom