Speed Impact experiment on GCJ
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.
More information about the Java