[PATCH] New numbers in the benchtests.

[Patrick McGehearty]

On 12/20/2017 11:56 AM, Joseph Myers wrote:
> On Wed, 20 Dec 2017, Patrick McGehearty wrote:
>
>> I did note in the comments (fairly far down) to the patch that
>> "For x86, tgamma showed a few values where the ulp increased to
>> 6 (max ulp for tgamma is 5). Sparc tgamma did not show these failures."
> The problem isn't ulps changes, the problem is that there were test
> failures (missing errno setting in this case) *other than* ones for which
> a libm-test-ulps regeneration sufficed, and such failures always need more
> investigation.
>
>> If the hypothesis is correct, I find it odd for get_rounding_mode
>> to not have matching behavior with libc_fesetround for x86.
> Well, get_rounding_mode has previously only been used (on x86_64 / x86) in
> interfaces such as strtod / printf (for which it was originally added),
> for which results when the SSE and x87 rounding modes are different don't
> matter.  Whereas libm functions can be called internally when those modes
> are different, as part of optimizations that rely on knowing which
> rounding mode is relevant for computations in a particular type and
> avoiding changing the other part of the floating-point state.  Thus, you
> need type-specific interfaces in libm (libc_fegetround{,f,l}) whereas you
> don't in strtod / printf.  (Of course this doesn't make any difference for
> architectures other than x86_64 / x86, because that's the only case where
> you have two different sets of floating-point state at all.)
>
Summary of results:
Tested replacing get_rounding_mode and libc_fesetround only when not in 
FE_TONEAREST
mode with SET_RESTORE_ROUND (FE_TONEAREST).

The tgamma failures disappeared, giving strong support to Joseph's 
hypothesis.
For x86, there is roughly a 5% performance cost which would be tolerable.
Unfortunately, for Sparc, there is a 76% performance cost which is
less tolerable. When Sparc changes the rounding mode, the instruction 
pipeline
is flushed which has a non-trival cost. I suspect the performance cost 
will be
higher on all platforms which have a high cost for changing the rounding 
mode.

Alternatives:
1) Accept the current behavior. - least work.

2) Just use SET_RESTORE_ROUND for now. - almost no additional work,
but slower on some platforms.

3) Define a macro either within e_exp.c or in an include file that selects
get_rounding_mode and libc_fesetround for all platforms except x86.
It selects SET_RESTORE_ROUND for x86.
Putting platform specific macros inside ieee754 branch seems
undesirable, but I thought I should mention it as a possibility.

4) Put the SET_RESTORE_ROUND version of e_exp.c as an x86 specific
version in the sysdeps tree and the get_rounding_mode version in
the ieee754 part of the tree.
Some more work when I'm ready to go on winter break. :-)

Or, do (2) now and maybe (4) later.


Also, as an separate experiment, I tested doubling the size of TBL[] again
to use step sizes of 1/128 instead of 1/64.
It reduces the error rate from 16.1/10000 to 9.7/10000.
It does not remove the 1 bit errors in the current "make check" tests.
To fix those will likely require increasing the size of TBL2[].
For my next patch I'm going to go with the larger TBL[] size unless
someone objects. Might as well reduce even small errors when we can.

- patrick

ps Apologies for continuing to accidentally send incomplete messaging
while composing. I apparently have an unconscious trained reflex to
type ^S whenever I pause for thought. That is beneficial for editors
that interpret that as "save file". No so much on mail programs
that interpret ^S as "send file". I will try to remember to compose
outside of mail in the future and then copy/paste into the mailer.