StrictMath performance improvement not ported to Math? (original) (raw)

Joe Darcy joe.darcy at oracle.com
Mon Jan 9 23:58:34 UTC 2012

Hello Martin,

Catching up after the holidays, I built a JDK with your patch and all the relevant regression tests passed and I've just pushed the changes to JDK 8's TL integration repository:

http://hg.openjdk.java.net/jdk8/tl/jdk/rev/858038d89fd5

Thanks,

-Joe

On 11/22/2011 1:47 PM, Martin Desruisseaux wrote:

Hello Joe

Le 22/11/11 04:20, Joe Darcy a écrit :

3) In if statements, replaced:

(a == 0.0d) && (Double.doubleToLongBits(a) == negativeZeroDoubleBits) by (Double.doubleToLongBits(a) == negativeZeroDoubleBits) since the later implies the former. The performance properties of the two versions of the code may differ depending on the frequency of zeros in the input and the cost of the bitwise conversion operation. I'd prefer to leave the code logic as-is in absence of some benchmarking that showed a helpful difference. I presumed that Double.doubleToRawLongBits(a) - I forgot the "Raw" in my previous post - was very cheap after HotSpot intrinsics (which exist according vmSymbols.hpp). If my old memory from 80286 assembler still have some value, it would have simply be a matter of comparing the value from the same memory address using a different machine instruction. But obviously this is only supposition, today picture is very different and I have no benchmark for confirming or refuting my supposition… I'd prefer to see a webrev with: * All min/max logic from StrictMath moved into math, including for the integral types int and long * All StrictMath min/max methods delegating to their Math counterpart Done. I updated the webrev at the same URL: http://webrev.geomatys.com/Math/minmax/index.html The new Math code is a verbatim copy-and-paste from StrictMath, including the formatting. I also made StrictMath.abs methods delegating to their Math counterpart, after making sure that the code was really identical. After this change, the only remaining duplicated code is toDegrees and toRadians. For those two methods, I added a comment saying why StrictMath dos not delegate to Math for them (because the StrictMath methods have the "strictfp" modifier - but this modifier is easy to miss, so a comment may be a worthy safety). * Verification all java/lang/Math and java/lang/StrictMath regression tests still pass I quicky tried, but it seems to be a bit tricky for me since I'm on a MacOS machine. Maybe it will be easier when the MacOS port project will be completed... Martin

More information about the core-libs-dev mailing list