This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 929388 - serious CPU time regressions in the glibc math library
serious CPU time regressions in the glibc math library
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: glibc (Show other bugs)
6.4
x86_64 Linux
urgent Severity high
: rc
: ---
Assigned To: Carlos O'Donell
Arjun Shankar
: ZStream
: 892635 (view as bug list)
Depends On:
Blocks: 964044
  Show dependency treegraph
 
Reported: 2013-03-30 06:58 EDT by Peter van Hoof
Modified: 2016-11-24 11:00 EST (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
A previous fix to prevent logic errors in various mathematical functions, including exp(), exp2(), expf(), exp2f(), pow(), sin(), tan(), and rint(), created CPU performance regressions for certain inputs. The performance regressions have been analyzed and the core routines have been optimized to raise CPU performance to expected levels.
Story Points: ---
Clone Of:
: 948822 (view as bug list)
Environment:
Last Closed: 2013-11-21 05:44:17 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test case used for getting the timings (196 bytes, text/x-c++src)
2013-03-30 06:58 EDT, Peter van Hoof
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 229993 None None None Never

  None (edit)
Description Peter van Hoof 2013-03-30 06:58:00 EDT
Created attachment 718234 [details]
test case used for getting the timings

Description of problem: When upgrading from RHEL 6.3 to 6.4 we noticed that our code ran noticeably longer, sometimes up to a factor two longer. We could track this down to serious CPU time regressions in the glibc math library. We have investigated 5 routines in the math library: exp(), pow(), sin(), and cos() all showed CPU time regression to varying degrees, while expf() clearly is faster (though we rarely use that in our code). We have not investigated other math routines, but we suspect that many more routines will show CPU time regressions.

These are the timings (in seconds) we got for the attached program:

         RHEL6.3 RHEL6.4 AMD
exp():   12.17   47.03   9.38

Using a slightly modified version of the program we found:

pow():   28.94   63.57   24.05 [x += pow(x,-0.9)]
sin():   158.91  192.35  14.43 [x += sin(x)]
cos():   157.27  191.47  14.38 [x += cos(x)]
expf():  93.92   10.58   8.35  [x += expf(-x)]

Though the speedup of the single-precision routine expf() is certainly welcome, it looks like it has been achieved at the expense of serious regressions in the double-precision routines (exp() almost by a factor 4, pow() more than a factor 2). Since the use of the double-precision variants will likely be dominant (it certainly is in our code) this needs to be fixed urgently. It is also obvious that the sin() and cos() functions (and likely other trigonometric functions) are embarrassingly slower than the AMD versions...

Going over the CPU times, I noticed that the absolute difference in run time for the double-precision test cases is nearly constant: exp(): +34.86 sec, pow(): +34.63 sec, sin(): +33.44 sec, cos(): +34.20 sec. This suggests that common code has been added to all double-precision routines that gobbles up a large amount of CPU time.

How reproducible: always

Steps to Reproduce: Compile the attached program with "g++ -O2 -ffast-math", then run with "time ./a.out". The timings were done using the glibc math libraries from RHEL 6.3 (glibc-2.12-1.80.el6_3.5.x86_64) and 6.4 (glibc-2.12-1.107.el6.x86_64), as well as the AMD math library v3.0.2 available here: http://developer.amd.com/tools/cpu-development/libm/

Timings were done on an otherwise empty system (with an Intel Xeon E5-2687W processor), and were repeated 3 times to check for accuracy. The median "user" run time is reported. Choosing the math library was done by setting the LD_LIBRARY_PATH variable. The executable was not modified in the process.
  
Actual & Expected results: the timings are shown above. Ideally the glibc math library should be as fast as the AMD version or faster, but at least it should not be slower then the RHEL 6.3 version.
Comment 1 Siddhesh Poyarekar 2013-04-01 03:28:22 EDT
Could you please try the packages here and see if they solve your problem:

http://people.redhat.com/yoguma/.bz892635/

Those are just for testing, so please don't deploy them on your production systems.
Comment 2 Peter van Hoof 2013-04-02 02:08:56 EDT
With package glibc-2.12-1.107.el6.1.bz892635.x86_64.rpm I get the following timings:

exp(): 13.73
pow(): 30.30
sin(): 158.70
cos(): 158.23
expf(): 10.60

So the CPU regression is largely solved in this version, though exp() and pow() are still somewhat slower than their RHEL6.3 counterparts.
Comment 3 Siddhesh Poyarekar 2013-04-02 02:18:58 EDT
OK, thanks for confirming that.
Comment 4 Siddhesh Poyarekar 2013-04-02 02:21:51 EDT
*** Bug 892635 has been marked as a duplicate of this bug. ***
Comment 10 Peter van Hoof 2013-05-08 05:53:13 EDT
requested information was already supplied in Comment 2.
Comment 21 errata-xmlrpc 2013-11-21 05:44:17 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-1605.html

Note You need to log in before you can comment on or make changes to this bug.