per-caller-thread limits
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
Hướng nghiên cứu
The issue identifies threadpool_limits in threadpoolctl but names no source files, tests, or implementation entry points. First read the thread limit handling and its tests to assess whether limits can be scoped to the caller thread. Done means caller-specific limits support subdividing a shared thread budget without oversubscription; the issue leaves the design open.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
The threadpool_limits are global. This makes it difficult to avoid oversubscription when invoking parallel operations (e.g., Numpy functions) from within a parallel divide-and-conquer algorithm.
Ideally, parallel multi-threading frameworks would be fully multi-threaded-aware, that is, have a limit on the total number of threads used, regardless of how many threads are generating requests. This however seems too much to ask for :-(
A simpler modification would be to set per-caller-thread limits. This way, a divide-and-conquer algorithm could, at each step, subdivide the total budget of threads. As an secondary upside, a budget of odd number of (2n+1) threads could be split to (n) threads for one sub-task and (n+1) threads for another, fully utilizing all threads, rather than setting a global budget of (n) threads per each (missing out on one) or (n+1) for each (oversubscribing).
Is such finer-grained control over thread limits possible? If so, I'd love to see support for it in threadpoolctl.
- 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
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của joblib/threadpoolctl
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
joblib/threadpoolctl#274 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Make it possible to set active/spin wait behavior of LLVM/Intel OpenMP via `kmp_set_blocktime`Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
joblib/threadpoolctl#271 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Make it possible to inspect active/spin wait behavior of LLVM/Intel OpenMP via `kmp_get_blocktime`Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 42/100
joblib/threadpoolctl#270 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 22/100
joblib/threadpoolctl#261 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Opt-in API that has a cached `ThreadpoolController`Có thể đã có người làm @itamarst đã nhận 29 ngày trước. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
joblib/threadpoolctl#254 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của joblib/threadpoolctl
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
CLIMADA-project/climada_python#1337 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
tail without reverseĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
8go/matrix-commander#233 ·
-
documentation
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
-
documentation enhancement priority:high size:M
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Validate non-divisible effective batch sizes in the Unsloth LoRA backendCó thể đã có người làm @debesh-biswas đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100