Vectorcall support

[kngwyu]

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]

@kngwyu I'd like to take this on

[kngwyu]

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]

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]

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]

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.