[Numpy-discussion] NumPy re-factoring project

Charles R Harris charlesr.harris at gmail.com
Thu Jun 10 23:43:44 EDT 2010


On Thu, Jun 10, 2010 at 8:40 PM, Sturla Molden <sturla at molden.no> wrote:

> Den 11.06.2010 03:02, skrev Charles R Harris:
> >
> > But for an initial refactoring it probably falls in the category of
> > premature optimization. Another thing to avoid on the first go around
> > is micro-optimization, as it tends to complicate the code and often
> > doesn't do much for performance.
>
>
>
>
> First, to refractor NumPy we must get rid of array iterators as Python
> objects. Retaining them as Python objects defies the whole purpose.
> Second, creating an array of pointers has the advantage of being more
> friendly to OpenMP and multi-core CPUs. We don't need to serialize
> access to an iterator, and we allow OpenMP to do load balancing. For
> things like FFT on vectors along an axis in a multidimensional array
> (e.g. in multi-dimensional FFTs), this is not a micro-optimization. Not
> to mention that it is easier to iterate over an array than use a
> complicated iterator object in C.
>
>
How does that work doing ffts along all axis? What about slicing and views,
axis rolling and transposes? Furthermore, if you are just going to add two
discontiguous arrays, or take the sine, making copies is wasted effort. I
think those things definitely fall in the category of optimizations for many
things and will just be a distraction from the real problems of the
refactoring.

When I say micro-optimization, I am not talking about such things, however.
Micro-optimization is such things as loop unrolling, which while it can
greatly speed up some things adds a lot of obfuscating code when the first
priority is to get things right. Another example would be trying to get a
tad more speed using pointers instead of indexes, an optimization which also
tends to be architecture dependent. Or using a ton of macros instead of
subroutines or inline functions. So on and so forth. I think in these things
the first priority is to have something readable and debuggable with clear
lines of control flow. This is easier said than done, of course.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20100610/a6a5142d/attachment.html>


More information about the NumPy-Discussion mailing list