[Numpy-discussion] strange sin/cos performance

Andrew Friedley afriedle at indiana.edu
Tue Aug 4 11:14:59 EDT 2009


Charles R Harris wrote:
> On Mon, Aug 3, 2009 at 11:51 AM, Andrew Friedley <afriedle at indiana.edu>wrote:
> 
>> Charles R Harris wrote:
>>> What compiler versions are folks using? In the slow cases, what is the
>>> timing for converting to double, computing the sin, then casting back to
>>> single?
>> I did this, is this the right way to do that?
>>
>> t =
>> timeit.Timer("numpy.sin(a.astype(numpy.float64)).astype(numpy.float32)",
>>                 "import numpy\n"
>>                 "a = numpy.arange(0.0, 1000, (2 * 3.14159) / 1000,
>> dtype=numpy.float64)")
>> print "sin converted float 32/64", min(t.repeat(3, 10))
>>
>> Timings on my opteron system (2-socket 2-core 2GHz):
>>
>> sin float32 1.13407707214
>> sin float64 0.133460998535
>> sin converted float 32/64 0.18202996254
>>
>> Not too surprising I guess.
>>
>> gcc --version shows:
>>
>> gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44)
>>
>> My compile flags for my Python 2.6.1/NumPy 1.3.0 builds:
>>
>> -Os -fomit-frame-pointer -pipe -s -march=k8 -m64
>>
> 
> That looks right. When numpy doesn't find a *f version it basically does
> that conversion. This is beginning to look like a hardware/software
> implementation problem, maybe compiler related. That is, I suspect the fast
> times come from using a hardware implementation. What happens if you use -O2
> instead of -Os?

Do you know where this conversion is, in the code?  The impression I got 
from my quick look at the code was that a wrapper sinf was defined that 
just calls sin.  I guess the typecast to float in there will do the 
conversion, is that what you are referring to, or something at a higher 
level?

I recompiled the same versions of Python/NumPy, using the same flags 
except -O2 instead of -Os, the behavior is still the same.

Andrew



More information about the NumPy-Discussion mailing list