[Python-Dev] Peephole Optimization

Raymond Hettinger python at rcn.com
Thu Feb 19 19:20:22 CET 2009


[Venkatraman S]
> the following line
> kind of confuses me and wasnt sure what exactly Raymond(et al) is planning, 

I think the AST optimization work is being pursued by tlee.
See his current results on the branch:   tlee-ast-optimize/
I don't know if this work has stalled but it was off to a good start.

> as i presume 
> that bytecode optimizations are much _easier_ than optimizations in AST.
. . .
>  "Most of the peepholer is going to be migrated up the chain, 
> after the AST is generated, but before the opcodes are generated." 

I don't think your presumption is true.  For some transformations (especially
constant folding), more is possible with AST than with bytecode.  We won't
know for sure until the work is done and there is a good, working patch.

Right now, the peepholer is limited by basic blocks, by only rewriting opcode
sequences that are same or shorter size, and has to do tricks like writing-out 
NOPs and the eliminating them while rewriting the jump targets.  Essentially,
it disassembles fragments, analyzes them, and reassembles them.  Better to
start before the assembly, do the AST rewrites, and then less the existing
assembler do its thing.   When it comes to optimizing long fragements
and extended args, the peepholer punts and does nothing.  All of this
makes it tightly bound to a given set of opcodes and everything must be
re-evaluated whenever someone proposes a new opcode or changes the
meaning of the existing code.

> If there are some optimizations that can be done in the bytecodes, 
> then 'where' would be the suggested place to incorporate the same;

The "where" is being developed.  Your help would be welcome.

> as i also see that some of the more rudimentary 
> optimizations have been rejected in many of the patches.

A number of patches have been accepted.  The ones that were rejected
were either too complicated, interfered with other optimizations, or did 
too much work for too little payoff (i.e. deadcode elimination which costs
compilation time but doesn't actually speedup code).


Raymond





More information about the Python-Dev mailing list