OpenMathLib / OpenMathLib/OpenBLAS

QUERY: Reduced performance in certain architecture only to-be-regained by `OPENBLAS_NUM_THREADS=1`

Open
#5,383 16 comments 0 reactions 1 assignee View on GitHub

@rgommers is already working on this.

Since Jul 16, 2025.

Distribution packaging problem
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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.