Re: Another toy benchmark...

[Thomas Fitzsimmons <fitzsim at redhat dot com>]

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