T1: Alat apa yang Anda gunakan untuk profiling kode (profiling, bukan benchmarking)?
T2: Berapa lama Anda membiarkan kode berjalan (statistik: berapa langkah waktu)?
T3: Seberapa besar kasing (jika kasing masuk ke dalam cache, solver adalah urutan besarnya lebih cepat, tetapi kemudian saya akan melewatkan proses terkait memori)?
Inilah contoh bagaimana saya melakukannya.
Saya memisahkan pembandingan (melihat berapa lama) dari profil (mengidentifikasi cara membuatnya lebih cepat). Tidaklah penting bahwa profiler menjadi cepat. Penting untuk memberi tahu Anda apa yang harus diperbaiki.
Saya bahkan tidak suka kata "profil" karena memunculkan gambar seperti histogram, di mana ada bilah biaya untuk setiap rutin, atau "bottleneck" karena itu menyiratkan hanya ada sedikit tempat dalam kode yang perlu tetap. Kedua hal ini menyiratkan semacam waktu dan statistik, yang Anda anggap akurasi adalah penting. Tidak ada gunanya memberikan wawasan untuk ketepatan waktu.
Metode yang saya gunakan adalah jeda acak, dan ada studi kasus lengkap dan peragaan slide di sini . Bagian dari pandangan dunia profiler-bottleneck adalah bahwa jika Anda tidak menemukan apa-apa, tidak ada yang ditemukan, dan jika Anda menemukan sesuatu dan mendapatkan persen percepatan tertentu, Anda menyatakan kemenangan dan berhenti. Penggemar profiler hampir tidak pernah mengatakan berapa banyak peningkatan yang mereka dapatkan, dan iklan hanya menampilkan masalah yang dibuat secara artifisial yang dirancang agar mudah ditemukan. Jeda acak menemukan masalah apakah itu mudah atau sulit. Kemudian memperbaiki satu masalah memperlihatkan yang lain, sehingga proses dapat diulang, untuk mendapatkan percepatan yang diperparah.
Dalam pengalaman saya dari banyak contoh, begini caranya: Saya dapat menemukan satu masalah (dengan jeda acak) dan memperbaikinya, mendapatkan percepatan beberapa persen, katakanlah 30% atau 1,3x. Maka saya bisa melakukannya lagi, menemukan masalah lain dan memperbaikinya, mendapatkan speedup lain, mungkin kurang dari 30%, mungkin lebih. Maka saya bisa melakukannya lagi, beberapa kali sampai saya benar-benar tidak dapat menemukan hal lain untuk diperbaiki. Faktor percepatan utama adalah produk yang berjalan dari faktor-faktor individual, dan itu bisa luar biasa besar - pesanan besarnya dalam beberapa kasus.
TERMASUK: Hanya untuk menggambarkan poin terakhir ini. Ada contoh terperinci di sini , dengan tampilan slide dan semua file, yang menunjukkan bagaimana speedup 730x dicapai dalam serangkaian pemindahan masalah. Versi pertama mengambil 2700 mikrodetik per unit kerja. Masalah A telah dihapus, membawa waktu ke 1800, dan memperbesar persentase masalah yang tersisa sebesar 1,5x (2700/1800). Kemudian B dihapus. Proses ini berlanjut melalui enam iterasi, menghasilkan hampir 3 perintah percepatan magnitudo. Tetapi teknik pembuatan profil harus benar-benar manjur, karena jika salah satu dari masalah itu tidak ditemukan, yaitu jika Anda mencapai titik di mana Anda salah berpikir tidak ada lagi yang bisa dilakukan, proses terhenti.
DITERBITKAN: Dengan kata lain, inilah grafik dari total faktor percepatan saat masalah yang berurutan dihapus:
Jadi untuk Q1, untuk benchmarking, timer sederhana sudah cukup. Untuk "profiling", saya menggunakan penghentian sementara.
T2: Saya memberikannya beban kerja yang cukup (atau hanya memutarnya) sehingga berjalan cukup lama untuk berhenti.
T3: Dengan segala cara, berikan itu beban kerja yang sangat besar sehingga Anda tidak ketinggalan masalah cache. Itu akan muncul sebagai sampel dalam kode melakukan pengambilan memori.