
Serhiy Storchaka <storchaka@...> 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. The *byte* size of bytecode is IMO largely unimportant. Python bytecode is synthetic and high-level, its expressive density is much higher than that of native code. I don't think the cache occupancy of bytecode is a significant contributor to Python performance (certainly much less so than the memory consumption of *objects*). (as for the disk occupancy of pyc files, if that is a concern we could actually compress those files; there are very fast compressors with decent efficiency these days, such as lzo or snappy) 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. Regards Antoine.