This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: The state of glibc libm
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: libc-alpha at sourceware dot org, gcc at gcc dot gnu dot org, Geert Bosch <bosch at adacore dot com>, Christoph Lauter <christoph dot lauter at lip6 dot fr>
- Date: Wed, 14 Mar 2012 16:30:35 +0000 (UTC)
- Subject: Re: The state of glibc libm
- References: <Pine.LNX.4.64.1202291655580.7156@digraph.polyomino.org.uk><20120314143045.GG3804@xvii.vinc17.org> <4F60B64D.1020606@redhat.com>
On Wed, 14 Mar 2012, Jeff Law wrote:
> On 03/14/2012 08:30 AM, Vincent Lefevre wrote:
> >
> > > (b) Where functions do make attempts at being correctly rounded
> > > (especially the IBM Accurate Mathematical Library functions), they tend to
> > > be sufficiently slow that the slowness attracts bug reports. Again, this
> > > would likely be addressed by new implementations that use careful error
> > > bounds and information about worst cases to reduce the cost of being
> > > correctly rounding.
> >
> > I'm not sure that the complaints are about worst cases. More probably
> > software implementation vs hardware implementation in the average
> > case. But a new software implementation (better in average) could
> > help.
> The complaints I typically see are about worst case performance. I
> occasionally see requests for better performance with the potential loss of
> accuracy.
I'd say that "better performance with the potential loss of accuracy"
should be covered by -ffast-math - that GCC should generate direct use of
fsin/fcos instructions for sin/cos for -O2 -funsafe-math-optimizations on
x86_64, as it does on x86, unless there is some reason to think they would
perform worse than the out-of-line implementation.
--
Joseph S. Myers
joseph@codesourcery.com