This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Another toy benchmark...
- From: Norman Hendrich <hendrich at informatik dot uni-hamburg dot de>
- To: java at gcc dot gnu dot org
- Date: Wed, 22 Feb 2006 14:31:23 +0100 (CET)
- Subject: Another toy benchmark...
- Reply-to: Norman Hendrich <hendrich at informatik dot uni-hamburg dot de>
Hello all,
yet another toy benchmark... You can download the source code from here:
http://tams-www.informatik.uni-hamburg.de/personal/hendrich/GameOfLife.java
The demo consists of a modified form of Conway's famous "game of life". The
modification is a slight random term that avoids the typical "+++" cycles
and attractors of the original game. The game board is displayed in a Swing
JPanel after each iteration, and the specified milliseconds "sleep" interval
is inserted after each iteration. (This is a quick hack, and the background
thread is not 100% safe. Also, a sparse-matrix representation of the gaming
board might be better. Matlab uses this.)
<java> GameOfLife -sleep <millis>
gcj --main=GameOfLife -O3 -d . GameOfLife.java
./a.out -sleep <millis>
Iterations per second: (Athlon 2600+, SuSE Linux 8.2)
JDK 1.4.2 JDK 1.5.0 JDK 1.6.0 JDK 1.6.0 jamvm+cp gcj 4.2.0
-client -client -client -server -O3
-sleep 50 16.66 16.66 16.66 16.66 3.99 3.20
-sleep 20 33.33 33.33 33.33 33.00 5.20 3.30
-sleep 5 50.00 50.00 50.00 50.00 5.20 3.30
-sleep 0 ~1900.00 ~2000.00 ~2000.00 ~2200.00 31.25 200 ..
2000
Conclusions:
1. the JDKs somehow limit repaints to about 50 fps max, and probably use
time-slicing in 8.33 msec intervals to assign repaint slots.
2. Newer versions of the JDK slightly improve raw performance.
3. jamvm+classpath is a pure interpreter, and loses this benchmark.
4. Raw calculation performance of gcj+classpath is not bad at all, but AWT
seems to be severely crippled. A factor of 15 slowdown (50/3.3) is not
always acceptable...
Please let me hear whether you can reproduce those numbers. Any insights?
- Norman