[Numpy-discussion] strange sin/cos performance
Andrew Friedley
afriedle@indiana....
Tue Aug 4 10:14:59 CDT 2009
Charles R Harris wrote:
> On Mon, Aug 3, 2009 at 11:51 AM, Andrew Friedley <afriedle@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