Fitur program pembuatan profil dalam C ++

Kadang-kadang, mungkin perlu untuk profil kinerja program atau konsumsi memori dalam program C ++. Sayangnya, seringkali ini tidak semudah kelihatannya.

Di sini kita akan mempertimbangkan fitur program profil menggunakan alat valgrind dan google perftools . Materi itu ternyata tidak terlalu terstruktur, itu lebih merupakan upaya untuk mengumpulkan basis pengetahuan "untuk tujuan pribadi" sehingga di masa depan Anda tidak perlu dengan panik mengingat "mengapa ini tidak berhasil" atau "bagaimana melakukannya". Kemungkinan besar, tidak semua kasus yang tidak jelas akan terpengaruh di sini, jika Anda memiliki sesuatu untuk ditambahkan, silakan tulis di komentar.

Semua contoh akan berjalan di sistem linux.

Runtime Profiling

Persiapan

Untuk menganalisis fitur-fitur pembuatan profil, saya akan menjalankan program kecil, biasanya terdiri dari satu file main.cpp dan satu file func.cpp beserta inklusi.
Saya akan mengkompilasinya dengan kompiler g ++ 8.3.0 .

Karena profiling program yang tidak dioptimalkan adalah tugas yang agak aneh, kami akan mengkompilasi dengan opsi -Ofast , dan untuk mendapatkan karakter debug dalam output, kami tidak akan lupa untuk menambahkan opsi -g . Namun, terkadang alih-alih nama fungsi normal, Anda hanya dapat melihat alamat panggilan yang tidak terdengar. Ini berarti bahwa telah ada "pengacakan alokasi ruang alamat". Ini dapat ditentukan dengan memanggil perintah nm pada biner. Jika sebagian besar alamat terlihat seperti ini 0000000000003030e0 (sejumlah besar nol di awal), maka kemungkinan besar ini dia. Dalam program normal, alamatnya terlihat seperti 0000000000402fa0. Karena itu, Anda perlu menambahkan opsi -no-pie . Akibatnya, set lengkap opsi akan terlihat seperti ini:
-Bergas -g -tidak-pai

Untuk melihat hasilnya, kami akan menggunakan program KCachegrind , yang dapat bekerja dengan format laporan callgrind

Callgrind

Utilitas pertama yang akan kita lihat hari ini adalah callgrind . Utilitas ini adalah bagian dari alat valgrind. Ini mengemulasi setiap instruksi yang dapat dieksekusi dari program dan, berdasarkan metrik internal tentang "biaya" dari setiap instruksi, mengeluarkan kesimpulan yang kita butuhkan. Karena pendekatan ini, kadang-kadang terjadi bahwa callgrind tidak dapat mengenali instruksi selanjutnya dan jatuh dengan kesalahan
Instruksi tidak dikenal di alamat
Satu-satunya jalan keluar dari situasi ini adalah dengan mempertimbangkan kembali semua opsi kompilasi dan mencoba menemukan interferensi

Mari kita buat program untuk menguji alat ini, yang terdiri dari satu pustaka bersama dan satu pustaka statis (nanti kita akan menyerahkan pustaka dalam pengujian lain). Setiap perpustakaan, serta program itu sendiri, akan menyediakan fungsi komputasi yang sederhana, misalnya, perhitungan urutan Fibonacci.




Kami mengkompilasi program, dan menjalankan valgrind sebagai berikut:

 valgrind --tool=callgrind ./test_profiler 100000000 

Kami melihat bahwa untuk pustaka statis dan fungsi reguler, hasilnya mirip dengan yang diharapkan. Tetapi di perpustakaan dinamis, callgrind tidak bisa sepenuhnya menyelesaikan fungsi.

Untuk memperbaiki ini, ketika memulai program, Anda perlu mengatur variabel LD_BIND_NOW menjadi 1, seperti ini:

 LD_BIND_NOW=1 valgrind --tool=callgrind ./test_profiler 100000000 

