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
