Re: SpecJVM98 (was: assembler warning when compiling obfuscated bytecode)

[Bryce McKinlay <bryce at albatross dot co dot nz>]

Godmar Back wrote:

> My initial results of running them are rather disappointing: javac, jack
> and mtrt don't work yet (which is probably *not* a gcj problem, I hope),
> the rest run, but except for compress and mpegaudio they're all (jess,
> jack and db, that is) a lot slower than with Kaffe's jit.  All are slower
> than IBM's.  The most promising is mpegaudio which went from 95 seconds
> to 38 seconds (IBM: 26 seconds).  I wonder how fast libgcj would be.
> (There's of course different allocators/collectors.)

My experience is that integer benchmarks on gcj 2.96 with lots of relativly long
methods should perform anywhere from ~20% slower to 50% faster than IBM's JIT.
FP performance is a bit slower. he reduced class loading overhead and lack of a
need for JIT compiling is also significant, and benchmarks typically wont show
that.

Code that triggers some of the current gcj performance bottlenecks (ie any of
the compiler-called _Jv_* methods) too regularly will give poor performance, of
course. I think they're current implementations can be optimized somewhat in the
runtime, and hopefully the compiler will be able to optimize out and/or inline
them eventually.

On ia32, gcj 2.96 does show significantly better scores than 2.95 on many tests.

And for some unquestionable proof that gcj/libgcj is faster than IBM 118, try
GCTest.java from kaffe/tests/regression or my earlier message ;-)

regards

  [ bryce ]