¿Cuáles son los gastos generales computacionales involucrados al resolver ecuaciones diferenciales parciales en entornos HPC?

En pocas palabras, son interacciones entre el modelo del problema, el modelo de programación, el modelo de procesamiento y la arquitectura de la plataforma de ejecución.

Aquí,

  • el modelo del problema se refiere a la manera en que el dominio del problema se discretiza para convertir el PDE en un problema numérico,
  • el modelo de programación es el conjunto de operaciones que los programadores tienen a su disposición para expresar el modelo del problema como un cómputo (a través de lenguajes o bibliotecas de extensión),
  • El modelo de procesamiento es una idea de cómo una computadora paralela abstracta lleva a cabo las operaciones del modelo de programación, y
  • La arquitectura de la plataforma en ejecución es el funcionamiento y el cableado del hardware real que hace todo al final.

Cosas como las condiciones de contorno, la formulación del problema, la selección del enfoque de resolución y otras cosas como lo que se menciona en los detalles de la pregunta, todos pertenecen a la parte de modelado del problema. Por brevedad, toquemos ese tema muy ligeramente, y recorramos el resto con un ejemplo que se centra más en entornos HPC que en ecuaciones diferenciales parciales.

Para tener una hoja de ruta, aquí hay una caricatura muy inexacta que intenta ilustrar cómo se relacionan los cuatro niveles al producir, por ejemplo, un criterio de convergencia global:


Para tener un modelo de problema lo suficientemente pequeño como para dibujar, la figura supone que el vector x es lo suficientemente grande como para dispersarse en 4 procesadores, y cada uno de ellos maneja 1/4 de cada operación de vector que involucra x. Partiendo de la idea de que la norma (euclidiana) debe verificarse contra un umbral de convergencia (como a veces necesitan los solucionadores de PDE), debemos sumar las sumas de cuadrados de los 4 procesadores en un total.

Esa es una reducción, que los modelos de programación comúnmente admiten como una operación dedicada. Por lo tanto, el modelo de programación de ejemplo permite que el cálculo se escriba como dos declaraciones, y la reducción de la suma de los cuadrados requiere una comunicación que represente algunos gastos generales. Encontrar cómo será esa sobrecarga requiere que veamos a través de la interfaz que expone el modelo de programación, porque ‘reducir’ se puede implementar de muchas maneras.

El nivel del modelo de procesamiento ilustra una de esas formas (patrón de mariposa), donde los pares seleccionados intercambian partes entre sí y toman mayores sumas parciales para el siguiente intercambio, continuando hasta que todos tengan un total de partes. Asintóticamente, esta forma se completa en un registro (#procesadores) número de pasos. También se puede hacer en 2 pasos constantes (todos envían al Proceso 0, el Proceso 0 agrega todo y lo vuelve a transmitir), un patrón de árbol, una secuencia de transmisiones de # procesadores y el uso de una gran cantidad de otros métodos de inteligencia variable. El punto es que, para la abstracción del modelo de programación, todos se ven como la misma operación de ‘reducción’, pero tienen costos muy diferentes en una máquina abstracta debajo.

El nivel final es que la máquina abstracta del modelo de procesamiento nos permite razonar sobre los costos de los métodos generales, pero idealiza las realidades del hardware. En la figura, tratar “El proceso 2 envía al Proceso 0” como una operación similar a “El proceso 1 envía al Proceso 0” oculta que P2 y P0 pueden ser océanos separados en comparación con la distancia entre P1 y P0. Esa es una distancia puramente física invisible para las preocupaciones programáticas, pero cuando sintoniza los cálculos de HPC para el rendimiento, esas distancias se convierten en gastos generales medibles. Para identificarlos, es necesario encontrar el mapeo entre el modelo de procesamiento y cómo se realiza su procesamiento; El patrón de comunicación de la mariposa en la figura da largas distancias entre P2 y P0 si la red física está estructurada en árbol. Esas distancias serán diferentes si se realizan, por ejemplo, en una red de hipercubos, que coincidiría mejor con el patrón de mariposa del modelo de procesamiento.

Este breve ejemplo ha cortado una gran cantidad de esquinas, porque en su sentido más general, la pregunta tiene un amplio alcance. Algunas omisiones notables son los gastos generales de la aritmética pura (donde interactúan los modelos problemáticos y arquitectónicos), cómo las mallas computacionales se asignan al subsistema de memoria cerca de un único procesador (donde interactúan los modelos problemáticos y de procesamiento), subprocesos frente a mensajes que pasan (donde los modelos arquitectónicos y de programación interactuar), diversidad de núcleos de procesamiento (donde interactúan los modelos de programación y procesamiento), la lista continúa, y sigue y sigue, y …

Las ecuaciones diferenciales parciales se han pasado por alto hasta ahora, la relevancia radica en que la mayoría de las diferencias de HPC. eq. los solucionadores toman la forma de particionar datos y realizar iteraciones periódicamente sincronizadas en ellos. El patrón de procesamiento paralelo de datos dentro de las iteraciones más los intercambios de dependencias en la sincronización permite encontrar gastos generales con bastante precisión en términos de las cuatro vistas dadas, al refinar sus detalles por problema. Los solucionadores directos, los métodos sin malla, los problemas vergonzosamente paralelos, la descomposición funcional, los esquemas de mensajería activa y otros asuntos paralelos a menudo están sujetos a gastos generales que dependen de diferentes factores de estos, pero en mi humilde experiencia, pasar del problema a la arquitectura en este es suficiente para descubrir y comprender las limitaciones de rendimiento de la mayoría de los solucionadores de PDE aplicados.

Todo lo anterior fue un intento de abordar cómo se pueden encontrar los gastos generales de los solucionadores de PDE en HPC, en lugar de una lista exhaustiva de gastos generales para todas las combinaciones de solucionadores y entornos. No creo que sea factible hacer una descripción completa, pero con suerte, este punto de partida aproximado para abordar casos específicos puede ser útil en su lugar.

Es un resumen terriblemente rápido y sucio, pero es el resumen más general que puedo ofrecer para un tema que presenta una gran variedad de detalles.

Los tipos de gastos generales dependen claramente de los pasos involucrados en su algoritmo [p. Ej., Jacobi si o modelo de Boltzmann de celosía o discretización de elementos finitos] y las estrategias de optimización [Eliminación de contribuciones con cero componentes (para un menor número de operaciones de punto flotante requeridas), colisión y propagación pasos en el mismo bucle (para reducir la transferencia de datos), pre-computar sub-expresiones comunes, etc., optimización de caché] que aplica y la arquitectura que usa [por ejemplo, optimización de vectores para arquitectura de vectores]
Cito los más típicos.

  1. Comunicación de arriba / mensaje que pasa por encima.
    1.1 Sobrecarga de comunicación para problemas 3-D
    1.2 Sobrecarga de comunicación en una malla [1]
  2. Sobrecarga en paralelo extender-agregar
  3. Gastos generales en los pasos de factorización
  4. Sobrecarga de particionamiento de datos [para PDE iterativos]

La página en Psu ilustra la expresión derivada de estos gastos generales [por supuesto, en un caso específico, es decir, al resolver sistemas linar con matrices dispersas en hipercubos, pero puede derivarlos para su caso una vez que haya terminado de calcular la sec-4]
[1] para leer más sobre la simulación PDE de malla y el equilibrio de carga involucrados, ver: Un generador de malla de calidad bidimensional y un triangulador y Arquímedes de Delaunay.