Bug 15936

Summary: Computing sin and cos is very slow when using AVX-powered processors
Product: glibc Reporter: Francesc Alted <faltet>
Component: mathAssignee: Not yet assigned to anyone <unassigned>
Severity: normal CC: carlos, david.abdurachmanov, zbyszek
Priority: P2 Flags: fweimer: security-
Version: 2.17   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:
Attachments: C program showing an slow behavior of sin/cos

Description Francesc Alted 2013-09-06 09:53:01 UTC
Created attachment 7191 [details]
C program showing an slow behavior of sin/cos

When computing expressions containing sin() and cos() (and possibly more), I am experiencing very slow performance.

In the attachment you can see a program that takes around 2.3 sec on my Intel(R) Core(TM) i5-3380M CPU @ 2.90GHz using openSUSE 12.3 (latest) and glibc 2.17, while in a virtual machine inside this machine (using VirtualBox here) with no support for AVX the time for executing the same code goes down to 0.436 sec (5x faster).  The virtual machine uses Ubuntu Quantal 64 bit with glibc (libc6) 2.15.

The fact that supports my suspicion that AVX support is flaky in libm is that 'perf top' is reporting the next usage in my machine:

 49.72%  libm-2.17.so                 [.] feraiseexcept
 21.34%  libm-2.17.so                 [.] __cos_avx
 20.75%  libm-2.17.so                 [.] __sin_avx
  2.26%  bug-avx                      [.] main

so apparently the AVX versions of cos and sin are incorrectly raising floating point exceptions (feraiseexcept) that should not happen.  In my virtual machine (Ubuntu Quantal 64, glibc 2.15) 'perf top' reports this:

 61.52%  libm-2.15.so        [.] sincos
  8.50%  perf_3.5.0-21       [.] 0x00000000000413f0
  6.45%  libc-2.15.so        [.] 0x000000000008044b
  5.96%  bug-avx             [.] main

We tried a another native OS, Fedora 19, which comes with glibc 2.17 and with a processor that supports AVX, and we are getting an important slowdown too.

Comment 1 Carlos O'Donell 2013-09-07 06:55:06 UTC
I'm closing this as a duplicate of 14412. This issue is fixed in 2.18 and needs to be backported by the distributions to 2.17 and included in their releases.

*** This bug has been marked as a duplicate of bug 14412 ***
Comment 2 David Abdurachmanov 2016-02-04 09:45:13 UTC
Do you recall which commit in glibc resolved the issue?
Comment 3 Carlos O'Donell 2016-02-10 14:26:38 UTC
(In reply to David Abdurachmanov from comment #2)
> Carlos,
> Do you recall which commit in glibc resolved the issue?

There are a whole series of commits for each relevant architecture which requires eliding the save/restore of rounding modes around the relevant functions that only operate correctly in round-to-nearest. So it isn't easy to point out just one commit. It matters the architecture and other factors like incremental improvements.