Re: There is room for improvement

[Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>]

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.