[Python-ideas] More compact bytecode

Antoine Pitrou solipsis at pitrou.net
Sun Feb 7 07:53:35 EST 2016


On Sat, 6 Feb 2016 16:21:11 -0800
Andrew Barnert via Python-ideas
<python-ideas at python.org> wrote:
> 
> To be honest, unlike everyone else on this thread, I'm actually more interested in the simplicity gains than the performance gains.

It is a laudable goal, but what is proposed here wouldn't simplify much
if anything, since some opcodes need more than 8 bits of arguments
(typically the opcodes that have two logical 8-bit arguments packed in
the 16-bit word). So you'll still get variable-sized opcode and need
an adequate decoding machinery for them.

So perhaps bytecode should be processed by the compile chain in the
form of:

typedef struct {
    int opcode;
    int operand;
} instruction_t;

instruction_t *bytecode;

And then get packed at the end, when creating the code object.

> When I'm running CPU-bound code that spends most of its time in CPython itself, it's usually more than fast enough--and, when it isn't, it's almost always an order of magnitude too slow, so adding up all these little 5-10% gains is never going to get us near the point where I can stop using PyPy or Cython or something.

I think that mirrors the experience of many people.  Small perf
improvements are not useless either, because they can make e.g.
command-line tools feel a bit more "snappy".

> (Plus, adding up all these little gains could soon get us to the point where 3.7 finally beats 2.7 in every benchmark, instead of just most of them, which would kill off an annoying source of FUD.)

I think that FUD is very tired now and very few people pay attention to
it. The only major factor slowing down the 2->3 migration is the
effort required for porting.

(also, the breadth of new features and improvements in the 3.x line
massively offsets small degradations on micro-benchmarks)

Regards

Antoine.




More information about the Python-ideas mailing list