This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug math/14412] Removal of sysdeps/x86_64/fpu/s_sincos.S causes regressions


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]