https://launchpad.net/distros/ubuntu/+source/glibc/+bug/53312 (basically just forewarding what the guy wrote) Architecture: amd64 glibc version 2.3.6-0ubuntu2 gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5) For most values of x, calling tan(x) takes less than a microsecond. However, when x = n*pi/2, n != 0, calling tan(x) takes several hundred microseconds (which it clearly shouldn't do). This doesn't occur when using the tanl or tanf functions.
Created attachment 1469 [details] Demonstrates tan(x) slowness for x=pi/2 The attached program demonstrates the difference between calling tan(x) for random values of x and when x is a multiple of pi/2. When executed, program should display something like: $ g++ tan-test.cpp && ./a.out Random average: 0.0001ms pi/2 average: 0.52ms
Most of the double libm functions are exact up to 0.5ulp and that's the price to pay for a correct implementation. The function first computes the result quickly using FPU instructions and if the maximum error is sufficiently low, just returns it. If the error is possibly bigger than 0.5ulp, it needs to compute longer series to make sure the result is correct.
(I'm the original downstream reporter). I believe the bug report is valid for two reasons: - Neither tanl or tanf suffer from the problem. - The case of x a multiple of pi, at least, should be quick - the result is simply zero.
Neither tanl nor tanf (unfortunately) are precise up to 0.5ulp, see e.g. http://www.inf.ethz.ch/personal/gonnet/FPAccuracy/ testsuite for a proof. And, when expecting exact 0 from a trigonometric function, the computation needed for 0.5ulp precise result is obviously most expensive, not cheapest, because .5ulp for 0.0 is of course orders of magnitude smaller than 0.5ulp for 1.0 (you need error below or equal to 2.47033e-324 for IEEE double, while if result is 1.0, the error needs to be below or equal to 1.110225e-16).