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. +1 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, Hans _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
