On 17/11/21 7:57 am, Ralf Gommers wrote:
Hi all,
...
At this point it looks like controlling the number of threads that OpenBLAS uses is the way we can work around this problem (or let users do so). Ways to control threading:
- Use `threadpoolctl` (see the README at https://github.com/joblib/threadpoolctl <https://github.com/joblib/threadpoolctl> for how) - Set an environment variable to control the behavior, e.g. `OPENBLAS_NUM_THREADS` - Rebuild the `libopenblas` we bundle in the wheel to have a max number of threads of 1, 2, or 4. ...
Thoughts on which option seems best? Any other options I missed?
Cheers, Ralf
There are openblas-specific utility functions like `openblas_set_num_threads` [0]. They lack documentation about which routines they affect but it might be an avenue to explore. Perhaps openblas_get_num_threads/openblas_set_num_threads could be used around the offending call like a context manager? Disadvantages: - This would affect global state. - It is not clear how to pull these functions into scipy. We tried fishing them out in CI via ctypes to check the openblas version, and failed on windows. Perhaps with a #ifdef OPENBLAS somewhere in C code? Matti [0] https://github.com/xianyi/OpenBLAS/wiki/OpenBLAS-Extensions