There is room for improvement

Fri Jan 11 17:25:00 GMT 2002

On Thursday, January 10, 2002, at 10:00 PM, Martin Kahlert wrote:
> 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)

Recent versions of GCC switched to DWARF2 debugging info on many 
targets, which is currently extremely space-inefficient. I suspect this 
explains the huge binary size - the debugging info is typically now 
several times larger than the code itself. Did you try stripping the 
binary?
> 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 :-).

Its hard to tell what the problem is without knowing what the 
application is doing. In general for computational code and I/O we 
already beat hotspot easily, but we lose when the application 
performance is more constrained by things like type checking and GC.
I have some plans for speeding up the type checks (and I think it can be 
improved quite a lot), but nothing implemented so far.
regards
Bryce.