Update: it seems that the JITting process has improved quite a bit these last years (which is to be expected), and the differences are much smaller (and in some cases in favor of Java). Also, the discussion below is to be understood in the context of trigonometric functions rather than floating point operations in general.
In the same podcast I referenced in my previous entry (Java Posse #222) I heard the following affirmation (this is from memory, so it may not be 100% correct): “Performing floating point calculations in Java is slower than native code by a factor of 6-7!”. If I recall correctly the biggest problem was with some trigonometric functions.
This came as quite a surprise for me, given the consensus of JIT-ed code being very close to “compiled” code in performance (in the 90% range). This is why I considered the possible performance gains by things like Google Native Code less significant compared to its problems (dependence on the x86 platforms, possible security risks, etc).
An other field where I would have considered Java to be perfect before this information was the World Community Grid / BOINC project. Now, I’m all for using the extra power of computers for solving large problems, however the model used by BOINC is a little problematic (IMHO) from a security standpoint: they repeteadly download both data and executables for each project that you take part in (I observed this because of a whitelisting solution that I use which prompts whenever an unknown executable is launched). I didn’t look into the safeguards (if any) BOINC has, but given that you run native code, I don’t know if there is much they can do. This is why I would have considered Java to be perfect for the job.
Looking for some more concrete results (because I’m lazy to do my own benchmarking :-)), I come over this site: JavaNumerics, where they have a nice Benchmarks section. Unfortunately they don’t seem to have a comparison with native code, only different JVM’s on different platforms. I also found this paper (warning! PDF) which claims that numerical computation in Java is 50%-60% slower than the equivalent compiled code. This is quite a lot and a big waste for distributed projects.
The (sad) conclusion seems to be: Java doesn’t seem to be “there” yet for numerical calculations (just as it doesn’t seem to be “there” with JavaFX either :-(). Hopefully this will be resolved sooner rather than later and we can dedicate our computer to things like computing rainbow tables with an extra level of safety.