Another toy benchmark...

Thomas Fitzsimmons fitzsim@redhat.com
Tue Mar 21 16:30:00 GMT 2006


Hi,

On Mon, 2006-02-27 at 14:09 -0500, Thomas Fitzsimmons wrote:
> On Mon, 2006-02-27 at 14:01 -0500, Thomas Fitzsimmons wrote:
> > On Wed, 2006-02-22 at 14:31 +0100, Norman Hendrich wrote:
> > > 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?
> > 
> > Can you file a bug for this with a test case?
> 
> Actually, can you also attach GameOfLife.java if it is redistributable?
> I did test this on my JamVM + Classpath setup and it is indeed much
> slower than on Sun.  The test case would probably be more useful if it
> eliminated the calculations so as to isolate the demonstration of the
> AWT performance problem.

To conclude this thread:

Norman filed this performance bug:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26486

and I committed a fix for it to GNU Classpath.  The performance problem
turned out to be in the GTK peers and had nothing to do with GCJ.

Tom




More information about the Java mailing list