Dan sekarang, seperti yang Anda lihat, semuanya baik-baik saja

Masalah callgrind berikutnya yang muncul dari profil dengan meniru instruksi adalah bahwa eksekusi program banyak melambat. Ini dapat membawa estimasi relatif yang salah dari waktu eksekusi berbagai bagian kode.

Mari kita lihat kode ini:

 int func(int arg) { int fst = 1; int snd = 1; std::ofstream file("tmp.txt"); for (int i = 0; i < arg; i++) { int res = (fst + snd + 1) % 19845689; std::string r = std::to_string(res); file << res; file.flush(); fst = snd; snd = res + r.size(); } return fst; } 

Di sini, saya menambahkan sejumlah kecil data ke file untuk setiap iterasi dari loop. Karena menulis ke file adalah operasi yang agak panjang, sebagai penyeimbang, saya menambahkan generasi garis dari angka ke setiap iterasi dari loop. Jelas, dalam hal ini, operasi penulisan ke file membutuhkan waktu lebih lama dari sisa logika fungsi. Tetapi callgrind berpikir secara berbeda:


Perlu juga dipertimbangkan bahwa panggilan balik hanya dapat mengukur biaya suatu fungsi saat bekerja. Fungsi tidak berfungsi - karenanya, biaya tidak meningkat. Ini menyulitkan debugging program yang dari waktu ke waktu memasukkan kunci atau bekerja dengan sistem / jaringan file pemblokiran. Mari kita periksa:

 #include "func.h" #include <mutex> static std::mutex mutex; int funcImpl(int arg) { std::lock_guard<std::mutex> lock(mutex); int fst = 1; int snd = 1; for (int i = 0; i < arg; i++) { int res = (fst + snd + 1) % 19845689; fst = snd; snd = res; } return fst; } int func2(int arg){ return funcImpl(arg); } int func(int arg) { return funcImpl(arg); } int main(int argc, char **argv) { if (argc != 2) { std::cout << "Incorrect args"; return -1; } const int arg = std::atoi(argv[1]); auto future = std::async(std::launch::async, &func2, arg); std::cout << "result: " << func(arg) << std::endl; std::cout << "second result " << future.get() << std::endl; return 0; } 

Di sini kita telah melampirkan seluruh eksekusi fungsi di kunci mutex, dan memanggil fungsi ini dari dua utas yang berbeda. Hasil dari callgrind cukup dapat diprediksi - ia tidak melihat masalah dalam menangkap mutex:


Jadi, kami memeriksa beberapa masalah dalam menggunakan profiler panggilan. Mari kita beralih ke subjek tes berikutnya - profiler google perftools

google perftools

Tidak seperti callgrind, google profiler bekerja berdasarkan prinsip yang berbeda.
Alih-alih menganalisis setiap instruksi dari program yang dapat dieksekusi, itu menjeda program secara berkala dan mencoba untuk menentukan fungsi yang saat ini berada di dalamnya. Akibatnya, ini hampir tidak mempengaruhi kinerja aplikasi yang sedang berjalan. Namun pendekatan ini juga memiliki kelemahannya.

Mari kita mulai dengan membuat profil program pertama dengan dua perpustakaan.

Sebagai aturan, untuk mulai membuat profil dengan utilitas ini, Anda harus melakukan preload pustaka libprofiler.so, mengatur frekuensi sampling dan menentukan file untuk menyimpan dump. Sayangnya, profiler membutuhkan program untuk mengakhiri "sendiri." Pengakhiran paksa program akan menyebabkan laporan tidak dibuang begitu saja. Ini tidak nyaman ketika membuat profil program yang berumur panjang yang tidak berhenti, seperti daemon. Untuk mengatasi kendala ini, saya membuat skrip ini:


