[Python-Dev] Bytecode analysis

[Christian Tismer]

Guido van Rossum wrote:
> We should probably stop while we're chasing Fredrik away again :-),

not by this discussion which he probably likes :-)

> but there could be some merit in Christian's idea of replacing some of
> the more rarely-used opcodes by function calls, or by some other way
> of encoding these that uses fewer cases in the switch.  But there
> aren't very many of these, so I'm not sure how much it will help.

Well, I haven't done a complete analysis yet, but there
are quite some other candidates for refactoring.
I just stumbled over IMPORT_XXX, which is normally only
used during some initialization code. (Yeah, some people
use it from inside a function, but I don't think it would
break semantics to cache that after the first call...)

UNPACK_SEQUENCE could stop to go through every alternative,
just do the most common tule stuff and otherwise transfer
to a function, which makes the code shorter.

Then, there are 13 new opcodes for the INPLACE_XXX things.
Are they used often enough to deserve so much space?
The code patterns are very similar, despite add and subtract,
which have inlined integer optimization. The latter special case
*might* be considered to be folded into the BINARY_ADD special
case, which looks almost exactly the same?
The code only differs by the
				x = PyNumber_Add(v, w);
vs.
				x = PyNumber_InPlaceAdd(v, w);
fallbacks.

Then, for example, see BINARY_XOR vs. INPLACE_XOR.
These have exactly the same pattern, just a different
function call inside. It can make sense to fold them
back into one, i.e. one case for two opcodes but
indexing the function, or even folding a whole bunch
of these which look so very similar, and having
a plain table of functions, directlyindexec by the
opcode which is probably still sitting in a register.

There are other patterns (randomly picked, since I didn't
intend to really do an analysis now), like here:

		case INPLACE_TRUE_DIVIDE:
		case INPLACE_FLOOR_DIVIDE:
		case INPLACE_MODULO:

The code has the same pattern all the time, popping stuff,
calling a different function, decrefing, pushing result
and handling errors.
I might (might, but that needs investigation) pay off to
fold such similar patterns into one routine, which picks
the only difference (the internal function to be called)
out of a table, instead of repeating all the surrounding
code, explicitly.

(although I generally agree that explicit is better than...:)

So there are lots of ways of folding to try, if somebody
cares. This is hard, anyway, since it is platform dependant
whether it creates an advantage or the opposite, I fear.

> (And we should be careful not to change the semantics.)

Absolutely d'acor - ly -- chris

-- 
Christian Tismer             :^)   <mailto:tismer@tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/