Use thread-local limiting APIs when possible, and fix deadlock - #228
Conversation
|
Not sure what's up with openmp suddenly failing to compile on macOS. Seems unrelated to this PR. |
| ( | ||
| {"user_api": "openmp"}, | ||
| "current_thread", | ||
| # Windows OpenMP is process-wide: |
There was a problem hiding this comment.
I asked an LLM to know if this was a bug or not. Apparently, this is not a bug but a consequence of a being an implementation of an older version of the spec:
| # Windows OpenMP is process-wide: | |
| # Windows OpenMP is process-wide as it claims to implement | |
| # the OpenMP 2.0 spec. This would be a violation of the | |
| # OpenMP 3.0 spec which mandates per-task | |
| # Internal Control Variables such as `nthreads-var`. | |
| # https://learn.microsoft.com/en-us/cpp/build/reference/openmp-enable-openmp-2-0-support?view=msvc-180 |
For information, recent MSVC can be configured to build with the -openmp:llvm flag to leverage libomp instead: https://devblogs.microsoft.com/cppblog/improved-openmp-support-for-cpp-in-visual-studio/
I don't know if there is an easy way to snif libomp specific symbols on such MSVC generated binary files.
There was a problem hiding this comment.
I imagine there's no reason not to use omp_set_num_threads on Windows, it might just not be thread-local (but it won't be worse than openblas_set_num_threads). So as a first pass I will:
- Change the code to run on Windows too.
- Still leave the test disabled on Windows.
- Open an issue to see if detection can be done.
Open an issue with OpenBLAS on Conda-Forge to use this flag, with the presumption I will verify that it doesn't already.
There was a problem hiding this comment.
Ah, sounds like that VS flag is experimental for now, so maybe I won't suggest it.
There was a problem hiding this comment.
I think it's still worth expanding the inline comment to explain that the current windows OpenMP runtime implement semantics from an older version of the OpenMP spec but that it is hopefully expected to change in the future, at which point we might want to update this test to make sure it passes on all platforms.
…with omp_set_num_threads()
|
Not really sure what's going on with the new compiler failures... |
|
Dug into compiler failures a bit: conda-forge/python-feedstock#914 (comment) |
|
There's a new PR in conda-forge/python-feedstock to fix the compilation issue, so hopefully by tomorrow it should be working again, will just need to re-run. |
|
I retriggered a build and the compiler problems went away but # _limit_blas runs BLAS operations in 2 Python threads, so by changing the
# BLAS limit from 1 to 4 we expect an extra 2 * (4 - 1) == 6 threads.
extra_threads = num_threads_created(4) - num_threads_created(1)
> assert extra_threads == 6
E assert 0 == 6on top of the unrelated macOS OpenMP failures. |
ogrisel
left a comment
There was a problem hiding this comment.
More feedback on the new iteration of this PR.
I've seen occasional results (in CI only) where the number of threads is unexpectedly when number of threads was increased. My current theory is that maybe OpenMP caps number of threads to number of cores, so I'll see if I can figure out hardware used in that run. |
|
Oh I wonder if that's just because it's flexiblas. So setting the number of threads is using the flexiblas API which doesn't use the |
…re there are multiple BLAS installed on the system.
Fixes #216
Fixes #229
I figured out a way to measure thread-creation that works on Linux, at least. Or that's the hope, anyway. (
ltracewould be much more robust but I can't get it to work on Conda binaries).