Utilitas ini perlu dijalankan, lewat sebagai parameter nama file yang dapat dieksekusi dan daftar parameternya. Juga, diasumsikan bahwa di sebelah skrip adalah file yang ia butuhkan libprofiler.so dan pprof. Jika program ini berumur panjang dan berhenti dengan mengganggu eksekusi, Anda harus mengatur variabel N_STOP menjadi true, misalnya, seperti ini:

 N_STOP=true ./gprof.sh ./test_profiler 10000000000 

Di akhir pekerjaan, skrip akan menghasilkan laporan dalam format callgrind favorit saya.

Jadi, mari kita jalankan program kami di bawah profiler ini.

 ./gprof.sh ./test_profiler 1000000000 

Pada prinsipnya, semuanya cukup jelas.

Seperti yang saya katakan, profiler Google bekerja dengan menghentikan eksekusi program dan menghitung fungsi saat ini. Bagaimana dia melakukannya? Dia melakukan ini dengan memutar tumpukan. Tetapi bagaimana jika, pada saat promosi tumpukan, program itu sendiri melepaskan tumpukan? Jelas, tidak ada hal baik yang akan terjadi. Mari kita periksa. Mari kita tulis fungsi seperti itu:

 int runExcept(int res) { if (res % 13 == 0) { throw std::string("Exception"); } return res; } int func(int arg) { int fst = 1; int snd = 1; for (int i = 0; i < arg; i++) { int res = (fst + snd + 1) % 19845689; try { res = runExcept(res); } catch (const std::string &e) { res = res - 1; } fst = snd; snd = res; } return fst; } 

Dan jalankan profil. Program membeku dengan sangat cepat.

Ada masalah lain yang terkait dengan kekhasan operasi profiler. Misalkan kita berhasil melepaskan tumpukan, dan sekarang kita perlu mencocokkan alamat dengan fungsi spesifik dari program. Ini bisa sangat non-trivial, karena di C ++ sejumlah besar fungsi sebaris. Mari kita lihat contoh seperti ini:

 #include "func.h" static int func1(int arg) { std::cout << 1 << std::endl; return func(arg); } static int func2(int arg) { std::cout << 2 << std::endl; return func(arg); } static int func3(int arg) { std::cout << 3 << std::endl; if (arg % 2 == 0) { return func2(arg); } else { return func1(arg); } } int main(int argc, char **argv) { if (argc != 2) { std::cout << "Incorrect args"; return -1; } const int arg = std::atoi(argv[1]); int arg2 = func3(arg); int arg3 = func(arg); std::cout << "result: " << arg2 + arg3; return 0; } 

Tentunya, jika Anda menjalankan program misalnya seperti ini:

 ./gprof.sh ./test_profiler 1000000000 

maka fungsi func1 tidak akan pernah dipanggil. Tetapi profiler itu berpikir berbeda:

(Omong-omong, valgrind di sini memutuskan untuk tetap diam dan tidak menentukan fungsi spesifik dari mana panggilan itu berasal).

Pembuatan profil memori

Seringkali ada situasi ketika memori dari aplikasi di suatu tempat "mengalir". Jika ini disebabkan oleh kurangnya pembersihan sumber daya, maka Memcheck akan membantu mengidentifikasi masalah. Tetapi dalam C ++ modern tidak begitu sulit dilakukan tanpa manajemen sumber daya manual. unique_ptr, shared_ptr, vektor, peta membuat manipulasi bare-point menjadi sia-sia.

Namun demikian, dalam aplikasi seperti itu, memori bocor. Bagaimana kabarnya? Sederhananya, sebagai aturan, itu adalah sesuatu seperti "memasukkan nilai dalam peta berumur panjang, tetapi lupa untuk menghapusnya". Mari kita coba lacak situasi ini.

