classification
Title: use computed goto's in ceval loop
Type: Stage:
Components: Interpreter Core Versions: Python 2.5
process
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 2006-02-17 08:43 by loewis. This issue is now closed.

Files
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:

http://sourceforge.net/tracker/index.php?func=detail&aid=693638&group_id=5470&atid=305470

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 
user_id=21627

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.
History
Date User Action Args
2006-01-18 03:21:12simonb1create