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,
I apologize for the lameness of this, but the comment spam was driving me nuts.
In order to be able to post a comment, you need to answer a simple question. Hopefully this question
is easy enough not to annoy serious commenters, but hard enough to keep the spammers away.
Anti-Spam Question: What method on java.lang.System returns an object's original hashcode (i.e. the
one that would be returned by java.lang.Object.hashCode() if it wasn't overridden)? (case is significant)
Powered by: newtelligence dasBlog 2.3.12105.0
© Copyright 2014, Jeroen Frijters