[Numpy-discussion] Speed degression?
arnd.baecker at web.de
Thu Jul 6 07:06:25 CDT 2006
On Thu, 6 Jul 2006, Travis Oliphant wrote:
> Steffen Loeck wrote:
> > Hi all,
> > i made some speed tests using the sin-function and the %-operation to compare
> > Numeric, numpy 0.9.8 and numpy 0.9.9.2732.
> > As result the latest numpy version seems to be very slow in comparison to the
> > two other candidates.
> > Results (in usec per loop):
> > sin-array mod-array
> > Numeric 134 18
> > numpy 0.9.8 97 55
> > numpy 0.9.9.2732 204 316
> > numpy 0.9.8 + math 38
> > numpy 0.9.9.2732 + math 161
> > Numeric + math 23
> > Can anyone verify my results and explain the observed speed degression?
> I can't verify the results, but it's possible that the indexing code for
> a single integer is a bit slower.
On the 64Bit machine I get
Results (in usec per loop):
Numeric 34 7
numpy 0.9.9.2746 56 92
numpy 0.9.9.2746 + math 42
Numeric + math 8
Though this does not do the comparison with 0.9.8,
it can roughly reproduce the ratios above.
In particular the mod seems not just a "bit slower", but more than
a factor 5. Also the " + math" variants for the sin
suffered by a factor of 4...
> However, you forgot to test the "use Python lists" approach which is the
> fastest of all on this code.
> python -m timeit -s "x = [0.1]*10;" "for i in xrange(9):
> Using Numeric/NumPy is always slower than lists if you are doing
> element-by-element processing. NumPy is slower than Numeric for such
> processing. But, Numeric was always slower than pure Python too for
> such processing. So, the moral of the story is:
> "don't compute like that with NumPy (or Numeric)"
Well, the example is a benchmark and not the real code ...
To me it seems that it clearly points out some significant slow-down.
> With that said. I can add back the 1-d integer check in the indexing
> code to see if that speeds things up...
That would be great - I will re-run the tests on the Opteron then.
More information about the Numpy-discussion