-
Notifications
You must be signed in to change notification settings - Fork 51
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Combined instructions #36
Comments
Well, I'm pretty much ready to give up on this. See these comments for why (a bit repetitive):
Basically ADD_INT is 0.1% of opcodes statically, and 0.5% dynamically; the POP_JUMP_IF[_NOT]_NONE opcodes are 0.2% statically (I expect the dynamic count to be 5x that but I didn't measure it) and I expect less return from RETURN_CONST/NONE. |
Some research was done on this previously by Serhiy in https://bugs.python.org/issue27255. |
Victor proposed RETURN_NONE before: https://bugs.python.org/issue28800 (and there's some discussion of RETURN_CONST there too). It was in the end rejected because (by definition) it can't occur in loops. |
Any bytecodes can occur in a loop, if they are in a function that is called in a loop. What do the numbers say? |
I’m going to have to spend some time developing a systematic approach to measuring this, both statically and dynamically. Eric already did some work on dynamic measurements. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
This is a spin-off from #16 (Super-instructions). Where the idea promoted in #16 is to keep the opcode count the same and replace the first opcode of a common pair by a new instruction that peeks ahead to get the oparg of the second instruction (and moves the program counter accordingly), the idea if combined instructions is to simply replace a pair of opcodes (e.g. LOAD_FAST + RETURN_VALUE) by a single opcode (e.g. RETURN_CONST or even RETURN_NONE).
All the work I've done so far is of the latter type, so this issue is about that. Starting with python/cpython#25090.
The text was updated successfully, but these errors were encountered: