Initial Heap Size and other tweaks (gcj 3.2.3 on debian)

[karlm at MIT dot EDU]

I inherited an admittedly poor Java port of a Fortran simulation.
It allocates and de-allocates immutable complex number objects
with each operation performed on the values of a matrix of complex
numbers.

This is known to thrash the libgcj garbage collector.  I tried the
recomended method of reducing the frequency of garbage colelctions
by setting the environment variable GC_INITIAL_HEAP_SIZE to
256000000.  This appears to not affect the initial heap size, unless
Linux only counts memory as used once it gets initially paged in
following a page fault.  In any case, even with "-O3 -fno-bounds-check
-fno-store-check -fomit-frame-pointer -static" the gcj-generated
native binary takes over 380 seconds to perform the main loop while
the IBM 1.4.0 JVM takes 25 seconds.  Both times are self-reported
by calling System.getTimeMillis() directly before and after the main loop
and printing the difference. My gcj version is gcj (GCC) 3.2.3 20030415 
(Debian prerelease).

Does anyone have any further suggestions for getting the GCJ
performance on par with the JVM?  From program load to program
exit, the Fortran77 version of the code does the same calculation
in 0.6 seconds, according to the "time" command-line utility.

The long-term solution is of course to use a mutable complex number
class (cleaner) or split the matrix into a matrix for the real part
and a matrix for the imaginary part (probably faster, but less clean).


Thanks,
-Karl

--------
Karl Alexander Magdsick

"For indoor and outdoor use only."
-- Japanese lights -- www.engrish.com