[Numpy-discussion] Performance problems with strided arrays in NumPy

faltet at xot.carabos.com faltet at xot.carabos.com
Sat Apr 15 05:06:01 CDT 2006


On Fri, Apr 14, 2006 at 05:03:06PM -0600, Travis Oliphant wrote:
> What I've found in experiments like this in the past is that numarray is 
> good at striding in one direction but much worse at striding in another 
> direction for multi-dimensional arrays.   Of course my experiments were 
> not complete.  That just seemed to be the case.
> 
> The array-iterator construct handles almost all of these cases.   The 
> copy method is a good place to start since it uses that code.

I'm not sure this is directly related with striding. Look at this:

In [5]: npcopy=timeit.Timer('a=a.copy()','import numpy as np;
a=np.arange(1000000,dtype="Float64")[::10]')

In [6]: npcopy.repeat(3,10)
Out[6]: [0.061118125915527344, 0.061014175415039062,
0.063937187194824219]

In [7]: npcopy2=timeit.Timer('b=a.copy()','import numpy as np;
a=np.arange(1000000,dtype="Float64")[::10]')

In [8]: npcopy2.repeat(3,10)
Out[8]: [0.29984092712402344, 0.29889702796936035, 0.29834103584289551]

You see? assigning to a new variable makes the copy go 5x times
slower! numarray is also affected by this, but not as much:

In [9]: nacopy=timeit.Timer('a=a.copy()','import numarray as np;
a=np.arange(1000000,type="Float64")[::10]')

In [10]: nacopy.repeat(3,10)
Out[10]: [0.039573907852172852, 0.037765979766845703,
0.038245916366577148]

In [11]: nacopy2=timeit.Timer('b=a.copy()','import numarray as np;
a=np.arange(1000000,type="Float64")[::10]')

In [12]: nacopy2.repeat(3,10)
Out[12]: [0.073218107223510742, 0.07414698600769043,
0.072872161865234375]

i.e. just a 2x slowdown. I don't understand this effect: in both cases
we are doing a plain copy, no? I'm missing something, but not sure what
it is.

Regards,

--
Francesc




More information about the Numpy-discussion mailing list