This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Mark.Shannon
Recipients Mark.Shannon, pablogsal, rhettinger, serhiy.storchaka
Date 2019-12-30.10:42:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1577702540.8.0.835064126959.issue39156@roundup.psfhosted.org>
In-reply-to
Content
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. 
The output can be sanity checked by visual inspection.


Although I expect a performance boost, I think this is a worthwhile improvement whether or not it helps 
performance as it makes the instructions better focused.


Pablo, currently there are 117 opcodes, increasing that to 120 is not a problem.
Also there is no reason why we are limited to 256 opcodes in the long term.
Plus, I'm 4 opcodes in credit, thanks to https://bugs.python.org/issue33387 :)

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.
History
Date User Action Args
2019-12-30 10:42:20Mark.Shannonsetrecipients: + Mark.Shannon, rhettinger, serhiy.storchaka, pablogsal
2019-12-30 10:42:20Mark.Shannonsetmessageid: <1577702540.8.0.835064126959.issue39156@roundup.psfhosted.org>
2019-12-30 10:42:20Mark.Shannonlinkissue39156 messages
2019-12-30 10:42:20Mark.Shannoncreate