Untuk melakukan ini, kami menulis ulang fungsi pengujian kami dengan cara ini

 #include "func.h" #include <deque> #include <string> #include <map> static std::deque<std::string> deque; static std::map<int, std::string> map; int func(int arg) { int fst = 1; int snd = 1; for (int i = 0; i < arg; i++) { int res = (fst + snd + 1) % 19845689; fst = snd; snd = res; deque.emplace_back(std::to_string(res) + " integer"); map[i] = "integer " + std::to_string(res); deque.pop_front(); if (res % 200 != 0) { map.erase(i - 1); } } return fst; } 

Di sini, pada setiap iterasi, kami menambahkan beberapa elemen ke peta, dan secara tidak sengaja (benar, benar) kami terkadang lupa menghapusnya dari sana. Juga, untuk menghindari mata kita, kita menyiksa std :: deque sedikit.

Kami akan menangkap kebocoran memori dengan dua alat - valgrind massif dan google heapdump .

Massif

Jalankan program dengan perintah ini

 valgrind --tool=massif ./test_profiler 1000000 

Dan kita melihat sesuatu seperti


Dapat dilihat bahwa massif mampu mendeteksi kebocoran pada fungsinya, tetapi sejauh ini tidak jelas di mana. Mari kita membangun kembali program dengan flag -fno-inline dan menjalankan analisis lagi


Sekarang sudah jelas di mana letak kebocoran dalam menambahkan elemen peta. Massif dapat mendeteksi objek berumur pendek, jadi manipulasi dengan std :: deque tidak terlihat dalam dump ini.

Heapdump

Agar google heapdump berfungsi, Anda perlu menautkan atau memuat pramuka perpustakaan tcmalloc . Perpustakaan ini menggantikan fungsi standar alokasi memori malloc, gratis, ... Juga, dapat mengumpulkan informasi tentang penggunaan fungsi-fungsi ini, yang akan kita gunakan untuk menganalisis program.

Karena metode ini bekerja sangat lambat (bahkan dibandingkan dengan massif), saya sarankan Anda segera menonaktifkan kompilasi fungsi dengan opsi -fno-inline saat mengkompilasi. Jadi, kami membangun kembali aplikasi kami dan berjalan bersama tim

 HEAPPROFILESIGNAL=23 HEAPPROFILE=./heap ./test_profiler 100000000 

Di sini diasumsikan bahwa pustaka tcmalloc ditautkan ke aplikasi kita.

Sekarang, kita menunggu beberapa waktu yang diperlukan untuk pembentukan kebocoran yang nyata, dan mengirimkan sinyal kepada proses kita 23

 kill -23 <pid> 

Akibatnya, sebuah file bernama heap.0001.heap muncul, yang kami konversi ke format callgrind dengan perintah

 pprof ./test_profiler "./heap.0001.heap" --inuse_space --callgrind > callgrind.out.4 

Juga perhatikan opsi pprof. Anda dapat memilih dari opsi inuse_space , inuse_objects , alokasi_space , alokasi_objects , yang menunjukkan ruang atau objek yang sedang digunakan, atau ruang dan objek yang dialokasikan untuk seluruh durasi program, masing-masing. Kami tertarik pada opsi inuse_space, yang menunjukkan ruang memori yang saat ini digunakan.

Buka kCacheGrind favorit kami dan lihat

std :: map telah memakan terlalu banyak memori. Mungkin ada kebocoran di dalamnya.

Kesimpulan

Membuat profil di C ++ adalah tugas yang sangat sulit. Di sini kita harus berurusan dengan fungsi inlining, instruksi yang tidak didukung, hasil yang salah, dll. Tidak selalu mungkin untuk mempercayai hasil profiler.

Selain fungsi yang diusulkan di atas, ada alat-alat lain yang dirancang untuk profil - perf, intel VTune dan lainnya. Tetapi mereka juga menunjukkan beberapa kekurangan ini. Oleh karena itu, jangan lupa tentang metode "kakek" dalam membuat profil dengan mengukur waktu eksekusi fungsi dan menampilkannya dalam log.

Juga, jika Anda memiliki teknik yang menarik untuk membuat profil kode Anda, silakan mempostingnya di komentar