This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug math/14412] Removal of sysdeps/x86_64/fpu/s_sincos.S causes regressions
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 29 Apr 2013 11:55:09 +0000
- Subject: [Bug math/14412] Removal of sysdeps/x86_64/fpu/s_sincos.S causes regressions
- Auto-submitted: auto-generated
- References: <bug-14412-131 at http dot sourceware dot org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=14412
--- Comment #27 from Rich Felker <bugdal at aerifal dot cx> 2013-04-29 11:55:09 UTC ---
wbrana, "getting the right answer is slow" is not an excuse for giving the
wrong answer. The "optimized" version of sincos has ZERO bits of precision for
certain inputs.
With that said, there are not "35000" apps and libraries to check and send bug
reports to. A quick check with nm(1) will show you which ones even call trig
functions, and it's a tiny fraction of that. Moreover, of those that do, a good
number (anything except gaming and graphics) actually want the correct answer,
not the fast-but-wrong answer, and had bugs that had gone unnoticed with the
old, wrong sincos.
Getting fast-but-wrong math results is easy; you don't need the standard
library for this. The purpose of the C language providing math functions (and
recommending that they conform to IEEE requirements) in the standard library is
to give applications something that would be very difficult to achieve
themselves. Being wrong-by-default but providing a special option to get
correct answers is not a solution because portable programs that were not
written specifically to glibc will not be able to get the right answers. They
would have to encode glibc-specific knowledge to override the incorrect
default. Requiring platform-specific knowledge to get the optimal performance
on a given platform (glibc) is unfortunate but at least justifiable. Requiring
platform-specific knowledge to get the correct results is not justifiable.
With all that said, I still question the cause of the huge performance drop.
The only cost of the correct sin/cos versus the incorrect one should be
argument reduction, which should be a no-op if the argument is already in the
range [-pi,pi] or so and cheap even a good ways outside of that range...
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.