[Numpy-discussion] Performance problems with strided arrays in NumPy
faltet at xot.carabos.com
faltet at xot.carabos.com
Sat Apr 15 10:29:01 EDT 2006
On Sat, Apr 15, 2006 at 07:55:46AM -0700, Tim Hochberg wrote:
> >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!
> >
> You are being tricked! In the first case, the array is discontiguous for
> the first copy but for every subsequenc copy is contiguous since you
> replace 'a'. In the second case, the array is discontiguous for every copy
Oh, yes!. Thanks for noting this!. So in order to compare apples with
apples, the difference between numarray and numpy in case of strided
copies is:
In [87]: npcopy_stride=timeit.Timer('b=a.copy()','import numpy as np;
a=np.arange(1000000,dtype="Float64")[::10]')
In [88]: npcopy_stride.repeat(3,10)
Out[88]: [0.30013298988342285, 0.29976487159729004, 0.29945492744445801]
In [89]: nacopy_stride=timeit.Timer('b=a.copy()','import numarray as np;
a=np.arange(1000000,type="Float64")[::10]')
In [90]: nacopy_stride.repeat(3,10)
Out[90]: [0.07545709609985351, 0.0731458663940429, 0.073173046112060547]
so numpy is aproximately 4x times slower than numarray.
Cheers,
Francesc
More information about the NumPy-Discussion
mailing list