[Python-ideas] More compact bytecode

Andrew Barnert abarnert at yahoo.com
Sat Feb 6 19:21:11 EST 2016


On Feb 6, 2016, at 11:18, Antoine Pitrou <antoine at python.org> wrote:
> 
> Serhiy Storchaka <storchaka at ...> writes:
>> 
>> 2. Use 16-bit opcodes as in WPython.
>> 
>> This will decrease mean size of opcode from 2.73 to 2.044 bytes (1.33 
>> times). But this might make decoding of 85% opcodes slightly faster.
> 
> It sounds like, by 16-bit opcodes, you mean combine the opcode and the
> argument in
> a single 16-bit word.  But that doesn't solve the issue you want to solve: you
> still have to decode the argument encoded in the 16-bit word.  I don't see
> where the benefit is.

If (at least most of the time) the argument is just the second byte of the two bytes, that decoding is trivial. The cost should be less than the savings of doing one short read instead of three byte reads. (Of course we won't know that for sure until we try.

It should also lets us simplify the eval loop a bit, and simplify all other code that has to deal with bytecode (although I'd like to simplify it even further, as discussed in the other thread).

> It is generally estimated the overhead of bytecode dispatch and decoding is
> around
> 10-30% for CPython. You cannot hope to eliminate that overhead entirely without
> writing a (JIT or AOT) compiler, so any heroic effort to restructure the current
> opcode space and structure will at best win 5 to 20% on select benchmarks.

To be honest, unlike everyone else on this thread, I'm actually more interested in the simplicity gains than the performance gains.

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 don't know whether other people have different use cases where these speedups really do matter, or if they're just chasing micro-optimization of the CPython core for its own sake, but I'm willing to cynically use their desire for an 8% speedup to get them onboard with selling my simplification. :)

(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.)



More information about the Python-ideas mailing list