Performance comparison

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

Hello,

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

My motivation for trying gcj was twofold:

* performance comparison. Hotspot profiling of the simulator shows
  that a large part of processor time is spent in event-queue
  management. Due to severe performance problems with early JDKs,
  we implemented our own memory management for event-queue nodes.
  Gcj should well be able to optimize away most of the run-time
  checks in that part of the code.

* option to run on servers without X11 installed.

---

Here are some performance numbers. More to come later (but probably
not while the current sunny weather lasts :-)) 

(Note that these numbers are not yet the promised garbage-collection 
torture tests; the simple simulation setup here uses only a few dozen 
simulation components (signals, gates, registers), a few pre-allocated 
immutable objects for the logic levels, and our own memory management 
for the event-queue. The simulation setup employs a LFSR-analyzer to
compress simulation results into a single signature value).

java/hades> gcj -c */*.java BatchMode.java
java/hades> gcj --main=BatchMode *.o */*.o 
java/hades> time a.out
GCJ: resourcename='/hades/ke15/3/testbench_3_1_b.hds'
GCJ: got the design:  Design: /testbench-3-1-b
GCJ: got the simulator: VhdlBatchSimKernel'simulator0'
...
final signature is: 1146175279
final generator value: -146512562
selftest OK.
8.190u 0.030s 0:08.27 99.3% 0+0k 0+0io 1872pf+0w



java/hades> gcj -c -O3 -fno-bounds-check -fno-store-check */*.java
java/hades> gcj -c -O3 -fno-bounds-check -fno-store-check BatchMode.java
java/hades> gcj --main=BatchMode *.o */*.o 
java/hades> time a.out
...
final signature is: 1146175279
final generator value: -146512562
selftest OK.
4.760u 0.010s 0:05.21 91.5% 0+0k 0+0io 1867pf+0w


java/hades> java -version
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
java/hades> time java BatchMode
...
final signature is: 1146175279
final generator value: -146512562
selftest OK.
4.090u 0.090s 0:04.74 88.1% 0+0k 0+0io 6660pf+0w


java/hades> java -version
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)
java/hades> time java BatchMode
...
final signature is: 1146175279
final generator value: -146512562
selftest OK.
3.910u 0.040s 0:04.85 81.4% 0+0k 0+0io 2636pf+0w


java/hades> java -version
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)
java/hades> time java -server BatchMode
...
final signature is: -1715011439
final generator value: 41491005
selftest OK.
2.130u 0.050s 0:03.41 63.9% 0+0k 0+0io 3107pf+0w

(YES, that is fast - but the wrong result...)


----

Here the results in events/sec, for slightly longer simulation runs,
on my Athlon XP1700+ under SuSE Linux 7.3 (kernel 2.4.10):

GIJ                                          ev/sec=   26255
JDK 1.1.8 green threads (interpreter)        ev/sec=  100854
GCJ -O3 -fno-bounds-check -fno-store-check   ev/sec=  948711
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.


---

I suspect that gcj is possibly just missing to inline one or two
critical functions. Overall performance is quite good. The
interpreter works fine but has some headroom for improvements :-)

Any other compiler options I should try?

- Norman