[Numpy-discussion] strange sin/cos performance

Andrew Friedley afriedle@indiana....
Mon Aug 3 12:39:39 CDT 2009

David Cournapeau wrote:
>> David Cournapeau wrote:
>>> On Mon, Aug 3, 2009 at 10:32 PM, Andrew Friedley<afriedle@indiana.edu> wrote:
>>>> While working on GSoC stuff I came across this weird performance behavior
>>>> for sine and cosine -- using float32 is way slower than float64.  On a 2ghz
>>>> opteron:
>>>> sin float32 1.12447786331
>>>> sin float64 0.133481025696
>>>> cos float32 1.14155912399
>>>> cos float64 0.131420135498
>>> Which OS are you on ? FWIW, on max os x, with recent svn checkout, I
>>> get expected results (float32 ~ twice faster).
>> The numbers above are on linux, RHEL 5.2.  The PS3 is running Fedora 9 I
>> think.
> I know next to nothing about the PS3 hardware, but I know that it is
> quite different compared to conventional x86 CPU. Does it even have
> both 4 and 8 bytes native  float ?

Yes.  As far as this discussion is concerned, the PS3/Cell is just a 
slow PowerPC.  Quite different from x86, but probably not as different 
as you think :)

>> Much more reasonable, but still not what I'd expect or what you seem to
>> expect.
> On a x86 system with sinf available in the math lib, I would expect
> the float32 to be faster than float64. Other than that, the exact
> ratio depends on too many factors (sse vs x87 usage, cache size,
> compiler, math library performances). One order magnitude slower seems
> very strange in any case.

OK.  I'll probably investigate this a bit further, but I don't have 
anything that really depends on this issue.  It does explain a large 
part of why my cos ufunc was so much faster.

Since I'm observing this on both x86 and PPC (PS3), I don't think its a 
hardware issue -- something in the software stack.  And now there's two 
people reporting results with only different numpy versions.

>>>> The times are in seconds, and are best of three runs of ten iterations of
>>>> numpy.{sin,cos} over a 1000-element array (script attached).  I've produced
>>>> similar results on a PS3 system also.  The opteron is running Python 2.6.1
>>>> and NumPy 1.3.0, while the PS3 has Python 2.5.1 and NumPy 1.1.1.
>>>> I haven't jumped into the code yet, but does anyone know why sin/cos are
>>>> ~8.5x slower for 32-bit floats compared to 64-bit doubles?
>>> My guess would be that you are on a platform where there is no sinf,
>>> and our sinf replacement is bad for some reason.
>> I think linux has sinf, is there a quick/easy way to check if numpy is
>> using it?
> You can look at the config.h in numpy/core/include/numpy, and see if
> there is a HAVE_SINF defined (for numpy >= 1.2.0 at least).

OK, I see HAVE_SINF (and HAVE_COSF) for my 1.3.0 build on the opteron 
system.  I'm using the distro-provided packages on other systems, so I 
guess I can't check those.

I don't think this matters -- numpy/core/src/npy_math.c just defines 
sinf as a function calling sin.  So if HAVE_SINF wasn't set, I'd expect 
the performance different to be very little, with floats still being 
slightly faster (less mem traffic).

Also I just went and wrote a C program to do a similar benchmark, and I 
am unable to reproduce the issue there.  Makes me think the problem is 
in NumPy, but I have no idea where to look.  Suggestions welcome :)


More information about the NumPy-Discussion mailing list