Sponsored link Serve your customers, not your servers, with VERIO Linux VPS. Full-access test-drive here. |
A look at GCJ 4.1A look at GCJ 4.1Posted Feb 9, 2006 10:57 UTC (Thu) by kleptog (subscriber, #1183)Parent article: A look at GCJ 4.1
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...
(Log in to post comments)
Run everywhere? Posted Feb 9, 2006 13:26 UTC (Thu) by man_ls (subscriber, #15091) [Link] 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.
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 thanbyte 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.583As 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 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.183As 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 :)
A look at GCJ 4.1 Posted Feb 10, 2006 2:59 UTC (Fri) by pimlott (subscriber, #1535) [Link] its possibility to run everywhere using bytecode was ahead of its time.Compiling to machine-independent bytecode is a very, very, very old idea.
A look at GCJ 4.1 Posted Feb 10, 2006 18:43 UTC (Fri) by im14u2c (subscriber, #5246) [Link] 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?
A look at GCJ 4.1 Posted Feb 16, 2006 21:22 UTC (Thu) by anton (guest, #25547) [Link] >>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:-).
|
Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds
Powered by Rackspace Managed Hosting.