Skip to content
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

Vectorcall support #684

Closed
kngwyu opened this issue Dec 8, 2019 · 7 comments
Closed

Vectorcall support #684

kngwyu opened this issue Dec 8, 2019 · 7 comments

Comments

@kngwyu
Copy link
Member

kngwyu commented Dec 8, 2019

Python 3.8 has a faster __call__ protocol for C-FFI namd vectorcall.
#641 added FFI functions for it, but we need more high level functions implemented.

@davidhewitt
Copy link
Member

@kngwyu I'd like to take this on

@kngwyu
Copy link
Member Author

kngwyu commented Feb 22, 2020

Thank you, but I don't think we should change all things to use vectorcall now.
How about starting from adding a call_* variant to ObjectProtocol or so?

@davidhewitt
Copy link
Member

Agreed. I plan to run a few experiments before I make any final PRs. Just wanted to give you a heads-up before I go too far so we don't end up duplicating the investigation!

@davidhewitt
Copy link
Member

Based on what I've been reading, I think that there's a few places we can potentially use vectorcall:

  • call_vectorcall to ObjectProtocol is a first point to start.
  • PyObject_Vectorcall internally uses the old calling convention if vectorcall isn't available, so in the long run I think we want to make an API where the users of pyo3 don't have to care about vectorcall, and we just dispatch the optimisation for them if they're on Python >= 3.8.
  • Also, it looks like our PyCFunctions defined with METH_VARARGS will not support vectorcall - so we should be changing these to be METH_FASTCALL. We will only want to do this for Python >= 3.8, so it will take some refactoring, but should lead to good speedups for users on those Python versions.

Before this goes anywhere though, I've hit a stumbling block that _PyObject_Vectorcall doesn't actually seem to be exported in libpython. It's defined as a static inline function in CPython's abstract.h.

I've asked about that in bpo-39773.

@davidhewitt
Copy link
Member

davidhewitt commented Mar 7, 2020

I've asked about that in bpo-39773.

A follow up to that. PyObject_Vectorcall is not actually exposed in libpython. This is by design as they want it as a performance optimisation for C.

This means that at the very least the wrappers added in #641 are not quite correct, because they're defining symbols which can't be linked to. I'll come up with a PR sometime to clean that up.

@alex
Copy link
Contributor

alex commented Oct 18, 2024

I think this can be closed now, yeah?

@davidhewitt
Copy link
Member

Yes, we use vectorcall in both directions. There are cases where we can probably get more efficient (e.g. we always pass keywords as a dict) bit that conversation can continue in #4503 and related threads.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants