[Python-Dev] Do more at compile time; less at runtime (original) (raw)
Mark Shannon mark at hotpy.org
Sun Dec 9 23:22:19 CET 2012
- Previous message: [Python-Dev] Emacs users: hg-tools-grep
- Next message: [Python-Dev] Do more at compile time; less at runtime
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi all,
The current CPython bytecode interpreter is rather more complex than it needs to be. A number of bytecodes could be eliminated and a few more simplified by moving the work involved in handling compound statements (loops, try-blocks, etc) from the interpreter to the compiler.
This simplest example of this is the while loop... while cond: body
This currently compiled as
start: if not cond goto end body goto start end:
but it could be compiled as
goto test: start: body if cond goto start
which eliminates one instruction per iteration.
A more complex example is a return in a try-finally block.
try: part1 if cond: return X part2 finally: part3
Currently, handling the return is complex and involves "pseudo exceptions", but if part3 were duplicated by the compiler, then the RETURN bytecode could just perform a simple return. The code above would be compiled thus...
PUSH_BLOCK try
part1
if not X goto endif
push X
POP_BLOCK
part3 <<< duplicated
RETURN_VALUE
endif: part2 POP_BLOCK part3 <<< duplicated
The changes I am proposing are:
Allow negative line deltas in the lnotab array (bytecode deltas would remain non-negative) Remove the SETUP_LOOP, BREAK and CONTINUE bytecodes Simplify the RETURN bytecode Eliminate "pseudo exceptions" from the interpreter Simplify (or perhaps eliminate) SETUP_TRY, END_FINALLY, END_WITH. Reverse the sense of the FOR_ITER bytecode (ie. jump on not-exhausted)
The net effect of these changes would be: Reduced code size and reduced code complexity. A small (1-5%)? increase in speed, due the simplification of the bytecodes and a very small change in the number of bytecodes executed. A small change in the static size of the bytecodes (-2% to +2%)?
Although this is a quite intrusive change, I think it is worthwhile as it simplifies ceval.c considerably. The interpreter has become rather convoluted and any simplification has to be a good thing.
I've already implemented negative line deltas and the transformed while loop: https://bitbucket.org/markshannon/cpython-lnotab-signed I'm currently working on the block unwinding.
So, Good idea? Bad idea? Should I write a PEP or is the bug tracker sufficient?
Cheers, Mark.
- Previous message: [Python-Dev] Emacs users: hg-tools-grep
- Next message: [Python-Dev] Do more at compile time; less at runtime
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]