Damien Morton wrote:
I tried adding a variety of new instructions to the PVM, initially with a code compression goal for the bytecodes, and later with a performance goal. ... Conclusions:
While reducing the size of compiled bytecodes by about 1%, the proposed modifications at best increase performance by 2%, and at worst reduce performance by 3%.
Enabling all of the proposed opcodes results in a 1% performance loss.
In general, it would seem that adding opcodes in bulk, even if many opcodes switch to the same labels, results in a minor performance loss.
The general problem with the ceval switch statement is that it is too big. Adding new opcodes will only make it bigger, so I doubt that much can be gained in general by trying to come up with new do-everything-in-one-opcode cases. Back in the 1.5.2 days I played a lot with the ceval loop and the best results I got came from: a) moving the LOAD_FAST opcode out of the switch b) splitting the switch statement in two: the first one for more commonly used opcodes, the second one for less often used opcodes c) ordering cases in the switch statements by usage frequency (using average opcode usage frequencs obtained by instrumenting the interpreter) The last point is probably compiler dependent. GCC has the tendency to use the same layout for the assembler code as you use in the C source code, so placing often used code close to the top results in better locality (at least on my machines). -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 27 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
Python UK 2003, Oxford: 33 days left EuroPython 2003, Charleroi, Belgium: 117 days left