gcj does pretty darned well... (was: Re: GCC and Fortran eat...)

[Terry Sikes]

I've been off the list for awhile but this seemed worth resubscribing 
for.  (I'll probably begin using gcj lots more from here on out, so this 
list should be a big help.:)

 >There is also a difference between the last released 3.2 and the 3.3
 >from CVS. With only the following flags "-march=athlon-xp
 >-mcpu=athlon-xp -O3" there was already the following difference for his
 >almabench on my machine:
 >
 >3.2: 92 seconds
 >3.3: 66 seconds
 >
 >So when 3.3 is released it should already have a positive impact on this
 >benchmark and hopefully the test will be repeated then.

That is great.  I also ran across the following on Slashdot this morning:

---begin article---
OK, I must admit I went into this with some preconceptions which I'm now 
re-evaluating. I think the author did a pretty good job, despite those 
inner-loop memory allocations and his timing methodology.

My feeling about timing is that it is trivial to get the system time to 
less than a microsecond resolution on x86 systems, and the overhead of 
doing so is totally negligible in a reasonable benchmark, as long as it 
only happens a few times. I modified his Java benchmark to print out a 
little more information. I also followed some advice from the discussion 
on better compiler switches for gcj.

Here are the results I got this morning:

[glock27@rigel java]$ java -version
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)
[glock27@rigel java]$ javac *
[glock27@rigel java]$ java almabench
starting...
elapsed ms: 3915
elapsed ms: 3904
elapsed ms: 3893
elapsed ms: 3894
elapsed ms: 3888
elapsed ms: 3909
elapsed ms: 3893
elapsed ms: 3895
elapsed ms: 3897
elapsed ms: 3899
elapsed ms: 3893
elapsed ms: 3897
elapsed ms: 3890
elapsed ms: 3918
elapsed ms: 3893
elapsed ms: 3897
elapsed ms: 3891
elapsed ms: 3908
elapsed ms: 3893
elapsed ms: 3893
total elapsed ms: 78509
[glock27@rigel java]$ gcc --version
gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[glock27@rigel java]$ make
gcj -o almabench.o -march=athlon -mcpu=athlon -O3 -ffast-math 
-funroll-loops -fno-bounds-check -c almabench.java
gcj --main=almabench -o almabench -march=athlon -mcpu=athlon -O3 
-ffast-math -funroll-loops -fno-bounds-check almabench.o
[glock27@rigel java]$ ./almabench
starting...
elapsed ms: 1227
elapsed ms: 1202
elapsed ms: 1209
elapsed ms: 1206
elapsed ms: 1209
elapsed ms: 1211
elapsed ms: 1207
elapsed ms: 1211
elapsed ms: 1219
elapsed ms: 1204
elapsed ms: 1212
elapsed ms: 1207
elapsed ms: 1205
elapsed ms: 1215
elapsed ms: 1207
elapsed ms: 1212
elapsed ms: 1205
elapsed ms: 1207
elapsed ms: 1207
elapsed ms: 1206
total elapsed ms: 24478

GREAT showing for gcj...now 3.2 TIMES faster than Sun JDK 1.4!!! I'll 
post results for gcc with similar mods later.

All times are on my completely stock Athlon 2100+ XP - which benched 
faster than his P4 2800 using JDK 1.4. Maybe he should check out AMD 
after all. ;-) My bench did not reflect startup time, but trust me it 
wasn't close to six seconds (more like less than one).

This has really changed my thinking about gcj, although I'm also 
impressed with his Intel compiler times. I'll see if there is a free 
trial and see how the Intel code does on my Athlon. I've heard the 
generated code runs well on AMD systems also - I suppose unless SSE2 is 
used. ;-)
---end post---

This looks much better for gcj.  Any other switches that might matter? 
-march=athlon-xp perhaps?  Note that gcj went from being slower than the 
Sun JDK 1.4.1 to *3.2 TIMES* faster than the Sun JDK.  That is 
*terrific*, and still using th 3.2 version!!!  BTW, I did open a bug 
report in the JCP for the 2x slowdown the Sun & IBM JDKs experienced on 
this code going from 1.3 to 1.4...PLEASE don't let gcj emulate those two 
packages in that regard!

The author still hasn't updated his page to show a run with similar gcj 
settings on his P4...perhaps a bit more prodding is in order?  There are 
a whole lot of folk on Slashdot with the wrong impression...

Terry