This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Math functions and rounding mode
On 1/1/2018 7:51 AM, Wilco Dijkstra wrote:
Patrick wrote:
Replaced get_rounding_mode and libc_fesetround() with SET_RESTORE_ROUND
to avoid Intel rounding mode issue which showed as test failures in
tgamma_upward. Adds noticable overhead for platforms that incur
significant cost when rounding mode is already FE_TONEAREST. Added
SET_RESTORE_ROUND to two more cases which resolved 1 ulp rounding
errors for cexp().
I don't see how this can be true. SET_RESTORE_ROUND always checks the
rounding mode first and avoids setting it if it is already as expected.
This is true for the generic implementation as well as the Sparc specific
one, so the overhead for both approaches should be identical.
Perhaps the Sparc specific version is not doing quite the optimal thing.
Using the explicit test and
get_rounding_mode/libc_fesetround that was in the earlier patch ran much
faster on Sparc than
SET_RESTORE_ROUND. The Intel version also ran slower with
SET_RESTORE_ROUND, but only by
a few percent.
I think we're using the wrong approach here. Assuming exp has acceptable ULP
errors in all rounding modes (we allow a larger ULP in non-nearest modes),
we never need to change rounding mode in exp itself. If functions like tgamma
or cexp end up with errors or unacceptable ULP in non-nearest rounding modes,
we should simply wrap *those* functions with SET_RESTORE_ROUND.
That ensures commonly used math functions have no extra overhead at all.
This should be a key goal given rounding mode changes are expensive on many
targets. If a math function calls multiple basic math functions, you actually
get a speedup as the rounding mode check is done only once.
This means we can concentrate on improving performance of the basic math
functions without spending a large amount of time dealing with non-standard
rounding mode issues in infrequently used math functions.
Does this look like a better way forward?
Wilco
When the current rounding mode is not FE_TONEAREST on entry to exp(),
and if we do not change the rounding mode to FE_TONEAREST within exp(),
then we get more 1 ulp errors according to the make check tests
of exp(). I suspect users who care enough to try other rounding
modes than FE_TONEAREST really care about those 1 ulp diffs.
If performance at the cost of more maintenance overhead were a goal,
we could supply a complete version of the math library which assumed
it was always in FE_TONEAREST and never checked/set/restored rounding mode.
That would also raise the question about which version should be the
default. I expect that question could generate lots of debate.
- patrick