[Python-Dev] Python 3 optimizations continued...

[stefan brunthaler]

>> Changing the bytecode width wouldn't make the interpreter more complex.
>
> No, but I think Stefan is proposing to add a *second* byte code format,
> in addition to the one that remains there. That would certainly be an
> increase in complexity.
>
Yes, indeed I have a more straightforward instruction format to allow
for more efficient decoding. Just going from bytecode size to
word-code size without changing the instruction format is going to
require 8 (or word-size) times more memory on a 64bit system. From an
optimization perspective, the irregular instruction format was the
biggest problem, because checking for HAS_ARG is always on the fast
path and mostly unpredictable. Hence, I chose to extend the
instruction format to have word-size and use the additional space to
have the upper half be used for the argument and the lower half for
the actual opcode. Encoding is more efficient, and *not* more complex.
Using profiling to indicate what code is hot, I don't waste too much
memory on encoding this regular instruction format.


> For example, I still plan to write a JIT for Python at some point. This
> may happen in two months, or in two years. I wouldn't try to stop
> anybody from contributing improvements that may become obsolete with the
> JIT.
>
I would not necessary argue that at least my optimizations would
become obsolete; if you still think about writing a JIT, it might make
sense to re-use what I've got and not start from scratch, e.g.,
building a simple JIT compiler that just inlines the operation
implementations as templates to eliminate the interpretative overhead
(in similar vein as Piumarta and Riccardi's paper from 1998) might be
good start. Thoug I don't want to pre-influence your JIT design, I'm
just thinking out loud...

Regards,
--stefan