[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