Dukungan akselerasi multi-proses dan multi-thread

Halaman ini menjelaskan sejauh mana qiskit-addon-sqd mendukung akselerasi multi-thread dan multi-proses, serta asumsi yang bisa dipegang developer high-performance-computing (HPC) saat mengintegrasikan paket ini ke dalam beban kerja yang diakselerasi.

Asumsi single-thread

Kecuali ditentukan lain, API di paket ini dimaksudkan untuk dipanggil dari satu thread. API tingkat tinggi yang disediakan paket ini tidak dijamin re-entrant, dan pengguna akhir sebaiknya tidak memanggilnya dari thread selain thread utama.

Eksekusi multi-proses kolektif

Paket ini mendukung akselerasi multi-proses kolektif dengan gaya single-program, multiple-data (SPMD), di mana seluruh program dijalankan sebagai beberapa proses terisolasi yang berjalan dengan sinkronisasi global dan komunikasi eksplisit di antara mereka (misalnya, mpirun -n 128 python my_program.py). Karena gaya SPMD berpadu dengan baik dengan job scheduler dan perangkat lunak paralel lainnya serta skalanya bagus untuk jumlah proses yang besar, gaya ini adalah model yang direkomendasikan untuk beban kerja berkinerja tinggi dan berskala besar, dan itulah yang dibahas di halaman ini.

Meskipun paket ini dirancang untuk mengakomodasi berbagai backend eksekusi kolektif, implementasinya saat ini menargetkan MPI, API message-passing standar untuk sistem HPC. Terlepas dari implementasinya, paket ini mengasumsikan bahwa satu thread mengendalikan setiap proses. Pada MPI, ini sesuai dengan MPI_THREAD_FUNNELED atau yang lebih rendah.

Jika sebuah fungsi mendukung eksekusi kolektif, dokumentasinya harus menyebutkannya. Jika dokumentasinya tidak menyebut eksekusi kolektif, fungsi tersebut tidak punya semantik kolektif dan harus dipanggil hanya dari proses kontrol.

Semantik nilai kembalian dan sinkronisasi spesifik dari sebuah fungsi kolektif didokumentasikan bersama fungsinya. Secara umum, dokumentasi itu sebaiknya menjelaskan dengan jelas:

• Apakah fungsi itu dimaksudkan untuk dipanggil secara independen oleh setiap proses pada data lokalnya sendiri, atau secara kolektif oleh semua proses.

• Bagaimana argumennya harus sesuai antar proses.

• Bagaimana nilai kembaliannya disampaikan—apakah hasilnya hanya ada di proses kontrol, apakah semua proses menerima nilai yang sama, atau apakah setiap proses menerima handle ke bagian lokal dari struktur data terdistribusi.

Saat ini hanya satu fungsi yang mendukung pemanggilan secara kolektif dari semua proses: diagonalize_fermionic_hamiltonian(). Saat dipanggil secara kolektif, langkah eigensolver adalah tempat semua proses berpartisipasi dan menyumbang kerja, sehingga implementasi eigensolver bisa memakai setiap proses. Bagian lain dari loop pemulihan konfigurasi tidak punya implementasi terdistribusi dan hanya berjalan di proses kontrol (rank 0).

Setiap subruang dari satu iterasi diteruskan ke eigensolver dalam satu panggilan, jadi sebuah implementasi bebas membagi proses ke dalam grup dan mendiagonalisasi beberapa subruang secara paralel. Bagaimana sebuah solver memakai proses yang tersedia adalah properti dari eigensolver tersebut.

Beberapa implementasi eigensolver yang ada mengharuskan program pemanggil berjalan di luar lingkungan MPI/SPMD, karena mereka meluncurkan dan mengelola proses paralelnya sendiri secara internal, misalnya dengan memanggil mpirun atas nama pengguna. Mode itu praktis untuk pekerjaan interaktif dan berbasis notebook dan tetap didukung; persyaratannya pada program pemanggil dijelaskan di referensi API fungsi diagonalize_fermionic_hamiltonian().

Penanganan error dalam konteks multi-proses

Fungsi yang dipanggil secara kolektif dari semua proses tidak boleh memunculkan exception atau meng-abort hanya satu proses, karena itu akan membuat proses lainnya deadlock atau berada dalam keadaan tidak konsisten. Sebagai gantinya, penanganan error mengikuti semantik fail-stop untuk konteks eksekusi secara keseluruhan: saat terjadi error, implementasi harus siap meng-abort seluruh konteks eksekusi secara kolektif (misalnya, dengan memakai MPI_Abort).

API tidak bisa menjamin pelaporan error yang terkoordinasi atau pengiriman exception secara kolektif ke semua proses, karena implementasi MPI tidak menyediakan jaminan seperti itu. Sebuah implementasi mungkin juga berusaha membuat error terlihat oleh semua proses yang berpartisipasi—misalnya, dengan meminta setiap proses memunculkan exception—tapi ini hanya bisa disediakan dengan upaya terbaik (best-effort) dan tidak boleh diandalkan untuk kebenaran atau pemulihan.

Ini adalah properti yang boleh dimiliki oleh implementasi kolektif, bukan jaminan untuk implementasi tertentu. Di paket ini, satu-satunya langkah kolektif adalah eigensolver (lihat bagian sebelumnya); implementasi defaultnya tidak terdistribusi, jadi pertimbangan ini berlaku untuk eigensolver kolektif kustom yang disediakan pengguna.