[Numpy-discussion] odd performance of sum?
e.antero.tammi at gmail.com
Thu Feb 10 15:29:10 EST 2011
On Thu, Feb 10, 2011 at 8:16 PM, Robert Kern <robert.kern at gmail.com> wrote:
> On Thu, Feb 10, 2011 at 11:53, eat <e.antero.tammi at gmail.com> wrote:
> > Thanks Chuck,
> > for replying. But don't you still feel very odd that dot outperforms sum
> > your machine? Just to get it simply; why sum can't outperform dot?
> > architecture (computer, cache) you have, it don't make any sense at all
> > when performing significantly less instructions, you'll reach to spend
> > time ;-).
> These days, the determining factor is less often instruction count
> than memory latency, and the optimized BLAS implementations of dot()
> heavily optimize the memory access patterns.
Can't we have this as well with simple sum?
> Additionally, the number
> of instructions in your dot() probably isn't that many more than the
> sum(). The sum() is pretty dumb
But does it need to be?
> and just does a linear accumulation
> using the ufunc reduce mechanism, so (m*n-1) ADDs plus quite a few
> instructions for traversing the array in a generic manner. With fused
> multiply-adds, being able to assume contiguous data and ignore the
> numpy iterator overhead, and applying divide-and-conquer kernels to
> arrange sums, the optimized dot() implementations could have a
> comparable instruction count.
Couldn't sum benefit with similar logic?
> If you were willing to spend that amount of developer time and code
> complexity to make platform-specific backends to sum()
Actually I would, but I'm not competent at all in that detailed level (:,
But I'm willing to spend more on my own time for example for testing,
debugging, analysing various improvements and suggestions if such emerge.
> , you could make
> it go really fast, too. Typically, it's not all that important to make
> it worthwhile, though. One thing that might be worthwhile is to make
> implementations of sum() and cumsum() that avoid the ufunc machinery
> and do their iterations more quickly, at least for some common
> combinations of dtype and contiguity.
Well I'm allready perplexd before reaching that 'ufunc machinery', it's
actually anyway trivial (for us more mortal ;-) to figure out what's
happening with sum on fromnumeric.py!
> Robert Kern
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
> -- Umberto Eco
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion