Unexpected performance degradation when running experiment
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
- performance
Hướng nghiên cứu
Bắt đầu với bình luận PR NumPy được liên kết và các biểu đồ đính kèm; so sánh các lần tìm kiếm tuần tự (noshuffle) và được xáo trộn tại n=20 và batch_size=1. Tái hiện benchmark, sau đó lần theo đường dẫn OpenBLAS liên quan và ghi lại một nguyên nhân đã được xác nhận cùng một cải thiện có thể đo lường; không có tệp nguồn, bài kiểm thử hoặc mã có thể chạy nào được cung cấp.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Dear OpenBLAS Team,
I'm currently working to improve Numpy's matmul for the strided case and I ran a large grid search with different BLAS frameworks, see
https://github.com/numpy/numpy/pull/23752#issuecomment-2629521597
Here a repost of the plots:
The plots show the improvement of performance of the respective BLAS framework plus copying over naïve matrix multiplication.
In the case of OpenBLAS, I've actually run two experiments: one where the iteration order over the search space is completely shuffled over all "pixels" of the experiment and one where the "pixel"-order is sequential (as is the actual obvious choice, called noshuffle here). In latter noshuffle case, there is an unexpected performance degradation visible as a red triangle in the top right corner, e.g. for n=20 and batch_size=1. That was the reason I've introduced shuffling in the first place. Other frameworks are not affected by iteration order (graphs not provided, but I can do so on demand).
I wonder whether with the help of these plots this performance artefact can be improved. I can do more benchmarks and plots like that if interested and also provide some code.
Best from Berlin, Michael
- 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
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 OpenMathLib/OpenBLAS
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
OpenMathLib/OpenBLAS#6069 ·
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ó 1/5 Dưới một giờ Mức phù hợp với người mới 92/100
sandialabs/seacas#945 ·
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 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