GH-29021: Convert _simd.c to multi-phase init (PEP 489) #29025
Conversation
dfd8b67 to
bc408c1
Compare
|
|
| static struct PyModuleDef defs = { | ||
| .m_base = PyModuleDef_HEAD_INIT, | ||
| .m_name = "numpy._core._simd", | ||
| .m_size = 0, |
There was a problem hiding this comment.
This was -1, did it become 0 on purpose?
There was a problem hiding this comment.
A value of -1 indicates to Python that the module has global state (PyModuleDef.m_size). It forbids any use of subinterpreters, re-initialisation, etc.
Changing to 0 was perhaps a gamble, seeing if tests passed. To be more conservative though, we could keep m_size to -1 and defer changing it to a non-negative number to a future PR. What would you suggest?
A
There was a problem hiding this comment.
Yes, I think we should change it to 0 in a future PR. Please only change it in a single PR, lets get one of these in before the mass move of all the other ones. Does the change impact performance? I would suggest redoing this in #29030, or one of the others that touch a commonly used module, and then running the benchmarks to see if there is a regression when using multi-phase init.
There was a problem hiding this comment.
Ok, I've updated #29030 to keep m_size = -1.
Is there infrastructure to benchmark a PR? My laptop isn't an ideal environment & I don't have a spare computer to run the local benchmarks.
There was a problem hiding this comment.
From https://github.com/numpy/numpy/actions/runs/15179012580/job/42684537494?pr=29030
m_size may not be negative for multi-phase initialization
I'll get the Python documentation updated, this isn't very obvious! In the meantime, I'll revert the change to #29030.
I believe 0 is the correct value to keep, as there is currently no per-module state and hence nothing to allocate memory for.
|
This change looks quite annoying: - import_array();
+ import_array1(-1);
At a glance from your PRs, there seems to be a larger issue in the CPython design with the normal meaning of a EDIT: discussion on this comment moved to #29030 (comment) |
Uh oh!
There was an error while loading. Please reload this page.