Statistik yang benar untuk melaporkan hasil percepatan


12

Katakanlah saya memiliki versi kode yang lambat dan cepat, dan ingin melaporkan nomor percepatan yang membandingkan keduanya. Saya menjalankan versi lambat kali dan versi cepat m kali, menghasilkan kali ( s 1 , ... , s n ) dan ( f 1 , ... , f m ) . Cara paling sederhana untuk menghasilkan speedup adalah dengan cara rata-rata: ˉ snm(s1,,sn)(f1,,fm) Namun, ini tidak mengambil outlier ke rekening.

s¯f¯=mi<nsinj<mfj

Pertanyaan : Apa statistik terbaik untuk digunakan ketika melaporkan angka-angka percepatan?


3
Seberapa besar standar deviasi dibandingkan dengan rata-rata? Apa pun yang Anda lakukan, Anda harus melaporkan apa yang Anda lakukan dan mungkin menempatkan bar kesalahan jika mereka besar. Jika benar-benar besar, Anda harus menyelidiki sumbernya. Sebagian besar kode komputer harus berjalan cukup deterministik dalam waktu kecuali ada komponen acak untuk program itu sendiri atau Anda berbagi sumber daya komputer dengan orang lain (ini bisa berupa jaringan atau disk, bukan hanya node cluster). Jika persaingan untuk sumber daya disk adalah masalahnya, Anda dapat mempertimbangkan melaporkan kinerja dengan I / O dinonaktifkan (sangat umum) - pastikan untuk mencatatnya.
Bill Barth

Pada Edison (komputer super Cray), saya memiliki perbedaan 2% antara dua sampel. Di laptop saya, saya melihat standar deviasi 6-8% diukur lebih dari 10 sampel. Keduanya hanya untuk kernel komputasi, tanpa I / O.
Geoffrey Irving

Untuk mengklarifikasi mengapa saya menyebutkan pencilan jika variasinya sudah cukup rendah: ini adalah jumlah statistik yang cukup mendasar sehingga saya ingin mengetahui cara yang ideal untuk melaporkannya, bahkan saya cara nonideal baik-baik saja dalam kasus khusus ini.
Geoffrey Irving

2
Pertanyaannya adalah apa yang Anda coba komunikasikan, dan formula akan mengkomunikasikan yang terbaik? Saya tidak berpikir saya pernah melihat sebuah makalah yang melaporkan variabilitas run-to-run dalam speedup kecuali jika penyebabnya adalah pusat kertas. Mengingat bahwa kami menempatkan hubungan linier antara waktu berjalan dan jumlah prosesor / tugas / utas, Anda mungkin baik-baik saja untuk menggunakan rasio rata-rata, tetapi kemudian bilah kesalahan dengan rasio max-to-min dan min-to-max jika Anda berpikir menunjukkan kisaran itu penting. Selain itu, Anda mungkin harus melihat opsi penskalaan frekuensi dan penandaan tugas untuk mengurangi variabilitas Anda. :)
Bill Barth

Mungkin ada banyak tipu daya dalam menghilangkan IO. Di antara optimisasi kompiler ke trik "Salin Saat Menulis" mungkin ada ikatan yang tidak jelas ke bawah. Saya biasanya mengikuti prototipe d1 = loadData (); d2 = copy (d1); r1 = algo (d2); r2 = algo (d1), dan hanya mempertimbangkan waktu lari kedua.
meawoppl

Jawaban:


9

Selain semua yang telah dikatakan Bill Barth di atas, izinkan saya menyebutkan bahwa orang sering melaporkan yang tercepat dari beberapa putaran. Alasannya adalah bahwa waktu menjalankan sebenarnya adalah waktu berjalan yang ideal ditambah sejumlah lambat yang dihasilkan dari proses lain yang berjalan, keterlambatan OS, keterlambatan jaringan, dll. Karena ini semua suara yang tidak kami minati, menggunakan waktu lari tercepat datang paling dekat dengan yang kita benar-benar ingin tahu.


Sayangnya, prinsip ini tidak membantu saat melaporkan percepatan antara dua algoritma.
Geoffrey Irving

3
@ GeoffreyIrving, mengapa tidak? Kedua algoritma memiliki ekspektasi kinerja teoritis vs ukuran masalah (atau jumlah prosesor atau parameter non-statistik lainnya) dengan istilah orde-independen dan parameter rendah diabaikan. Menggunakan waktu tercepat (dan mencatat fakta ini) hanya membantu Anda mengabaikan ketentuan tambahan ini. Yang sepertinya strategi yang bagus. Kecuali jika Anda memberi tahu kami secara berbeda, sepertinya Anda mencoba mencari cara untuk mengkomunikasikan perbedaan antara algoritma yang paling efektif, dan saran Wolfgang adalah konvensional dan diharapkan sehingga dapat menyampaikan informasi itu dengan baik.
Bill Barth

1
Ups, ya, Anda benar. Saya dengan senang hati menarik pernyataan saya.
Geoffrey Irving

(+1) Sebuah pertanyaan sampingan: Saya menyelesaikan melihat poin Anda tentang distribusi noise non-simetris , dll. Katakanlah meskipun saya membuat implementasi A, dan implementasi B dan saya benchmark mereka dan setelah jumlah yang wajar berjalan, 25-th kuantil dan median dan rata-rata ~ 4,5x lebih cepat dalam A daripada B sedangkan 0% kuantil adalah ~ 3x. Ketika membandingkan implementasi A ke B, terlepas dari kenyataan bahwa yes A is theoretically only ~3x faster:, bukankah ~ 3x percepatan tidak representatif dari percepatan yang mungkin diharapkan saat menggunakan implementasi A alih-alih B? (Ini adalah contoh kehidupan nyata)
usεr11852

1
@ usεr11852: Semuanya tergantung pada sistem yang Anda gunakan. Jika median atau kuantil ke-25 Anda begitu berjauhan sehingga mendistorsi statistik dengan cara Anda berhipotesis di sini, maka Anda kemungkinan pada sistem yang memiliki banyak suara. Sebagai contoh, ini dapat digunakan oleh orang lain pada saat yang sama, dll. Itu mungkin tidak mewakili sistem yang dimiliki orang lain untuk percobaan ulang mereka, dan itu akan terdengar bagi saya seperti Anda terlalu banyak menjual hasil Anda dalam kasus itu. Jadi, saya masih menyarankan untuk melaporkan kinerja terbaik. Apa pun yang Anda lakukan, Anda harus melaporkan di koran statistik apa yang Anda gunakan.
Wolfgang Bangerth

1

Saya sarankan Anda menggunakan median untuk memberikan perkiraan statistik. Berbeda dengan rata-rata, median tidak dikorupsi oleh outlier.


1
Untuk data di mana semua noise positif (yaitu, dengan distribusi noise non-simetris), median sama buruknya dengan statistik lainnya. Untuk run-times, inilah masalahnya, lihat jawaban saya di atas.
Wolfgang Bangerth

0

Jika standar deviasi tidak dapat diabaikan, Anda dapat menggunakan dua plot kotak berdampingan, dibangun masing-masing dengan waktu salah satu algoritma. Mereka tentu saja tidak standar dalam analisis numerik, tetapi mereka melakukan pekerjaan besar dalam menampilkan informasi semacam ini.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.