[Python-Dev] new bytecode results

[M.-A. Lemburg]

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