Can anyone quantify performance differences between C++ and Java?

Question

Java was initially slow before the JIT but today performance is pretty close to C++. I want to know if someone has done measurable performance comparisons between the two langu

Answer 1

To complete Pax's and Uri's answer, here are some recent benchmarks:

• Performance Comparison - C++ / Java / Python / Ruby/ Jython / JRuby / Groovy
• Java Performance (wikipedia)

As said, those are two very different languages, and some are convinced that Java will ever be slower than C++ because of:

• Heap allocation for all objects (even small ones like iterators)
• lots of dynamic castings
• increased memory usage

[Humor]

"Java is high performance. By high performance we mean adequate. By adequate we mean slow." Mr. Bunny

As mentioned by dribeas in the comments, Heap allocation is not a good argument.
This "Urban performance legends, revisited" mentions:

"Garbage collection will never be as efficient as direct memory management." And, in a way, those statements are right -- dynamic memory management is not as fast -- it's often considerably faster.
The malloc/free approach deals with blocks of memory one at a time, whereas the garbage collection approach tends to deal with memory management in large batches, yielding more opportunities for optimization (at the cost of some loss in predictability).

Answer 2

Java apps have an initialization overhead that C++ programs do not. When JITed, they are not micro-optimized as much as C++ programs. Also, there is a small runtime overhead (GC + indirect call overhead). Overall, these quantifiable differences don't add up to much. But...

It's well known that when a Java app first starts, it must activate its flux capacitor to bring it's environment back to 1995. This introduces a little delay in startup. But once that's over, the JVM performs about as well as a comparable C++ program running on hardware from 1995.

Answer 3

What many people forget is that JIT techniques can be applied to any kind of binaries, even those produced by a C++ compiler. Most of the benefits of JIT compilation for Java are also valid for C++ if you use something like HP's Dynamo (an emulator that runs executables faster than the native chip it runs on and emulates). Runtime profiling is not really a performance advantage of Java, but of JIT compilation in general.

Answer 4

Some things are better built with Java, C# or any Managed programming languages. Other things will always be better built with an un-managed programming language (like C or C++)

The former category normally includes "applications" in general while the second category normally includes "platforms" in general.

To build FireFox or WebKit in Java is not only just plain stupid but will make the end product become really, really slow, bad and waste a lot of resources for the end users. Open Office is maybe a good candidate for Java, C# or SmallTalk for that matter. But to build FireFox or WebKit in Java (or C# for that matter) is plain stupid and is a failure guarantee...

C++ and C will be several orders of magnitudes faster for many things, in addition to that it'll use a fraction of the memory. That's just the way it is. And as long as Java and C# are "Managed" programming languages this will never change. Maybe someday the CPUs are so fast that "it doesn't matter". But I doubt it since people tend to flex their demands as more CPU is given...

If you want to build browser I am sorry to say that you need to teach yourself C or C++ ;)

Answer 5

JIT compilers can be faster for many individual code constructs because they can take advantage of runtime profiling of code.

For example, VonC in his answer to this question mentions heap allocation for all objects. This is not actually true: the JIT can allocate objects on the stack if it can prove by escape analysis that references to the object will not outlive the stack frame. In this way, the compiler can get the performance benefit of stack allocation while the programmer can rest assured of the safety of assumed GC heap allocation.

Similarly, Uri mentions virtual functions (called virtual methods in most non-C++ languages). This is another case that JIT compilers have an advantage that is almost never available to ahead-of-time (AOT) compilers: the JIT can insert an inlined cheap type check (a dereferenced-word comparison) and actually inline a virtual method call if that particular call site happens to be monomorphic (i.e. the actual type is always the same in practice). It turns out that up to 95% of all virtual method calls are monomorphic in practice, so this can be quite a big win - and it's a win that is hard for AOT compilers to take advantage of, since runtime code loading may change runtime characteristics dynamically.

Answer 6

Where does Java fall short when compared to C++?

Excellent question. Java and the JVM have two main deficiencies that cripple performance compared to C++:

• Generics based upon type erasure.

• Lack of value types.

The former means that generic code incurs boxing and unboxing which incur massive amounts of unnecessary allocation and extra levels of indirection that are cache unfriendly.

The latter means it is impossible for the programmer to unbox arbitrary data structures like complex numbers (pairs of floats), hash table entries (key-value pairs) and vertex data.

Both of these problems combine to make it impossible to implement an efficient generic hash table in Java. In particular, .NET solved both of these problems. For example, Java's generic hash table can be 17× slower than a .NET Dictionary.

In addition, JVMs have very slow FFIs compared to C++. I've heard that simply invoking an external C function from Java can take 1,000 cycles.