On Thu, Jun 10, 2010 at 8:40 PM, Sturla Molden <stu...@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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
