OpenMathLib / OpenMathLib/OpenBLAS
QUERY: Reduced performance in certain architecture only to-be-regained by `OPENBLAS_NUM_THREADS=1`
@rgommers is already working on this.
Since Jul 16, 2025.
- Dominant language
- C
- Stars
- 7.6k
- Forks
- 1.7k
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 42
Description
Hello,
This is probably not a real issue for OpenBLAS but basically a request for information. Over SciPy, we have been receiving sporadic reports that, otherwise identical C translations of the old Fortran77 code was running substantially slower when thread number is not limited to 1.
https://github.com/scipy/scipy/issues/22438
https://github.com/scipy/scipy/issues/23161
https://github.com/scipy/scipy/issues/23191
The code in question is here (not sure it matters but for reference)
https://github.com/scipy/scipy/blob/main/scipy/optimize/__lbfgsb.c
and the only BLAS/LAPACK calls made in this code are
DAXPY
DSCAL
DCOPY
DNRM2
DDOT
DPOTRF
DTRTRS
I am trying to understand which call might be being affected since I don't quite understand why OPENBLAS_NUM_THREADS=1 recovers the performance. If this is needed at all times, probably we should, on the SciPy side, include some sort of a guard since users won't even know this setting is needed for comparable performance. And since we are using these functions in other parts of SciPy it would be nice to know when we are entering into such behavior.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.