StrictMath performance improvement not ported to Math?

[Joe Darcy]

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/min_max/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
>