Supporto per l'accelerazione multiprocesso e multithread

Questa pagina illustra in che misura il pacchetto qiskit-addon-sqd supporti l'accelerazione multithread e multiprocesso, nonché i presupposti su cui uno sviluppatore nel campo del calcolo ad alte prestazioni (HPC) può fare affidamento quando integra questo pacchetto in un carico di lavoro accelerato.

L'ipotesi del single-threaded

Salvo diversa indicazione, le API contenute in questo pacchetto sono pensate per essere chiamate da un unico thread. Non è garantito che le API di alto livello fornite da questo pacchetto siano rientranti, pertanto gli utenti finali non dovrebbero richiamarle da thread diversi dal thread principale.

Esecuzione collettiva di più processi

Questo pacchetto supporta l'accelerazione collettiva multiprocesso secondo lo stile "single-program, multiple-data" (SPMD), in cui l'intero programma viene avviato come una serie di processi isolati che operano con sincronizzazione globale esplicita e comunicazione tra loro (ad esempio, mpirun -n 128 python my_program.py). Poiché lo stile SPMD si integra perfettamente con gli scheduler di job e altri software paralleli ed è scalabile fino a un numero elevato di processi, rappresenta il modello consigliato per carichi di lavoro ad alte prestazioni e su larga scala, ed è proprio l'argomento trattato in questa pagina.

Sebbene questo pacchetto sia progettato per supportare diversi backend di esecuzione collettiva, la sua attuale implementazione è pensata per MPI, l’API standard per il passaggio di messaggi nei sistemi HPC. Indipendentemente dall'implementazione, questo pacchetto presuppone che ogni processo sia controllato da un unico thread. Nel caso dell'MPI, ciò corrisponde a MPI_THREAD_FUNNELED o un valore inferiore.

Se una funzione supporta l'esecuzione collettiva, la relativa documentazione deve indicarlo. Se la documentazione non fa riferimento all'esecuzione collettiva, la funzione non presenta una semantica collettiva e deve essere chiamata esclusivamente dal processo di controllo.

Il valore di ritorno specifico e la semantica di sincronizzazione di una funzione collettiva sono documentati insieme alla funzione stessa. In generale, tale documentazione dovrebbe chiarire:

• Se la funzione debba essere chiamata in modo indipendente da ciascun processo sui propri dati locali, oppure collettivamente da tutti i processi.
• In che modo i suoi argomenti devono essere coerenti tra i vari processi.
• Come viene fornito il valore di ritorno: se il risultato esiste solo nel processo di controllo, se tutti i processi ricevono lo stesso valore oppure se ciascun processo riceve un handle a una porzione locale di una struttura dati distribuita.

Attualmente solo una funzione supporta la chiamata collettiva da tutti i processi: diagonalize_fermionic_hamiltonian(). Quando viene richiamato in modo collettivo, la fase di risoluzione degli autovalori è quella in cui tutti i processi partecipano e contribuiscono al lavoro, pertanto un’implementazione del risolutore degli autovalori può avvalersi di ogni singolo processo. Le restanti parti del ciclo di configurazione-ripristino non hanno un'implementazione distribuita e vengono eseguite esclusivamente sul processo di controllo (rango 0).

Alcune implementazioni esistenti di eigensolver richiedono invece che il programma chiamante venga eseguito al di fuori di un ambiente MPI/SPMD, poiché avviano e gestiscono internamente i propri processi paralleli, ad esempio richiamando mpirun per conto dell’utente. Tale modalità è utile per il lavoro interattivo e basato su notebook e continua a essere supportata; i requisiti relativi al programma chiamante sono descritti nella documentazione di riferimento dell'API della funzione diagonalize_fermionic_hamiltonian() .

Gestione degli errori in un contesto multiprocesso

Una funzione chiamata collettivamente da tutti i processi non deve generare un'eccezione né interrompere un solo processo, poiché ciò lascerebbe i processi rimanenti in una situazione di deadlock o in uno stato incoerente. La gestione degli errori segue invece la semantica "fail-stop" per il contesto di esecuzione nel suo complesso: in caso di errore, l'implementazione deve essere pronta a interrompere l'intero contesto di esecuzione in modo collettivo (ad esempio, utilizzando MPI_Abort).

L'API non può garantire una segnalazione coordinata degli errori né una gestione collettiva delle eccezioni tra i vari processi, poiché le implementazioni MPI non forniscono tali garanzie. Un'implementazione potrebbe inoltre cercare di rendere visibile un errore a tutti i processi coinvolti — ad esempio, facendo sì che ciascun processo generi un'eccezione — ma ciò può essere garantito solo "nel limite del possibile" e non deve essere considerato un elemento su cui fare affidamento ai fini della correttezza o del ripristino.

Si tratta di caratteristiche che un'implementazione collettiva può avere, non di garanzie relative a una caratteristica specifica. In questo pacchetto, l'unico passaggio collettivo è il risolutore degli autovalori (vedi la sezione precedente); la sua implementazione predefinita non è distribuita, pertanto queste considerazioni si applicano a un risolutore degli autovalori collettivo personalizzato fornito dall'utente.