At the time I wrote the original posting I did search around for some tests related to floating point performance in java (as compared to C), however I didn't find any (I didn't know about Scimark2).

Thank you for drawing my attention to the problem and hopefully the comments and the disclaimer at the beginning of the article will create a more realistic picture to the future readers.

PS: I have a "you comment, I follow policy", which means that the links in the username for the comments (not the ones in the body) are linked without nofollow. So next time maybe you can specify your blog 🙂

PS PS 🙂 There is also a selfish reason for asking you to give homepage: frequently I found the commenters blogs/twitter accounts/homepage/etc interesting.

This is not true. The truth is that floating point calculation in Java is around 95% of native optimized (O3) C code (I stress C code, as C in numerical calculations is normally faster than C++ due to all the overhead).

But OK, the FFT timing in the test show that Java speed is 83% of C in the "small" model and 65% of C in the "large" model. So it is true that trig functions are slower in Java when using the Java Math lib.

Java vs C for SOR is 120% and Monte Carlo simulation is about 195 % (2 tims faster in Java)

From the headline "point out the half-truths and misinformation which floats around…" – well, then do this by at least running the only real test that compares Java to C head to head instead of adding more half-truths and misinformation. That is all 🙂

I would love to be proven wrong, but Dick is knowledgeable guy who generally knows what he's talking about.

On the "large" model (uncached) Java is 82% of C code in -client mode. In server mode Java is 94% of the C-code. They use Mflops.

So, in a practical application Java will have about 95% of the speed of optimized C code (not C++) in pure number crunching performance.

About the quote from Java Posse 222 – you are correct that trig (or in fact transcendental) functions are the problem. In fact, in practice, much of the floating point performance is as good as or even in some cases better (for tight loops that can be optimized by hotspot) in Java as that of C/C++. However transcendental functions are much slower.

The situation has improved with Java 6, but performance is still not on a par with other languages. The problem is that the hardware functions on x86 hardware is not considered accurate enough for Java. While there is some truth to this (the routines are flawed on x86), the fact remains that Java is the only mainstream language that refuses to let the developer decide whether to take the faster, less accurate implementation in the hardware, or the slower more accurate IEEE routines in software.

I have rallied against this decision for a long time but have made little headway (the worst case I have seen is less than one part in a million innacuracy – not something that can even be observed in, say, a coordinate transformation).

Cheers

Dick Wall (Java Posse)