posted 14 years ago
Actually, this is a particular sore spot with Java. Java is intended to be "write once, run anywhere", and they take that directive so seriously that even the floating-point calculations and binary serializations should be accurately reproducible.
However, there are a number of different floating-point implementations, depending on the hardware involved. To stay portable, Java dictates the IEEE floating-point representation.
The original IBM System/370 floating point (optional on selected S/360 models) was a rather odd format. So to run IEEE floating point on it, and its descendants, the floating-point hardware had to be totally ignored and the actual floating-point calculations be done totally in software. As a result, although on most benchmarks, Java can often exceed the runtime speeds of native C code, when you add floating-point, it loses badly (C isn't required to be write once, run anywhere so it can use whatever FP resources it wants).
Two mechanisms were provided to compensate for this. For general Java use, there's a modifier that says "Use the machine's native floating-point facilities". That way you can take advantage of the hardware accelerators. For IBM mainframes, the recent crop of z/Series machines added IEEE accelerators alongside their older unique FP hardware.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.