This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] New numbers in the benchtests.

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

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

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.

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]