[Numpy-discussion] Performance problems with strided arrays in NumPy
oliphant.travis at ieee.org
Sat Apr 15 10:55:02 CDT 2006
faltet at xot.carabos.com wrote:
> 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 : npcopy=timeit.Timer('a=a.copy()','import numpy as np;
>>> In : npcopy.repeat(3,10)
>>> Out: [0.061118125915527344, 0.061014175415039062,
>>> In : npcopy2=timeit.Timer('b=a.copy()','import numpy as np;
>>> In : npcopy2.repeat(3,10)
>>> Out: [0.29984092712402344, 0.29889702796936035, 0.29834103584289551]
>>> You see? assigning to a new variable makes the copy go 5x times
>> 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 : npcopy_stride=timeit.Timer('b=a.copy()','import numpy as np;
> In : npcopy_stride.repeat(3,10)
> Out: [0.30013298988342285, 0.29976487159729004, 0.29945492744445801]
> In : nacopy_stride=timeit.Timer('b=a.copy()','import numarray as np;
> In : nacopy_stride.repeat(3,10)
> Out: [0.07545709609985351, 0.0731458663940429, 0.073173046112060547]
> so numpy is aproximately 4x times slower than numarray.
This also seems to vary from compiler to compiler. On my system it's
not quite so different (about 1.5x slower).
I'm wondering what the effect of an inlined memmove is. Essentially
numarray has an inlined for-loop to copy bytes while NumPy calles memmove.
I'll try that out and see...
More information about the Numpy-discussion