Compatibilidad con aceleración multiproceso y multihilo

Esta página documenta hasta qué punto qiskit-addon-sqd admite la aceleración multihilo y multiproceso, y las suposiciones en las que puede apoyarse un desarrollador de computación de alto rendimiento (HPC) al integrar este paquete en una carga de trabajo acelerada.

La suposición de un solo hilo

Salvo que se indique lo contrario, las API de este paquete están pensadas para llamarse desde un único hilo. No se garantiza que las API de alto nivel que expone este paquete sean reentrantes, y los usuarios finales no deben invocarlas desde ningún hilo que no sea el hilo principal.

Ejecución multiproceso colectiva

Este paquete admite la aceleración multiproceso colectiva al estilo de un único programa con múltiples datos (SPMD), en el que todo el programa se lanza como varios procesos aislados que se ejecutan con sincronización global y comunicación explícitas entre ellos (por ejemplo, mpirun -n 128 python my_program.py). Dado que el estilo SPMD se integra bien con los planificadores de trabajos y otro software paralelo, y escala a un gran número de procesos, es el modelo recomendado para cargas de trabajo de alto rendimiento y a gran escala, y es el tema de esta página.

Aunque este paquete está diseñado para admitir distintos backends de ejecución colectiva, su implementación actual está orientada a MPI, la API estándar de paso de mensajes para sistemas HPC. Independientemente de la implementación, este paquete asume que un único hilo controla cada proceso. En el caso de MPI, esto corresponde a MPI_THREAD_FUNNELED o inferior.

Si una función admite la ejecución colectiva, su documentación debe indicarlo. Si la documentación no menciona la ejecución colectiva, la función no tiene semántica colectiva y debe llamarse únicamente desde el proceso de control.

La semántica específica de valor de retorno y de sincronización de una función colectiva se documenta junto con la propia función. En general, esa documentación debería dejar claro:

• Si la función está pensada para que cada proceso la llame de forma independiente sobre sus propios datos locales, o de forma colectiva todos los procesos.

• Cómo deben coincidir sus argumentos entre los procesos.

• Cómo se entrega su valor de retorno: si el resultado existe solo en el proceso de control, si todos los procesos reciben el mismo valor, o si cada proceso recibe un identificador de una parte local de una estructura de datos distribuida.

Actualmente, solo una función admite ser llamada de forma colectiva desde todos los procesos: diagonalize_fermionic_hamiltonian(). Cuando se invoca de forma colectiva, el paso del solucionador de valores propios es aquel en el que participan todos los procesos y aportan trabajo, de modo que una implementación del solucionador puede usar todos los procesos. El resto de las partes del bucle de recuperación de configuraciones no tienen una implementación distribuida y se ejecutan solo en el proceso de control (rango 0).

Todos los subespacios de una iteración se pasan al solucionador de valores propios en una sola llamada, por lo que una implementación es libre de dividir los procesos en grupos y diagonalizar varios subespacios en paralelo. La forma en que un solucionador usa los procesos de que dispone es una propiedad de ese solucionador.

Algunas implementaciones existentes de solucionadores de valores propios requieren que el programa que las llama se ejecute fuera de un entorno MPI/SPMD, porque lanzan y gestionan internamente sus propios procesos paralelos, por ejemplo invocando mpirun en nombre del usuario. Ese modo es cómodo para el trabajo interactivo y basado en notebooks y sigue siendo compatible; sus requisitos para el programa que llama se describen en la referencia de la API de la función diagonalize_fermionic_hamiltonian().

Gestión de errores en un contexto multiproceso

Una función a la que se llama de forma colectiva desde todos los procesos no debe lanzar una excepción ni abortar un solo proceso, porque eso dejaría a los demás procesos en un bloqueo mutuo o en un estado inconsistente. En su lugar, la gestión de errores sigue una semántica de parada ante fallos para el contexto de ejecución en su conjunto: ante un error, la implementación debe estar preparada para abortar colectivamente todo el contexto de ejecución (por ejemplo, usando MPI_Abort).

La API no puede garantizar un reporte coordinado de errores ni la entrega colectiva de excepciones entre procesos, porque las implementaciones de MPI no ofrecen tales garantías. Una implementación podría además intentar que un error sea visible para todos los procesos participantes (por ejemplo, haciendo que cada proceso lance una excepción), pero esto solo puede ofrecerse en la medida de lo posible y no debe darse por supuesto para la corrección ni la recuperación.

Estas son propiedades que una implementación colectiva puede tener, no garantías sobre ninguna en particular. En este paquete, el único paso colectivo es el solucionador de valores propios (consulta la sección anterior); su implementación predeterminada no es distribuida, por lo que estas consideraciones se aplican a un solucionador de valores propios colectivo personalizado proporcionado por el usuario.