Suporta para sa multi-process at multi-threaded na akselerasyon

Inilalarawan ng pahinang ito kung hanggang saan sinusuportahan ng qiskit-addon-sqd ang multi-threaded at multi-process na akselerasyon, at ang mga pagpapalagay na maaaring asahan ng isang high-performance-computing (HPC) developer kapag isinasama ang package na ito sa isang pinabilis na workload.

Ang pagpapalagay na single-threaded

Maliban kung iba ang tinukoy, ang mga API sa package na ito ay nilalayong tawagin mula sa iisang thread. Ang mga high-level na API na inilalantad ng package na ito ay hindi garantisadong re-entrant, at hindi dapat tawagin ng mga end user ang mga ito mula sa anumang thread maliban sa main thread.

Collective na multi-process na pagpapatupad

Sinusuportahan ng package na ito ang collective na multi-process na akselerasyon sa istilong single-program, multiple-data (SPMD), kung saan ang buong programa ay inilulunsad bilang maraming hiwalay na process na tumatakbo na may tahasang global na synchronization at komunikasyon sa pagitan nila (halimbawa, mpirun -n 128 python my_program.py). Dahil maayos na nakakasama ang istilong SPMD sa mga job scheduler at iba pang parallel na software at nakakapag-scale sa malaking bilang ng process, ito ang inirerekomendang modelo para sa mga high-performance at malakihang workload, at ito ang paksa ng pahinang ito.

Bagaman idinisenyo ang package na ito para tumanggap ng iba't ibang collective-execution backend, ang kasalukuyang implementasyon nito ay nakatuon sa MPI, ang standard na message-passing API para sa mga HPC system. Anuman ang implementasyon, ipinapalagay ng package na ito na iisang thread ang kumokontrol sa bawat process. Sa kaso ng MPI, tumutugma ito sa MPI_THREAD_FUNNELED o mas mababa.

Kung sinusuportahan ng isang function ang collective execution, dapat itong sabihin ng dokumentasyon nito. Kung hindi binabanggit ng dokumentasyon ang collective execution, walang collective semantics ang function at dapat itong tawagin mula sa control process lamang.

Ang mga partikular na semantics ng return value at synchronization ng isang collective function ay nakadokumento kasama ng function mismo. Sa pangkalahatan, dapat gawing malinaw ng dokumentasyong iyon ang:

• Kung ang function ay nilalayong tawagin nang hiwalay ng bawat process sa sarili nitong lokal na data, o collective ng lahat ng process.

• Kung paano dapat magkasundo ang mga argumento nito sa lahat ng process.

• Kung paano inihahatid ang return value nito—kung ang resulta ay umiiral lamang sa control process, kung tumatanggap ang lahat ng process ng parehong halaga, o kung tumatanggap ang bawat process ng handle sa isang lokal na bahagi ng isang distributed na data structure.

Isang function lamang ang kasalukuyang sumusuporta sa pagtawag nang collective mula sa lahat ng process: diagonalize_fermionic_hamiltonian(). Kapag tinawag ito nang collective, ang hakbang ng eigensolver ang kung saan lumalahok at nag-aambag ng trabaho ang lahat ng process, kaya magagamit ng isang implementasyon ng eigensolver ang bawat process. Ang natitirang bahagi ng configuration-recovery loop ay walang distributed na implementasyon at tumatakbo lamang sa control process (rank 0).

Ang bawat subspace ng isang iteration ay ipinapasa sa eigensolver sa iisang tawag, kaya malaya ang isang implementasyon na hatiin ang mga process sa mga grupo at i-diagonalize nang magkakasabay ang ilang subspace. Ang paraan ng paggamit ng isang solver sa mga process na magagamit nito ay katangian ng eigensolver na iyon.

Ang ilang umiiral na implementasyon ng eigensolver ay nangangailangang tumakbo ang tumatawag na programa sa labas ng isang MPI/SPMD na environment, dahil sila mismo ang naglulunsad at namamahala ng sarili nilang mga parallel na process sa loob, halimbawa sa pamamagitan ng pagtawag sa mpirun para sa user. Maginhawa ang mode na iyon para sa interactive at notebook-based na trabaho at nananatiling suportado; ang mga kinakailangan nito sa tumatawag na programa ay inilalarawan sa API reference ng function na diagonalize_fermionic_hamiltonian().

Paghawak ng error sa multi-process na konteksto

Ang isang function na tinatawag nang collective mula sa lahat ng process ay hindi dapat mag-raise ng exception o mag-abort ng iisang process lamang, dahil iiwan nitong deadlocked o nasa hindi pare-parehong estado ang natitirang mga process. Sa halip, sumusunod ang paghawak ng error sa fail-stop semantics para sa buong execution context: kapag may error, dapat handa ang implementasyon na i-abort nang collective ang buong execution context (halimbawa, sa pamamagitan ng paggamit ng MPI_Abort).

Hindi magagarantiya ng API ang koordinadong pag-uulat ng error o collective na paghahatid ng mga exception sa mga process, dahil hindi nagbibigay ng ganoong garantiya ang mga implementasyon ng MPI. Maaaring subukan din ng isang implementasyon na gawing nakikita ang isang error sa lahat ng kalahok na process—halimbawa, sa pamamagitan ng pagpapa-raise ng exception sa bawat process—ngunit best-effort lamang ito at hindi dapat asahan para sa kawastuhan o recovery.

Ito ay mga katangiang pinapayagang taglayin ng isang collective na implementasyon, hindi mga garantiya tungkol sa alinmang partikular. Sa package na ito, ang tanging collective na hakbang ay ang eigensolver (tingnan ang naunang seksyon); hindi distributed ang default na implementasyon nito, kaya ang mga konsiderasyong ito ay nalalapat sa isang custom, collective na eigensolver na ibinibigay ng user.