Hi Joe, Thanks a lot for your valuable comments.
On 17-11-2016 15:35, joe darcy wrote: >> Currently, optimization for building fdlibm is disabled, except for the >> "solaris" OS target [1]. > > The reason for that is because historically the Solaris compilers have had > sufficient discipline and control regarding floating-point semantics and > compiler optimizations to still implement the > Java-mandated results when optimization was enabled. The gcc family of > compilers, for example, has lacked such discipline. oh, I see. Thanks for clarifying that. I was exactly wondering why fdlibm optimization is off even for x86_x64 as it, AFAICS regarding gcc 5 only, does not affect the precision, even if setting -O3 does not improve the performance as much as on PPC64. >> As a consequence on PPC64 (Linux) StrictMath methods like, but not limited >> to, >> sin(), cos(), and tan() perform verify poor in comparison to the same methods >> in Math class [2]: > > If you are doing your work against JDK 9, note that the pow, hypot, and cbrt > fdlibm methods required by StrictMath have been ported to Java (JDK-8134780: > Port fdlibm to Java). I have intentions to > port the remaining methods to Java, but it is unclear whether or not this > will occur for JDK 9. Yes, I'm doing my work against 9. So is there any problem if I proceed with my change? I understand that there is no conflict as JDK-8134780 progresses and replaces the StrictMath methods by their counterparts in Java. Please, advice. Is it intended to downport JDK-8134780 to 8? > Methods in the Math class, such as pow, are often intrinsified and use a > different algorithm so a straight performance comparison may not be as fair > or meaningful in those cases. I agree. It's just that the issue on StrictMath methods was first noted due to that huge gap (Math vs StrictMath) on PPC64, which is not prominent on x64. > Accumulating the the results of the functions and comparisons the sums is not > a sufficiently robust way of checking to see if the optimized versions are > indeed equivalent to the non-optimized ones. > The specification of StrictMath requires a particular result for each set of > floating-point arguments and sums get round-away low-order bits that differ. That's really good point, thanks for letting me know about that. I'll re-test my change under that perspective. > Running the JDK math library regression tests and corresponding JCK tests is > recommended for work in this area. Got it. By "the JDK math library regression tests" you mean exactly which test suite? the jtreg tests? For testing against JCK/TCK I'll need some help on that. Thank you very much. Regards, Gustavo
