This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: GCC and Fortran eat GCJ for lunch at number crunching
- From: "Erik Poupaert" <erik dot poupaert at chello dot be>
- To: "Per Bothner" <per at bothner dot com>
- Cc: <java at gcc dot gnu dot org>
- Date: Thu, 2 Jan 2003 19:42:05 +0100
- Subject: RE: GCC and Fortran eat GCJ for lunch at number crunching
>>>>> A couple of people have pointed out on slashdot that
>>>>> compiling with --fast-math makes a huge difference.
I assume most performance optimizations will be the province of the backend;
or is "--fast-math" something the front end is involved in as well?
I've found about 20 options to pass to gcc:
http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Optimize-Options.html#Optimize%20O
ptions
Is there anything in the front-end that prevents gcj from benefiting from
these back-end optimizations?
Are there any typical front-end java-oriented optimizations performed as
well? I was thinking, for example, of doing some involved call graph
analysis that allows a good share of the objects to be allocated to stack,
instead of burdening the heap and the garbage collector; or else, other
garbage-avoidance strategies; but maybe it doesn't really contribute? Maybe
there are other front-end optimization strategies possible?
When tuning gcj-produced executables, what things should one keep in mind?
Things, that may be different from gcc-produced executables?