Creación de código paralelo con Hybrid Fortran - Calendae | Informática, Electrónica, CMS, Ciberseguridad

Creación de código paralelo con Hybrid Fortran

Hola otra vez. Te habla Simón Sánchez y hoy vamos a hablar sobre Creación de código paralelo con Hybrid Fortran

En el blog Typhoon Computing, Michel Müller aborda un tema que está en la cima de la mente de muchos programadores de HPC: transferir código a aceleradores.

Los programadores de Fortran que transfieren su código a GPGPU (unidad de procesamiento de gráficos de propósito general) tienen una nueva herramienta disponible, llamada Hybrid Fortran. Müller muestra cómo este marco de código abierto puede mejorar la portabilidad sin sacrificar el rendimiento y la capacidad de mantenimiento.

Desde Blog (nota del editor: el sitio estaba caído en el momento de la publicación):

Digamos que está comenzando a programar una aplicación HPC. No hay problema, ¿verdad? Sabe cómo funciona la máquina subyacente en términos de arquitectura de memoria y ALU. (¿O no? Bueno, eso tampoco es un problema, los compiladores se han vuelto tan buenos que estoy escuchando, seguramente lo descubrirán). Sabes qué aproximación numérica se utilizará para mapear tu problema de manera más eficiente. Ya sabe todo sobre el modelado de rendimiento de Roofline, por lo que puede comprobar si su algoritmo funciona en el hardware como esperaba. Sabe lo que debe hacer cuando se encuentra con un paralelismo de datos. Entonces, ¡sentémonos y hagámoslo!

¡Pero espera!

Escuchó que su organización solicitó un nuevo clúster. Para acercarse a Exascale, este grupo exhibirá estos nuevos e imaginativos aceleradores. Por lo tanto, todos los proyectos de software de HPC nuevos deben considerar si pueden utilizar coprocesadores y cómo. Empieza a leerse a sí mismo en el panorama del acelerador. OpenCL, CUDA, OpenACC, OpenMP, ArrayFire, Tesla, Intel MIC, Parallela … Su cabeza comienza a aturdirse por todas estas cosas: todas estas herramientas de hardware y software se superponen, pero también diferencias significativas. Lo más importante es que son muy diferentes de la arquitectura de CPU x86. ¿Porque?

Es esencialmente el hecho de que en 2005 terminó el almuerzo gratuito.

Con almuerzo gratis, Müller obviamente se refiere a la desaceleración de la ley de Moore. Cuando las velocidades de reloj del procesador alcanzaron su límite, los fabricantes de chips comenzaron a llenar más núcleos en un chip y nació la era multinúcleo. Esto coloca la carga sobre el programador para explotar este paralelismo. Pero mientras tenga que hacer toda esa implementación multiproceso, ¿por qué no aprovecharla al máximo ?, pregunta Müller, o como él dice, «¿Por qué molestarse con seis u ocho subprocesos si podemos tener miles?»

A partir de aquí, Müller atraviesa un proceso gradual de otros obstáculos potenciales, como las aplicaciones limitadas por el ancho de banda de la memoria, el bus PCI Express lento y la tentación de permitir que los científicos usen la versión antigua (no acelerada) del código solo en máquinas. CPU existentes.

Todo esto conduce al dilema final: ¿qué pasaría si una mayor portabilidad se produjera a expensas del rendimiento y la capacidad de mantenimiento?

Para el código escrito en Fortran, hay esperanza en la forma de una directiva Fortran de código abierto llamada Hybrid Fortran. los Página de GitHub del código lo explica como «una forma de seguir escribiendo código Fortran como está acostumbrado, solo que ahora con soporte GPGPU».

Con esta solución administrada por máquina, un preprocesador basado en Python se encarga de las transformaciones necesarias en tiempo de compilación, por lo que no hay sobrecarga en tiempo de ejecución. Analiza las anotaciones junto con la estructura del código de Fortran, las declaraciones, los accesores y las llamadas a procedimientos, luego escribe versiones separadas del código: una para CPU con paralelización OpenMP y otra para GPU con CUDA Fortran.

El programador solo necesita agregar dos cosas:

(1) ¿Dónde está el código para paralelizar? (Se puede especificar por separado para CPU y GPU).
(2) ¿Qué símbolos deben transformarse en diferentes dimensiones?

Müller muestra las diferencias de rendimiento de este enfoque a continuación:

[1] Si está disponible, compare con la versión C de referencia; de lo contrario, compare con la implementación de CPU híbrida Fortran. Se usó Kepler K20x como GPU, Westmere Xeon X5670 se usó como CPU (TSUBAME 2.5). Todos los resultados medidos con doble precisión. Los núcleos de la CPU se limitaron a un socket utilizando afinidad de subprocesos «compactos» con 12 subprocesos lógicos. Para la CPU, se utilizaron los compiladores Intel ifort / icc con la configuración «-fast». Para la GPU, se utilizó el compilador PGI con configuración «-fast» y capacidad de cálculo CUDA 3.x. Todos los resultados de la GPU incluyen el tiempo de copia de memoria del host al dispositivo.

Müller no solo se encontró con esta solución, también es el desarrollador principal del código base. En el Instituto de Tecnología de Tokio, Müller trajo el núcleo físico del modelo de pronóstico del tiempo nacional de próxima generación de Japón a GPGPU. Se encontró con muchos de los problemas que presenta en este blog, y la solución de estos problemas lo llevó al desarrollo de Hybrid Fortran. Müller trabaja actualmente en el Instituto de Tecnología de Tokio, donde planea llevar el modelo meteorológico de código abierto WRF utilizado internacionalmente al Hybrid Fortran.

Puedes compartir en una historia de tu Instagram para que tus colegas lo consulten

??? ? ? ???

Comparte