PPC64: Poor StrictMath performance due to non-optimized compilation

[Gustavo Romero]

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