Does CPython already has Peephole optimizations?

[Laxmikant Chitare]

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 Mon, 17 Feb 2014 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>