JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 042 contents

I read somehere that Java could theoretically run faster than a C program. Is there any truth to that?

Well, since both programs ultimately get executed as machine code on a particular CPU, you could theoretically reverse engineer one such program into the other, and hence get the same performance from either. But more practically, I think you are referring to the fact that Java has a virtual machine which can optimize the program at runtime, whereas C is a statically compiled program. Some people do say that this means the Java virtual machine (JVM) has runtime information that is not available to the static optimizer, and so is theoretically capable of optimizing the program to be more efficient. Are there any practical examples which can show this?

Yes. In an interesting discussion Jeff Kesselman (Sun engineer focused on games) had in his java.net blog, ( see the blog here), Jeff made the following points (my thanks to Jeff for allowing me to use his comments):

Java code (or any run-time compiled code) has the potential to run FASTER then pre-compiled code because it can (and does) factor in knowledge of the operating environment.
Some examples:

• If you want C code on Win32 to run on multi-processor systems you need to compile for that and put in synchronization instructions that slows it down for single processor systems. The Hotspot JIT detects how many CPUs you have and generates code accordingly.
• When you compile C code you need to state a minimal platform (P2, P3, etc). In doing so you lose access to all the extended instructions of more recent proessors. Hotspot again detects what kind of processor and generates code accordingly.
• The list of run-time code improvements is almost endless. Inlining is good, but only so much that you don't overflow your cache. A precompiler has to guess at cache size -- a JIT knows it. Potentially polymorphic dispatch points in C++ CANNOT be inlined, they have to go through a jump table. In Hotspot they ARE inlined and then, if if the dispatch point actually gets *used* in a polymorphic way, that inlining is backed out.

Now before I get the usual bunch of armchair commentators writing desperately in green ink to tell me that they can optimize their C program to be faster than any Java version, let's just clarify this series of points. Java is faster for some things, C is faster for others. You can further optimize your C program for the particular runtime conditions if you know what they are. And no doubt you can spend lots of time analyzing your code to get your allocations and deallocations lightning fast, and your loops and recursive calls equally fast. And I can do the same in Java, spending lots of time hand optimizing code and reducing objects. Until we both end up with Assembler-like versions that are the fastest possible.

But the vast majority of programs, whether C or Java, do not have the person resources do do all that optimization. Maybe you don't have a life, but I sure have better things to do. Your typical program gets the benefit of whatever compiler optimizations or runtime optimizations that are available, plus some hand coded optimizations to get rid of any remaining bottlenecks until the code is fast enough.

And in this type of environment, the JVM runtime optimization can outdo the static optimizations possible for C programs. So, yes, knowing the runtime environment and being able to adapt to that runtime environment allows a class of optimizations that are not available to most statically compiled programs, unless those statically compiled programs have a very well defined target runtime environment that they are being compiled for.

Which all means that the answer to the original question is: yes, there is some truth to it.

The JavaPerformanceTuning.com team

Back to newsletter 042 contents