[Python-Dev] Bytecode analysis

[Guido van Rossum]

> > Some stats about JUMP_IF_FALSE opcodes
> > 
> > Of the 2768 JUMP_IF_FALSE opcodes encountered, 2429 have a POP_TOP on
> > both branches.
> > 
> > Id like to propose that JUMP_IF_FALSE consume the top-of-stack.
> 
> I'm all against changing existing opcodes for a minor
> speed-up. Real speed-up is available by a specializing
> compiler which turns things into real code.

If you are referring Psyco, I expect that it is several years before
maturity.  Currently it uses too much memory to be realistic.

> If you really want to change the engine, I would consider
> to emit an extra opcode and try how the change performs
> against a couple of applications. I doubt the effect, since
> the little POP_TOP is pretty fast.

OTOH, compared to the work that POP_TOP does, the work of decoding the
opcodes is significant.

> Where you really can save some time is to shortcut some
> of the very short opcodes to not jump back to the ticker
> counting code, but into a shorter circle. This avoids
> quite some register moves and gives some local optimization
> possibilities.

Some of that is already done (these say 'continue' instead of
'break').  But I'm sure more can be done.

> I would anyway suggest not to change the semantics of
> existing opcodes for just little win.

Why not?  The opcodes are an internal detail of the PVM, and they
change a bit with almost every Python version.

> ...
> 
> > Id like to propose the following opcodes be added
> > LOAD_CONST(NONE)
> > LOAD_CONST(1)
> > LOAD_CONST(0)
> > LOAD_CONST(EMPTY_STR)
> 
> I'd be careful here, too. The interpreter loop is quite
> large, already, and there is a good chance to loose
> locality of reference by adding a little bit of code.
> I had that several times. You don't think you changed
> much, but where are these 10 percent gone now?

Agreed.  This adds more cases to the switch and doesn't reduce the
number of opcodes to be decoded (it only reduces the number of bytes
per opcode, a very meagre gain indeed).

> Not trying to demoralize you completely, but there are
> limits about what can be gathered by optimizing the
> interpreter loop. There was once the p2c project, which
> gave an overall improvement of 25-40 percent, by totally
> removing the interpreter loop.

Yes, that's an upper bound for what you can gain by fiddling upcodes.

There are other gains possible though.  The PVM isn't just the switch
in ceval.c: it is also all the object implementations.  While most are
pretty lean, there's still fluff, e.g. in the lookup of builtins (SF
patch 597907).

--Guido van Rossum (home page: http://www.python.org/~guido/)