[Python-Dev] Store x Load x --> DupStore

[Michael Hudson]

Guido van Rossum <gvanrossum at gmail.com> writes:

>> Any objections to new peephole transformation that merges a store/load
>> pair into a single step?
>> 
>> There is a tested patch at:  www.python.org/sf/1144842
>> 
>> It folds the two steps into a new opcode.  In the case of
>> store_name/load_name, it saves one three byte instruction, a trip around
>> the eval-loop, two stack mutations, a incref/decref pair, a dictionary
>> lookup, and an error check (for the lookup).  While it acts like a dup
>> followed by a store, it is implemented more simply as a store that
>> doesn't pop the stack.  The transformation is broadly applicable and
>> occurs thousands of times in the standard library and test suite.

I'm still a little curious as to what code creates such opcodes...

> What exactly are you trying to accomplish? Do you have examples of
> code that would be sped up measurably by this transformation? Does
> anybody care about those speedups even if they *are* measurable?
>
> I'm concerned that there's too much hacking of the VM going on with
> too little benefit. The VM used to be relatively simple code that many
> people could easily understand. The benefit of that was that new
> language features could be implemented relatively easily even by
> relatively inexperienced developers. All that seems to be lost, and I
> fear that the end result is going to be a calcified VM that's only 10%
> faster than the original, since we appear to have reached the land of
> diminishing returns here.

In the case of the bytecode optimizer, I'm not sure this is a fair
accusation.  Even if you don't understand it, you can ignore it and
not have your understanding of the rest of the VM affected (I'm not
sure that compile.c has ever been "easily understood" in any case :).

> I don't see any concentrated efforts trying to figure out where the
> biggest pain is and how to relieve it; rather, it looks as if the
> easiest targets are being approached. Now, if these were low-hanging
> fruit, I'd happily agree, but I'm not so sure that they are all that
> valuable.

I think some of the peepholer's work are pure wins -- x,y = y,x
unpacking and the creation of constant tuples certainly spring to
mind.

If Raymond wants to spend his time on this stuff, that's his choice.
I don't think the obfuscation cost is all that high.

> Where are the attempts to speed up function/method calls? That's an
> area where we could *really* use a breakthrough...

The problem is that it's hard!

> Eventually we'll need a radically different approach, maybe PyPy,
> maybe Starkiller.

Yup.

Cheers,
mwh

-- 
  Gevalia is undrinkable low-octane see-through only slightly
  roasted bilge water. Compared to .us coffee it is quite
  drinkable.                                      -- Måns Nilsson, asr