This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: removing slow paths in various dbl-64 libm functions
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Carlos O'Donell <carlos at redhat dot com>, Anton Blanchard <anton at au1 dot ibm dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Tue, 01 Dec 2015 16:43:42 +0000
- Subject: Re: RFC: removing slow paths in various dbl-64 libm functions
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1511261736421 dot 10502 at digraph dot polyomino dot org dot uk> <5657D3A5 dot 5090005 at redhat dot com> <20151130230324 dot 3dd0c293 at kryten> <565D24D0 dot 70804 at redhat dot com>
On 01/12/15 04:40, Carlos O'Donell wrote:
I expect that computations near sharp cuts still require MP solutions to
attain reasonably accurate answers. What users don't like is that the
time taken to compute an answer is not constant, and that might even
constitute a timing oracle in some cases. Either way I think the community
it does not have to be const, only within a reasonable bound.
i think timing oracle is less of a problem than denial of service
on systems with real-time requirements.
(low precision libm cannot solve this completely as the general
bessel functions will take an enormous time depending on the n
argument:
double yn(int,double);
int main(){return yn(1e9,1e9);}
will dos gcc when it tries to eval yn at compile-time,
but for other math functions than yn,jn a low time
bound can be guaranteed for all inputs.)
has consensus that we might try an even lower precision libm with constant
runtime via the use of -ffast-math to select an alternate libm with no MP
fallback and higher ULPs. We have discussed this, but have not moved on
the implementation.
if that happens it should be implemented in such a way
that -ffast-math at link time does not affect the
behaviour of code that was not compiled with -ffast-math.
(i.e. the low prec functions should have different name.)
this is currently a problem with gcc -ffast-math that it
disables subnormal support (flush-to-zero fpu mode) which
affects all fp code in the process (including the c runtime),
which i find too broken to be useful even for -ffast-math.