Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork32k
gh-119109: improvefunctools.partial
vectorcall with keywords#124584
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
base:main
Are you sure you want to change the base?
Conversation
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Perhaps@vstinner has the time and interest in looking at this. |
I think it is a good compromise between simplicity and performance now. One micro-optimization that I couldn't figure out how to do simply is pre-storing Not sure how much sense it makes yet, but I postedfaster-cpython/ideas#699 in relation to this. Ready for review now. |
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Was wandering if it might be worth factoring out macros for private use. |
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
functools.partial
vectorcall with keywordspicnixz commentedJan 5, 2025 • 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.
Is the performance change a direct effect of the simplification or is this the other way around? (namely, can we decouple the performance gains from the simplification?) (not that the PR is too big but for bisecting commits, it's easier when we have atomic changes) |
dg-pb commentedJan 5, 2025 • 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.
Your title change is incorrect, this has wider implications. It removes dynamic switching, which causes issues with free threading. And generally results in more linear straight forward flow, so it is a design improvement as well. The fact that |
functools.partial
vectorcall with keywordsfunctools.partial
vectorcall with keywords
yes, it is one atomic change. There is no way to split it. |
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
(Potentiallycloses#128050)
This IMO is the best approach to resolve fallback "issue". It:
a) Eliminates the need for the fallback or any need to switch between implementation after initial construction
b) Delivers performance benefits for vectorcall when
partial
has keywordsBenchmark:
No penalty for calls without
pto_kwds
.Non negligible speed improvement for calls with
pto_kwds
: 27 - 55%