Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
#5,383 コメント 16 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@rgommers がすでに取り組んでいます。

2025年7月16日 から。

評価

この issue はまだ評価されていません。

説明

Distribution packaging problem

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.

主要言語
C
スター
7.6k
フォーク
1.7k
平均マージ
1日 6時間
マージ済み PR(30日)
46

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

OpenMathLib/OpenBLAS のほかの issue

OpenMathLib/OpenBLAS の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。