[PATCH] Improves __ieee754_exp() performance by greater than 5x on sparc/x86.

[Patrick McGehearty]

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