classification
Title: Extend peepholer to reverse loads or stores instead of build/unpack
Type: performance Stage:
Components: Interpreter Core Versions: Python 3.3
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: rhettinger, serprex
Priority: low Keywords: patch

Created on 2010-12-08 01:25 by serprex, last changed 2011-01-08 10:28 by rhettinger. This issue is now closed.

Files
File name Uploaded Description Edit
peep.diff serprex, 2010-12-08 01:25
Messages (2)
msg123588 - (view) Author: Demur Rumed (serprex) Date: 2010-12-08 01:25
This modifies the peepholer's BUILD/UNPACK_SEQUENCE for the case when all stores are simple, or all loads are simple

It first scans to see if the pushing is done with simple LOADs. If so, it reverses the loads and removes the build unpack. If not, it scans ahead to see if it is followed by simple STOREs. If so, it reverses the stores and removes the build unpack
msg123592 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-12-08 04:02
Thanks for the patch.  I had looked at this long ago when I first added the ROT2 optimization and the ROT3/ROT2 optimization.  It wasn't included because it wasn't worth the added complexity in the peepholer logic and because there were concerns about executing internally in a different order than specified by the code.

Since LOAD_NAME and LOAD_GLOBAL are subject to user control, changing their order of evaluation causes a visible change in semantics.  For example, the following result is different than before the patch.

>>> class Dict(dict):
...     def __getitem__(self, key):
...          print(key)
...          return dict.__getitem__(self, key)
...
>>> ns = Dict()
>>> exec('c=1; d=2; a,b=c,d', globals(), ns)
d
c

For the most part, I'm not too excited about the patch because
* it is limited to very simple cases that already have some optimization
* it needs to be limited even further to be semantically neutral
* it adds complexity to a part of the peepholer that is already a bit too complicated (the more peephole assumptions we make, the harder it is to maintain, especially when opcodes are added, deleted, or changed).
* changing order of execution starts to venture into territory that we've stayed away from (on purpose).
History
Date User Action Args
2011-01-08 10:28:58rhettingersetstatus: open -> closed
resolution: rejected
2010-12-08 04:02:47rhettingersetmessages: + msg123592
2010-12-08 01:33:08rhettingersetpriority: normal -> low
assignee: rhettinger

nosy: + rhettinger
versions: + Python 3.3, - Python 3.2
2010-12-08 01:25:50serprexcreate