This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] New numbers in the benchtests.
On 12/20/2017 5:42 PM, Joseph Myers wrote:
On Wed, 20 Dec 2017, Patrick McGehearty wrote:
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
But is presumably still better than the existing code (as you mentioned a
5x improvement), so is a reasonable incremental step.
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.
The correct thing to do is as I said: add libc_fegetround,
libc_fegetroundf and libc_fegetroundl to the large set of math_private.h /
fenv_private.h libc_fe* macros. All of these would default to using
get_rounding_mode, but sysdeps/i386/fpu/fenv_private.h would, in the
__SSE_MATH__ case, use the SSE rounding mode for libc_fegetroundf, and in
the __SSE2_MATH__ case use it also for libc_fegetround. Then you could
use libc_fegetround where you previously used get_rounding_mode.
However, using SET_RESTORE_ROUND as an incremental step still makes sense
before adding libc_fegetround* as an improvement on top of that.
While investigating SET_RESTORE_ROUND, I found two cases which were
missing the Rounding mode correction. Fixing those removed the cexp()
test case failures. I also increased the table size to 256 from 64
to reduce the 1 ulp failures to less than 1 in 1000 by informal testing.
Those remaining failures are likely to be in the range of 0.51 ulp.
Investigating those issues delayed my revised submission until now.
I agree it would be desirable to add libc_fegetround* where appropriate,
but I also agree it is better to get the revised patch in the code
base first, then see about the rounding changes.
- Patrick McGehearty