-
-
Notifications
You must be signed in to change notification settings - Fork 11k
ENH: Improve performance for np.result_type #28710
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
Changes from all commits
757f48b
ec968e3
4419d7c
4b41258
112b54e
9e836b8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1597,13 +1597,12 @@ PyArray_ResultType( | |
return NULL; | ||
} | ||
|
||
PyArray_DTypeMeta **all_DTypes = (PyArray_DTypeMeta **)workspace; | ||
PyArray_DTypeMeta **all_DTypes = (PyArray_DTypeMeta **)workspace; // borrowed references | ||
PyArray_Descr **all_descriptors = (PyArray_Descr **)(&all_DTypes[narrs+ndtypes]); | ||
|
||
/* Copy all dtypes into a single array defining non-value-based behaviour */ | ||
for (npy_intp i=0; i < ndtypes; i++) { | ||
all_DTypes[i] = NPY_DTYPE(descrs[i]); | ||
Py_INCREF(all_DTypes[i]); | ||
all_descriptors[i] = descrs[i]; | ||
} | ||
|
||
|
@@ -1628,14 +1627,10 @@ PyArray_ResultType( | |
all_descriptors[i_all] = PyArray_DTYPE(arrs[i]); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This part is not touched by the PR, but is this safe in the free-threading build? The There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Here is a reproducer:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you file an issue for this? This is kind of a weird thing to do so I’m not very worried but maybe there’s a simple workaround. |
||
all_DTypes[i_all] = NPY_DTYPE(all_descriptors[i_all]); | ||
} | ||
Py_INCREF(all_DTypes[i_all]); | ||
} | ||
|
||
PyArray_DTypeMeta *common_dtype = PyArray_PromoteDTypeSequence( | ||
narrs+ndtypes, all_DTypes); | ||
for (npy_intp i=0; i < narrs+ndtypes; i++) { | ||
Py_DECREF(all_DTypes[i]); | ||
} | ||
if (common_dtype == NULL) { | ||
goto error; | ||
} | ||
|
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 seems safe, since we are holding on to
descrs
, but best to check with @sebergThere 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.
Borrowed references can be unsafe on the free-threaded build. That said, these are references to immortal (?) DType objects. The question mark there is that in principle someone could delete a DType in one thread and then another thread could hold the last reference to it here.
I have no idea if, in practice, we actually allow deleting DTypes or if that's a true goal for us to support.
Another option is to only drop the reference counting on the GIL-enabled build, since borrowed references should always be safe on the GIL-enabled build.
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.
My reasoning: here
descrs
is passed as an argument toPyArray_ResultType
which means the elements ofdescrs
cannot (or should not!?) be deleted by another thread. Sincedescrs
objects are not deleted, the type of thedescr
should be safe to use.