This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Improves __ieee754_exp() performance by greater than 5x on sparc/x86.
On 12/13/2017 7:28 PM, Joseph Myers wrote:
On Fri, 8 Dec 2017, Patrick McGehearty wrote:
Revised constants t2, t3, t4, t5 to better match values of 1/n factorial.
To expand on the logic for such a change:
If the values were previously not 1/n! presumably they were coefficients
in some form of minimax approximation minimising the maximum error
(however measured) in the interval used in the original implementation.
The maximum error from just using 1/n! would be at the endpoints of the
interval (whereas a minimax approximation using an nth degree polynomial
would have equal maximum errors with alternating signs at n+2 points -
increasing some errors closer to 0 to decrease those at the endpoints).
You've changed the code to use a narrower interval. Thus, the original
minimax approximation is no longer optimal for the new interval, and it's
quite plausible that the maximum error from using 1/n! is smaller when you
restrict to the new interval.
This patch version is OK.
You are correct that the original values for t2-t5 give better results
for the original 64 table entries.
I investigated your suggestion by comparing the prior values for t2-t5
with the 1/n! values on the prior interval size. My test of 10 million
values in 4 rounding modes showed substantially better results with
the prior values. All estimates of error rates based on 10 million
test values run in with each of the usual 4 rounding modes. Differences in
error rates between rounding modes were less than 1%.
Original Studio values: 29.5 of 10,000 tests off by 1ulp
1/n! for t2-t5 : 39.2 of 10,000 tests off by 1ulp
org studio t2-t5/128 intervals: 16.3 of 10,000 tests off by 1ulp
1/n! for t2-t5, 128 intervals : 16.1 of 10,000 tests off by 1ulp
That suggests we might be able to further reduce the error rate
either by refining the values for t2-t5 or by increasing the
interval table to use 256 values instead of 128.
I don't have any strong basis for making further tradeoffs
of possible small accuracy gains vs perf costs. I suspect
such effort is beyond the current accuracy expectations
for most users of Linux libm, but that issue might be
revisited at some time in the future as part of a total
review of libm accuracy goals.
- patrick