Matt's Mind

Friday, July 09, 2004

Java vs .NET runtime optimization

This article is yet another article showing Java beating C/C++ in several benchmarks. There are quite a few of these around, and whether you have problems with their methodology or not, I think they provide cumulative evidence using C++ for performance alone is pointless. I think it's likely that the only people remaining in the "Java must be slow" camp don't actually use it.

Interestingly it contains a discussion on why Java might be able to beat C++. There seem to be two main reasons why:

  1. The Java JIT can make global optimizations at run time that aren't possible at compile time: this includes system classes.

  2. The removal of arbitrary pointer manipulation allows not only safe GC, but also safe inferences about aliasing.

Some of real wins come when the JIT can de-virtualize and inline methods. For example, although any method on HashMap might be overridden by a subclass, 99% of the apps out there won't subclass it. For those apps, methods like HashMap.isEmpty () can be inlined and reduced from a virtual method call to three bytecode instructions (and probably two in machine code).

In fact I believe the main reason why C# defaults to non-virtual methods is because of the CLR's use of precompilation, which means that having every method virtual would be a big performance hit. So in the CLR, de-virtualization effectively needs to be done by hand. C#'s designer makes a virtue out of a necessity by claiming this is a better idea anyway: you should design for overridable methods. While I can agree with that, there's no reason not to use virtual by default and use "final" when you really don't want to have someone override a method.

MS actually recommends you do not use static compilation in this MSDN article, making the same claim that the JIT can produce much better performance. So why do they precompile the CLR framework classes and remove the opportunity for global optimizations?

0 Comments:

Post a Comment

<< Home