Mark Wielaard did some benchmarks of
some of the free JVMs available.
I noted on the Classpath mailing list that the IKVM floating point performance is
probably overstated, because IKVM doesn't implement FP correctly. It uses the .NET
framework FP instructions and methods and those in turn are implemented using the
x86 FP instructions.
The original JVM specification was very strict in specifying floating point operations.
Basically, it mapped 100% onto the Sparc floating point model and this caused spec
compliant FP code to be slow on Intel. I don't think any of the early VMs correctly
implemented the spec so this wasn't really a problem. I don't know why early the VM
implementers didn't implement the spec, maybe they felt the performance cost was too
high or maybe they just didn't find it an interesting issue (the "problem" is that
the Intel FP results are actually too accurate).
In JDK 1.2 Sun introduced the strictfp keyword
and corresponding JVM method and class access flag. Interestingly, they loosened the
default FP requirements and specified the original FP behavior for methods (or classes)
marked with the strictfp keyword.
IKVM doesn't implement strictfp at the
moment, but this isn't the whole story. For trigonometric* functions (e.g. Math.sin())
IKVM uses the equivalent .NET Math functions and those are (probably) implemented
using the x86 FP instructions and these are not compliant with the JVM specification
and I think that in this case the Intel instructions are not more accurate than required,
but actually less accurate. So this is a real problem that should be fixed at some
point in the future.
*This probably also applies to other Math functions, like Math.exp, Math.log, Math.sqrt,
etc.