Suport pentru accelerare multi-proces și multi-fir

Această pagină documentează în ce măsură qiskit-addon-sqd acceptă accelerarea multi-fir și multi-proces, precum și ipotezele pe care se poate baza un dezvoltator de calcul de înaltă performanță (HPC) când integrează acest pachet într-o sarcină de lucru accelerată.

Ipoteza firului unic

Dacă nu se specifică altfel, API-urile din acest pachet sunt destinate să fie apelate dintr-un singur fir. API-urile de nivel înalt expuse de acest pachet nu sunt garantate a fi reentrante, iar utilizatorii finali nu ar trebui să le apeleze din alt fir decât cel principal.

Execuție colectivă multi-proces

Acest pachet acceptă accelerarea colectivă multi-proces în stilul program unic, date multiple (SPMD), în care întregul program este lansat ca mai multe procese izolate, care rulează cu sincronizare globală explicită și comunicare între ele (de exemplu, mpirun -n 128 python my_program.py). Deoarece stilul SPMD se compune curat cu planificatoarele de sarcini și cu alte programe paralele și scalează la un număr mare de procese, este modelul recomandat pentru sarcinile de lucru de înaltă performanță și de scară largă, și este subiectul acestei pagini.

Deși acest pachet este conceput să accepte diferite backend-uri de execuție colectivă, implementarea sa actuală vizează MPI, API-ul standard de transmitere a mesajelor pentru sistemele HPC. Indiferent de implementare, acest pachet presupune că un singur fir controlează fiecare proces. În cazul MPI, aceasta corespunde cu MPI_THREAD_FUNNELED sau mai puțin.

Dacă o funcție acceptă execuția colectivă, documentația ei trebuie să o spună. Dacă documentația nu menționează execuția colectivă, funcția nu are semantică colectivă și trebuie apelată doar din procesul de control.

Semantica specifică a valorii returnate și a sincronizării unei funcții colective este documentată împreună cu funcția. În general, acea documentație ar trebui să precizeze clar:

• Dacă funcția este destinată să fie apelată independent de fiecare proces pe propriile date locale sau colectiv de toate procesele.

• Cum trebuie să coincidă argumentele ei între procese.

• Cum este livrată valoarea returnată — dacă rezultatul există doar pe procesul de control, dacă toate procesele primesc aceeași valoare sau dacă fiecare proces primește un handle către o porțiune locală a unei structuri de date distribuite.

În prezent, doar o singură funcție acceptă să fie apelată colectiv de la toate procesele: diagonalize_fermionic_hamiltonian(). Când este invocată colectiv, pasul de rezolvare a stărilor proprii este cel în care toate procesele participă și contribuie cu muncă, astfel încât o implementare de solver de stări proprii poate folosi fiecare proces. Celelalte părți ale buclei de recuperare a configurațiilor nu au o implementare distribuită și rulează doar pe procesul de control (rangul 0).

Fiecare subspațiu al unei iterații este transmis solverului de stări proprii într-un singur apel, deci o implementare este liberă să împartă procesele în grupuri și să diagonalizeze mai multe subspații în paralel. Modul în care un solver folosește procesele disponibile este o proprietate a acelui solver de stări proprii.

Unele implementări existente de solvere de stări proprii cer ca programul apelant să ruleze în afara unui mediu MPI/SPMD, deoarece își lansează și își gestionează intern propriile procese paralele, de exemplu invocând mpirun în numele utilizatorului. Acest mod este convenabil pentru lucrul interactiv și bazat pe notebook-uri și rămâne acceptat; cerințele lui față de programul apelant sunt descrise în referința API a funcției diagonalize_fermionic_hamiltonian().

Gestionarea erorilor într-un context multi-proces

O funcție apelată colectiv de la toate procesele nu trebuie să genereze o excepție sau să oprească un singur proces, deoarece aceasta ar lăsa procesele rămase în blocaj sau într-o stare inconsistentă. În schimb, gestionarea erorilor urmează semantica fail-stop pentru contextul de execuție în ansamblu: în caz de eroare, implementarea trebuie să fie pregătită să oprească colectiv întregul context de execuție (de exemplu, folosind MPI_Abort).

API-ul nu poate garanta raportarea coordonată a erorilor sau livrarea colectivă a excepțiilor între procese, deoarece implementările MPI nu oferă astfel de garanții. O implementare ar putea încerca în plus să facă o eroare vizibilă tuturor proceselor participante — de exemplu, prin generarea unei excepții de către fiecare proces — dar aceasta poate fi oferită doar în regim best-effort și nu trebuie să se conteze pe ea pentru corectitudine sau recuperare.

Acestea sunt proprietăți pe care o implementare colectivă are voie să le aibă, nu garanții despre vreuna anume. În acest pachet, singurul pas colectiv este solverul de stări proprii (vezi secțiunea anterioară); implementarea lui implicită nu este distribuită, deci aceste considerații se aplică unui solver de stări proprii colectiv personalizat, furnizat de utilizator.