Speed Impact experiment on GCJ

Thomas Hallgren thomas@tada.se
Wed Feb 15 11:29:00 GMT 2006

Rui Wang wrote:
> I am using Sun Java 1.4.2, my understanding is that libgcj is implemented based Sun Java 1.4.2,
> thus, I would imagine that using 1.5 will cause a problem. Please correct me if I am wrong.  
I think that's incorrect. The 1.5 JVM and it's rt.jar is backward compatible with 1.4. And 
you're likely to see some performance gain if you upgrade to the latest 1.5.0_06 version. I 
think even a highly optimized gcj compilation will have a hard time to catch up. It would be 
interesting to see a comparison.

Also note that the Sun JVM is not the fastest one around. Both IBM and BEA (JRockit) are 
known to be faster.

It's a general misconception that compiled images execute faster than byte codes. Any modern 
JVM will compile the byte code into machine code as soon as it sees the need for it (hence 
the term Just In Time compilation (JIT)). In addition, it will optimize that code 
dynamically based on heuristics collected as the process is running. No static compiler can 
do that, no matter how effective its optimizer might be.

Typically, you will see compiled code getting a performance advantage with tasks that have a 
very short duration (the JIT never kicks in or the actual JIT compilation takes a 
significant part of the execution time as a whole) and/or when the code is very simple to 
optimize (the advanced heuristic based optimization doesn't really add anything). Your code 
fits both categories. In real life, that's seldom the case.

I love gcj, since it makes some things possible that are hard do with other JVM's. 
Performance is not one of those reasons though.

Thomas Hallgren

More information about the Java mailing list