Does CPython already has Peephole optimizations?

Tue Feb 18 00:11:05 EST 2014

Thank you all for the enlightening inputs. I have learnt a lot just with
this one question. Great to know about dis library. Ned, from explanation
I now realize how important it is to do impact analysis. Things are not
always rosy :).
I have always appreciated everyone over this list. This is just another
opportunity.
Best regards,
Laxmikant
On Mon, Feb 17, 2014 at 7:21 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 2/17/2014 3:59 AM, Steven D'Aprano wrote:
>>> On 2014年2月17日 13:54:25 +0530, Laxmikant Chitare wrote:
>>>> I read about this article:
>>> http://www.python.org/workshops/1998-11/proceedings/papers/montanaro/
>>>>> montanaro.html
>>>>>>>> Just wanted to clarify whether CPython already includes these kind of
>>> byte code optimizations?
>>>>>> Most of the easily seen and obviously safe low-hanging fruits for the
> compile step have been plucked. Note that the effect of the peephole
> process would only save a few percent, if any, for real apps*. Improving
> the C code invoked by bytecode has resulted in much larger gains.
>> * We now have a much better benchmark suite with some real apps. This is
> thanks in part to the pypy project.
>>> Are all the temporary variables removed when byte code is generated?
>>>>>>> You can check these things for yourself:
>>>> import dis
>> dis.dis(function)
>>>> will show you the byte code.
>>>> But in general, I would expect not. CPython (that's the Python you
>> probably use) doesn't do a lot of optimization apart from some simple
>> constant folding. If you're interested in optimizing Python, you should
>> look at the JIT optimizing Python compiler, PyPy.
>>>> For CPython, new optimization has mostly moved to AST tranformations prior
> to compilation. (Python ASTs are new since Skip started the peephole work.)
> I believe there are some open issues on the tracker.
>> Once optimization constraint Skip did not mention is the correspondence
> between source lines and blocks of bytecode, which is used by profiling,
> tracing, and tracebacks. Effectively transforming
>> if type(a) == types.ComplexType:
> x = cmath.sin(a)
> foo(x)
> else:
> x = math.sin(a)
> foo(x)
>> into
>> if type(a) == types.ComplexType:
> x = cmath.sin(a)
> else:
> x = math.sin(a)
> foo(x)
>> breaks the correspondence. If foo(x) raises, which original line should be
> reported as the source of the exception?
>> --
> Terry Jan Reedy
>> --
> https://mail.python.org/mailman/listinfo/python-list
>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20140218/87de1089/attachment.html>