This is the mail archive of the mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Speed Impact experiment on GCJ

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]