Thống kê chính xác để báo cáo kết quả tăng tốc

Giả sử tôi có các phiên bản chậm và nhanh của một số mã và muốn báo cáo số tăng tốc so sánh hai mã. Tôi chạy phiên bản chậm lần và phiên bản nhanh lần, tạo ra thời gian và . Cách đơn giản nhất để tạo tốc độ là lấy trung bình các phương tiện: Tuy nhiên, điều này không tính đến các ngoại lệ. $n$ $m$ $(s_1, \ldots, s_n)$ $(f_1, \ldots, f_m)$

\frac{\bar{S}}{\bar{f}} = = \frac{m \underset{Tôi < n}{Σ} S_{Tôi}}{n \underset{j < m}{Σ} f_{j}}

$\frac{\bar{s}}{\bar{f}} = \frac{m \sum_{i<n} s_i}{n \sum_{j<m} f_j}$

Câu hỏi : Thống kê tốt nhất để sử dụng khi báo cáo số tăng tốc là gì?

statistics publications

— Geoffrey Irving
nguồn

Độ lệch chuẩn lớn như thế nào so với giá trị trung bình? Dù bạn làm gì, bạn nên báo cáo những gì bạn đã làm và có thể đặt các thanh lỗi nếu chúng lớn. Nếu chúng thực sự lớn, bạn nên điều tra nguồn. Hầu hết các mã máy tính nên chạy khá chắc chắn theo thời gian trừ khi có một thành phần ngẫu nhiên cho chính chương trình hoặc bạn đang chia sẻ tài nguyên máy tính với người khác (đây có thể là mạng hoặc đĩa, không chỉ các nút cụm). Nếu sự cạnh tranh về tài nguyên đĩa là vấn đề, bạn có thể xem xét hiệu suất báo cáo với I / O bị vô hiệu hóa (khá phổ biến) - chỉ cần chắc chắn lưu ý nó.

— Bill Barth

Trên Edison (một siêu máy tính Cray), tôi có chênh lệch 2% giữa hai mẫu. Trên máy tính xách tay của tôi, tôi thấy độ lệch chuẩn 6-8% được đo trên 10 mẫu. Cả hai chỉ dành cho kernel tính toán, không có I / O.

— Geoffrey Irving

Để làm rõ lý do tại sao tôi đề cập đến các ngoại lệ nếu phương sai đã ở mức thấp một cách hợp lý: đây là một đại lượng thống kê cơ bản đủ mà tôi muốn biết cách lý tưởng để báo cáo, ngay cả những cách không hữu ích trong trường hợp cụ thể này.

— Geoffrey Irving

Câu hỏi là những gì bạn đang cố gắng để giao tiếp, và công thức sẽ giao tiếp tốt nhất? Tôi không nghĩ rằng tôi đã từng thấy một bài báo cáo về sự biến động khi chạy để tăng tốc trừ khi nguyên nhân là trọng tâm của bài báo. Cho rằng chúng tôi đặt ra mối quan hệ tuyến tính giữa thời gian chạy và số lượng bộ xử lý / tác vụ / luồng, có lẽ bạn sẽ ổn khi sử dụng tỷ lệ phương tiện, nhưng sau đó thanh lỗi với tỷ lệ giữa tối đa và tối thiểu đến tối đa nếu bạn nghĩ hiển thị phạm vi là quan trọng. Ngoài ra, có lẽ bạn nên xem xét các tùy chọn chia tỷ lệ tần số và tác vụ để giảm bớt mức độ biến đổi của bạn. :)

— Bill Barth

Có thể có rất nhiều mánh khóe trong việc loại bỏ IO. Giữa các tối ưu hóa trình biên dịch thành các thủ thuật "Sao chép khi ghi" có thể có các mối quan hệ thực sự không rõ ràng đi xuống. Tôi thường theo nguyên mẫu của d1 = loadData (); d2 = bản sao (d1); r1 = algo (d2); r2 = algo (d1) và chỉ xem xét thời gian của lần chạy thứ hai.

— meawoppl

Câu trả lời:

