[Numpy-discussion] Speed degression?

Arnd Baecker arnd.baecker at web.de
Thu Jul 6 07:06:25 CDT 2006


Hi Travis,

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):
                                     sin-array            mod-array
 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):
> x[i+1]=(x[i]+1.1)%(1.0)"
>
>
> 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.

Many thanks,

Arnd




More information about the Numpy-discussion mailing list