[capi-sig]Some work on reorganizing header files of CPython
Hi,
I working on the Include/ directory of CPython to separate the different levels of API into subdirectories:
Move internal headers to Include/internal/ : https://bugs.python.org/issue35081
Move !Py_LIMITED_API to Include/pycapi/: https://bugs.python.org/issue35134
I also started to use replace macros with static inline functions:
Convert Py_INCREF() and PyObject_INIT() to inlined functions https://bugs.python.org/issue35059
All these changes are connected to my https://pythoncapi.readthedocs.io/ project. It's the very first steps towards a better C API. The most concrete changes are that Py_BUILD_CORE are now in separated header files and so removed from Include/. You have to explicitly include pycode_xxx.h (ex: pycode_accu.h).
Victor
On 06Nov2018 1322, Victor Stinner wrote:
I also started to use replace macros with static inline functions:
Convert Py_INCREF() and PyObject_INIT() to inlined functions https://bugs.python.org/issue35059
Have we verified that all our main compilers do in fact inline these all the time? Including when run in C++ mode (when people build C++ extension modules using our headers)?
Historically, reference counting has been highly performance sensitive, and I don't think we should start regressing performance until we have the full picture of how the changes will enable performance improvements.
(I'm still of the opinion that we need to replace the entire C API to be able to enable better performance, but I'm not going to block innocuous cleanups and refactorings that help improve the current one, provided they aren't regressions.)
Cheers, Steve
Le 08/11/2018 à 19:33, Steve Dower a écrit :
On 06Nov2018 1322, Victor Stinner wrote:
I also started to use replace macros with static inline functions:
Convert Py_INCREF() and PyObject_INIT() to inlined functions https://bugs.python.org/issue35059
Have we verified that all our main compilers do in fact inline these all the time? Including when run in C++ mode (when people build C++ extension modules using our headers)?
This is 2018, so I think we should assume decent compilers which /do/ inline tiny functions explicitly marked "inline". At least with optimizations enabled... Debug mode performance might be hindered, though.
Regards
Antoine.
On 08Nov2018 1046, Antoine Pitrou wrote:
Le 08/11/2018 à 19:33, Steve Dower a écrit :
On 06Nov2018 1322, Victor Stinner wrote:
I also started to use replace macros with static inline functions:
Convert Py_INCREF() and PyObject_INIT() to inlined functions https://bugs.python.org/issue35059
Have we verified that all our main compilers do in fact inline these all the time? Including when run in C++ mode (when people build C++ extension modules using our headers)?
This is 2018, so I think we should assume decent compilers which /do/ inline tiny functions explicitly marked "inline". At least with optimizations enabled... Debug mode performance might be hindered, though.
And clearly we did assume that, but can we check it as well? Not a big ask.
Cheers, Steve
Le 08/11/2018 à 21:21, Steve Dower a écrit :
On 08Nov2018 1046, Antoine Pitrou wrote:
Le 08/11/2018 à 19:33, Steve Dower a écrit :
On 06Nov2018 1322, Victor Stinner wrote:
I also started to use replace macros with static inline functions:
Convert Py_INCREF() and PyObject_INIT() to inlined functions https://bugs.python.org/issue35059
Have we verified that all our main compilers do in fact inline these all the time? Including when run in C++ mode (when people build C++ extension modules using our headers)?
This is 2018, so I think we should assume decent compilers which /do/ inline tiny functions explicitly marked "inline". At least with optimizations enabled... Debug mode performance might be hindered, though.
And clearly we did assume that, but can we check it as well? Not a big ask.
I suppose people can run benchmarks on their configurations of choice ;-)
Regards
Antoine.
Yes. Please see https://bugs.python.org/issue35059 for details.
Victor Le jeu. 8 nov. 2018 à 19:33, Steve Dower <steve.dower@python.org> a écrit :
On 06Nov2018 1322, Victor Stinner wrote:
I also started to use replace macros with static inline functions:
Convert Py_INCREF() and PyObject_INIT() to inlined functions https://bugs.python.org/issue35059
Have we verified that all our main compilers do in fact inline these all the time? Including when run in C++ mode (when people build C++ extension modules using our headers)?
Historically, reference counting has been highly performance sensitive, and I don't think we should start regressing performance until we have the full picture of how the changes will enable performance improvements.
(I'm still of the opinion that we need to replace the entire C API to be able to enable better performance, but I'm not going to block innocuous cleanups and refactorings that help improve the current one, provided they aren't regressions.)
Cheers, Steve
participants (3)
-
Antoine Pitrou -
Steve Dower -
Victor Stinner