Bug 15267 - Add note on performance characteristics of some libm functions
Summary: Add note on performance characteristics of some libm functions
Status: NEW
Alias: None
Product: glibc
Classification: Unclassified
Component: manual (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-11 06:35 UTC by Siddhesh Poyarekar
Modified: 2014-06-13 18:43 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Siddhesh Poyarekar 2013-03-11 06:35:05 UTC
libm has a fallback to multiprecision calculation for some functions (log, exp, atan, pow, etc.) which is much slower than the fast path.  While the inputs that trigger this are unknown, it would be useful to document the fact that there is such a performance difference, along with an explanation of why the multiprecision stage is needed at all.
Comment 1 Manuel López-Ibáñez 2013-03-11 09:10:09 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".
Comment 2 Rich Felker 2013-03-15 05:57:21 UTC
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.
Comment 3 Carlos O'Donell 2013-03-15 14:37:59 UTC
(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.