[Python-Dev] [numpy wishlist] Interpreter support for temporary elision in third-party classes
Terry Reedy
tjreedy at udel.edu
Fri Jun 6 00:57:32 CEST 2014
On 6/5/2014 4:51 PM, Nathaniel Smith wrote:
> In fact, AFAICT it's 100% correct for libraries being called by
> regular python code (which is why I'm able to quote benchmarks at you
> :-)). The bytecode eval loop always holds a reference to all operands,
> and then immediately DECREFs them after the operation completes. If
> one of our arguments has no other references besides this one, then we
> can be sure that it is a dead obj walking, and steal its corpse.
>
> But this has a fatal flaw: people are unreasonable creatures, and
> sometimes they call Python libraries without going through ceval.c
> :-(. It's legal for random C code to hold an array object with a
> single reference count, and then call PyNumber_Add on it, and then
> expect the original array object to still be valid. But who writes
> code like that in practice? Well, Cython does. So, this is no-go.
I understand that a lot of numpy/scipy code is compiled with Cython, so
you really want the optimization to continue working when so compiled.
Is there a simple change to Cython that would work, perhaps in
coordination with a change to numpy? Is so, you could get the result
before 3.5 comes out.
I realized that there are other compilers than Cython and non-numpy code
that could benefit, so that a more generic solution would also be good.
In particular
> Here's the idea. Take an innocuous expression like:
>
> result = (a + b + c) / c
>
> This gets evaluated as:
>
> tmp1 = a + b
> tmp2 = tmp1 + c
> result = tmp2 / c
...
> There's an obvious missed optimization in this code, though, which is
> that it keeps allocating new temporaries and throwing away old ones.
> It would be better to just allocate a temporary once and re-use it:
> tmp1 = a + b
> tmp1 += c
> tmp1 /= c
> result = tmp1
Could this transformation be done in the ast? And would that help?
A prolonged discussion might be better on python-ideas. See what others say.
--
Terry Jan Reedy
More information about the Python-Dev
mailing list