Run everywhere? [LWN.net]

Run everywhere?

Posted Feb 9, 2006 13:26 UTC (Thu) by man_ls (subscriber, #15091)
In reply to: A look at GCJ 4.1 by kleptog
Parent article: A look at GCJ 4.1

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.

(Log in to post comments)

pre-compiled, fast code

Posted Feb 10, 2006 0:49 UTC (Fri) by pkolloch (subscriber, #21709) [Link]

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!

pre-compiled, fast code

Posted Feb 10, 2006 13:52 UTC (Fri) by man_ls (subscriber, #15091) [Link]

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.

Not too fast on amd64

Posted Feb 12, 2006 2:54 UTC (Sun) by man_ls (subscriber, #15091) [Link]

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.

Benchmarks...

Posted Feb 16, 2006 9:17 UTC (Thu) by mjw (subscriber, #16740) [Link]

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 :)