Cara memvisualisasikan data acara untuk mencari masalah kinerja

10

Saya mencoba untuk mengoptimalkan aplikasi MPI dengan pola komunikasi yang sangat tidak sinkron. Setiap peringkat memiliki daftar hal-hal untuk dihitung, dan mengirim pesan seperlunya jika input atau output berada pada peringkat yang berbeda. Selain itu, setiap peringkat di utas (saat ini dengan satu utas komunikasi dan 5 pekerja).

Saya telah memasukkan kode dengan pengukur waktu di sekitar bagian kritis kinerja yang berbeda dari kode, yang memberi saya daftar tiga kali lipat (mulai, akhir, jenis) untuk setiap utas. Plot dengan cara yang jelas, dengan waktu sebagai sumbu horizontal, pangkat dan benang sebagai vertikal, dan warna yang menunjukkan apa yang sedang dilakukan masing-masing thread, saya mendapatkan gambar seperti ini untuk 16 peringkat dengan 6 benang / peringkat:

Peringkat dan sejarah thread Pentago

Pertanyaan saya adalah: apa cara lain untuk memvisualisasikan data ini yang dapat membantu merinci masalah kinerja? Adakah yang memiliki jenis plot favorit yang mereka gunakan saat membuat profil aplikasi asinkron?

Kumpulan data ini terbatas karena tidak mengetahui struktur aliran data, tetapi saya ingin mendapatkan wawasan sebanyak mungkin sebelum mencoba mengumpulkan sesuatu yang lebih rumit.

Gambar yang tidak terkompresi ada di sini kalau-kalau ada yang ingin melihat-lihat (gagal mengunggah melalui rute normal). Sayangnya, Firefox tidak menerimanya meskipun saya yakin itu valid, mungkin karena terlalu besar.

mpi visualization

— Geoffrey Irving
sumber

Saya agak kesulitan mendapatkan browser saya atau hampir semua program lain untuk memuat gambar besar. Pada akhirnya, gimp melakukannya, tetapi Anda mungkin ingin mempertimbangkan kembali opsi ukuran atau format file.

— Pedro

Maaf soal itu. Saya pikir gambar tersebut valid, karena Firefox memberi saya kesalahan yang sama dengan menjalankannya melalui konversi (ImageMagick). Mungkin melebihi ambang batas ukuran yang sewenang-wenang.

— Geoffrey Irving

4

Saya menghabiskan banyak waktu menulis dan men-debug kode paralel, baik dengan memori yang dibagikan dan / atau didistribusikan, tetapi tanpa mengetahui masalah spesifik Anda, saya hanya dapat memberi tahu Anda apa yang paling cocok untuk saya.

Mengetahui rutinitas mana yang memerlukan waktu berapa banyak adalah hal yang penting jika Anda melihat efisiensi komputasi, tetapi jika Anda khawatir tentang efisiensi paralel, maka Anda harus lebih khawatir tentang apa yang kode Anda lakukan ketika tidak melakukan perhitungan apa pun. Agak seperti khawatir apa yang dilakukan anak-anak ketika terlalu sepi ...

Karena Anda menggunakan pendekatan memori bersama / terdistribusi hibrid, saya kira kode Anda, di bagian yang kosong, baik menunggu panggilan MPI atau pada variabel mutex / kondisi. Anda juga dapat membungkus panggilan ini dengan timer, dan itu akan memberi Anda gambaran yang lebih baik tentang apa yang memperlambat Anda, misalnya jika selalu kondisional yang sama atau selalu sama MPI_REDUCEdengan utas Anda yang macet.

Salah satu perangkat lunak yang saya gunakan cukup sering adalah Intel Vtune Amplifier XE . Ini memiliki fitur / opsi plot bagus yang memvisualisasikan konkurensi utas. Program ini akan menggambar plot yang sangat mirip dengan Anda, namun ketika sebuah thread menunggu pada mutex atau variabel kondisi, ia menarik garis diagonal dari thread yang menunggu, pada saat itu mulai menunggu, ke thread yang benar-benar merilis mutex atau memberi sinyal kondisi yang ditunggu-tunggu, pada saat dilepaskan / diisyaratkan. Ini bisa sangat berantakan, tetapi itu membuat kemacetan muncul segera.

Akhirnya, saya juga mengumpulkan statistik massal, misalnya untuk setiap panggilan mutex / sinyal / MPI, berapa waktu tunggu rata-rata dan maksimum? Berapa histogram waktu tunggu yang dikumpulkan? Meskipun plot memberi Anda gambaran yang bagus, alurnya bisa berantakan ketika sampai pada detail halus.

Akhirnya, satu pertanyaan yang tidak boleh diremehkan: Bagaimana Anda mengumpulkan waktu Anda? Apakah timer Anda tidak cukup mengganggu untuk tidak mempengaruhi kode Anda? Saya menggunakan hitungan instruksi CPU bila memungkinkan, yaitu RDTSCpada arsitektur x86. Ini biasanya hanya menambah satu instruksi ke kode Anda.

