Each instruction is two codewords, and consists of "opcode, oparg, 0, 0"#100106
Each instruction is two codewords, and consists of "opcode, oparg, 0, 0"#100106iritkatriel wants to merge 8 commits intopython:mainfrom
Conversation
✅ Deploy Preview for python-cpython-preview canceled.
|
gvanrossum
left a comment
There was a problem hiding this comment.
Cool work. So the doubling of the instruction size only costs us 1%. That means if we can realize the removal of LOAD/STORE_FAST and LOAD_CONST we should be able to gain quite a bit.
Do you envision we could do a gradual transition to the register world, where some instructions use registers and others still use the stack?
I think so. A register can be an index into the stack, and some opcodes can just push and pop as before. This makes the transition incremental. |
Sounds good. Maybe we should add that to faster-cpython/ideas#485 (or one of the other issues about registers?) |
gvanrossum
left a comment
There was a problem hiding this comment.
Time to start making one simple instruction use an extra oparg? Without even optimizing LOAD/STORE -- we could just tackle UNARY_NEGATIVE and give it a second oparg that designates the destination, and make the compiler write the bytecode like that.
| #define NB_INPLACE_XOR 25 | ||
|
|
||
| /* number of codewords for opcode+oparg(s) */ | ||
| #define OPSIZE 2 |
There was a problem hiding this comment.
I guess for now we're not contemplating the size depending on the opcode. Probably just as well.
There was a problem hiding this comment.
Yeah, it won’t be hard to change this macro if we decide to do that.
|
I made a new PR with this stuff on today's version of main: #100276. |
This emits "opcode, oparg, 0, 0" for each instruction.
Still debugging some test failures related to line numbers/tracing etc. But this works well enough to benchmark with pyperformance: