<p dir="ltr">On 18 Feb 2014 10:21, "Julian Taylor" <<a href="mailto:jtaylor.debian@googlemail.com">jtaylor.debian@googlemail.com</a>> wrote:<br>
><br>
> On Mon, Feb 17, 2014 at 9:42 PM, Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br>
> > On 17 Feb 2014 15:17, "Sturla Molden" <<a href="mailto:sturla.molden@gmail.com">sturla.molden@gmail.com</a>> wrote:<br>
> >><br>
> >> Julian Taylor <<a href="mailto:jtaylor.debian@googlemail.com">jtaylor.debian@googlemail.com</a>> wrote:<br>
> >><br>
> >> > When an array is created it tries to get its memory from the cache and<br>
> >> > when its deallocated it returns it to the cache.<br>
> >><br>
> ...<br>
> ><br>
> > Another optimization we should consider that might help a lot in the same<br>
> > situations where this would help: for code called from the cpython eval<br>
> > loop, it's afaict possible to determine which inputs are temporaries by<br>
> > checking their refcnt. In the second call to __add__ in '(a + b) + c', the<br>
> > temporary will have refcnt 1, while the other arrays will all have refcnt<br>
> >>1. In such cases (subject to various sanity checks on shape, dtype, etc) we<br>
> > could elide temporaries by reusing the input array for the output. The risk<br>
> > is that there may be some code out there that calls these operations<br>
> > directly from C with non-temp arrays that nonetheless have refcnt 1, but we<br>
> > should at least investigate the feasibility. E.g. maybe we can do the<br>
> > optimization for tp_add but not PyArray_Add.<br>
> ><br>
><br>
> this seems to be a really good idea, I experimented a bit and it<br>
> solves the temporary problem for this types of arithmetic nicely.<br>
> Its simple to implement, just change to inplace in<br>
> array_{add,sub,mul,div} handlers for the python slots. Doing so does<br>
> not fail numpy, scipy and pandas testsuite so it seems save.<br>
> Performance wise, besides the simple page zeroing limited benchmarks<br>
> (a+b+c), it also it brings the laplace out of place benchmark to the<br>
> same speed as the inplace benchmark [0]. This is very nice as the<br>
> inplace variant is significantly harder to read.</p>
<p dir="ltr">Sweet.</p>
<p dir="ltr">> Does anyone see any issue we might be overlooking in this refcount ==<br>
> 1 optimization for the python api?<br>
> I'll post a PR with the change shortly.</p>
<p dir="ltr">It occurs belatedly that Cython code like<br>
  a = np.arange(10)<br>
  b = np.arange(10)<br>
  c = a + b<br>
might end up calling tp_add with refcnt 1 arrays. Ditto for same with cdef np.ndarray or cdef object added. We should check...</p>
<p dir="ltr">-n</p>