perf report shows most cycles spent in blas_thread_server
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ó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 28/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Đình trệ
- Lĩnh vực
- backend, performance
Hướng nghiên cứu
Bắt đầu bằng cách tái hiện quá trình import chậm bằng Linux perf record và perf report, đồng thời so sánh việc import numpy và pytorch. Kiểm tra driver/others/blas_server.c quanh dòng được trích dẫn và so sánh các mẫu blas_thread_server từ liblapack.so.3 và libcblas.so.3. Hoàn thành khi xác định được thời gian nằm trong OpenBLAS hay trong một consumer, kèm theo chẩn đoán có thể tái hiện.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Not sure this is necessarily an issue with OpenBLAS vs users of OpenBLAS (numpy, pytorch).
I'm seeing slow python imports of pytorch; literally import pytorch is taking multiple seconds on my system.
When I record the python interpreter with linux perf record, perf report shows most cycles are spent in blas_thread_server via BOTH liblapack.so.3 and libcblas.so.3. i.e.
Overhead Command Shared Object Symbol
40.31% python liblapack.so.3 [.] blas_thread_server
36.85% python libcblas.so.3 [.] blas_thread_server
If I annotate either, it seems both are near reading the time stamp counter:
0.31 │3c:┌─→mov (%r15),%rax ▒
│ │ cmp $0x1,%rax ▒
│ │↓ ja b0 ▒
│ │ nop ▒
│ │ nop ▒
│ │ nop ▒
│ │ nop ▒
│ │ nop ▒
│ │ nop ▒
5.29 │ │ nop ▒
│ │ nop ▒
│ │ rdtsc ◆
91.82 │ │ sub %ecx,%eax ▒
│ │ cmp %eax,thread_timeout ▒
2.59 │ └──jae 3c
I'm guessing that's corresponding to code around here.
https://github.com/numpy/numpy/issues/24639 seems like someone else hit this, too, but...https://xkcd.com/979/.
How do I even go about debugging this further? Is it an issue in pytorch? numpy? openblas? PEBKAC?
Importing numpy alone doesn't seem problematic, though I suspect that it's part of the chain of dependencies here. Perhaps related to how pytorch is (mis)using numpy then???
- Ngôn ngữ chính
- C
- Star
- 7.6k
- Fork
- 1.7k
- Merge trung bình
- 1 ngày 6 giờ
- Pull request đã merge (30 ngày)
- 46
Chuẩn bị môi trường
Chúng tôi chưa kiểm tra các tệp thiết lập môi trường của dự án này. 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 OpenMathLib/OpenBLAS
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
OpenMathLib/OpenBLAS#6062 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Missing cgroup awarenessĐang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
OpenMathLib/OpenBLAS#6059 ·
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 48/100
OpenMathLib/OpenBLAS#6029 · 21 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
OpenMathLib/OpenBLAS#6028 · 1 bình luận ·
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 35/100
OpenMathLib/OpenBLAS#6005 · 21 bình luận · 2 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của OpenMathLib/OpenBLAS
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
ARM-software/sysarch-acs#556 · 1 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug needs triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
netdata/netdata#24062 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100