This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Minimum floating-point requirements
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Mon, 17 Feb 2014 18:07:46 +0000
- Subject: Re: Minimum floating-point requirements
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1401302108080 dot 12540 at digraph dot polyomino dot org dot uk> <Pine dot LNX dot 4 dot 64 dot 1402072347200 dot 12232 at digraph dot polyomino dot org dot uk> <OF54854818 dot C108092B-ON86257C7B dot 0063B8C0-86257C7B dot 006B6B53 at us dot ibm dot com> <Pine dot LNX dot 4 dot 64 dot 1402102231400 dot 26591 at digraph dot polyomino dot org dot uk> <CAGWvnyn-Cj4Mw4efQTs2MYFHhknyskAEznEqpGeYnb9rY3X4hg at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1402150136490 dot 31722 at digraph dot polyomino dot org dot uk> <CAGWvny=aJCdoQvC8q-dNvFdDNAqRCcZ7_adD=Sst8FDr0MN1Qg at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1402151656510 dot 6358 at digraph dot polyomino dot org dot uk> <20140216045946 dot GG184 at brightrain dot aerifal dot cx> <CAGWvny=9Jeippop9xuERzwgWL8+QbZiqQFhgxGNdAW0C=EnOLQ at mail dot gmail dot com> <20140216214623 dot GI184 at brightrain dot aerifal dot cx> <53014CBC dot 6080508 at linux dot vnet dot ibm dot com>
On Sun, 16 Feb 2014, Adhemerval Zanella wrote:
> For instance, Joseph's patch
> http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00157.html showed some
> performance degradation on pow and exp in my experiments (of about 8%
> using GLIBC benchtests). It is due we use expl in exp and the patches
I'd certainly consider performance for pow and exp more significant (in
terms of actual users) than performance for the long double functions.
But that performance cost is also very easy to fix.
* The benchtests are biased to slow cases of current implementations
anyway, not to typical input. It's only the slow cases that use expl.
* In accordance with the documented goals for libm functions, I think we
could cut out all the slow cases from exp, pow and a few other functions,
and still have results within 1ulp, which is within the documented goals -
correct rounding is not a documented goal of most functions, and having
documented goals allows us to say "this code is unnecessary and can be
removed, possibly speeding up the function" just as it allows us to say
"this function needs to be fixed, possibly slowing it down, to follow the
goals for accuracy of results and exceptions". (But check the logic used
to determine when to use slow cases, to confirm that if that logic is
correct for correct rounding, then omitting the slow cases will still give
results within 1ulp. E.g. __ieee754_exp does "if (res == (res + cor *
err_0))", and err_0 is 1.000014, meaning (since the way cor is computed
means it's at most 0.5ulp) the error is expected to be at most 0.5 *
1.000014 ulp, so less than 1ulp even without the slow case.)
* If you don't just cut out the slow cases, with my suggestion at
<https://sourceware.org/ml/libc-alpha/2014-02/msg00469.html> you could
make pow and exp use __ieee754_expl_nonieee if you've determined that
meets the requirements of pow and exp.
> And currently I also tend to agree to David: Joseph current goal in to
> push a modification that *he* sees as important.
You seem to be suggesting this is something bad. I'd say that people
fixing things of interest to them (which may or may not be of interest to
other people) is fundamental to a large proportion of free software
development.
--
Joseph S. Myers
joseph@codesourcery.com