[Python-Dev] new bytecode results

[M.-A. Lemburg]

damien morton wrote:
>>From: M.-A. Lemburg [mailto:mal@lemburg.com] 
>>
>>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
> 
> 
> Are you suggesting a test for LOAD_FAST before the switch, 
> 
> e.g.
> if (opcode == LOAD_FAST) {
>  // load fast
> }
> else switch (opcode) {
>  // body
> }

Yes.

>>b) splitting the switch statement in two: the first one for
>>    more commonly used opcodes, the second one for less often
>>    used opcodes
> 
> 
> Are you suggesting something like: 
> 
> switch (opcode) {
>  case COMMON_OP:
>  case COMMON_OP:
>  ...
>  default:
>    switch (opcode) {
>      case UNCOMMON_OP:
>      case UNCOMMON_OP:
> }

Yes, except that in the default case the code is placed after the
first switch.

switch (opcode) {
  case COMMON_OP:
    goto nextInstruction;
  case COMMON_OP:
  ...
    goto nextInstruction;
  default:
    ;
}

switch (opcode) {
  case UNCOMMON_OP:
  case UNCOMMON_OP:
}
goto nextInstruction;

> Or something like this:
> 
> switch (opcode) {
>  case COMMON_OP:
>  case COMMON_OP:
>  ...
>  default:
>    handle_uncommon_ops();
> }

That's hard to do because the loop has so many variables
to pass into handle_uncommon_ops(). I haven't tried
it though (or at least I don't remember trying it :-),
so perhaps this is even better.

>>c) ordering cases in the switch statements by usage frequency
>>    (using average opcode usage frequencs obtained by
>>    instrumenting the interpreter)
> 
> I might try a little simulated annealing to generate layouts with high
> frequency opcodes near the front and coorcurring opcodes near each
> other.

I did that by hand, sort of :-) The problem is that the
scoring phases takes rather long, so you better start with
a good guess.

>>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 28 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford:                                     32 days left
EuroPython 2003, Charleroi, Belgium:                       116 days left