There is room for improvement

[Martin Kahlert]

Hi java developpers!
This is for your information:

I made a small benchmark with gcj (gcc-20020107 with the discussed to death
bugfix for Double.MAX_VALUE)
and Tower on a Solaris 2.7 (sparc-sun-solaris2.7) machine.

The sources (a compiler, which compiles VHDL-AMS into Fortran code)
consists of 1776 Java Files summing up to 316415 lines (including blank
lines and comments). This is mostly integer stuff, very few floating point.

The Tower generated C files are compiled by gcc-2.95.3 using
-O3 -funroll-loops -fomit-frame-pointer (at least i think/hope so...)

The binary sizes:
Tower  : 9905816 bytes (includes the Tower Java runtime)
gcj    : 7647948 bytes (depends on libgcc_s.so, libgcj.so, ...)
gcj -O : 6946484 bytes (one source file crashed the compiler with an ICE, so
                        no -O for that one)
I will try static linking with gcj later.

The runtimes (for a big VHDL input file) are very similar, too:
Tower  : about 21.0 sec
gcj    : about 22.8 sec
gcj -O : about 21.6 sec
All times vary a by about 1-2 secs. The above values are some kind of mean 
value obtained by ocular inspection :-).

Conclusion (for this application only):
- gcj is comparable with Tower both in executable size and runtime speed,
  when similar backends (gcc) are used. Tower should be in front with
  Sun's own compilers.
- gcj -O doesn't give much (on sparc). Is this intentional up to now?

Thanks for your effort to make this happen,
Martin.

-- 
The early bird catches the worm. If you want something else for       
breakfast, get up later.