public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "vincent-srcware at vinc17 dot net" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug math/13932] dbl-64 pow unexpectedly slow for some inputs Date: Sat, 23 May 2020 21:31:52 +0000 [thread overview] Message-ID: <bug-13932-131-ZPwdXlGqYI@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-13932-131@http.sourceware.org/bugzilla/> https://sourceware.org/bugzilla/show_bug.cgi?id=13932 --- Comment #26 from Vincent Lefèvre <vincent-srcware at vinc17 dot net> --- (In reply to Michael Kerrisk from comment #25) > Fix documented for man-pages-5.07. [...] > -On 64-bits, > +Before glibc 2.28, > .\" > .\" https://sourceware.org/bugzilla/show_bug.cgi?id=13932 > +on some architectures (e.g., x86-64) > .BR pow () > may be more than 10,000 times slower for some (rare) inputs > than for other nearby inputs. [...] The problematic values are uncommon, but not so rare, in the sense that they are close to simple values, i.e. are likely to occur in practice. An example given above: pow(0.999999999999999889, 1.5) 1 and 1.5 are very simple values, which are more likely to occur in practice than some fixed random value. Then it suffices to have a small rounding error on 1... For instance, this is very different from hard-to-round cases of exp, which are also very slow IMHO, but unless one writes a specific program for them, no-one should notice the slowness because such a case would typically occur only once among billions (I don't remember the accuracy before the slowest path in this library). -- You are receiving this mail because: You are on the CC list for the bug.
next prev parent reply other threads:[~2020-05-23 21:31 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-03-31 2:23 [Bug math/13932] New: x86_64 " ppluzhnikov at google dot com 2012-12-13 16:45 ` [Bug math/13932] " manu at gcc dot gnu.org 2012-12-13 18:58 ` ppluzhnikov at google dot com 2013-01-04 11:33 ` siddhesh at redhat dot com 2013-01-04 23:24 ` herve at guillemet dot org 2013-03-08 14:08 ` manu at gcc dot gnu.org 2013-03-11 6:29 ` siddhesh at redhat dot com 2013-03-11 6:36 ` siddhesh at redhat dot com 2013-03-11 9:07 ` manu at gcc dot gnu.org 2013-03-11 10:19 ` siddhesh at redhat dot com 2013-08-24 21:39 ` vz-sourceware at zeitlins dot org 2013-12-03 18:42 ` jsm28 at gcc dot gnu.org 2014-02-06 18:27 ` [Bug math/13932] dbl-64 " jsm28 at gcc dot gnu.org 2014-05-07 15:42 ` jsm28 at gcc dot gnu.org 2014-06-12 19:26 ` fweimer at redhat dot com 2020-05-23 19:32 ` mtk.manpages at gmail dot com 2020-05-23 21:31 ` vincent-srcware at vinc17 dot net [this message] 2020-05-25 11:38 ` mtk.manpages at gmail dot com 2020-05-25 12:08 ` vincent-srcware at vinc17 dot net 2020-05-25 13:19 ` mtk.manpages at gmail dot com
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=bug-13932-131-ZPwdXlGqYI@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@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: linkBe 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).