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.

Title: use computed goto's in ceval loop
Type: Stage:
Components: Interpreter Core Versions: Python 2.5
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: loewis, simonb1
Priority: normal Keywords: patch

Created on 2006-01-18 03:21 by simonb1, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit
ceval-cgotos.tgz simonb1, 2006-01-18 03:21 patch and new file Include/opdef.h
Messages (2)
msg49340 - (view) Author: Simon David Burton (simonb1) Date: 2006-01-18 03:21
An experiment where the big switch in ceval.c
is replaced with a computed goto construct.
Uses #define's to make it optional.
Inspired by Mono's MINT interpreter code,
and Neil Norwitz's attempt to use a function
pointer table:

Result: about 1% slower on the pystone benchmark.

Also it seems to have broken the interpreter;
at least one test fails (test_StringIO).

Not sure if the other switch speedup
hacks (eg. PREDICT(op)) conflict 
at all with this patch (ie. make it
slower than it could be).

Mono actually uses a much larger opcode
set, with 2-byte opcodes, that includes
type info in each opcode. This means that
the actual case statements are much faster.
My initial thought about using computed goto's
(January 2003) was that the python opcode cases
were much fatter than mono's (often involving
a function call) and that the overhead of
branching on the opcode would be insignificant.
It seems that this is true indeed.

Patch is for python revision 42025.
msg49341 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-02-17 08:43
Logged In: YES 

I fail to see the point of this patch (why should it be
included if it makes Python slower and breaks it), so I'm
rejecting it.
Date User Action Args
2022-04-11 14:56:15adminsetgithub: 42804
2006-01-18 03:21:12simonb1create