Performance degradation for some double precision math functions after upgrade to glibc-2.5-81.el5_8.7
Environment
- Red Hat Enterprise Linux 5
glibc-2.5-81.el5_8.7
Issue
Certain double precision math functions (exp, sin, cos, tan) have slowed down significantly after the upgrade to glibc-2.5-81.el5_8.7, with factors between approximately 3.5 to 6.5.
Resolution
- This issue is fixed in
glibc-2.5-118.
A fix to prevent logic errors in various mathematical functions, including
exp(), exp2(), expf(), exp2f(), pow(), sin(), tan(), and rint(), caused by
inconsistent results when the functions were used with the non-default rounding
mode, creates performance regressions for certain inputs. The performance
regressions have been analyzed and the core routines have been optimized to
improve performance. (BZ#861871)
Root Cause
glibc-2.5-81.el5_8.7 is from RHSA-2012-1207 which included a fix for the following following bug:
* Previously, logic errors in various mathematical functions, including exp,
exp2, expf, exp2f, pow, sin, tan, and rint, caused inconsistent results when
the functions were used with the non-default rounding mode. This could also
cause applications to crash in some cases. With this update, the functions now
give correct results across the four different rounding modes. (BZ#839411)
There are currently no plans to change this code or revert that patch. It was necessary to fix correctness/accuracy issues in various floating point routines.
glibc prioritizes floating point accuracy over floating point performance and it is often the case that fixing accuracy issues can cause raw performance to degrade in the math library.
Through private bugzilla #506398, Red Hat Engineering is investigating the use of alternate library code (Content from lipforge.ens-lyon.fr is not included.CRlibm) that would be used for certain pathological performance cases in the math library. Related to this are the Content from sourceware.org is not included.Observations on libm in the upstream wiki. These efforts may result in improvements for future releases of Red Hat Enterprise Linux. There are no plans to backport such improvements to Red Hat Enterprise Linux 5.
Background
The implementation of the affected functions uses the implementation of exp. That implementation of exp has basically two major code paths.
The first path is used for the vast majority of inputs and is very fast. We preform a series of straightforward, straight-line (non-looping) calculations and get a result which we can test for accuracy.
When those calculations have an error range that is too large for the resulting value to have proper numerical accuracy (.5 Content from en.wikipedia.org is not included.ULPs) we then are forced to use a multi-precision library which is orders of magnitude slower.
The multiprecision library basically converts the input to an internal representation with significantly more bits of precision and performs the exponentiation. Depending on the exact values passed to exp, those internal values and intermediates will need to have either 6X or 32X the precision to ensure the resulting value after exponentiation will have proper numerical accuracy. Needless to say, this is very slow, but currently necessary.
Other routines can exhibit the same behaviour across certain inputs -- pow in particular.
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.