[Python-Dev] Do more at compile time; less at runtime
Guido van Rossum
guido at python.org
Sun Dec 9 23:43:15 CET 2012
Sounds good to me. No PEP needed, just a tracker item, tests, review etc...
--Guido van Rossum (sent from Android phone)
On Dec 9, 2012 2:24 PM, "Mark Shannon" <mark at hotpy.org> wrote:
> 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:
> This currently compiled as
> if not cond goto end
> goto start
> but it could be compiled as
> goto test:
> if cond goto start
> which eliminates one instruction per iteration.
> A more complex example is a return in a try-finally block.
> if cond:
> return X
> 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
> if not X goto endif
> push X
> part3 <<< duplicated
> 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<https://bitbucket.org/markshannon/cpython-lnotab-signed>
> I'm currently working on the block unwinding.
> Good idea? Bad idea?
> Should I write a PEP or is the bug tracker sufficient?
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev