Return to Answer

This question operates on false premises: where it counts, Java is still slow. Where it counts are computation-heavy algorithms on large data sets. Granted, these can be optimized, sometimes to be on par with C/C++ code, but only at the cost of modularity and genericity. Efficient C++ code can be designed to be generic and usable as a general-purpose library. Java code can’t. Just look at the heavily optimized Array.sort method, which uses different implementations for all fundamental types, and whose object variant is still much slower than C++’ generic sort because these objects have to dispatch equality comparisons dynamically.

Granted, just in time optimizations as performed by the HotSpot engine can actually predict the target of these virtual calls and attempt inlining. But this is still slower than the directly inlined call that is dispatched inside C++’ sort method.

A former colleague of mine has done comparative benchmarks of a problem on huge data sets (q-gram counting using dynamic shapes) with a templated C++ implementation and an object-oriented Java implementation. The Java code was orders of magnitude slower than the C++ code. Of course this is comparing apples with oranges.

But the point is that the Java implementation was the best possible implementation (in terms of performance, given the degree of modularity required for a library), and so was the C++ implementation.

Unfortunately, the benchmark data is not freely available but others have found similar numbers when comparing the overhead of runtime abstraction. For instance, Scott Meyers writes in Effective STL about the overhead of C’s generic qsort function:

C++’s sort virtually always embarrasses C’s qsort when it comes to speed. […] At runtime, sort makes inline calls to its comparison function … while qsort calls its comparison function through a pointer. […] In my tests on a vector of a million doubles, [sort] ran up to 670% faster …

This question operates on false premises: where it counts, Java is still slow. Where it counts are computation-heavy algorithms on large data sets. Granted, these can be optimized, sometimes to be on par with C/C++ code, but only at the cost of modularity and genericity. Efficient C++ code can be designed to be generic and usable as a general-purpose library. Java code can’t. Just look at the heavily optimized Array.sort method, which uses different implementations for all fundamental types, and whose object variant is still much slower than C++’ generic sort because these objects have to dispatch equality comparisons dynamically.

Granted, just in time optimizations as performed by the HotSpot engine can actually predict the target of these virtual calls and attempt inlining. But this is still slower than the directly inlined call that is dispatched inside C++’ sort method.

A former colleague of mine has done comparative benchmarks of a problem on huge data sets (q-gram counting using dynamic shapes) with a templated C++ implementation and an object-oriented Java implementation. The Java code was orders of magnitude slower than the C++ code.

Of course this is comparing apples with oranges. But the point is that the Java implementation was the best possible implementation (in terms of performance, given the degree of modularity required for a library), and so was the C++ implementation.

Unfortunately, the benchmark data is not freely available but others have found similar numbers when comparing the overhead of runtime abstraction. For instance, Scott Meyers writes in Effective STL about the overhead of C’s generic qsort function:

C++’s sort virtually always embarrasses C’s qsort when it comes to speed. […] At runtime, sort makes inline calls to its comparison function … while qsort calls its comparison function through a pointer. […] In my tests on a vector of a million doubles, [sort] ran up to 670% faster …

This question operates on false premises: where it counts, Java is still slow. Where it counts are computation-heavy algorithms on large data sets. Granted, these can be optimized, sometimes to be on par with C/C++ code, but only at the cost of modularity and genericity. Efficient C++ code can be designed to be generic and usable as a general-purpose library. Java code can’t. Just look at the heavily optimized Array.sort method, which uses different implementations for all fundamental types, and whose object variant is still much slower than C++’ generic sort because these objects have to dispatch equality comparisons dynamically.

Granted, just in time optimizations as performed by the HotSpot engine can actually predict the target of these virtual calls and attempt inlining. But this is still slower than the directly inlined call that is dispatched inside C++’ sort method.

A former colleague of mine has done comparative benchmarks of a problem on huge data sets (q-gram counting using dynamic shapes) with a templated C++ implementation and an object-oriented Java implementation. The Java code was around 400 times slower than the C++ code.

