Skip to content
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

Debugging #8544 #8671

Conversation

stuartarchibald
Copy link
Contributor

As title. Do not merge.

This removes Numba's reliance on NumPy ufunc inner loops. All the
cases where a ufunc inner loop (or something from
`numpy/npy_math.h`) was present, have been replaced as follows:

* `np.signbit` -> Numba custom builder implementation.
* `np.nextafter` -> Numba helperlib wrapped C library call.
* `np.spacing` -> Numba custom builder implementation.
* `np.log2` -> llvm intrinsic.
* `np.exp2` -> llvm intrinsic.
* `np.logaddexp` -> custom Numba overload translation of NumPy C code.
* `np.logaddexp2` -> custom Numba overload translation of NumPy C code.
* Numba helperlib `numba_cpowf` -> now uses `<complex.h>` functions in
  place of NumPy functions.
…c_loop_reliance

Resolved conflicts in:
	numba/tests/test_ufuncs.py
@stuartarchibald stuartarchibald added the abandoned PR is abandoned (no reason required) label Dec 15, 2022
@@ -58,10 +58,10 @@ def _check_external_compiler():
ntf.close()
# *output_dir* is set to avoid the compiler putting temp files
# in the current directory.
compiler.compile([ntf.name], output_dir=Path(ntf.name).anchor)
#compiler.compile([ntf.name], output_dir=Path(ntf.name).anchor)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Potential problem line.

@stuartarchibald
Copy link
Contributor Author

ebc9299 has no temp.{c, cxx} in the log, which suggests this line #8671 (comment) is potentially the cause.

@stuartarchibald
Copy link
Contributor Author

e221307 has no temp.{c, cxx} in the log but does have this line #8671 (comment) present. This perhaps suggests it's NumPy's distutils patching standard distutils that "fixes" the problem. Seems like this could be due to the replacement of .spawn in the CCompiler https://github.com/numpy/numpy/blob/62e075c1c22530528bf5b6778ef51e212f65acb7/numpy/distutils/ccompiler.py#L112-L183.

The stdlib vendored distutils variant of .spawn uses a Popen with no specification for stderr handling (the new process will inherit the file descriptors from the parent): https://github.com/python/cpython/blob/3939a4b7d95a403ee587ff5d222db53ec83bec2c/Lib/distutils/spawn.py#L79 whereas the NumPy patched version of .spawn has redirection to stdout in a checked_output call https://github.com/numpy/numpy/blob/62e075c1c22530528bf5b6778ef51e212f65acb7/numpy/distutils/ccompiler.py#L145. i.e. any output to stdout/stderr from the subprocess in the NumPy patch version will be "hidden".

@stuartarchibald
Copy link
Contributor Author

Closing, investigation is complete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
abandoned PR is abandoned (no reason required)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant