Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Thread-local limits for OpenBLAS with pthreads

Đang mở
  • Có gì không ổn?
#220 4 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Ít trao đổi
Công nghệ
python
Lĩnh vực
backend, performance

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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?
Ngôn ngữ chính
Python
Star
434
Fork
38
Merge trung bình
2 ngày 14 giờ
Pull request đã merge (30 ngày)
8

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của joblib/threadpoolctl

Tất cả issue của joblib/threadpoolctl

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.