[Numpy-discussion] Ufunc memory access optimization

Hans Meine meine@informatik.uni-hamburg...
Thu Jul 1 10:02:01 CDT 2010

Hi Pauli and Anne,

On Tuesday 15 June 2010 13:37:30 Pauli Virtanen wrote:
> pe, 2010-06-11 kello 10:52 +0200, Hans Meine kirjoitti:
> > At the bottom you can see that he basically wraps all numpy.ufuncs he can
> > find in the numpy top-level namespace automatically.
> Ok, here's the branch:
> http://github.com/pv/numpy-work/compare/master...feature;ufunc-memory-acce
> ss-speedup

Great!  (I did not keep up with the NumPy list lately, sorry.)

Oh, and that was not even so much code, that's good news, too! :-)

> As expected, some improvement can be seen. There's also appears to be
> an additional 5 us (~ 700 inner loop operations it seems) overhead
> coming from somewhere; perhaps this can still be reduced.

How much time would you expect the new optimized reordering to take?
5 µs is not exactly much, right?

Anyhow, thanks a lot for this contribution!

On Tuesday 15 June 2010 20:15:39 Pauli Virtanen wrote:
> Another optimization could be flipping negative strides. This sounds a
> bit dangerous, though, so one would need to think if it could e.g. break
> 	a += a[::-1]
> etc.

I agree that this is more dangerous, yet doing "a += a[::-1]" has always been 
considered dangerous already, right?

> > I'm more worried this may violate some users' assumptions. If a user
> > knows they need an array to be in C order, really they should use
> > ascontiguousarray. But as it stands it's enough to make sure that it's
> > newly-allocated as the result of an arithmetic expression. Incautious
> > users could suddenly start seeing copies happening, or even transposed
> > arrays being passed to, C and Fortran code.
> Yes, it's a semantic change, and we have to make it consciously (and
> conscientiously, to boot :).

I am all ready for the change though.

> Personally, I believe this change is worth making, with suitable mention
> in the release notes.


Also, recall that new users will be bitten by the current behaviour, too.
Imagine how much work Ulli put in the reordering and how he sweared when he 
found out that a simple addition broke all fortran-orderedness of our images.. 

> > [...] We want as many of those operations as possible to operate
> > on contiguous arrays, but it's possible that an out-of-order array
> > could propagate indefinitely, forcing all loops to be done with one
> > array having large strides, and resulting in output that is stil
> > out-of-order.
> I think, at present, non-C-contiguous arrays will propagate
> indefinitely.

Right, but that's a good thing!

Anne wrote:
> > Some preference for C contiguous output is worth adding.

When you talk about the preference for C contiguous arrays, it sounds as if 
Fortran-ordered arrays were somehow evil.  With the new behaviour, that would 
be much less so, because at least ufuncs would not be any slower anymore for 
Fortran arrays.

And numpy would not get into the way of users who are actually trying to use 
Fortran order so much anymore, which is a good thing.

I really don't know how much C-order preference is justified.

Have a nice day,

More information about the NumPy-Discussion mailing list