Re: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp iff 2.29 or greater on AArch64.
On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne <github.com+73799211+gregcawthorne@openjdk.org> wrote:
Glibc 2.29 onwards provides optimised versions of log,log10,exp. These functions have an accuracy of 0.9ulp or better in glibc 2.29.
Therefore this patch adds code to parse, store and check the runtime glibcs version in os_linux.cpp/hpp. This is then used to select the glibcs implementation of log, log10, exp at runtime for c1 and c2, iff we have glibc 2.29 or greater.
This will ensure OpenJDK can benefit from future improvements to glibc.
Glibc adheres to the ieee754 standard, unless stated otherwise in its spec.
As there are no stated exceptions in the current glibc spec for dlog, dlog10 and dexp, we can assume they currently follow ieee754 (which testing confirms). As such, future version of glibc are unlikely to lose this compliance with ieee754 in future.
W.r.t performance this patch sees ~15-30% performance improvements for log and log10, with ~50-80% performance improvements for exp for the common input ranged (which output real numbers). However for the NaN and inf output ranges we see a slow down of up to a factor of 2 for some functions and architectures.
Due to this being the uncommon case we assert that this is a worthwhile tradeoff.
Where does the requirement for monotonicity come from? ------------- PR: https://git.openjdk.java.net/jdk/pull/3510
On 5/6/2021 5:21 AM, Carlos O'Donell wrote:
On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne <github.com+73799211+gregcawthorne@openjdk.org> wrote:
Glibc 2.29 onwards provides optimised versions of log,log10,exp. These functions have an accuracy of 0.9ulp or better in glibc 2.29.
Therefore this patch adds code to parse, store and check the runtime glibcs version in os_linux.cpp/hpp. This is then used to select the glibcs implementation of log, log10, exp at runtime for c1 and c2, iff we have glibc 2.29 or greater.
This will ensure OpenJDK can benefit from future improvements to glibc.
Glibc adheres to the ieee754 standard, unless stated otherwise in its spec.
As there are no stated exceptions in the current glibc spec for dlog, dlog10 and dexp, we can assume they currently follow ieee754 (which testing confirms). As such, future version of glibc are unlikely to lose this compliance with ieee754 in future.
W.r.t performance this patch sees ~15-30% performance improvements for log and log10, with ~50-80% performance improvements for exp for the common input ranged (which output real numbers). However for the NaN and inf output ranges we see a slow down of up to a factor of 2 for some functions and architectures.
Due to this being the uncommon case we assert that this is a worthwhile tradeoff. Where does the requirement for monotonicity come from?
From the specifications: "The computed result [of log] must be within 1 ulp of the exact result. Results must be semi-monotonic." https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/Math....) and similarly for the other method. -Joe
On Thu, 29 Apr 2021 20:24:25 GMT, Carlos O'Donell <github.com+3019228+codonell@openjdk.org> wrote:
Where does the requirement for monotonicity come from?
Semi-monotonicity, to be precise. In the spec of java.lang.Math, "Besides accuracy at individual arguments, maintaining proper relations between the method at different arguments is also important. Therefore, most methods with more than 0.5 ulp errors are required to be semi-monotonic: whenever the mathematical function is non-decreasing, so is the floating-point approximation, likewise, whenever the mathematical function is non-increasing, so is the floating-point approximation. Not all approximations that have 1 ulp accuracy will automatically meet the monotonicity requirements." I wouldn't be surprised if the approximations we need in glibc meet this anyway. We just need to check. ------------- PR: https://git.openjdk.java.net/jdk/pull/3510
participants (3)
-
Andrew Haley
-
Carlos O'Donell
-
Joe Darcy