LWN: Comments on "A look at GCJ 4.1"

A look at GCJ 4.1

anton — 2006-02-16T21:22:06+00:00

>>While Java is a slightly odd language for some things, its
>>possibility to run everywhere using bytecode was ahead of its time.
>
>What happened to p-Code?

Way ahead of its time:-).

Benchmarks...

mjw — 2006-02-16T09:17:34+00:00

There were recently some benchmark tests done. Some claim gcj produced code is native-complied GCJ modules are almost always about 30-40% faster than other implementations (at least on real world code). Others have micro-benchmarks that show that there are cases where gcj isn't as fast at all. But in the end you have to be careful about what you benchmark, or GCJ will just optimize away all non-used code :)

Not too fast on amd64

man_ls — 2006-02-12T02:54:14+00:00

I did not keep the code around, so I rewrote it -- now with a much simpler structure -- and run it on my amd64 (some call it x86-64) running OpenSUSE 10.0. The machine had sporadic loads; but the results are quite similar over several rounds, and quite definite too.

I will post the code for review if anyone is interested. Sun's JDK 1.5 revision 6 for amd64, and gcj 4.0.2 20050901 with optimization -O2 were used. The results are:

results for null benchmark
java        gcj
0.007       1.638

results for add int benchmark
java        gcj
1.298       1.118

results for add long benchmark
java        gcj
0.751       1.810

results for add float benchmark
java        gcj
3.054       2.399

results for add double benchmark
java        gcj
3.103       2.223

results for method call benchmark
java        gcj
0.069       4.398

results for create object benchmark
java        gcj
27.28       148.356

results for append string benchmark, 1/5000
java        gcj
0.069       0.183

As you can see Sun has improved some things, notably method calls; while object creation has horrible performance in both Sun's java and GCJ. (The null benchmark was an artifact of the previous test setup, so you can ignore it; probably string concatenation too.) GCJ keeps a slight edge in some arithmetic operations.

I'm looking forward to try out GCJ 4.1.

A look at GCJ 4.1

jzbiciak — 2006-02-10T18:43:55+00:00

While Java is a slightly odd language for some things, its possibility to run everywhere using bytecode was ahead of its time.

What happened to p-Code?

pre-compiled, fast code

man_ls — 2006-02-10T13:52:43+00:00

I also did some benchmarks some time ago (may 2004). The results are here (in Spanish, the site is under maintenance right now); I will quote some of them here. Code was inserted in a loop and repeated 10^9 times, except the last loop which had 2*10^5 iterations.

results for null benchmark
java        gcj
0.812       1.527

results for add int benchmark
java        gcj
2.66        0.082

results for add float benchmark
java        gcj
3.703       0.981

results for add double benchmark
java        gcj
2.649       0.985

results for method call benchmark
java        gcj
2.818       0.081

results for create object benchmark
java        gcj
3.081       10.02

results for append string benchmark, 1/5000
java        gcj
4.003       9.583

As you can see, arithmetic computations and method calls were much faster in gcj; object creation was slower. It would be interesting to repeat the tests again, with newer versions of both Sun's JVM and GCJ. I will see if I have the code lying around.

A look at GCJ 4.1

pimlott — 2006-02-10T02:59:02+00:00

its possibility to run everywhere using bytecode was ahead of its time.

Compiling to machine-independent bytecode is a very, very, very old idea.

pre-compiled, fast code

pkolloch — 2006-02-10T00:49:49+00:00

I think that precompiled Java code (using gcj) is often still slower than
byte code on a recent commercial JVM with JIT. That doesn't mean that it
isn't quite fast!

(_Years_ ago I made some simplistic tests showing that the C++ STL
containers didn't perform significantly better than the Java equivalents
when using a decent amount of initial JVM memory. Both sides have probably
been improved now.)

What is absolutely wonderful about precompiled, binary Java code is
integration with C, C++, ...! And then using gdb to debug it all!

Run everywhere?

man_ls — 2006-02-09T13:26:56+00:00

While Java is a slightly odd language for some things, its possibility to run everywhere using bytecode was ahead of its time.

With Perl you can also run the same file, and on many more platforms than Java. So it is with any program in Bash, Python, BASIC... and you don't have to go through the motion of a pre-compilation which serves no practical purpose other than a very primitive obfuscation.

What I find really interesting in gcj is the ability to compile Java into a useful and fast binary for your platform.

A look at GCJ 4.1

kleptog — 2006-02-09T10:57:30+00:00

Thanks for the update it's really quite interesting. One thing that strikes me is the Java might finally be able to take the position it could have had years ago. While Java is a slightly odd language for some things, its possibility to run everywhere using bytecode was ahead of its time.

But it has always been hampered by restrictive licencing and initially speed. I remember at Uni we used the IBM Java compiler because the standard one was sloooow. It was cool to be able to test and run your assignments at home and then upload them unchanged to the Uni (different platform, different OS).

It's also nice to have Java installed via your distribution so you can run Java programs without having to mess with third party installers...