Of course this is comparing apples with oranges. But the point is that the Java implementation was the best possible implementation (in terms of performance, given the degree of modularity required for a library), and so was the C++ implementation.

This question operates on false premises: where it counts, Java is still slow. Where it counts are computation-heavy algorithms on large data sets. Granted, these can be optimized, sometimes to be on par with C/C++ code, but only at the cost of modularity and genericity. Efficient C++ code can be designed to be generic and usable as a general-purpose library. Java code can’t. Just look at the heavily optimized Array.sort method, which uses different implementations for all fundamental types, and whose object variant is still much slower than C++’ generic sort because these objects have to dispatch equality comparisons dynamically.

Granted, just in time optimizations as performed by the HotSpot engine can actually predict the target of these virtual calls and attempt inlining. But this is still slower than the directly inlined call that is dispatched inside C++’ sort method.

A former colleague of mine has done comparative benchmarks of a problem on huge data sets (q-gram counting using dynamic shapes) with a templated C++ implementation and an object-oriented Java implementation. The Java code was orders of magnitude slower than the C++ code. Of course this is comparing apples with oranges. 

But the point is that the Java implementation was the best possible implementation (in terms of performance, given the degree of modularity required for a library), and so was the C++ implementation.

Unfortunately, the benchmark data is not freely available but others have found similar numbers when comparing the overhead of runtime abstraction. For instance, Scott Meyers writes in Effective STL about the overhead of C’s generic qsort function:

C++’s sort virtually always embarrasses C’s qsort when it comes to speed. […] At runtime, sort makes inline calls to its comparison function … while qsort calls its comparison function through a pointer. […] In my tests on a vector of a million doubles, [sort] ran up to 670% faster …

This question operates on false premises: where it counts, Java is still slow. Where it counts are computation-heavy algorithms on large data sets. Granted, these can be optimized, sometimes to be on part with C/C++ code, but only at the cost of modularity and genericity. Efficient C++ code can be designed to be generic and usable as a general-purpose library. Java code can’t. Just look at the heavily optimized Array.sort method, which uses different implementations for all fundamental types, and whose object variant is still much slower than C++’ generic sort because these objects have to dispatch equality comparisons dynamically.

Granted, just in time optimizations as performed by the HotSpot engine can actually predict the target of these virtual calls and attempt inlining. But this is still slower than the directly inlined call that is dispatched inside C++’ sort method.

A former colleague of mine has done comparative benchmarks of a problem on huge data sets (q-gram counting using dynamic shapes) with a templated C++ implementation and an object-oriented Java implementation. The Java code was around 400 times slower than the C++ code.

Of course this is comparing apples with oranges. But the point is that the Java implementation was the best possible implementation (in terms of performance, given the degree of modularity required for a library), and so was the C++ implementation.

This question operates on false premises: where it counts, Java is still slow. Where it counts are computation-heavy algorithms on large data sets. Granted, these can be optimized, sometimes to be on par with C/C++ code, but only at the cost of modularity and genericity. Efficient C++ code can be designed to be generic and usable as a general-purpose library. Java code can’t. Just look at the heavily optimized Array.sort method, which uses different implementations for all fundamental types, and whose object variant is still much slower than C++’ generic sort because these objects have to dispatch equality comparisons dynamically.

Granted, just in time optimizations as performed by the HotSpot engine can actually predict the target of these virtual calls and attempt inlining. But this is still slower than the directly inlined call that is dispatched inside C++’ sort method.

A former colleague of mine has done comparative benchmarks of a problem on huge data sets (q-gram counting using dynamic shapes) with a templated C++ implementation and an object-oriented Java implementation. The Java code was around 400 times slower than the C++ code.

Of course this is comparing apples with oranges. But the point is that the Java implementation was the best possible implementation (in terms of performance, given the degree of modularity required for a library), and so was the C++ implementation.