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.5325284e-06
Marked as misclassified No
Message-id <1230740121.10858.30.camel@localhost>
In-reply-to <1230739325.18.0.0588390159547.issue4753@psf.upfronthosting.co.za>
Content
> 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:
http://codespeak.net/pipermail/pypy-dev/2008q4/004916.html

> 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).
History
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