-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
BUG: move reduction initialization to ufunc initialization #28123
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
Conversation
I'm also relying on the existing tests for reductions to cover this refactor - any suggestions for new tests? |
Refactored to call Also added a test. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, nice to keep things together. I still think it would be good to agressively simplify the new code, unless I am missing something?
Nice that you have a threading test! (I am almost wondering if there is some pytest plugin that would run each tests N times in parallel, or if that could be a fun project... but, we certainly have a few bad test that might not survive that :), although a plugin could use a pytest.mark
to run them only once)
} | ||
|
||
PyArray_Descr **descrs = PyMem_Calloc(ufunc->nin + ufunc->nout, | ||
sizeof(PyArray_Descr *)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is one of the places where the NPY_ALLOC_WORSPACE
could also be used, but I don't much, this isn't performance critical.
(And it might be that at least with mimalloc
all of this barely matters anyway.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But more importantly. We only ever use the initial value for reductions. So I think you might as well hard-code all of this (if you like up to the knowledge that get_initial_form_ufunc()
only usees descrs[0]
anyway).
So make descrs[3]
or just &singleton
... (of course only enter the branch if nin == 2
and nout == 1
)
There's pytest-run-parallel which SciPy is using heavily. Using it in NumPy may discover some things but I suspect it will mostly detect use of global state in tests and the signal-to-noise ratio may not be great. In particular the Python For now I'm just adding one-off multithreaded tests for specific issues as I find them. Thanks for the review! |
Co-authored-by: Sebastian Berg <sebastian@sipsolutions.net>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, LGTM to me now, let's put it in.
There are ways to work around that (e.g. https://github.com/jax-ml/jax/pull/25626/files#diff-10c9477e1279e29626a5bbb8dccc529723495114f796523371741f472fc28e23) if you're sufficiently motivated. But it might be best just to wait for something like python/cpython#128300 to land upstream. |
* BUG: move reduction initialization to ufunc initialization * MAINT: refactor to call get_initial_from_ufunc during init * TST: add test for multithreaded reductions * MAINT: fix linter * Apply suggestions from code review Co-authored-by: Sebastian Berg <sebastian@sipsolutions.net> * MAINT: simplify further --------- Co-authored-by: Sebastian Berg <sebastian@sipsolutions.net>
Fixes #28041.
Because the reduction initialization happens during ufunc initialization, this means that ufunc initialization now depends on the allocator context variables being initialized, so I moved those initialization steps up before ufunc initialization in the main
_multiarray_umath
module initialization function.