Hacia escalabilidad extrema en aplicaciones iterativas de tipo stencil

Hacia escalabilidad extrema en aplicaciones iterativas de tipo stencil David D´ıez 1, Sergio Alonso Pascual 2, Arturo Gonzalez-Escribano3 Resumen— Los grandes sistemas de c´omputo prey exaescala necesitan soluciones para desarrollar y ejecutar aplicaciones con enormes capacidades de escalabilidad. Esto implica en un caso general abstraer y fusionar capas de portabilidad entre dispositivos heterog´eneos y/o aceleradores con mecanismos que permitan solapar c´omputo y comunicaci´on de forma muy eficiente. Una clase importante de aplicaciones cient´ıficas con un alto potencial de escalabilidad son las aplicaciones ISL (Iterative Stencil Loop). EPSILOD es una herramienta para simplificar el desarrollo y ejecuci´on de aplicaciones ISL en entornos heterog´eneos distribuidos. En este trabajo se proponen mejoras y extensiones para una nueva versi´on de EPSILOD que ampl´ıan el rango de aplicaciones que se pueden construir y la eficiencia de los mecanismos de implementaci´on y comunicaci´on para conseguir un alto grado de escalabilidad en sistemas de c´omputo de primer nivel. Se presentan resultados experimentales, con hasta 1024 GPUs distribuidas en 256 nodos, que indican que la nueva versi´on de EPSILOD puede conseguir altos niveles de escalabilidad fuerte y d´ebil en diferentes tipos de escenarios y aplicaciones ISL. Se incluye una comparaci´on experimental con otras herramientas del estado del arte que permiten implementar f´acilmente aplicaciones ISL distribuidas: Muesli y Celerity basado en SYCL. Los resultados muestran que EPSILOD permite mejorar sus medidas de rendimiento, especialmente en altos niveles de escalabilidad. Palabras clave— Computaci´on paralela, Aplicaciones stencil, Escalabilidad, Sistemas distribuidos, Sistemas heterog´eneos I. Introducci´ on EN una ´epoca en la que predominan los sistemas pre-exaescala y comienzan a estar disponibles los primeros sistemas exaescala es cada vez m´as necesario aportar soluciones con un alto grado de escalabilidad que sean capaces de aprovechar al m´aximo este tipo de arquitecturas. Estos sistemas presentan normalmente arquitecturas heterog´eneas, que emplean distintos tipos de unidades de c´omputo CPU y GPU, estos ´ultimos utilizados para todo tipo de procesamiento de prop´osito general (GPGPU). Uno de los retos cl´asicos en este contexto de HPC (High Performance Computing) es el desarrollo herramientas y modelos de programaci´on eficientes en entornos altamente paralelos. A su vez, se busca mantener un alto grado de abstracci´on con el objetivo de reducir la complejidad inherente a la programaci´on en estos entornos complejos. Algunas de estas soluciones son m´as gen´ericas, mientras que otras est´an adaptadas a un tipo de problema concreto. 1Dpto. de Inform´atica, Universidad de Valladolid, e-mail: [email protected] 2Dpto. de Inform´atica, Universidad de Valladolid, e-mail: [email protected] 3Dpto. de Inform´atica, Universidad de Valladolid, e-mail: [email protected] Los ISLs o Iterative Stencil Loops son una clase representativa de aplicaciones cient´ıficas con un alto potencial de escalabilidad. En ellos, el valor de los elementos del dominio se obtiene repitiendo el mismo c´alculo sobre cada elemento del dominio en cada iteraci´on. El c´alculo depende de los valores en la iteraci´on anterior de un conjunto de elementos vecinos. El criterio de vecindad lo define cada aplicaci´on concreta, creando un patr´on de acceso fijo (stencil) que introduce dependencias con los datos vecinos. Esta caracter´ıstica implica que paralelizar el c´omputo de stencils requiere comunicaciones de datos entre unidades de proceso que tienen asignados elementos vecinos en el dominio. El dominio se parte normalmente en bloques contiguos de grano grueso para maximizar la localidad y minimizar las comunicaciones. Sus caracter´ısticas de localidad implican que son problemas especialmente adecuados para el uso GPUs en la computaci´on local. Todo esto los convierte en problemas especialmente interesantes de cara a su uso en sistemas HPC. El grupo de investigaci´on Trasgo, ha propuesto EPSILOD [1] como modelo para el desarrollo de aplicaciones ISL. Est´a basado en el concepto de esqueletos paralelos. Abstrae los detalles del reparto de trabajo y los patrones de c´omputo y comunicaci´on para simplificar la implementaci´on de ISLs eficientes en sistemas heterog´eneos distribuidos. EPSILOD se ha convertido en una herramienta muy apropiada para experimentar nuevas t´ecnicas de implementaci´on, despliegue y ejecuci´on de aplicaciones de tipo ISL en sistemas heterog´eneos distribuidos de todo tipo de escala. EPSILOD se apoya en dos bibliotecas de funciones subyacentes que conforman su capa de portabilidad entre dispositivos heterog´eneos (Controller) y de distribuci´on de carga y comunicaciones en sistemas distribuidos (Hitmap). En este trabajo presentamos una serie de cambios de dise˜no y nuevas t´ecnicas introducidas en EPSILOD y en las bibliotecas de funciones subyacentes que permiten: (1) Mejorar su capacidad para implementar nuevos tipos de aplicaciones ISL; (2) Aumentar su flexibilidad para experimentar con diferentes pol´ıticas y mecanismos de partici´on y mapeo; y (3) Mejorar su rendimiento y escalabilidad. En concreto presentamos las siguientes contribuciones: Hemos a˜nadido soporte para tipos gen´ericos de datos. Esto permite trabajar sobre estructuras de datos cuyo elemento base sea una estructura arbitrariamente compleja, lo que abre las puertas a la experimentaci´on con una mayor gama de aplicaciones. Hemos a˜nadido un nuevo sistema para escoger en tiempo de ejecuci´on la pol´ıtica de partici´on del dominio. Este sistema simplifica el proceso de escoger las pol´ıticas e introduce nuevas combinaciones para particionar el dominio de una forma m´as intuitiva. Esto facilita explorar como influyen diferentes pol´ıticas en el rendimiento de las aplicaciones. Hemos optimizado el modelo de comunicaciones para mejorar el solapamiento entre c´omputo y comunicaci´on, lo que mejora la escalabilidad. Hemos simplificado el mecanismo interno de gesti´on de colas basado en eventos, reduciendo el sobrecoste de ejecuci´on del modelo en la capa de portabilidad que maneja los dispositivos heterog´eneos. Estas mejoras son especialmente notables en las pruebas de escalabilidad fuerte, cuando se distribuyen cargas de trabajo de tama˜no fijo entre un gran n´umero de nodos. Hemos realizado un estudio experimental en un supercomputador pre-exaescala para mostrar las nuevas mejoras de EPSILOD y su escalabilidad utilizando dos aplicaciones de ejemplo, una con dominio de dos dimensiones y otro con dominio de tres dimensiones y un tipo de datos m´as complejo. Este estudio contiene comparaciones de rendimiento con dos herramientas actuales del estado del arte que permiten implementar f´acilmente aplicaciones ISL distribuidas: Muesli y Celerity (basado en SYCL). Este estudio incluye pruebas de escalabilidad d´ebil y fuerte. Los resultados experimentales muestran que EPSILOD presenta un alto grado de escalabilidad. En escalabilidad d´ebil EPSILOD presenta degradaciones de rendimiento de hasta menos de 0.99 % para 864 GPUs con respecto a la referencia en 1 GPU, en el mejor escenario de tres dimensiones en el que el dominio crece de forma lineal en una dimensi´on. En escalabilidad fuerte, en una aplicaci´on con dominio de dos dimensiones muestra una aceleraci´on de hasta 56.87x en 64 nodos y de 114x en 256 nodos con respecto al tiempo de referencia en 1 nodo. La comparaci´on con Muesli y Celerity muestra que EPSILOD mejora sus resultados de rendimiento consiguiendo mejor escalabilidad tanto d´ebil como fuerte para un gran n´umero de dispositivos. El c´odigo de la nueva versi´on de EPSILOD junto con las implementaciones de las aplicaciones utilizadas en el estudio experimental est´a a disposici´on p´ublica1. El resto del art´ıculo tiene la siguiente estructura. En la secci´on II se detalla trabajo relacionado incluyendo otros modelos similares. La secci´on III describe EPSILOD y las bibliotecas en las que se apoya. La secci´on IV describe las mejoras propuestas. Describimos el estudio experimental en la secci´on V. Por ´ultimo, la secci´on VI trata las conclusiones y el trabajo futuro. 1https://gitlab.com/trasgo-group-valladolid/ controllers/-/tree/25_JP_epsilod2?ref_type=tags II. Estado del arte Se pueden encontrar en la literatura diversos modelos o herramientas de programaci´on para desarrollar y ejecutar aplicaciones ISL en sistemas heterog´eneos y distribuidos. Estas soluciones presentan abstracciones para ocultar los detalles del manejo de dispositivos heterog´eneos y/o aceleradores y los detalles de la distribuci´on y comunicaci´on de datos. Existen diversos modelos y herramientas de programaci´on que permiten trabajar con c´odigos ISL en sistemas con GPUs [2], [3], [4], [5], [6], [7], [8]. Algunas est´an basadas en esqueletos o patrones paralelos. Estos permiten explotar caracter´ısticas espec´ıficas del patr´on de c´omputo y comunicaci´on del tipo de aplicaci´on. SkelCL [9] o SkePU3 [10] incluyen un esqueleto MapOverlap que puede ser utilizado para implementar aplicaciones ISL. Ambos soportan multi-GPU en este esqueleto, pero no multi-nodo con aceleradores. Lo mismo sucede con el patr´on iterative stencil + reduce en Fastflow [11]. Otras bibliotecas de esqueletos como Muesli [12] soportan multi-GPU y multi-nodo para aplicaciones ISL, con optimizaciones espec´ıficas para dominios complejos [13]. Todas estas soluciones no implementan mecanismos que exploten completamente el solapamiento de c´omputo y comunicaciones, tanto entre dispositivos y nodo anfitri´on como entre nodos. Estas soluciones escalan cuando el ratio entre c´omputo y comunicaci´on es lo suficientemente alto como para que las comunicaciones no sean muy significativas. Sin embargo, su coste afecta a la escalabilidad en escenarios comunes en los que el ratio de comunicaci´on con respecto al c´omputo crece con el n´umero de dispositivos o nodos, siendo especialmente notable en aplicaciones ISL complejas con alto volumen de comunicaci´on. Adem´as, estos costes de comunicaci´on se revelan ineludiblemente en estudios de escalabilidad fuerte cuando la cantidad de c´omputo por nodo se reduce lo suficiente. Otra soluci´on para implementar aplicaciones ISL es utilizar una herramienta suficientemente abstracta aunque no especifica para esta clase de problemas. Por ejemplo, Celerity [14] utiliza como capa de portabilidad para dispositivos heterog´eneos SYCL [15]. Celerity a˜nade por encima un sistema abstracto para expresar distribuciones de datos y dependencias, que genera internamente las comunicaciones en MPI solapando parte de las transferencias de datos con el c´omputo. Finalmente, EPSILOD [1], la herramienta que nos ocupa en este trabajo, se construye sobre una capa de portabilidad para sistemas heterog´eneos denominada Controller [16], [17], integrada con una capa de gesti´on de comunicaciones en sistemas distribuidos denominada Hitmap [18]. Presenta un esqueleto paralelo con optimizaciones para aplicaciones ISL que aprovechan posibilidades m´as sofisticadas de solapamiento de c´omputo y comunicaciones, lo que facilita la escalabilidad de las soluciones. III. Antecedentes Para facilitar el desarrollo de aplicaciones eficientes en entornos HPC, el grupo Trasgo ha desarrollado previamente varias bibliotecas de funciones escritas en C11, compatibles con cualquier compilador moderno de C/C++. Las aplicaciones desarrolladas sobre estas bibliotecas se despliegan y adaptan en entornos distribuidos con configuraciones de hardware diversas tanto homog´eneas como heterog´eneas. Por tanto, proporcionan una capa de abstracci´on que simplifica el desarrollo y el despliegue en m´ultiples tipos de entornos: desde contextos de peque˜na escala como sistemas empotrados con hardware heterog´eneo, hasta cl´usteres exaescala con arquitecturas uniformes que incluyen aceleradores. A. Hitmap Hitmap [18] facilita las tareas relacionadas con la partici´on jer´arquica de arrays multidimensionales u otras estructuras de datos con dominios tanto densos como dispersos. Se encarga del particionado de los datos en tiles (teselas), del mapeado de los mismos a los procesos y la comunicaci´on y sincronizaci´on entre ellos. Implementa un sistema de plug-ins para las pol´ıticas de partici´on y mapeo. Las comunicaciones se expresan en funci´on de los objetos resultantes. Por tanto, el c´odigo escrito con Hitmap es independiente de la forma en que se distribuye el trabajo. Permite tambi´en agrupar conjuntos de acciones de comunicaci´on en patrones completos que se pueden reutilizar en diferentes puntos del programa. Hitmap est´a construida sobre MPI. Se ha mostrado con diversas aplicaciones que Hitmap puede ser tan eficiente como la implementaci´on manual en MPI, reduciendo el esfuerzo de programaci´on. B. Controller Controller [16], [17] es una biblioteca de funciones. Implementa el concepto de controlador, una entidad abstracta que se encarga de gestionar, de forma transparente para el programador, la memoria y el lanzamiento de tareas en un dispositivo de c´omputo. Un dispositivo puede ser desde un conjunto de n´ucleos de CPU hasta un acelerador hardware como una GPU o FPGA. Al utilizar unas abstracciones comunes para todos los dispositivos reduce el esfuerzo de programaci´on. Controller implementa diferentes backends o sistemas de ejecuci´on que se encargan de enlazar el c´odigo del usuario con las tecnolog´ıas espec´ıficas para el manejo del dispositivo correspondiente. Por ejemplo, OpenMP para conjuntos de n´ucleos o procesadores CPU; CUDA, HIP u OpenCL para tarjetas gr´aficas de NVIDIA y AMD; y OpenCL para FPGAs. Controller ofrece varias abstracciones. Tiene un mecanismo para definir kernels espec´ıficos para diferentes dispositivos con el mismo nombre y enlazarlos en un programa (fat binary). El programa escoge la implementaci´on apropiada para cada dispositivo en el momento de la ejecuci´on. Tambi´en permite definir kernels gen´ericos independientes de detalles del modelo de programaci´on. Se definen una ´unica vez y se reutilizan en cualquier dispositivo. Los kernels y operaciones de c´omputo se lanzan de forma as´ıncrona. El sistema analiza las dependencias de datos entre los argumentos de los kernels y se ocupa de forma transparente de mantener la consistencia de memoria entre los diferentes espacios de memoria y de mantener la consistencia secuencial con las sincronizaciones necesarias. Adem´as, ofrece una abstracci´on para indexar de forma unificada un espacio abstracto de hilos de grano fino que se adapta a la arquitectura del dispositivo, junto con una interfaz para acceder a las estructuras de datos en funci´on de los ´ındices de los hilos que unifica los criterios de coalescencia y explotaci´on de memorias cach´e tanto en CPUs como en aceleradores. C. Aplicaciones ISL y EPSILOD Una aplicaci´on ISL es una aplicaci´on iterativa. En cada iteraci´on todas las celdas de una estructura de datos se actualizan con los valores de la iteraci´on anterior en un conjunto de celdas vecinas. Qu´e celdas se consideran vecinas lo determina el patr´on geom´etrico u operador de stencil que define cada aplicaci´on. Una implementaci´on paralela parte el espacio de la estructura de datos en bloques de datos contiguos que se asignan a cada proceso o dispositivo. A partir del operador de stencil se determina el tama˜no y forma de los bordes de cada parte. Estos bordes representan las partes de la estructura que son celdas vecinas de alguna de las asignadas a otras partes. Por tanto, ser´a necesario comunicar sus valores actualizados a otros dispositivos. La parte de datos asignada a cada dispositivo se ampl´ıa para tener unas zonas denominadas halos, donde se recibe la informaci´on de los bordes de otras partes que se han de recibir. Estos halos se utilizan en los c´alculos de la siguiente iteraci´on. EPSILOD [1] es una herramienta para automatizar la creaci´on y ejecuci´on de aplicaciones ISL. Se implementa como un esqueleto paralelo. Un esqueleto paralelo [19] es un constructo de programaci´on en forma de funci´on de segundo orden que abstrae los detalles de un patr´on de computaci´on e interacci´on paralelos. El esqueleto paralelo definido en EPSILOD recibe como argumentos el tama˜no del espacio de datos a partir y computar, una especificaci´on del patr´on u operador de stencil y la funci´on que calcula o actualiza cada celda. EPSILOD utiliza mecanismos tanto de Controller como de Hitmap. Internamente, aplica una partici´on de datos por bloques y con el resultado de la misma calcula los tama˜nos y posiciones de los bordes y halos necesarios en cada dispositivo. En cada iteraci´on lanza kernels para calcular de forma separada los valores de cada borde. Cuando se detecta que los valores en un borde ya se han calculado realiza autom´aticamente las comunicaciones as´ıncronas necesarias para copiar esos datos en los halos correspondientes de otro dispositivo. De esta forma se maximizan las oportunidades para solapar estas comunicaciones con el c´omputo de la parte principal o central de los datos asignados al dispositivo. Los resultados experimentales presentados en la literatura sobre la primera versi´on de EPSILOD indican que permite obtener una buena escalabilidad fuerte y d´ebil tanto para sistemas homog´eneos como heterog´eneos, con mejor rendimiento que utilizando las versiones disponibles en aquel momento de herramientas de comunicaci´on abstracta como Celerity [14]. IV. Propuesta e implementaci´ on En esta secci´on se describen los avances introducidos en EPSILOD con el objetivo de: (1) Mejorar su capacidad para implementar nuevos tipos de aplicaciones ISL; (2) Aumentar su flexibilidad para experimentar con diferentes pol´ıticas y mecanismos de partici´on y mapeo; (3) Mejorar su rendimiento y escalabilidad. A. Datos gen´ericos La versi´on previa de EPSILOD solo soportaba estructuras de datos con elementos de un tipo nativo del lenguaje de programaci´on C. Para cambiar el tipo nativo por otro la biblioteca deb´ıa ser recompilada. Con el objetivo de poder implementar una mayor variedad de aplicaciones, se ha adaptado EPSILOD permitiendo el uso de tipos de datos gen´ericos. Los elementos de las estructuras de datos que representan el dominio del problema se pueden declarar ahora con un tipo de datos arbitrario. Permite tipos de datos definidos por el usuario, incluyendo estructuras complejas. En el fichero de configuraci´on de cada aplicaci´on se especifica el tipo de datos elemental deseado. De forma autom´atica se compila una versi´on de EPSILOD por cada tipo de datos especificado en alguna aplicaci´on, permitiendo al compilador realizar optimizaciones autom´aticas espec´ıficas para cada tipo. Cada aplicaci´on se enlaza con la versi´on de EPSILOD correspondiente. En el listado 1 se puede ver un ejemplo de c´omo declarar y utilizar un tipo de datos definido por el usuario (cell t). Cada aplicaci´on utiliza la macro EPSILOD BASE TYPE para declarar su tipo de datos. Si no se especifica, el tipo por defecto es float. B. Mejoras en la descomposici´on del dominio La descomposici´on del dominio para la paralelizaci´on de los problemas de tipo ISL implica la creaci´on de un patr´on de comunicaci´on de datos entre los procesos que realizan computaci´on sobre subdominios vecinos. La cantidad de datos en los bordes y halos supone un sobrecoste de la paralelizaci´on de este tipo de algoritmos. Por un lado, se trata de un sobrecoste de memoria, ya que cada proceso tiene que alojar estos datos adicionales. Adem´as, implica un sobrecoste de tiempo de ejecuci´on, ya que esos datos se tienen que intercambiar entre los distintos procesos. Este coste es proporcional al volumen de datos y su disposici´on en memoria (contiguos o dispersos), por lo que reducir dicha cantidad y optimizar su localizaci´on en memoria es de gran importancia. Listado 1: Mecanismo de tipado gen´erico para definir el elemento base de las estructuras de datos de EPSILOD en C. 1 2typedef struct { 3float data [19]; 4} cell_t; 5 6# define EPSILOD_BASE_TYPE cell_t 7#include "epsilod.h" 8 9CTRL_KERNEL ( updateCell , GENERIC , DEFAULT , 10 KHitTile_cell_t matrix , 11 const KHitTile_cell_t matrixCopy , ... , { 12 ... 13 }); 14 15 REGI ST ER_ ST ENC IL ( updateCell , GENERIC , DEFAULT ) ; 16 ... 17 int main ( int argc , char * argv []) { 18 ... 19 stencilC om putatio n (...) ; 20 ... 21 } Una forma de optimizar la cantidad de datos que intervienen en las comunicaciones consiste en una elecci´on adecuada de la pol´ıtica de descomposici´on del dominio [20]. La cantidad de opciones y su complejidad aumenta con el n´umero de dimensiones del problema. Para un dominio de dos dimensiones, la ecuaci´on 1 expresa el tama˜no de los halos al partir en una dimensi´on y la 2 al partir por dos dimensiones. Sh,1d= 4n(1) Sh,2d= 8 n √p(2) Donde Sh,1dySh,2des el tama˜no de los halos, n, el tama˜no del lado de la matriz y p, el n´umero de procesos. Estas f´ormulas se obtienen al multiplicar el n´umero de comunicaciones que hace cada proceso (env´ıos y recepciones) por el tama˜no de las mismas. A partir de cierto n´umero de procesos, partir en 2 dimensiones resulta en un menor tama˜no de los halos. Esto se puede extrapolar a un mayor n´umero de dimensiones, tanto del dominio como de particionado. As´ı, en el caso de problemas con tres dimensiones, al partir la matriz en subdominios en una dimensi´on el volumen de los halos crece notablemente m´as r´apido que si se descompone en dos dimensiones. A partir de las f´ormulas 1 y 2, se ha calculado como evoluciona la proporci´on entre el n´umero de datos a comunicar y el n´umero de datos que intervienen en el c´omputo por cada proceso. Este resultado se muestra en la figura 1. Esto solo tiene en cuenta el volumen de datos, por lo que es necesario obtener resultados experimentales para ver como influyen en los tiempos de ejecuci´on para cada tipo de partici´on otros factores como la dispersi´on de los datos en memoria o las latencias en la transmisi´on en diferentes escenarios. La primera versi´on de EPSILOD no permit´ıa al usuario cambiar la pol´ıtica de partici´on directamente. Era necesario cambiar en el c´odigo de EPSILOD las llamadas a Hitmap para escoger una topolog´ıa virtual para los procesos y una pol´ıtica de descomposici´on y partici´on sobre esa topolog´ıa, recompilando la herramienta. Para facilitar el experimentar con 0 200 400 600 800 1000 Número de dispositivos 0.00 0.05 0.10 0.15 0.20 0.25 0.30 0.35 0.40 Ratio comunicación / cómputo Partición en 1 dimensión Partición en 2 dimensiones Fig. 1: C´alculo te´orico de la proporci´on, por proceso, entre el volumen de datos en comunicaciones y c´omputo, cuando se utilizan particiones de 1 y 2 dimensiones sobre una estructura de datos de tres dimensiones. En este ejemplo cada dispositivo computa 10003elementos. diferentes pol´ıticas se ha propuesto flexibilizar la herramienta introduciendo un par´ametro en forma de variable de entorno que permite al usuario escoger la pol´ıtica de partici´on en el momento del lanzamiento con un ´unico argumento. Se han dise˜nado una colecci´on de pol´ıticas que expresan de forma m´as sencilla combinaciones de topolog´ıas virtuales y distribuciones de datos de las disponibles en el sistema de plugins de Hitmap. Tambi´en se ha construido un nuevo plug-in de Hitmap que mejora el equilibrio de la cantidad de procesos en cada dimensi´on de una tipolog´ıa multidimensional. C. Optimizaci´on de las comunicaciones Se propone reducir la complejidad y tiempo de las comunicaciones entre iteraciones de dos formas. La primera consiste en detectar los halos correspondientes a l´ımites del dominio para evitar transferencias innecesarias al dispositivo. En la versi´on original de EPSILOD se transfer´ıan desde el espacio de memoria del proceso anfitri´on hacia el dispositivo todos los halos. En EPSILOD los procesos que gestionan los dispositivos se organizan en una topolog´ıa virtual que puede ser uni-dimensional o multidimensional. Cu´antas m´as dimensiones se usan m´as procesos tienen alg´un borde en el l´ımite del dominio. Estos bordes no se comunican y los correspondientes halos no reciben nada. La segunda optimizaci´on est´a relacionada con el solapamiento del c´omputo y las comunicaciones. Durante la experimentaci´on con la versi´on original de EPSILOD en cl´usters de supercomputaci´on con dispositivos GPU, se observa que en algunas configuraciones las comunicaciones predominan sobre el c´omputo. De esta forma, aparecen per´ıodos en los que los dispositivos est´an ociosos. Adem´as, observamos que el patr´on de comunicaciones espera a todas las transferencias de datos entre procesos antes de iniciar las transferencias a la memoria de la GPU correspondiente. Se puede observar este efecto en la imagen del profiler gr´afico presentado en la figura (a). Para reducir el tiempo empleado en las comunicaciones hemos cambiado el patr´on para ir detectando la finalizaci´on de cada transmisi´on as´ıncrona de datos pertenecientes a un halo, e iniciar la transferencia a la GPU pertinente inmediatamente. Como se puede observar en la figura (b), en el caso medio, todas las transferencias de memoria hacia los dispositivos menos la ´ultima quedan solapadas con las esperas por otras comunicaciones entre procesos. El tiempo total que tardan las comunicaciones y transferencias con el dispositivo se reduce. D. Optimizaciones en la gesti´on de eventos Cuando el tama˜no de datos con el que trabaja cada proceso es suficientemente grande, las operaciones de bajo nivel, tales como encolar kernels o realizar sincronizaciones con eventos en el sistema de bajo nivel (CUDA, HIP, etc.) quedan ocultas por los tiempos de ejecuci´on de los kernels y/o las comunicaciones. No obstante, cuando la cantidad de datos sobre la que trabaja cada proceso se reduce, como es el caso en las pruebas de escalabilidad fuerte, estas operaciones pueden tomar un papel protagonista y llegar a convertirse en el camino cr´ıtico de la ejecuci´on del programa. EPSILOD utiliza la biblioteca Controller como capa de portabilidad para gestionar los dispositivos de c´omputo heterog´eneos de forma transparente. Controller utiliza un sistema de gesti´on de eventos gen´erico para sincronizar la ejecuci´on de c´omputo, las transferencias de memoria y las operaciones con el anfitri´on y otros dispositivos de cualquier tipo [17]. Para mejorar el rendimiento de EPSILOD en los escenarios en los que los tiempos de la gesti´on de las operaciones de bajo nivel son relevantes, se proponen dos optimizaciones en los sistemas de gesti´on de eventos en Controller. Primero, minimizar la cantidad de operaciones con eventos que se utilizan para sincronizar los patrones de lanzamiento de kernels y transferencias de memoria de EPSILOD. Segundo, mover al mismo hilo de ejecuci´on las operaciones de que realizan escrituras (creaci´on, destrucci´on y grabado) utilizando tecnolog´ıas de bajo nivel como CUDA, HIP, etc. Los drivers de estas tecnolog´ıas, cuando detectan operaciones de escritura en eventos desde diversos hilos, utilizan autom´aticamente locks y mutexes para crear regiones cr´ıticas y resolver potenciales problemas de concurrencia. Invocar las funciones de gesti´on de eventos desde un ´unico hilo elimina la necesidad de utilizar esas costosas operaciones de sincronizaci´on en el driver, reduciendo el sobrecoste de la gesti´on de eventos. V. Estudio experimental Realizamos un estudio experimental para mostrar el comportamiento de EPSILOD en sistemas de supercomputaci´on de gran escala. El dise˜no de los experimentos contempla estudios de escalabilidad fuerte y d´ebil. Tambi´en incluimos comparaciones de rendimiento con otras soluciones del estado del arte que permiten construir aplicaciones ISL en el mismo entorno con alto nivel de abstracci´on: (1) Muesli [12], una herramienta basada en esqueletos paralelos que incluye uno espec´ıfico para aplicaciones ISL de hasta 3 dimensiones que utiliza CUDA para trabajar con GPUs de NVIDIA; (2) Celerity [14], un mecanismo abstracto para construir aplicaciones con comunicaciones gen´ericas en sistemas distribuidos con acelera- (a) Patr´on de comunicaciones con espera total (b) Patr´on de comunicaciones con espera parcial Fig. 2: L´ınea temporal de dos sesiones de profiling del ejemplo gas simulation dores, que utiliza SYCL [15] como capa de portabilidad. Dise˜namos diversos experimentos para poner de manifiesto la influencia de distintos m´etodos de partici´on e implementaci´on en dominios con distinto n´umero de dimensiones. A. Aplicaciones utilizadas Para probar la escalabilidad de EPSILOD y compararla con otras herramientas del estado del arte como Muesli y Celerity, hemos seleccionado dos aplicaciones que se encuentran en los ejemplos provistos con estas herramientas. Estos ejemplos se encuentran ya desarrollados y han sido verificados en los modelos con los que se han desarrollado originalmente. Por un lado, de Muesli hemos seleccionado uno de sus ejemplos en tres dimensiones denominado gas simulation. De Celerity hemos seleccionado el ejemplo que implementa una aplicaci´on ISL en dos dimensiones, denominado wave simulation. Gas simulation es una simulaci´on de fluidos basada en los m´etodos de red de Boltzmann (LBM) [21]. La implementaci´on de Muesli tiene la particularidad de usar un tipo compuesto como valor de cada celda de un dominio tridimensional. Esto nos permite probar el nuevo soporte de EPSILOD para tipos gen´ericos de datos. Adem´as, este tipo de datos compuesto, implica comunicaciones m´as costosas con respecto a otros ejemplos. Por su parte, Wave simulation tiene un operador de stencil cl´asico en dos dimensiones con cinco puntas (usa los valores de la propia celda y de sus cuatro vecinas). En la literatura de EPSILOD se denomina 2d5. Pero tiene la peculiaridad de emplear tambi´en su propio valor calculado dos iteraciones atr´as. A la hora de adaptar estas aplicaciones a EPSILOD, el objetivo es hacer una traducci´on directa de los c´odigos originales. Hemos puesto especial atenci´on a la traducci´on de los kernels de c´omputo sin introducir ning´un tipo de optimizaci´on o mejora. En el c´odigo de los kernels originales simplemente se han cambiado los accesos a las estructuras de datos para usar las llamadas a Hitmap equivalentes. Se han cambiado los prototipos de los kernels y se han adaptado las funciones de inicializaci´on y salida de resultados. B. Plataforma experimental La experimentaci´on se ha realizado en Leonardo, un supercomputador pre-exaescala al que se ha accedido a trav´es del programa EuroHPC JU. Leonardo est´a localizado en un centro de datos del Tecnopolo de Bologna en Italia y est´a gestionado por Cineca. Se ha empleado la partici´on Booster, dedicada al c´omputo con GPUs. Esta partici´on cuenta con 3456 nodos, cada uno con 4 GPUs NVIDIA Ampere A100 con 64 GB de memoria y una CPU Intel Xeon Platinum “Ice Lake” de 32 n´ucleos. El sistema de colas permite ejecutar hasta en 256 nodos simult´aneamente en esta partici´on. Las pruebas en Leonardo se han realizado utilizando GCC 12.2, CUDA 12.3, Open MPI 4.1.6 y Celerity 0.6.0 compilado con Clang y basado en AdaptiveCpp 24.10.0. C. Escenarios de escalabilidad Hemos realizado pruebas de escalabilidad d´ebil y de escalabilidad fuerte. Para las primeras partimos como referencia de la ejecuci´on con un tama˜no fijo para un ´unico dispositivo GPU. El dominio de partida es un cuadrado en la aplicaci´on de dos dimensiones y un cubo en la de tres. Consideramos dos escenarios de escalado: (1) Prisma: El dominio crece solo en la primera dimensi´on multiplicando el n´umero de filas por el n´umero de GPUs, formando un rect´angulo en dos dimensiones o un prisma cuadrado en tres dimensiones; (2) Politopo regular: El dominio crece en todas las dimensiones por igual (un cuadrado o un cubo repartido entre todas las GPUs), manteniendo un n´umero de elementos aproximadamente igual al de la referencia multiplicado por el n´umero de GPUs. En el escenario de Prisma, para particiones en una sola dimensi´on, la cantidad de datos a comunicar entre cada par de nodos es independiente del n´umero de GPUs implicadas. La proporci´on entre comunicaciones y c´omputo en cada nodo se mantiene constante. Nos provee de un escenario de control para corroborar que los ejemplos muestran un comportamiento previsible sin sobrecostes ocultos o inesperados que crezcan con el n´umero de dispositivos. En el escenario de politopo regular la matriz mantiene su forma cuadrada o c´ubica al escalar. Para particiones en una dimensi´on esto supone un incremento notable del ´area de comunicaci´on entre cada par de procesos al escalar. Este incremento es menor en particiones en un mayor n´umero de dimensiones. Para las pruebas de escalabilidad fuerte utilizamos como referencia la ejecuci´on en un nodo completo con un dominio cuadrado en 2D o c´ubico en 3D repartido entre las cuatro GPUs del nodo. Este dominio se reparte con la pol´ıtica seleccionada entre todas las GPUs de los nodos escogidos en cada experimento. D. Tama˜nos del dominio Hemos elegido como tama˜nos de partida los tama˜nos m´as grandes posibles de las matrices considerando la memoria disponible de cada GPU y las limitaciones espec´ıficas de cada modelo. Hemos buscado que la distribuci´on entre los dispositivos sea uniforme. El n´umero de dispositivos de c´omputo tambi´en se ha escogido de cara a lograr esta uniformidad. Para la aplicaci´on gas simulation, se han escogido dos posibles tama˜nos de partida: Caso A: Tama˜no escogido para poder comparar EPSILOD con Muesli. En Muesli el tama˜no de dominio global a repartir entre todas las GPUs est´a restringido por la cantidad de datos que se puede direccionar con un entero de 32 bits. Esto limita el m´aximo n´umero de nodos a utilizar en la experimentaci´on y/o el tama˜no de entrada de la referencia. Adem´as, Muesli impone otra restricci´on: el tama˜no de la matriz en la dimensi´on ztiene que ser m´ultiplo del n´umero de procesos – un proceso por nodo – y del n´umero de GPUs por nodo. Esto complica la elecci´on de tama˜nos de la matriz. En escalabilidad d´ebil ya no puede ser exactamente c´ubica para cualquier n´umero de dispositivos si se quiere mantener la uniformidad de la distribuci´on de la matriz entre los elementos de c´omputo. En escalabilidad d´ebil el tama˜no de partida en una GPU es de 2023elementos. Esto supone una ocupaci´on por GPU de unos 1.16 GB de los 64 GB disponibles. En este caso, las limitaciones de Muesli, permiten escalar hasta 256 GPUs en 64 nodos. En el caso de escalabilidad fuerte, es posible partir de un tama˜no 5123en un nodo, con una ocupaci´on de 4.75 GB por GPU. Debido a la restricci´on del eje z, este tama˜no permite escalar hasta 512 GPUs en 128 nodos. Caso B: Para ver el comportamiento de la aplicaci´on con una mayor ocupaci´on de la GPU con EPSILOD hemos definido otro caso con un mayor tama˜no de entrada. En escalabilidad fuerte partimos de un tama˜no de 11843en 1 nodo. En estas condiciones, la ocupaci´on de las matrices de c´omputo es de unos 52.98 GB de los 64 GB disponibles. Esto es principalmente debido al tama˜no adicional que requieren los halos al partir en 1 dimensi´on. Adem´as es necesario dejar algo de espacio libre para algunas estructuras auxiliares, las estructuras de gesti´on propias de sistemas subyacentes y los datos de profiling si se desea utilizar dicha herramienta. En escalabilidad d´ebil la referencia es una matriz de 7203en una GPU. Como hemos comentado previamente, el n´umero de datos a comunicar crece m´as r´apido para particiones en una dimensi´on. Por ello, y para limitar el tiempo de ejecuci´on de las pruebas y la cuota consumida, hemos limitado el n´umero m´aximo de nodos a 64 en las pruebas de este caso cuando se parte en una dimensi´on. En el resto de pruebas de este caso escalamos hasta 1024 GPUs en 256 nodos, el m´aximo disponible. En la aplicaci´on wave simulation los elementos de las matrices son del tipo nativo float. Por tanto, es necesario un n´umero mayor de elementos para conseguir una alta ocupaci´on de las GPUs. En este caso es en EPSILOD donde el tipo de datos empleado para indexar los datos se convierte en un factor limitante, lo que nos lleva a un ´unico caso de experimentaci´on: Caso C: En escalabilidad fuerte la matriz cuadrada de referencia en un nodo tiene 901122elementos. En escalabilidad d´ebil la matriz cuadrada de referencia en 1 GPU tiene 450562elementos. En ambos casos podemos escalar hasta 1024 GPUs en 256 nodos, el m´aximo disponible. E. Resultados de escalabilidad d´ebil La Fig. 3 muestra los resultados de escalabilidad d´ebil para la aplicaci´on gas simulation con el escenario en el que el dominio crece como un politopo regular (cubo). En esta aplicaci´on el volumen de comunicaci´on es alto comparado con el c´omputo, por lo que las comunicaciones pueden dominar el tiempo de ejecuci´on f´acilmente. Se observa que en EPSILOD la partici´on en una dimensi´on no es adecuada, ya que el volumen de comunicaci´on crece con el n´umero de GPUs. En el caso de la partici´on en dos dimensiones el crecimiento est´a mucho m´as acotado. En el Caso B de tama˜no grande con una gran ocupaci´on de la memoria de las GPUs se observa que hasta 64 nodos las comunicaciones est´an completamente solapadas y no influyen en el tiempo de ejecuci´on. A partir de ese punto no quedan completamente solapadas y los tiempos de ejecuci´on crecen ligeramente siguiendo la tendencia del crecimiento del volumen de los halos. En el caso del tama˜no peque˜no soportado por Muesli el c´omputo es menor y la tendencia aparece antes. En Muesli observamos que el tiempo crece r´apidamente con la cantidad de nodos. Sus comunicaciones no est´an solapadas por lo que su efecto es inevitable. Utiliza una partici´on en una dimensi´on, pero con un solo proceso por nodo, utilizando comunicaciones m´as optimizadas entre los dispositivos del mismo nodo. Esto introduce un factor multiplicativo que reduce los tiempos de ejecuci´on comparados con la partici´on de una dimensi´on en EPSILOD. Pero no puede evitar la misma tendencia de crecimiento en funci´on del n´umero de nodos. En la izquierda de la Fig. 5 se muestran los resultados con la aplicaci´on wave simulation con el escenario de crecimiento en forma de politopo regular (cuadrado). Aunque en los primeros nodos la introducci´on de los efectos de la red de interconexi´on s´ı incrementan los tiempos, luego se estabilizan, puesto que el volumen de comunicaci´on ya no llega a ser suficiente para hacer crecer los tiempos de forma proporcional. Se observa que Celerity obtiene un peor 1 8 27 64 Núm. nodos 0 0 2 2 4 4 6 6 8 8 10 10 12 12 Tiempo de ejecución (s) Gas Simulation. Escalabilidad débil. Cubo. Tamaño A. EPSILOD 1D EPSILOD 2D Muesli 18 27 64 125 216 Núm. nodos 0 0 20 20 40 40 60 60 80 80 100 100 120 120 140 140 Tiempo de ejecución (s) Gas Simulation. Escalabilidad débil. Cubo. Tamaño B. EPSILOD 1D EPSILOD 2D Fig. 3: Escalabilidad d´ebil. Gas simulation. Escenario politopo regular (cubo). Tama˜no Caso A a la izquierda, tama˜no Caso B (solo soportado por EPSILOD) a la derecha. En EPSILOD 1D indica partici´on solo en la primera dimensi´on, 2D indica partici´on en las dos primeras dimensiones. 1 8 27 64 Núm. nodos 0.0 0.0 0.1 0.1 0.2 0.2 0.3 0.3 0.4 0.4 0.5 0.5 0.6 0.6 0.7 0.7 Tiempo de ejecución (s) Gas Simulation. Escalabilidad débil. Prisma. Tamaño A. EPSILOD 1D Muesli 18 27 64 125 216 Núm. nodos 0 0 5 5 10 10 15 15 20 20 Tiempo de ejecución (s) Gas Simulation. Escalabilidad débil. Prisma. Tamaño B. EPSILOD 1D Fig. 4: Escalabilidad d´ebil. Gas simulation. Escenario prisma. Tama˜no Caso A a la izquierda, tama˜no Caso B (solo soportado por EPSILOD) a la derecha. En EPSILOD 1D indica partici´on en la primera dimensi´on. 1 416 36 64 144 256 Núm. nodos 0.0 0.0 0.5 0.5 1.0 1.0 1.5 1.5 2.0 2.0 2.5 2.5 3.0 3.0 3.5 3.5 4.0 4.0 Tiempo de ejecución (s) Wave simulation. Escalabilidad débil. Cuadrado. Tamaño C. Celerity EPSILOD 1D EPSILOD 2D 1 416 36 64 144 256 Núm. nodos 0.0 0.0 0.5 0.5 1.0 1.0 1.5 1.5 2.0 2.0 2.5 2.5 3.0 3.0 3.5 3.5 4.0 4.0 Tiempo de ejecución (s) Wave simulation. Escalabilidad débil. Rectángulo. Tamaño C. Celerity EPSILOD 1D Fig. 5: Escalabilidad d´ebil. Wave simulation. Escenario politopo regular (cuadrado) a la izquierda. Escenario prisma (rect´angulo) a la derecha. En EPSILOD 1D indica partici´on solo en la primera dimensi´on, 2D indica partici´on en las dos dimensiones. rendimiento en todos los casos. Un an´alisis detallado con herramientas de profiling muestra que estas p´erdidas se deben principalmente a un mayor coste de ejecuci´on de los mismos kernels que se han portado a EPSILOD. Esto se debe a que SYCL y por extensi´on Celerity utiliza su propio compilador para compilar los kernels para GPU. En la Fig. 4 y en la derecha de la Fig. 5 se observa que cuando el dominio crece en forma de prisma en una dimensi´on, en ambas aplicaciones EPSILOD consigue una alta escalabilidad d´ebil, con p´erdidas de menos del 1 % con hasta 1024 GPUs en 256 nodos, incluso para el tama˜no Caso A en gas simulation. En estos casos el volumen de comunicaci´on entre dispositivos vecinos se mantiene independientemente del n´umero de GPUs. Luego el coste de comunicaciones es constante. Tanto Muesli como Celerity muestran unas tendencias similares aunque con mayores tiempos de ejecuci´on que EPSILOD. Un an´alisis con herramientas de profiling muestra que en Muesli el principal inconveniente es el coste de las comunicaciones que no est´a solapado con el c´omputo, mientras que en Celerity el principal problema es el mayor coste de ejecuci´on de los kernels. 1 2 4 8 16 32 64 128 256 Núm. nodos (escala log) 100100 Tiempo de ejecución (s) (escala log) Gas Simulation. Escalabilidad fuerte. Cubo. Tamaño A. EPSILOD 1D EPSILOD 2D Muesli 1 2 4 8 16 32 64 128 256 Núm. nodos (escala log) 100100 101101 Tiempo de ejecución (s) (escala log) Gas Simulation. Escalabilidad fuerte. Cubo. Tamaño B. EPSILOD 1D EPSILOD 2D Fig. 6: Escalabilidad fuerte. Gas simulation. Escenario politopo regular (cubo). Tama˜no Caso A a la izquierda, tama˜no Caso B (solo soportado por EPSILOD) a la derecha. En EPSILOD 1D indica partici´on solo en la primera dimensi´on, 2D indica partici´on en las dos primeras dimensiones. 1 2 4 8 16 32 64 128 256 Núm. nodos (escala log) 10 110 1 100100 Tiempo de ejecución (s) (escala log) Wave simulation. Escalabilidad fuerte. Cubo. Tamaño C. Celerity EPSILOD 1D EPSILOD 2D Fig. 7: Escalabilidad fuerte. Wave simulation. Escenario politopo regular (cuadrado). 1D indica partici´on en la primera dimensi´on. En EPSILOD 1D indica partici´on solo en la primera dimensi´on, 2D indica partici´on en las dos dimensiones. F. Resultados de escalabilidad fuerte La figura 6 muestra los resultados de escalabilidad fuerte para la aplicaci´on gas simulation. Como ya vimos anteriormente partir por 2 dimensiones una matriz de 3 resulta en una mejor escalabilidad fuerte que partir por una dimensi´on. Esta ´ultima partici´on deja de escalar a partir de 2 o 4 nodos dependiendo del tama˜no del dominio. En cuanto a la partici´on en 2 dimensiones, aunque la escalabilidad no es ideal, muestra una tendencia que se mantiene incluso hasta 1024 GPUs en 256 nodos, consiguiendo un speedup de 33.58x. En Muesli, la falta de solapamiento de las comunicaciones se revela en cuanto el tama˜no del c´omputo se reduce al dividirse en un n´umero creciente de GPUs, de forma que no consigue escalar. La figura 7 muestra los resultados de escalabilidad fuerte en wave simulation. En EPSILOD la escalabilidad es casi perfecta hasta 256 GPUs en 64 nodos. En 128 y 256 nodos la cantidad de c´omputo se reduce de tal forma que las comunicaciones ya no quedan completamente solapadas observ´andose una reducci´on de la escalabilidad. En el caso de usar partici´on en 2 dimensiones los bordes ortogonales a la primera dimensi´on se componen de elementos no contiguos en memoria. En este caso las operaciones internas para colocar en el buffer y recolocar los datos en sus posiciones en la recepci´on son m´as costosas y afectan r´apidamente a la escalabilidad. En el caso de la partici´on en una dimensi´on la escalabilidad se reduce pero m´as lentamente, llegando a un 114x para 1024 GPUs en 256 nodos. En el caso de Celerity vemos que su sistema de comunicaciones est´a menos optimizado y a partir de 64 nodos, cuando el coste de las comunicaciones pasa a ser el cuello de botella deja de escalar derivando incluso un incremento en el tiempo de ejecuci´on para 1024 GPUs en 256 nodos. VI. Conclusiones En este trabajo se presentan una serie de cambios de dise˜no y nuevas t´ecnicas introducidas en EPSILOD, una herramienta para desarrollar y ejecutar aplicaciones ISL (Iterative Stencil Loop) en sistemas heterog´eneos distribuidos, para soportar nuevos tipos de aplicaciones, flexibilizar los mecanismos de partici´on y mejorar su rendimiento y escalabilidad. En concreto se ha introducido un sistema para soportar aplicaciones ISL que utilizan estructuras de datos con elementos de tipos gen´ericos y arbitrariamente complejos. Se ha a˜nadido un sistema para escoger en tiempo de ejecuci´on la pol´ıtica de partici´on, con un ´unico argumento que simplifica escoger las combinaciones de topolog´ıas y distribuciones de datos. Se ha mejorado el equilibrio de la distribuci´on de procesos en los diferentes ejes de las topolog´ıas multidimensionales. Se ha optimizado el modelo de comunicaciones para mejorar el solapamiento entre c´omputo y comunicaci´on y mejorar la escalabilidad. Se han simplificado los mecanismos de gesti´on de eventos en la capa de portabilidad entre dispositivos heterog´eneos para eliminar los costes de operaci´on que son especialmente significativos en estudios de escalabilidad fuerte extrema. Se presenta un estudio experimental en un supercomputador pre-exaescala que muestra la escalabilidad de la nueva versi´on de EPSILOD en escenarios de hasta 1024 GPUs distribuidas en 256 nodos. El estudio utiliza dos aplicaciones de ejemplo de otras herramientas, una con un dominio de dos dimensiones y otra con un dominio de tres dimensiones y un tipo de datos complejo que deriva en un alto