You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add METH_FASTCALL: new calling convention for C functions #71997
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=<Date2016-09-12.12:59:03.974>created_at=<Date2016-08-20.00:32:46.209>labels= ['type-feature']
title='Add METH_FASTCALL: new calling convention for C functions'updated_at=<Date2019-05-14.20:40:00.365>user='https://github.com/vstinner'
Using METH_VARARGS, args is a Python tuple. Using METH_FASTCALL, args is a C array of PyObject*, and there is a second nargs parameter.
Later, Argument Clinic will be modified to *generate* code using the new METH_FASTCALL calling convention. Code written with Argument Clinic will only need to be updated by Argument Clinic to get the new faster calling convention (avoid the creation of a temporary tuple for positional arguments).
This issue depends on the issue bpo-27809 "_PyObject_FastCall(): add support for keyword arguments". I will wait until this dependency is implemented, before working on the implementation of this part.
For a full implementation, see my first attempt in the issue bpo-26814. I will extract the code from this branch to write a new patch.
I agree that this would be cool. There is a tiny bit of a backwards compatibility concern as the new function signature would be incompatible with anything we had before, but I would guess that any code that chooses to bypass PyObject_Call() & friends would at least fall back to using it if it finds flags that it cannot handle. Cython code definitely does and always did, but there might be bugs. This change is the perfect way to "find" those. ;-)
Anyway, Victor, I definitely appreciate your efforts in this direction.
There is a tiny bit of a backwards compatibility concern as the new function signature would be incompatible with anything we had before,
Right. If you call directly PyCFunction functions, you will likely get quickly a crash. But... who call directly PyCFunction functions? Why not using the 30+ functions to call functions?
Hopefully, it's easy to support METH_FASTCALL in an existing function getting a tuple:
Extensive callback interfaces like map() come to mind, where a large number of calls becomes excessively time critical and might thus have made people implement their own special purpose calling code.
However, I don't know any such code (outside of Cython) and I agree that this is such a special optimisation that there can't be many cases. If there are others, they'll likely be using the obvious fallback already, or otherwise just adapt when Py3.6 comes out and move on. The fix isn't complex at all.
Extensive callback interfaces like map() come to mind, where a large number of calls becomes excessively time critical and might thus have made people implement their own special purpose calling code.
I didn't patch map_next() of Python/bltinmodule.c nor list.sort() for use fast call yet. With my full patch, map() and list.sort() are *faster*, but even more changes are needed ;-)
I'm now aware of map() or list.sort()/sorted() function rewritten from scratch for better performance, but I can imagine that someone did that. But do these specialized implementation use PyObject_Call() or "inline" PyCFunction_Call()?
If someone "inlines" PyCFunction_Call(), be prepared to "backward incompatible changes", since it's common that CPython internals change in a subtle way.
However, I don't know any such code (outside of Cython)
I used GitHub to search for such code using "case METH_VARARGS". I found:
According to discussions in the issue bpo-27809, require a Python dict leads to inefficient code because a temporary dict may be required. The issue bpo-27830 proposes to pass keyword arguments as (key, value) pairs.
It should be used for the new METH_FASTCALL calling convention.
I changed the dependency to the issue bpo-27830 "Add _PyObject_FastCallKeywords(): avoid the creation of a temporary dictionary for keyword arguments" which itself depends on the issue bpo-27213 "Rework CALL_FUNCTION* opcodes".
Where args is a C array of positional arguments followed by values of keyword
arguments. nargs is the number of positional arguments, kwnames are keys of
keyword arguments. kwnames can be NULL.
Stefan Behnel: "There is a tiny bit of a backwards compatibility concern as the new function signature would be incompatible with anything we had before,"
Python 3.6 will probably have two "fast call" calling convention:
_PyObject_FastCallDict(): expect a Python dict for keyword arguments
_PyObject_FastCallKeywods(): expect a Python tuple for keys of keyword arguments, keyword values are packed in the same array than positional arguments
_PyObject_FastCallKeywods() is not really written to be called directly: Python/ceval.c calls you, but you may call _PyObject_FastCallKeywods() again "wrapper" functions, like functools.partial().
Currently, tp_call (and tp_init and tp_new) still expects a (tuple, dict) for positional and keyword arguments, but later I will add something to also support METH_FASTCALL for callable objects. I just don't know yet what is the best option to make this change.
--
The main idea is implemented (implement METH_FASTCALL), I close the issue.
I will open new issues for more specific changes, and maybe extend the API (especially tp_call).
Could you please wrap "#define METH_FASTCALL 0x0080" with "#ifndef Py_LIMITED_API"/"#endif"? I think this method still is not stable, and we shouldn't encourage using it in third-party extensions.
I would use two methods: just METH_FASTCALL and METH_FASTCALL|METH_KEYWORDS. The former is simpler and more stable, it takes just an array of positional parameters. The latter takes also keyword arguments, and the format of passing keyword arguments may be changed.
Activity
vstinner commentedon Aug 20, 2016
The issue bpo-27128 added _PyObject_FastCall() to avoid the creation of temporary tuples when calling functions.
Using METH_VARARGS, args is a Python tuple. Using METH_FASTCALL, args is a C array of PyObject*, and there is a second nargs parameter.
Later, Argument Clinic will be modified to *generate* code using the new METH_FASTCALL calling convention. Code written with Argument Clinic will only need to be updated by Argument Clinic to get the new faster calling convention (avoid the creation of a temporary tuple for positional arguments).
This issue depends on the issue bpo-27809 "_PyObject_FastCall(): add support for keyword arguments". I will wait until this dependency is implemented, before working on the implementation of this part.
For a full implementation, see my first attempt in the issue bpo-26814. I will extract the code from this branch to write a new patch.
scoder commentedon Aug 22, 2016
I agree that this would be cool. There is a tiny bit of a backwards compatibility concern as the new function signature would be incompatible with anything we had before, but I would guess that any code that chooses to bypass PyObject_Call() & friends would at least fall back to using it if it finds flags that it cannot handle. Cython code definitely does and always did, but there might be bugs. This change is the perfect way to "find" those. ;-)
Anyway, Victor, I definitely appreciate your efforts in this direction.
vstinner commentedon Aug 22, 2016
Right. If you call directly PyCFunction functions, you will likely get quickly a crash. But... who call directly PyCFunction functions? Why not using the 30+ functions to call functions?
Hopefully, it's easy to support METH_FASTCALL in an existing function getting a tuple:
I guess that Cython calls directly PyCFunction. cpyext module of PyPy probably too. Ok, except of them, are you aware of other projects doing that?
scoder commentedon Aug 22, 2016
Extensive callback interfaces like map() come to mind, where a large number of calls becomes excessively time critical and might thus have made people implement their own special purpose calling code.
However, I don't know any such code (outside of Cython) and I agree that this is such a special optimisation that there can't be many cases. If there are others, they'll likely be using the obvious fallback already, or otherwise just adapt when Py3.6 comes out and move on. The fix isn't complex at all.
I do not consider this a road block.
vstinner commentedon Aug 22, 2016
I didn't patch map_next() of Python/bltinmodule.c nor list.sort() for use fast call yet. With my full patch, map() and list.sort() are *faster*, but even more changes are needed ;-)
https://bugs.python.org/issue26814#msg263999
I'm now aware of map() or list.sort()/sorted() function rewritten from scratch for better performance, but I can imagine that someone did that. But do these specialized implementation use PyObject_Call() or "inline" PyCFunction_Call()?
If someone "inlines" PyCFunction_Call(), be prepared to "backward incompatible changes", since it's common that CPython internals change in a subtle way.
I used GitHub to search for such code using "case METH_VARARGS". I found:
In short, I found nothing. But I didn't search far, maybe there are a few other code bases using "case METH_VARARGS:"?
vstinner commentedon Aug 22, 2016
According to discussions in the issue bpo-27809, require a Python dict leads to inefficient code because a temporary dict may be required. The issue bpo-27830 proposes to pass keyword arguments as (key, value) pairs.
It should be used for the new METH_FASTCALL calling convention.
vstinner commentedon Aug 25, 2016
I changed the dependency to the issue bpo-27830 "Add _PyObject_FastCallKeywords(): avoid the creation of a temporary dictionary for keyword arguments" which itself depends on the issue bpo-27213 "Rework CALL_FUNCTION* opcodes".
python-dev commentedon Sep 9, 2016
New changeset a25c39873d93 by Victor Stinner in branch 'default':
Issue bpo-27810: Add _PyCFunction_FastCallKeywords()
https://hg.python.org/cpython/rev/a25c39873d93
vstinner commentedon Sep 10, 2016
fastcall.patch combines two changes:
changeset: 103513:74abb8ddf7f2
tag: tip
user: Victor Stinner <[email protected]>
date: Fri Sep 09 17:40:38 2016 -0700
files: Include/modsupport.h Python/getargs.c Tools/clinic/clinic.py
description:
Emit METH_FASTCALL code in Argument Clinic
Issue bpo-27810:
working on a tuple directly.
changeset: 103512:d55abcddd194
user: Victor Stinner <[email protected]>
date: Fri Sep 09 17:40:22 2016 -0700
files: Include/abstract.h Include/methodobject.h Objects/abstract.c Objects/methodobject.c
description:
Add METH_FASTCALL calling convention
Issue bpo-27810: Add a new calling convention for C functions:
Where args is a C array of positional arguments followed by values of keyword
arguments. nargs is the number of positional arguments, kwnames are keys of
keyword arguments. kwnames can be NULL.
python-dev commentedon Sep 10, 2016
New changeset 86b0f5a900c7 by Victor Stinner in branch 'default':
Add METH_FASTCALL calling convention
https://hg.python.org/cpython/rev/86b0f5a900c7
New changeset 633f850038c3 by Victor Stinner in branch 'default':
Emit METH_FASTCALL code in Argument Clinic
https://hg.python.org/cpython/rev/633f850038c3
New changeset 97a68adbe826 by Victor Stinner in branch 'default':
Issue bpo-27810: Rerun Argument Clinic on all modules
https://hg.python.org/cpython/rev/97a68adbe826
python-dev commentedon Sep 10, 2016
New changeset 3934e070c9db by Victor Stinner in branch 'default':
Issue bpo-27810: Fix getargs.c compilation on Windows
https://hg.python.org/cpython/rev/3934e070c9db
python-dev commentedon Sep 11, 2016
New changeset 603bef7bb744 by Serhiy Storchaka in branch 'default':
Issue bpo-27810: Regenerate Argument Clinic.
https://hg.python.org/cpython/rev/603bef7bb744
vstinner commentedon Sep 12, 2016
Stefan Behnel: "There is a tiny bit of a backwards compatibility concern as the new function signature would be incompatible with anything we had before,"
Python 3.6 will probably have two "fast call" calling convention:
_PyObject_FastCallKeywods() is not really written to be called directly: Python/ceval.c calls you, but you may call _PyObject_FastCallKeywods() again "wrapper" functions, like functools.partial().
Currently, tp_call (and tp_init and tp_new) still expects a (tuple, dict) for positional and keyword arguments, but later I will add something to also support METH_FASTCALL for callable objects. I just don't know yet what is the best option to make this change.
--
The main idea is implemented (implement METH_FASTCALL), I close the issue.
I will open new issues for more specific changes, and maybe extend the API (especially tp_call).
serhiy-storchaka commentedon Sep 12, 2016
Could you please wrap "#define METH_FASTCALL 0x0080" with "#ifndef Py_LIMITED_API"/"#endif"? I think this method still is not stable, and we shouldn't encourage using it in third-party extensions.
I would use two methods: just METH_FASTCALL and METH_FASTCALL|METH_KEYWORDS. The former is simpler and more stable, it takes just an array of positional parameters. The latter takes also keyword arguments, and the format of passing keyword arguments may be changed.
python-dev commentedon Sep 12, 2016
New changeset 08a500e8b482 by Victor Stinner in branch 'default':
Issue bpo-27810: Exclude METH_FASTCALL from the stable API
https://hg.python.org/cpython/rev/08a500e8b482
vstinner commentedon Sep 12, 2016
Sorry, this is a mistake. I tried to exclude all new symbols related to fast call from the stable API.
It should now be fixed.
python-dev commentedon Dec 15, 2016
New changeset ecd218c41cd4 by Victor Stinner in branch 'default':
Use _PyDict_NewPresized() in _PyStack_AsDict()
https://hg.python.org/cpython/rev/ecd218c41cd4
jdemeyer commentedon May 14, 2019
Breakage due to the usage of borrowed references in _PyStack_UnpackDict(): bpo-36907