Feature Requests item #1764638, was opened at 2007-07-31 09:12
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1764638&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Paul Pogonyshev (doublep)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: add new bytecodes: JUMP_IF_{FALSE|TRUE}_AND_POP
Initial Comment:
In disassembled code of Python functions I often see stuff like this:
421 JUMP_IF_FALSE 14 (to 438)
424 POP_TOP
1178 ...
435 JUMP_FORWARD 1 (to 439)
>> 438 POP_TOP
>> 439 END_FINALLY
Note how both branches of execution after JUMP_IF_FALSE do POP_TOP. This
causes the true-branch add JUMP_FORWARD, the only purpose of which is to bypass
the POP_TOP command.
I propose adding two new bytecodes, JUMP_IF_FALSE_AND_POP and
JUMP_IF_TRUE_AND_POP. Their semantics would be the same as that of existing
JUMP_IF_FALSE/JUMP_IF_TRUE except the commands would also pop the stack once,
after checking whether to jump. This would simplify the above code to just
421 JUMP_IF_FALSE_AND_POP 14 (to 438)
1178 ...
>> 438 END_FINALLY
This shortens bytecode by 5 bytes and both execution branches, by 1 and 2
commands correspondingly.
I'm willing to create a patch, if this sounds like a worthwile improvement.
Maybe it is better to skip 2.6 and target it for 3000 instead.
----------------------------------------------------------------------
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-08-01 23:24
Message:
Logged In: YES
user_id=80475
Originator: NO
This was looked at and rejected long ago.
The main reasons were that the new code would interfere with and
complicate other byte code optimizations. Also, the need was mitigated
almost entirely by the predict macros.
----------------------------------------------------------------------
Comment By: Paul Pogonyshev (doublep)
Date: 2007-08-01 16:52
Message:
Logged In: YES
user_id=1203127
Originator: YES
I have made first stab at this. It shows about 2% speedup on pystone,
even though peephole optimizer does no related optimizations for new
bytecodes yet.
Note that having separate entries in ceval.c's switch() for the new
bytecodes is essential. Perhaps because they are also used for prediction,
not sure.
File Added: new-bytecodes.diff
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1764638&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