— Pedro
sumber

Data sudah memiliki blok di sekitar semua menunggu; dalam diagram mereka ditampilkan sebagai putih untuk utas pekerja menganggur dan kuning untuk utas komunikasi menunggu. Sayangnya, semua menunggu dalam utas komunikasi terjadi dalam satu selimut MPI_Waitsome karena asinkron. Vtune tidak berlaku dalam kasus ini karena kinerja murni berulir pada dasarnya sempurna, tetapi terima kasih atas penunjuknya. Saran histogram juga bagus.

— Geoffrey Irving

Adapun waktu overhead: Saya menggunakan gettimeofday, yang diperlukan setidaknya di sekitar bagian idle karena saya menggunakan variabel kondisi pthread. Dapatkah penghitungan instruksi CPU dibuat untuk bekerja dalam situasi seperti itu? Biaya overhead sudah cukup rendah, tetapi lebih rendah tentu lebih baik.

— Geoffrey Irving

1

@ GeoffreyIrving: Ya, Anda dapat menggunakannya, tetapi mereka hanya masuk akal pada CPU yang memiliki constant_tscset flag (centang /proc/cpuinfo) dan jika Anda menggunakan kunci setiap utas ke inti tertentu, yaitu setiap utas selalu membaca register yang sama dari inti yang sama, misalnya menggunakan pthread_setaffinity_np. Perhatikan bahwa yang terakhir adalah khusus Linux dan karenanya tidak portabel.

— Pedro

@ GeoffreyIrving: Sekalipun Anda sedang menunggu acara yang dirahasiakan MPI_Waitsome, Anda masih bisa mencatat permintaan apa yang sebenarnya datang dan dari mana. Informasi ini mungkin atau mungkin tidak berguna ...

— Pedro

5

Terkadang Anda bisa mendapatkan pandangan alternatif tentang masalah kinerja melalui analisis sumber daya tingkat tinggi: Apakah ada hambatan yang relevan seperti bandwidth memori? Apakah setiap thread pekerja melakukan jumlah pekerjaan yang sama? Data ini dapat dikumpulkan dengan mudah dengan likwid-perfctr dari LIKWID tool suite proyek kode Google LIKWID . Jika profilnya sedemikian rupa sehingga ada banyak hot spot yang berbeda, Anda mungkin diminta untuk menanganinya satu per satu. Mungkin juga ada masalah yang berbeda, tergantung pada berapa banyak utas / proses yang digunakan.

— Georg Hager
sumber

Demi pengungkapan yang sempurna, Georg mengerjakan proyek LIKWID dan saya meminta tanggapan ini karena saya ingin melengkapi jawaban Pedro yang luar biasa dengan perspektif lain (dan alat yang hebat, tersedia secara bebas).

— Aron Ahmadia

2

Ketika saya memiliki masalah dalam jaringan proses yang sangat tidak sinkron yang diatur oleh pesan atau peristiwa, saya menggunakan metode yang tidak mudah tetapi efektif. Itu melibatkan mendapatkan log waktu proses, menggabungkan mereka ke dalam timeline umum, dan melacak kemajuan beberapa pesan ketika mereka memicu kegiatan, memicu pesan lebih lanjut. Apa yang saya cari adalah penundaan antara waktu pesan diterima dan waktu ditindaklanjuti, dan memahami alasan penundaan. Ketika masalah ditemukan, itu diperbaiki, dan prosesnya diulang. Dengan cara ini, Anda bisa mendapatkan kinerja yang sangat memuaskan.

Penting untuk melihat bagaimana ini berbeda dari pendekatan di mana Anda mengukur, mengukur, mengukur. Satu-satunya hal yang dapat diukur menurut Anda adalah di mana Anda tidak harus melihatnya. Penyesuaian kinerja nyata membutuhkan melihat detail dengan cermat, dari perspektif waktu. Apa yang Anda cari bukanlah di mana waktu dihabiskan, tetapi di mana dihabiskan secara tidak perlu.

Semoga berhasil.

— Mike Dunlavey
sumber

Dengan kata lain, tidak ada visualisasi berguna dari data yang saya miliki. :) Jed Brown menyarankan Jumpshot (dan utilitas terkait) sebagai salah satu cara untuk mengumpulkan dan memvisualisasikan data yang Anda sarankan, jadi saya akan memeriksanya.

— Geoffrey Irving

@ Geof: Semoga berhasil dengan visualisasi. Satu-satunya alat yang saya anggap berguna adalah sesuatu untuk mengumpulkan dan menggabungkan log peristiwa sehingga saya bisa mengikuti jalur satu atau lebih permintaan saat itu membuat jalan melalui berbagai utas, karena itu satu-satunya cara saya tahu untuk mendeteksi yang tidak perlu keterlambatan. Itulah yang akan terjadi pada masalah kinerja - penundaan yang tidak perlu.

— Mike Dunlavey