-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
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
Break up COMPARE_OP into logically distinct operations. #83337
Comments
Currently the COMPARE_OP instruction performs one of four different tasks. The four tasks are: The current implementation involves an unnecessary extra dispatch to determine which task to perform. In addition, testing for exception matching is always followed by a branch, so the test and branch can be combined. I propose adding three new instructions and changing the meaning of COMPARE_OP should only perform rich comparisons, and should call |
I think is a good idea, being the only problem that I see that as the opcode targets are limited we would be burning 3 more. I specially like the proposal for JUMP_IF_NOT_EXC_MATCH as PyCmp_EXC_MATCH is only used in the code for the try-except and is always followed by a POP_JUMP_IF_FALSE. As a curiosity, it would be good to have an idea on performance gains of specializing the comparison. |
When COMPARE_OP occurs in a loop, the dispatch tends to be branch predictable. So there may not be real-world performance benefit to splitting the opcodes. |
Few years ago I experimented with a special opcode for exception matching. It could make the bytecode a tiny bit smaller and faster, but since catching an exception in Python is relatively expensive, it would not have significant performance benefit. As for splitting COMPARE_OP for comparison, identity and containment tests, all these operations look the same from the compiler side, they correspond the same AST node. Introducing new opcodes will complicate the compiler. |
And it will complicate opcode.py and peephole.c and anything else that touches the word codes. |
Moving work from the interpreter to the compiler is always a good idea. Performance: The compiler is run once per code unit, the interpreter thousands or millions of times. The compiler is easier to test. Just match the expected bytecode with the actual bytecode. Although I expect a performance boost, I think this is a worthwhile improvement whether or not it helps Pablo, currently there are 117 opcodes, increasing that to 120 is not a problem. Raymond, regarding the performance of COMPARE_OP, it is not just branch prediction that matters. With this change, the number of (hardware) instructions executed is always reduced, even if branch prediction is no better. Serhiy, the benefit of having a special opcode for exception matching is not really to speed up exception matching, but to avoid slowing down other tests. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: