Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork32.1k
bpo-46841: Improve the failure stats forCOMPARE_OP
#31663
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
sweeneyde left a comment• edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Looks good.
We could also consider packing extended opargs into the top 13 bits ofcache->mask
when it fits there.
Edit: I suppose it would be difficult to do next_instr++ the correct number of times in ceval. Store how far to jump ahead for that branch as well?
@markshannon is already brainstorming ideas for how to tackle the general problem of longer jumps infaster-cpython/ideas#297 andfaster-cpython/ideas#301. We should probably wait to see how that pans out first before adding a bunch of new logic to the different |
Feel free to add suggestions tofaster-cpython/ideas#301. faster-cpython/ideas#297 is more about giving the bytecode compiler freedom to lay out basic blocks. |
Uh oh!
There was an error while loading.Please reload this page.
With the move to inline caching, jumps are getting a bit longer. This adds new category of
COMPARE_OP
failures for the (increasingly more common) case where aCOMPARE_OP
instruction is followed by anEXTENDED_ARG
.New stats for a full
pyperformance
run:Specialization attempts
https://bugs.python.org/issue46841