Podpora vícenásobných procesů a vícevláknového zrychlení
Tato stránka dokumentuje, do jaké míry qiskit-addon-sqd podporuje vícevláknové a vícenásobné procesní zrychlení a jaké předpoklady může vývojář pro vysoce výkonné počítání (HPC) použít při integraci tohoto balíčku do zrychlené úlohy.
Předpoklad jednoho vlákna
Pokud není uvedeno jinak, API v tomto balíčku jsou určena k volání z jednoho vlákna. U vysokoúrovňových API vystavených tímto balíčkem není zaručeno, že jsou reentrantní, a koncoví uživatelé by je neměli volat z žádného jiného vlákna než hlavního.
Kolektivní vícenásobné procesní spouštění
Tento balíček podporuje kolektivní vícenásobné procesní zrychlení ve stylu single-program, multiple-data (SPMD), při kterém se celý program spouští jako několik izolovaných procesů s explicitní globální synchronizací a komunikací mezi nimi (například mpirun -n 128 python my_program.py). Protože se styl SPMD čistě skládá s plánovači úloh a jiným paralelním softwarem a škáluje na velké počty procesů, je to doporučený model pro vysoce výkonné a rozsáhlé úlohy a je předmětem této stránky.
Ačkoli je tento balíček navržen tak, aby podporoval různé backendy kolektivního spouštění, jeho současná implementace cílí na MPI, standardní API pro předávání zpráv v HPC systémech. Bez ohledu na implementaci tento balíček předpokládá, že každý proces řídí jediné vlákno. V případě MPI to odpovídá MPI_THREAD_FUNNELED nebo nižšímu.
Pokud funkce podporuje kolektivní spouštění, musí to její dokumentace uvádět. Pokud dokumentace kolektivní spouštění nezmiňuje, funkce nemá kolektivní sémantiku a musí se volat pouze z řídicího procesu.
Konkrétní sémantika návratové hodnoty a synchronizace kolektivní funkce je zdokumentována u samotné funkce. Dokumentace by obecně měla objasnit:
-
Zda je funkce určena k volání nezávisle každým procesem nad jeho vlastními lokálními daty, nebo kolektivně všemi procesy.
-
Jak se musí její argumenty shodovat napříč procesy.
-
Jak je doručena její návratová hodnota – zda výsledek existuje pouze v řídicím procesu, zda všechny procesy dostanou stejnou hodnotu, nebo zda každý proces dostane odkaz na lokální část distribuované datové struktury.
V současnosti podporuje kolektivní volání ze všech procesů pouze jedna funkce: diagonalize_fermionic_hamiltonian(). Při kolektivním volání je krok řešiče vlastních stavů místem, kde se všechny procesy účastní a přispívají prací, takže implementace řešiče vlastních stavů může využít každý proces. Zbývající části smyčky obnovy konfigurací nemají distribuovanou implementaci a běží pouze na řídicím procesu (rank 0).
Každý podprostor jedné iterace je předán řešiči vlastních stavů jedním voláním, takže implementace může procesy rozdělit do skupin a diagonalizovat několik podprostorů paralelně. Jak řešič využije dostupné procesy, je vlastností daného řešiče vlastních stavů.
Některé existující implementace řešiče vlastních stavů vyžadují, aby volající program běžel mimo prostředí MPI/SPMD, protože si vlastní paralelní procesy spouštějí a spravují interně, například voláním mpirun jménem uživatele. Tento režim je pohodlný pro interaktivní práci a práci v noteboocích a zůstává podporován; jeho požadavky na volající program jsou popsány v referenci API funkce diagonalize_fermionic_hamiltonian().
Zpracování chyb ve vícenásobném procesním kontextu
Funkce, která je volána kolektivně ze všech procesů, nesmí vyvolat výjimku ani ukončit pouze jeden proces, protože by to ponechalo zbývající procesy v deadlocku nebo nekonzistentním stavu. Zpracování chyb místo toho sleduje sémantiku fail-stop pro celý spouštěcí kontext: při chybě musí být implementace připravena kolektivně ukončit celý spouštěcí kontext (například pomocí MPI_Abort).
API nemůže zaručit koordinované hlášení chyb ani kolektivní doručení výjimek napříč procesy, protože implementace MPI takové záruky neposkytují. Implementace se může navíc pokusit zviditelnit chybu všem zúčastněným procesům – například tak, že každý proces vyvolá výjimku – ale to lze zajistit jen na základě nejlepší snahy a nelze se na to spoléhat z hlediska správnosti ani zotavení.
Jsou to vlastnosti, které kolektivní implementace mít smí, nikoli záruky pro nějakou konkrétní implementaci. V tomto balíčku je jediným kolektivním krokem řešič vlastních stavů (viz předchozí část); jeho výchozí implementace není distribuovaná, takže tyto úvahy platí pro vlastní kolektivní řešič vlastních stavů dodaný uživatelem.