On Wednesday, April 13, 2016 09:25, Victor Stinner wrote:
The side effect of wordcode is that arguments in 0..255 now uses 2 bytes per instruction instead of 3, so it also reduce the size of bytecode for the most common case.
Larger argument, 16-bit argument (0..65,535), now uses 4 bytes instead of 3. Arguments are supported up to 32-bit: 24-bit uses 3 units (6 bytes), 32-bit uses 4 units (8 bytes). MAKE_FUNCTION uses 16-bit argument for keyword defaults and 24-bit argument for annotations. Other common instruction known to use large argument are jumps for bytecode longer than 256 bytes.
A couple months ago during an earlier discussion of wordcode, I got curious enough to instrument dis.dis so that I could calculate the actual size changes expected in practice. I ran it on a large chunk of our product code, here are the results (looks best with a fixed font). I suspect the fairly significant reduction in footprint will also give better cache hit characteristics, so we might see some "magic" speed ups from that, too.
Code-generating source lines = 70,792 Total bytes = 1,196,653 Argument-bearing operators = 380,978 Operands over 1 byte long = 12,191 Extended arguments = 0 Percentage of 1-byte args = 96.80%
Total operators = 434,697 Non-argument ops = 53,719 One-byte args = 368,787 Multi-byte args = 12,191 Byte code size = 1,196,653 Word code size = 893,776 Word:byte size = 74.69%
Just for the record, here's my arithmetic: byteCodeSize = 1*nonArgumentOps + 3*oneByteArgs + 3*multiByteArgs wordCodeSize = 2*nonArgumentOps + 2*oneByteArgs + 4*multiByteArgs
(It is interesting to note that I have never encountered an EXTENDED_ARG operator in the wild, only in my own synthetic examples.)