From: "Joseph S. Myers" <joseph@codesourcery.com>
To: Jeff Law <law@redhat.com>
Cc: libc-alpha@sourceware.org, gcc@gcc.gnu.org,
Geert Bosch <bosch@adacore.com>,
Christoph Lauter <christoph.lauter@lip6.fr>
Subject: Re: The state of glibc libm
Date: Wed, 14 Mar 2012 16:30:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1203141627170.22094@digraph.polyomino.org.uk> (raw)
In-Reply-To: <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
next prev parent reply other threads:[~2012-03-14 16:30 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-29 18:21 Joseph S. Myers
2012-02-29 21:56 ` David Miller
2012-03-14 14:31 ` Vincent Lefevre
2012-03-14 14:40 ` Joseph S. Myers
2012-03-15 2:08 ` Vincent Lefevre
2012-03-15 18:23 ` James Cloos
2012-03-16 12:17 ` Steven Munroe
2012-03-22 16:11 ` Vincent Lefevre
2012-03-22 16:29 ` Joseph S. Myers
2012-03-26 10:26 ` Vincent Lefevre
2012-03-26 16:13 ` Steven Munroe
2012-03-27 13:01 ` Vincent Lefevre
2012-03-14 16:11 ` Jeff Law
2012-03-14 16:30 ` Joseph S. Myers [this message]
2012-03-14 17:08 ` Jeff Law
2012-03-14 20:37 ` Andi Kleen
2012-03-14 21:05 ` Joseph S. Myers
2012-03-14 21:47 ` Andi Kleen
2012-03-15 9:46 ` Richard Guenther
2012-03-15 14:18 ` Andi Kleen
2012-03-15 14:24 ` Richard Guenther
2012-03-14 21:57 ` David Miller
2012-03-14 20:52 ` Marc Glisse
2012-03-14 21:08 ` Joseph S. Myers
2012-03-28 15:18 ` Joseph S. Myers
[not found] <CAFULd4bg4Ctr_CUZAduBbkV+s6A_Y0cACNfuiE5iAYRtEeUoDg@mail.gmail.com>
2012-03-15 14:53 ` Uros Bizjak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.1203141627170.22094@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=bosch@adacore.com \
--cc=christoph.lauter@lip6.fr \
--cc=gcc@gcc.gnu.org \
--cc=law@redhat.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).