This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients arigo, christian.heimes, lemburg, pitrou
Date 2008-12-31.16:15:20
SpamBayes Score 1.53253e-06
Marked as misclassified No
Message-id <1230740121.10858.30.camel@localhost>
In-reply-to <>
> I'm having trouble understanding the technique of the jump table. Can
> you provide some links to papers that explain the threaded code? I'm
> interested in learning more.

I haven't read any papers. Having a jump table in itself isn't special
(the compiler does exactly that when compiling the switch() statement).
What's special is that a dedicated indirect jump instruction at the end
of each opcode helps the CPU make a separate prediction for which opcode
follows the other one, which is not possible with a switch statement
where the jump instruction is shared by all opcodes. I believe that's
where most of the speedup comes from.

If you read the patch it will probably be easy to understand.

I had the idea to try this after a thread on pypy-dev, there are more
references there:

> How does your implementation compare to the GForth based threaded code
> speedwise?

Don't know! Your experiments are welcome. My patch is far simpler to
integrate though (it's small, introduces very few changes and does not
break any existing tests).
Date User Action Args
2008-12-31 16:15:22pitrousetrecipients: + pitrou, lemburg, arigo, christian.heimes
2008-12-31 16:15:21pitroulinkissue4753 messages
2008-12-31 16:15:20pitroucreate