Performance comparison (update)

[Norman Hendrich <hendrich at informatik dot uni-hamburg dot de>]

About inlining and garbage collection:

> after I got my simulation framework to compile and run under gcj
> (in non-GUI mode), you might be interested in the first results.

Jeff> Thanks.  What version of gcj did you try?

gcc 3.1 release


Jeff> When I benchmark "real" applications I often find the results are
Jeff> dominated by object allocation/collection times.  I haven't seen any
Jeff> convincing improvement from inlining (perhaps because the RTL inliner
Jeff> never really worked that well anyway).

I suspected method inlining from actually looking at the generated
assembly for a microbenchmark I tried about one year ago. For that
benchmark, gcj was as fast as IBMs and SUNs JDK 1.3 after inlining
- manual inlining, that is: rewriting the code to eliminate a method 
call in the inner loop :-)

For the numbers reported below, there should be very little object
allocation while the simulation is running. Naturally, I could have
missed (again) something that happens im my code. Is there some
magic GC flag or hook to print messages, whenever objects are created?

Note: For older 1.1.x generation JDKs and "real" workloads for our
simulator, garbage collection would often use 80+ percent of CPU...
JDK 1.3 behaves *much* better in this regard.


> Any other compiler options I should try?

Jeff> -O2 is worth a try; -O3 performs more optimizations but sometimes 
Jeff> worsens overall performance due to code bloat.
Jeff> -static could be interesting.

See below. Compiling -static is very slow and needs 200 MB of memory...

Bryce> -finline-functions can still be used to turn on the old inliner. 

Thanks, I will try that next.

- Norman




---------------- updated data, including (-O2, -static) options ---


Here the results in events/sec, for slightly longer simulation runs,
on my Athlon XP1700+ under SuSE Linux 7.3 (kernel 2.4.10). 
(Variance between several runs is on the order of 2 percent):

GIJ                                                 ev/sec=   26255
JDK 1.1.8 green threads (interpreter)               ev/sec=  100854

GCJ -static                                         ev/sec=  503601
GCJ -O3 -fno-bounds-check -fno-store-check          ev/sec=  948711
GCJ -O2 -fno-bounds-check -fno-store-check          ev/sec=  981954
GCJ -static -O2 -fno-bounds-check -fno-store-check  ev/sec=  988823
GCJ -static -O3 -fno-bounds-check -fno-store-check  ev/sec= 1072332

JDK 1.3.1 Hotspot client VM                         ev/sec= 1303758
JDK 1.3.0 IBM cx130-20010626                        ev/sec= 1338029
JDK 1.4.0 Hotspot client VM                         ev/sec= 1457247
JDK 1.4.0 Hotspot server VM (CAUTION)               ev/sec= 1995464

(Note that Hotspot server often works fine, but sometimes does not.
 The hardware is certainly ok; I have no small test case that exhibits
 the bug; Sun has never answered to my corresponding bug report.)

ls -lrt
-rwxr-xr-x    1 hendrich users     5310863 Jul 29 18:35 BatchMode-shared.exe
-rwxr-xr-x    1 hendrich users    28930458 Jul 29 18:42 BatchMode-static.exe
-rwxr-xr-x    1 hendrich users    26951501 Jul 29 19:42 BatchMode-static-O2.exe