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

Thread-local limits for OpenBLAS with pthreads

オープン
  • 何か問題がありますか？
#220 コメント 4 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
静か
技術スタック
python
領域
backend, performance

調査の方向性

Start by reading the issue’s discussion of OpenBLAS with pthreads and how threadpoolctl currently applies limits; the payload names no source files or tests. The proposed behavior is still undecided, including when to run inline or use all cores, so first establish the intended policy with maintainers. Done would mean an agreed policy and a defined way to verify thread limits across Python threads.

索引モデルが issue の本文から書いたものです。

説明

The problem

OpenBLAS with pthreads is widely used: a billion downloads of NumPy from PyPI a month; 400 million for SciPy. Not all are Linux, but most are. Not all of them use BLAS, of course, but some do. It adds up!

The API limit for threads is process-wide. This is annoying, but not the worst part.

The worst part is that it has a process-wide shared pool. Consider a CPU with 32 cores, and a Python thread pool with 4 threads, each of which wants to do some OpenBLAS work. A user whose code needs to run with a variety of BLAS libraries (e.g. sklearn committer) sets a limit 32 // 4 == 8 cores. For many setups this is fine; for OpenBLAS with pthreads, it means 24 cores sit idle.

Potential solutions

  • Change this upstream in OpenBLAS.
  • Get PyPI packages to stop shipping pthreads version and instead use OpenMP version. So far all OpenMP libraries I've seen don't have process-wide shared thread pool, so this will make things better in most cases.
  • Turning https://github.com/itamarst/openblas-tod/ into a real project, and having its own thread-local-scoped limiting API.
  • Rethink scope limiting in threadpoolctl in this case.

To expand on the last point—

Maybe threadpoolctl should do something different for OpenBLAS with pthreads (or more broadly APIs affecting a process-wide thread pool)

A user might set three different settings:

  1. All cores. "All" means... all cores if it's a top-level process, or whatever share of cores were assigned to this process if it's a worker in a process pool.
  2. Run inline/sequentially, without a thread pool, typically set via 1 or 0.
  3. A number in between.

Typically the first case will be used when there are no Python threads, so it should be exactly the right number. The second case will be used when there is a Python thread per-core, so again exactly the right number.

The only problems occur, then, in the third case. As we saw in the example above, you may end up with a bunch of cores sitting idle. So maybe in the third case it's worth changing the user limit to something better.

To make this concrete, imagine 16 cores, and a Python thread pool that calls BLAS but also does other work, perhaps in a single thread, perhaps in additional thread pools (Python thread pools, OpenMP, etc, who can say...).

Python thread pool size Naive OpenBLAS limit Better OpenBLAS limit
2 8 All cores might be better, 16 instead of 8, but risks oversaturation
3 5 All cores might be better, 16 instead of 5, but risks oversaturation
4 4 All cores might be better, 16 instead of 4, but risks oversaturation
5 3 1 is somewhat better, since then it runs inline and uses 5 cores instead of 3. since it is inline there is no risk of oversaturation
6 2 or 3 1 is much better, since then it runs inline and uses 6 cores instead of 2 or 3. since it is inline there is no risk of oversaturation
7 2 1 is much better
8 2 1 is much better
9-16 1 1 is fine

With 64 cores:

Python thread pool size Naive OpenBLAS limit Better OpenBLAS limit
2 32 Maybe better unchanged? Depends if there are other nested thread pools
4 16 ?
8 8 ?
9 7 ?
10 6 1 might be better, depending on if there are other nested thread pools there are that might end up running in parallel to BLAS and thus utilizing more cores.
16-31 3 or 4 1 is vastly better. alternatively, all cores... maybe viable for smaller number of python threads?
32-63 2 1 is vastly better

Conclusions:

  • If you limit the number of BLAS threads below a certain threshold, you typically want to just set it to 1. E.g. if you set it to 2, better to just run inline. Will have to think about heuristic thresholds; one potential one is BLAS limit being lower than square root of available cores for the process, since that means parent Python thread pool has higher number of threads than the BLAS limit so running inline will use more cores.
  • There may be some cases where it's probably better to use all cores instead of the set limit?
主要言語
Python
スター
434
フォーク
38
平均マージ
2日 9時間
マージ済み PR（30日）
7

環境構築

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

はじめの一歩

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

joblib/threadpoolctl のほかの issue

joblib/threadpoolctl の issue をすべて見る

似ている issue

Python の issue をもっと見る

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

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