PIRA
v0.6.0
Kerangka kerja otomasi Penyempurnaan Instrumentasi Kinerja PIRA mendekati tugas yang memakan waktu untuk menghasilkan pengukuran kinerja yang masuk akal untuk basis kode yang tidak diketahui saat menggunakan Score-P. Untuk informasi lebih lanjut silakan lihat makalah kami:
| [PI18] | Jan-Patrick Lehr, Alexander Huck, Christian Bischof. PIRA: otomatisasi penyempurnaan instrumentasi kinerja. Dalam Lokakarya Internasional ACM SIGPLAN ke-5 tentang Kecerdasan Buatan dan Metode Empiris untuk Rekayasa Perangkat Lunak dan Sistem Komputasi Paralel (AI-SEPS) , halaman 1-10, ACM, 2018. |
| [PI19] | Jan-Patrick Lehr, Alexandru Calotoiu, Christian Bischof, Felix Wolf. Penyempurnaan Instrumentasi Otomatis untuk Pemodelan Kinerja Empiris. Dalam Lokakarya Internasional tentang Pemrograman dan Alat Visualisasi Kinerja (ProTools) , halaman 40-47, IEEE, 2019. |
| [PI21] | Peter Arzt, Yannic Fischler, Jan-Patrick Lehr, Christian Bischof. Deteksi Ketidakseimbangan Beban Overhead Rendah Otomatis dalam Aplikasi MPI. Di Euro-Par 2021: Pemrosesan Paralel. Catatan Kuliah Ilmu Komputer, vol 12820 , halaman 19-34, Springer, 2021. |
PIRA menjalankan empat fase berikut (2-4 diulang):
PIRA mendukung pemfilteran fungsi waktu kompilasi dan waktu proses , termasuk pemfilteran waktu proses fungsi MPI melalui pembungkus yang dibuat secara otomatis. Dalam pemfilteran waktu kompilasi, hanya fungsi yang diinginkan yang diinstrumentasikan pada waktu kompilasi, sehingga mengurangi pengaruh pengukuran keseluruhan secara signifikan. Sebaliknya, dalam pemfilteran waktu proses, kompiler menyisipkan kait instrumentasi ke dalam setiap fungsi aplikasi target, dan pemfilteran terjadi pada waktu proses.
PIRA membutuhkan CMake (>=3.16), Clang/LLVM 10, Python 3, Qt5 dan OpenMPI 4. Ini (atau MetaCG) selanjutnya akan diunduh (dan dibangun)
Jika Anda ingin membangun PIRA di lingkungan tanpa akses internet, silakan lihat skrip resources/build_submodules.sh , dan sesuaikan dengan kebutuhan Anda.
Kloning repositori PIRA.
$> git clone https://github.com/tudasc/pira
$> cd pira
Kedua, buat submodul dependen menggunakan skrip yang disediakan, atau berikan nilai untuk opsi berbeda (lihat info penggunaan melalui -h untuk opsi yang tersedia). Semua file yang diunduh dan dibuat akan ditempatkan di external/src/ sementara semua instalasi akan ditempatkan di external/install/ . Tentukan jumlah proses kompilasi yang akan dilakukan untuk kompilasi eksternal PIRA. Skrip akan mengunduh dependensi PIRA dalam versi defaultnya. Versi ini juga diuji di CI kami dan diharapkan berfungsi.
$> cd resources
$> ./build_submodules.sh -p <ncores>
Sebagai langkah terakhir, skrip build akan menulis jalur instalasi submodul ke dalam file resources/setup_paths.sh . Jika Anda ingin membangun kembali PIRA, harap ingat untuk git restore file ini.
Kami juga menyediakan Dockerfile (eksperimental) untuk membangun PIRA dan mencobanya.
$> podman build -t pira:master -f docker/Dockerfile .
Saat menjalankan di dalam container, misalnya pengujian integrasi, harap aktifkan skrip sebagai berikut.
$> cd resources
$> . setup_paths.sh
$> cd ../test/integration/GameOfLife # Example test case
# By default PIRA will look into $HOME/.local, which is not currently existent in the docker
# XDG_DATA_HOME signals where to put the profiling data PIRA generates
$> XDG_DATA_HOME=/tmp ./run.sh
Untuk contoh lengkap cara menggunakan PIRA, periksa skrip run.sh di folder /test/integration/* . Titik awal yang berpotensi baik adalah folder GameOfLife dan test case-nya.
Pertama, atur jalur yang diperlukan dengan mencari sumber skrip di folder resources .
$> cd resources/
$> . setup_paths.sh
Kemudian, Anda dapat menjalankan contoh aplikasi PIRA pada implementasi Conway's Game of Life yang sangat sederhana dengan menggunakan skrip run.sh yang disediakan di folder ./test/integration/GameOfLife .
$> cd ./test/integration/GameOfLife
$> ./run.sh
Skrip melakukan semua langkah yang diperlukan dari awal, yaitu menyiapkan semua komponen untuk kode target baru, hingga akhirnya memanggil PIRA. Pada bagian selanjutnya, langkah-langkah tersebut dijelaskan lebih detail. Langkah-langkahnya adalah:
config Jalur ke file konfigurasi (argumen yang diperlukan)--config-version [1,2] Versi konfigurasi PIRA, 2 adalah default dan dianjurkan; 1 tidak digunakan lagi.--runtime-filter Gunakan pemfilteran run-time, defaultnya salah. Dalam pemfilteran waktu kompilasi, fungsi tidak diinstrumentasikan pada waktu kompilasi, sehingga mengurangi pengaruh pengukuran keseluruhan secara signifikan, namun mengharuskan target dibuat ulang di setiap iterasi. Sebaliknya, dengan pemfilteran runtime, kompiler menyisipkan kait instrumentasi di setiap fungsi aplikasi target.--iterations [number] Jumlah iterasi Pira, nilai defaultnya adalah 3.--repetitions [number] Jumlah pengulangan pengukuran, nilai defaultnya adalah 3.--tape Lokasi di mana rekaman logging (agak luas) harus ditulis.--extrap-dir Direktori dasar tempat struktur folder Extra-p ditempatkan.--extrap-prefix Awalan ekstra-P, harus berupa rangkaian karakter.--version Mencetak nomor versi instalasi PIRA--analysis-parameters Jalur ke file konfigurasi yang berisi parameter analisis untuk PGIS. Diperlukan untuk mode Extra-P dan LIDe.--slurm-config [path to slurm cfg file] Memungkinkan menjalankan kode target pada cluster slurm. File konfigurasi slurm diperlukan. Silakan lihat bagian ini untuk informasi lebih lanjut. --hybrid-filter-iters [number] Kompilasi ulang setelah [number] iterasi, gunakan pemfilteran runtime di antaranya.--export Melampirkan model Extra-P yang dihasilkan dan ukuran kumpulan data ke dalam file IPCG target.--export-runtime-only Membutuhkan --export ; Hanya melampirkan nilai median runtime dari semua pengulangan ke fungsi. Hanya tersedia saat tidak menggunakan Extra-P.--load-imbalance-detection [path to cfg file] Mengaktifkan dan mengonfigurasi mode deteksi ketidakseimbangan beban. Silakan baca bagian ini untuk informasi lebih lanjut. PIRA menggunakan informasi kode sumber untuk membuat instrumentasi awal dan memutuskan fungsi mana yang akan ditambahkan ke instrumentasi selama penyempurnaan berulang. Ini menyediakan alat grafik panggilan berbasis Dentang yang mengumpulkan semua informasi yang diperlukan dan mengeluarkan informasi dalam file .json . Anda dapat menemukan alat cgcollector di subdirektori ./extern/src/metacg/cgcollector . PIRA mengharuskan file callgraph berada dalam format file MetaCG di versi 2 (MetaCG v2).
Informasi lebih lanjut tentang CGCollector dan komponennya dapat ditemukan di dokumentasi MetaCG.
Penerapan CGCollector biasanya terjadi dalam dua langkah.
Pada awalnya, cgc dipanggil pada setiap file sumber dalam proyek. misalnya:
for f in $(find ./src -type f ( -iname "*.c" -o -iname "*.cpp" ) ); do
cgc --metacg-format-version=2 $f
done
File .ipcg yang dibuat pada langkah 1 kemudian digabungkan ke file umum menggunakan cgmerge .
"null" 2. Jika proyek Anda berisi lebih dari satu fungsi main , harap gabungkan file dengan fungsi main yang benar saja. echo "null" > $IPCG_FILENAME
find ./src -name "*.ipcg" -exec cgmerge $IPCG_FILENAME $IPCG_FILENAME {} +
Grafik terakhir perlu ditempatkan ke dalam direktori callgraph-analyzer. Karena PGIS saat ini digunakan untuk analisis CG, seluruh file program yang dihasilkan disalin ke direktori PGIS. Saat ini, penting agar file dalam direktori PGIS diberi nama mengikuti pola item_flavor.mcg . Item mewakili aplikasi target. Lebih lanjut tentang istilah rasa dan item di bagian selanjutnya.
# Assuming $PIRA holds the top-level PIRA directory
$> cp my-app.mcg $PIRA/extern/install/pgis/bin/item_flavor.mcg
Konfigurasi PIRA berisi semua informasi yang diperlukan PIRA untuk menjalankan proses otomatis. Berbagai direktori yang perlu ditentukan dalam file konfigurasi dapat berupa jalur absolut , atau jalur, yang relatif terhadap jalur eksekusi pira . Jalur mungkin berisi variabel lingkungan, misalnya $HOME . Contoh diambil dari contoh GameOfLife di ./test/integration/GameOfLife .
Pengguna menentukan: direktori untuk mencari item yang ditentukan selanjutnya, dalam contoh, direktorinya adalah ./gol/serial_non_template . Direktori ini diberi alias, yang direferensikan menggunakan tanda '%'. Item di PIRA adalah aplikasi target, dibangun dengan cara tertentu, yang menjadi alasannya dikelompokkan dalam konfigurasi di bawah builds .
{
"builds": {
"%gol": {
"items": {
"gol": {
...
}
}
}
}
"directories": {
"gol": "./gol/serial_non_template"
}
}
Setiap item menentukan penganalisis mana yang harus digunakan. Penganalisis default dikirimkan bersama PIRA, dan sumbernya dapat ditemukan di ./extern/src/metacg/pgis atau instalasi di ./extern/install/pgis/bin . Penganalisis bertanggung jawab untuk mengarahkan penyempurnaan instrumentasi, dan oleh karena itu, merupakan bagian penting dari kerangka PIRA.
Bidang argmap menentukan argumen berbeda yang diteruskan ke aplikasi target saat menjalankan eksperimen kinerja. Bagaimana argumen diteruskan ke aplikasi target ditentukan oleh pembuat peta yang berbeda. Dalam contoh ini, mapper linier digunakan, yang hanya mengulangi nilai parameter bernama size sesuai urutan yang diberikan dalam daftar.
"argmap": {
"mapper": "Linear",
"size": [50, 80, 110, 150, 300, 500]
}
Bidang kubus adalah lokasi dimana PIRA harus menyimpan profil Score-P yang diperoleh. Ini akan membuat pohon direktori di lokasi tersebut, sehingga pengguna dapat, setelah PIRA selesai, juga dengan mudah memanggil alat pemodelan Extra-P hanya dengan meneruskannya ke lokasi masing-masing, misalnya /tmp/pira pada contoh.
"cubes": "/tmp/pira"
Bidang ragam menambahkan tingkat kemungkinan pembedaan lainnya, karena aplikasi target dapat dibuat dalam ragam yang berbeda. Contohnya adalah menentukan perpustakaan matematika berbeda yang harus ditautkan oleh aplikasi target.
Terakhir, direktori functors mengarahkan PIRA ke lokasi di mana ia mencari fungsi Python yang disediakan pengguna yang pada akhirnya memberi tahu PIRA cara membangun, menjalankan, dan menganalisis aplikasi target. Dalam contoh ini, PIRA diarahkan ke direktori yang disebut functors relatif terhadap lokasi konfigurasi.
"flavors": [
"ct"
],
"functors": "./functors",
"mode": "CT"
Bidang mode , dalam versi PIRA ini, diabaikan.
Saat ini, pengguna perlu mengimplementasikan lima fungsi berbeda:
analyze_<ITEM>_<FLAVOR>.py : memanggil penganalisis.clean_<ITEM>_<FLAVOR>.py : membersihkan direktori build.<ITEM>_<FLAVOR>.py : membuat versi berinstrumen.no_instr_<ITEM>_<FLAVOR>.py : membuat versi vanilla.runner_<ITEM>_<FLAVOR>.py : menjalankan aplikasi target. Fungsi, secara umum, mendukung dua mode pemanggilan: aktif dan pasif . Fungsi tersebut memberi tahu PIRA mode mana yang digunakannya dengan menyetel nilai masing-masing ke True dalam kamus yang dikembalikan oleh fungsi get_method() .
Dalam mode aktif, fungsi itu sendiri menjalankan perintah yang diperlukan, misalnya, untuk membangun perangkat lunak. Ketika dipanggil, functor diteruskan dengan parameter **kwargs yang berisi, misalnya, direktori saat ini dan sebuah instance dari shell subproses.
Mode pasif hanya mengembalikan perintah yang akan dieksekusi, misalnya string make untuk memanggil Makefile sederhana pada direktori tingkat atas item. Ini juga meneruskan parameter kwargs yang menyimpan informasi spesifik, seperti nilai yang telah ditentukan sebelumnya yang diperlukan untuk ditambahkan ke CXXFLAGS atau flag linker tambahan. Contoh fungsi pasif dapat ditemukan di examples dan direktori test . Saat ini, semua fungsi yang diimplementasikan menggunakan mode pasif.
PIRA meneruskan argumen kata kunci berikut ke semua fungsi. Selain itu, komponen PIRA yang berbeda mungkin memberikan argumen tambahan.
Penting : Kami sekarang mengirimkan versi Score-P kami sendiri. Dengan demikian, tidak diperlukan lagi penyesuaian perintah kompilasi di PIRA. Lihat fungsi di test/integration/AMG2013 misalnya penggunaan informasi yang berbeda.
Saat ini, tidak ada informasi yang diteruskan ke semua fungsi
[0] mengakses argumen pertama, [1] argumen kedua, dan seterusnya..so yang mengimplementasikan fungsi pembungkus MPI (penting untuk pemfilteran MPI). Parameter tambahan diperlukan untuk beberapa mode analisis. Secara khusus, PIRA LIDe (lihat di bawah) dan analisis pemodelan Extra-P memerlukan parameter yang disediakan pengguna. Buat file JSON dan berikan jalurnya ke PIRA menggunakan --analysis-parameters -switch. Contoh berikut berisi parameter untuk mode pemodelan Extra-P. Strategi yang tersedia untuk menggabungkan beberapa model Extra-P (saat suatu fungsi dipanggil dalam konteks berbeda) adalah: FirstModel , Sum , Average , Maximum .
{
"Modeling": {
"extrapolationThreshold": 2.1,
"statementThreshold": 200,
"modelAggregationStrategy": "Sum"
}
}
Untuk detail lebih lanjut tentang fitur deteksi ketidakseimbangan beban, silakan merujuk ke [PI21]. Berikan pemanggilan PIRA jalur ke file konfigurasi menggunakan --load-imbalance-detection -parameter. File JSON ini harus memiliki struktur berikut:
{
"metricType": "ImbalancePercentage",
"imbalanceThreshold": 0.05,
"relevanceThreshold": 0.05,
"contextStrategy": "None",
"contextStepCount": 5,
"childRelevanceStrategy": "RelativeToMain",
"childConstantThreshold": 1,
"childFraction": 0.001
}
Untuk menjalankan PIRA pada klaster dengan manajer beban kerja SLURM, aktifkan dengan flag --slurm-config . Berikan jalur ke file konfigurasi sistem batch Anda dengannya. Lihat tes integrasi yang diakhiri dengan _Slurm ( test/integration/*_Slurm/ ). PIRA saat ini mendukung sistem batch dengan manajer beban kerja SLURM. PIRA mendukung penggunaan sistem module , yang dapat ditemukan di cluster slurm.
File konfigurasi sistem batch adalah file JSON, yang disusun sebagai berikut:
{
"general": {
"backend": "slurm",
"interface": "pyslurm",
"timings": "subprocess"
},
"module-loads": [
{
"name": "gcc",
"version": "8.5"
},
{
"name": "llvm",
"version": "10.0.0",
"depends-on": [
{
"name": "gcc",
"version": "8.5"
}
]
}
],
"batch-settings": {
"time_str": "00:10:00",
"mem_per_cpu": 3800,
"number_of_tasks": 1,
"partition": null,
"reservation": null,
"account": "your_account_here",
"cpus_per_task": 96
}
}
Perincian:
general : Memungkinkan Anda memilih cara PIRA akan mengeksekusi kode Anda pada sistem batch. Karena setiap opsi di bagian ini bersifat opsional, Anda dapat menghilangkan seluruh bagian, jika Anda tidak keberatan menggunakan opsi default:backend : Manajer beban kerja apa yang akan digunakan. Pilihan: slurm , untuk manajer beban kerja slurm. Default: slurm , oleh karena itu opsional.interface : Dengan cara apa PIRA harus berinteraksi dengan manajer sistem batch Anda. Untuk backend SLURM, ini adalah: pyslurm , untuk menggunakan PySlurm (ini memerlukan instalasi PySlurm, lihat bagian ini; sbatch-wait , untuk menggunakan sbatch standar dengan flag --wait ; os , untuk panggilan interaksi sbatch dan squeue standar. Default: pyslurm , oleh karena itu opsional.timings : Bagaimana pengaturan waktu kode target harus dilakukan. Pilihan: subprocess , untuk pengaturan waktu dengan pembungkus python dan os.times dalam subproses (persis seperti yang dilakukan PIRA jika dijalankan secara lokal); os , untuk menggunakan /usr/bin/time . Default: subprocess , oleh karena itu opsional.force-sequential : Default false . Setel ke true untuk memaksa PIRA/sistem batch Anda melakukan semua proses secara berurutan (hanya satu eksekusi kode target dalam satu waktu). Ini berarti PIRA akan menjaga agar sistem batch Anda menjalankan pengulangan, serta tugas berbeda dalam menskalakan eksperimen secara berurutan. Jika disetel ke/kiri pada false PIRA akan mencoba menginstruksikan sistem batch untuk melakukan eksekusi sebanyak mungkin dalam setiap iterasi secara paralel.module-loads : Saat ini tidak digunakan di PIRA, pekerjaan sedang berlangsung! Saat ini, Anda perlu memuat semua modul secara manual, sebelum memulai PIRA! Dimaksudkan untuk modul mana yang harus dimuat dengan sistem module . Ini memerlukan satu yang ada (perintah module load dan module purge dapat digunakan oleh PIRA). Jika Anda tidak memiliki sistem module , atau tidak ingin menggunakannya, hilangkan bagian ini sepenuhnya, atau setel "module-loads": null . Untuk menentukan modul yang harus dimuat PIRA, tentukan daftar modul, seperti pada contoh di atas.name .version ini opsional, jika tidak diberikan, itu akan bergantung pada apa yang dimuat sistem module sebagai versi modul default. Disarankan untuk selalu memberikan versi secara eksplisit.depends-on juga opsional. Berikan daftar modul yang menjadi sandaran modul ini. Modul-modul ini harus memiliki name dan dapat diberi version opsional. Ketergantungan yang ditentukan di sini digunakan oleh PIRA untuk menentukan urutan modul yang harus dimuatnull , diasumsikan modul ini tidak memiliki ketergantungan.depends-on apa pun, PIRA akan (mencoba) memuat modul persis dengan urutan yang diberikan dalam file konfigurasi.batch-setting : Perangkat keras aktual dan opsi pekerjaan untuk sistem batch. Beberapa opsi di bagian ini bersifat wajib, Anda tidak dapat mengabaikan bagian ini.time : Opsi sbatch --time , wajib.mem-per-cpu : Opsi sbatch --mem-per-cpu , wajib.ntasks : Opsi sbatch --ntasks , wajib.partition , reservation , account (semua default ke null =tidak diberikan), cpus-per-task (default ke 4 ), exclusive (default ke true ; tidak didukung dengan pyslurm ), dan cpu-freq (defaultnya adalah null ).sbatch yang tidak dapat Anda tentukan dalam konfigurasi ini. Hal ini disebabkan oleh beberapa opsi yang digunakan oleh PIRA secara internal, misalnya opsi --array , untuk memetakan pengulangan ke array pekerjaan. Bagaimana dan versi PySlurm mana yang akan diinstal pada cluster Anda, sangat bergantung pada versi SLURM Anda, dan instalasi SLURM Anda. Solusi pemasangan dan pengemasan untuk pyslurm dengan PIRA sedang dalam proses. Lihat README mereka. Anda dapat mencoba beberapa hal berikut:
include dan lib .python3 setup.py build --slurm-lib=/opt/slurm/21.08.6/lib --slurm-inc=/opt/slurm/21.08.6/includepython3 setup.py install --slurm-lib=/opt/slurm/21.08.6/lib --slurm-inc=/opt/slurm/21.08.6/include .