Ngoài tất cả những gì Bill Barth đã nói ở trên, hãy để tôi đề cập rằng mọi người thường báo cáo nhanh nhất trong một số lần chạy. Lý do là thời gian chạy thực tế là thời gian chạy lý tưởng cộng với bất kỳ số lần chậm nào do các quá trình khác đang chạy, sự chậm trễ của hệ điều hành, sự chậm trễ mạng, v.v. Vì đây là tất cả những tiếng ồn mà chúng tôi không quan tâm, sử dụng thời gian chạy nhanh nhất gần nhất với người mà chúng ta thực sự muốn biết.

— Wolfgang Bangerth
nguồn

Thật không may, nguyên tắc này không giúp ích khi báo cáo tăng tốc giữa hai thuật toán.

— Geoffrey Irving

@GeoffreyIrving, tại sao không? Cả hai thuật toán đều có kỳ vọng về hiệu suất lý thuyết so với kích thước bài toán (hoặc số lượng bộ xử lý hoặc tham số không thống kê khác) với các thuật ngữ độc lập và tham số độc lập thấp. Sử dụng thời gian nhanh nhất (và lưu ý thực tế này) chỉ đơn giản là giúp bạn bỏ qua các điều khoản bổ sung này. Mà có vẻ như một chiến lược tốt. Trừ khi bạn nói với chúng tôi khác nhau, có vẻ như bạn đang cố gắng tìm ra cách truyền đạt sự khác biệt giữa các thuật toán một cách hiệu quả nhất và đề xuất của Wolfgang là thông thường và được mong đợi để nó có thể truyền đạt thông tin đó tốt nhất.

— Bill Barth

Rất tiếc, vâng, bạn đúng. Tôi vui vẻ rút lại tuyên bố của mình.

— Geoffrey Irving

(+1) Câu hỏi phụ: Tôi hoàn toàn thấy quan điểm của bạn về phân phối tiếng ồn không đối xứng , v.v ... Hãy nói rằng mặc dù tôi thực hiện A, và triển khai B và tôi đánh giá chúng và sau một số lần chạy hợp lý , Lượng tử thứ 25 và trung vị và trung bình nhanh hơn ~ 4,5 lần so với B trong khi lượng tử 0% là ~ 3x. Khi so sánh việc triển khai A với B, mặc dù thực tế rằng yes A is theoretically only ~3x faster:, không phải là tốc độ tăng gấp 3 lần so với tốc độ tăng tốc có thể mong đợi khi sử dụng triển khai A thay vì B? (Đây là một ví dụ thực tế bằng cách này)

— usεr11852 nói Rebstate Monic

@ usεr11852: Tất cả phụ thuộc vào hệ thống của bạn. Nếu lượng tử trung bình hoặc số 25 của bạn cách xa nhau đến mức làm sai lệch các số liệu thống kê theo cách bạn đưa ra giả thuyết ở đây, thì có khả năng bạn đang ở trên một hệ thống có nhiều tiếng ồn. Ví dụ, nó có thể được sử dụng bởi những người khác cùng một lúc, v.v. Đó có thể không phải là đại diện cho các hệ thống mà người khác có cho các thử nghiệm lặp lại của họ và nó có vẻ như tôi đang giám sát kết quả của bạn trong trường hợp đó. Vì vậy, tôi vẫn đề nghị báo cáo các hoạt động tốt nhất. Dù bạn làm gì, bạn nên báo cáo trong bài báo bạn sử dụng số liệu thống kê nào.

— Wolfgang Bangerth

Tôi đề nghị bạn sử dụng trung bình để đưa ra ước tính thống kê. Không giống như trung bình, trung vị không bị hỏng bởi các ngoại lệ.

— tháng một
nguồn

Đối với dữ liệu có tất cả nhiễu là dương (nghĩa là với phân bố nhiễu không đối xứng), trung vị cũng tệ như bất kỳ thống kê nào khác. Đối với thời gian chạy, đây thực sự là trường hợp, xem câu trả lời của tôi ở trên.

— Wolfgang Bangerth

Nếu độ lệch chuẩn không đáng kể, bạn có thể sử dụng hai ô vuông cạnh nhau, được xây dựng từng ô với thời gian của một trong các thuật toán. Chúng có nghĩa là không chuẩn trong phân tích số, nhưng chúng làm rất tốt trong việc hiển thị loại thông tin này.

— Federico Poloni
nguồn