[Numpy-discussion] strange sin/cos performance

[Andrew Friedley]

David Cournapeau wrote:
> On Wed, Aug 5, 2009 at 12:14 AM, Andrew Friedley<afriedle@indiana.edu> wrote:
> 
>> 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
> 
> Exact. Given your CPU, compared to my macbook, it looks like the
> float32 is the problem (i.e. the float64 is not particularly fast). I
> really can't see what could cause such a slowdown: the range over
> which you evaluate sin should not cause denormal numbers - just to be
> sure, could you try the same benchmark but using a simple array of
> constant values (say numpy.ones(1000)) ? Also, you may want to check
> what happens if you force raising errors in case of FPU exceptions
> (numpy.seterr(raise="all")).

OK, have some interesting results.  First is my array creation was not 
doing what I thought it was.  This (what I've been doing) creates an 
array of 159161 elements:

numpy.arange(0.0, 1000, (2 * 3.14159) / 1000, dtype=numpy.float32)

Which isn't what I was after (1000 elements ranging from 0 to 2PI).  So 
the values in that array climb up to 999.999.

Running with numpy.ones() gives a much different timing (I did 
numpy.ones(159161) to keep the array lengths the same):

sin float32 0.078202009201
sin float64 0.0767619609833
cos float32 0.0750858783722
cos float64 0.088515996933

Much better, but still a little strange, float32 should be relatively 
faster yet.  I tried with 1000 elements and got similar results.

So the performance has something to do with the input values.  This is 
believable, but I don't think it explains why float32 would behave that 
way and not float64, unless there's something else I don't understand.

Also I assume you meant seterr(all='raise').  This didn't seem to do 
anything, I don't have any exceptions thrown or other output.

Andrew