| Summary: | Fix libm performance by relaxing ULP errors. | ||
|---|---|---|---|
| Product: | glibc | Reporter: | Siddhesh Poyarekar <siddhesh> |
| Component: | manual | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | bugdal, carlos, manu, mtk.manpages, nszabolcs, roland, wdijkstr |
| Priority: | P2 | Flags: | fweimer:
security-
|
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
|
Description
Siddhesh Poyarekar
2013-03-11 06:35:05 UTC
Some background on why such documentation could save a lot of frustration can be found in bug 13932, and in http://entropymine.com/imageworsener/slowpow/, and simply by googling "slowpow". Shouldn't this issue just be fixed? IEEE specifically omits the requirement of correct rounding for transcendental functions because of the long-known issue that there's no known efficient way to compute the correctly-rounded results. As far as I can tell, no other libm implementations have these performance bugs; they're unique to glibc and the "IBM Accurate Mathematical Library" written for glibc. (In reply to comment #2) > Shouldn't this issue just be fixed? IEEE specifically omits the requirement of > correct rounding for transcendental functions because of the long-known issue > that there's no known efficient way to compute the correctly-rounded results. > As far as I can tell, no other libm implementations have these performance > bugs; they're unique to glibc and the "IBM Accurate Mathematical Library" > written for glibc. Sorry, are you advocating we "fix it" as opposed to "document it?" If you are then I agree, but documenting things until you fix them is a good intermediate step. At least since release 4.04, the Linux man-pages say: On 64-bits, pow() may be more than 10,000 times slower for some (rare) inputs than for other nearby inputs. This affects only pow(), and not powf() nor powl(). I'm going to retitle this bug and instead of saying we're going to document the performance issues, we should fix them. We have already agreed to relax the ULPs to 9 ULPs for all functions and thus remove the MP-fallback paths in these cases. We have just had a user report that: * acos * asin Both have MP-fallback cases that are very bad and should be fixed. Szabolcs Nagy from Arm has worked on many of these fixes. All slow paths have now been removed from all math functions. |