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

[Guido van Rossum]

> 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.

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.

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.

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

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

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)