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
Consolidate stateful C globals under a single struct. #75043
Comments
CPython's C code makes extensive use of global variables. The globals fall into one of several categories:
Those in the last category are not explicitly organized nor easily discoverable. Among other things, this has an impact on efforts that change the runtime (e.g. my multi-core Python project). To improve the situation I'd like to do the following:
One side effect of consolidating these globals is a significant performance improvement of CPython. Presumably this is due to the caching behavior of a single struct vs. that of dozens of separate globals. I have a patch and will put up a PR momentarily. |
One thing I'd like to also try is to use a freelist embedded in _PyRuntimeState for the PyInterpreterState and PyThreadState linked lists. |
See also bpo-29881. |
After looking at the PR, I'm a bit skeptical about this. Suddenly a lot of things which are implementation details get moved to the public include files, which makes things more confusing from my POV. I also don't know why all globals should be consolidated in a single place (it is not a widespread policy in other projects AFAIK, but I may be mistaken). Perhaps it would be more reasonable to consolidate the globals in each .c file independently, without trying to join all of them together in one place nor expose them in the public include files. |
The core motivation driving the original refactoring was to better understand and consolidate our runtime state in order to clarify what the GIL is actually protecting (aside from the reference counts). That then turned out to have surprising performance benefits (presumably by way of loading all of this state permanently into the CPU cache and then keeping it there). The changes to the public include files arise more from the fact we don't currently have a common place to put internal CPython headers for declarations we want to share across compilation modules. I agree the latter is confusing, and it could be worth having a separate "Include/internal/CPython.h" header that outright failed the build if you attempted to include it without Py_BUILD_CORE set. (This also ties into my comments on the PR, where I believe the current approach of mixing public and private state in the same structs will cause problems with compilers generating incorrect field offsets in extension modules and embedding applications) |
Sadly, Windows doesn't like much your big change. Just one example:
|
I'm also a bit skeptical about the header design in this PR. We should not to have a monolithic _Python.h header, and it should not be sometimes included in Python.h. Rather, code that needs the internal headers should include them directly. In fact, this PR regresses that by moving all the internal headers into Include/... |
Regarding the accidental exposure of _Py_CheckRecursionLimit, the main active usage of the stable ABI that we're aware of is Riverbank's C/C++ binding generator for PyQt: http://pyqt.sourceforge.net/Docs/sip4/directives.html#directive-%Module (see the use_limited_api option for the linked directive) I checked with Phil Thomson (sip's maintainer), and the bindings sip generates don't use either of the public macros that access this nominally private value. |
FYI, the merged code introduced a bunch of new warnings on Windows. I'm looking into it. |
New changeset 4866957 by Victor Stinner in branch 'master': |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: