Compiladores heterogéneos listos para despegar - Calendae | Informática, Electrónica, CMS, Ciberseguridad

Compiladores heterogéneos listos para despegar

Hola de nuevo. Te habla Simón Sánchez y en esta ocasión te voy a hablar sobre Compiladores heterogéneos listos para despegar

La segunda ola de herramientas de desarrollo de software GPGPU está sobre nosotros. La primera ola, ejemplificada por CUDA de NVIDIA y Brook + de AMD, permitió a los primeros usuarios comenzar con la computación GPU a través de herramientas de bajo nivel específicas del proveedor. Las herramientas de próxima generación de The Portland Group Inc. (PGI) y CAPS Enterprise, con sede en Francia, permiten a los programadores de C y Fortran de todos los días aprovechar la aceleración de la GPU en un entorno informático heterogéneo integrado.

Durante los últimos cinco años, la comunidad HPC se ha unido en torno a la arquitectura x86. Esto facilitó la focalización para empresas como IGP. Hoy en día, el 85 por ciento del TOP500 se basa en microprocesadores x86 de 64 bits, y el porcentaje es probablemente incluso mayor en el ámbito sub-500. Aunque Intel y AMD continúan innovando con arquitecturas multinúcleo, están limitadas a velocidades de reloj de alrededor de 2.5-3.5 GHz.

Mientras tanto, las GPU se han convertido en procesadores vectoriales de uso general con cientos de núcleos simples y están escalando a una velocidad más rápida que las CPU. El hecho de que los proveedores de compiladores como PGI ahora apunten a las GPU dice mucho sobre hacia dónde se dirige la industria con la aceleración genérica, especialmente en el espacio HPC.

«Como proveedor de compiladores, nos preguntamos: ‘¿Qué viene después?'», Dijo Doug Miles, director de Compiladores y Herramientas Avanzados de PGI. «Nuestra mejor suposición es que lo que viene a continuación es la computación acelerada».

PGI apuesta a que x86 de 64 bits con «algún tipo de acelerador» será la nueva plataforma elegida para muchas aplicaciones de HPC. En este momento, la GPU es el acelerador de la supercomputación. El primer enfoque del acelerador para PGI son las GPU habilitadas para CUDA de NVIDIA. Para implementar esto, PGI aprovechará la cadena de herramientas CUDA y el SDK asociado, mientras que la compilación del lado del host se basará en la tecnología x86 de PGI.

Dado que las GPU están conectadas a la plataforma host como dispositivos externos en lugar de como verdaderos coprocesadores, el modelo de software de bajo nivel es bastante complejo. En el lado del host, implica transferencias de datos entre la CPU y la GPU (a través de PCIe), asignación / desasignación de memoria y otra administración de dispositivos de bajo nivel. Por el lado de la GPU, el código también puede ser bastante complicado, ya que tiene que encargarse de la paralelización del algoritmo y la jerarquía de memoria de la GPU.

Para que la programación de la GPU sea más productiva, vale la pena ocultar la mayoría de estos detalles al desarrollador de la aplicación. Lo que PGI ha hecho es definir un conjunto de pragmas C y directivas Fortran que se pueden incrustar en el código fuente y ordenar al compilador que descargue las secuencias de código especificadas a la GPU.

Este enfoque es análogo a OpenMP, que define pragms y directivas para aplicar subprocesos múltiples en un programa secuencial. A diferencia de un enfoque basado en bibliotecas, este modelo permite a los desarrolladores mantener una base de fuentes común para una variedad de destinos diferentes. En el caso de PGI, los compiladores que no admiten el acelerador pueden usar la misma fuente, pero simplemente ignorarán los pragms o las directivas externas. Incluso dentro del entorno PGI, los pragms y las directivas del acelerador se pueden desactivar en tiempo de compilación para que solo se genere código x86.

La forma general del pragma del acelerador de C es #pragma acc directive-name [clause [,clause]…]; el equivalente de Fortran es! $ acc directive-name [clause [,clause]…]. Aplicar una región de acelerador a un ciclo de multiplicación de matrices en Fortran se vería así:

módulo mymm
contiene
subrutina mm1 (a, b, c, m)
tamaño real (:, 🙂 :: a, b, c
entero i, j, k, m
! $ acc region
hacer j = 1, m
dar i = 1, n
a (yo, j) = 0.0
enddo
hacer k = 1, p
dar i = 1, n
a (yo, j) = a (yo, j) + b (yo, k) * c (k, j)
enddo
enddo
enddo
! $ acc región final
fin de subrutina
forma definitiva

El bucle encerrado por la directiva del acelerador se paralelizará y descargará a la GPU, asumiendo que está presente. Para todo el programa, el compilador generará tanto el código de la CPU como el de la GPU, que posteriormente se vincularán en un solo archivo ejecutable. Dado que el código generado proporcionará todas las transferencias de datos necesarias, la gestión de la memoria y la contabilidad del dispositivo, el programador no necesita ningún conocimiento especial de la arquitectura del acelerador.

En realidad, esto es solo parcialmente cierto. La conclusión es que la programación paralela en cualquier objetivo probablemente requerirá una reestructuración para un rendimiento óptimo. «La programación en paralelo no es fácil», admite el ingeniero del compilador de PGI Michael Wolfe. Según él, este primer paso en la tecnología del compilador CPU-GPU es hacer que el problema sea más accesible. (Puede encontrar una discusión más profunda de los pensamientos de Wolfe sobre el modelo de programación de GPU de PGI aquí).

PGI tiene actualmente una versión beta del compilador NVIDIA x64 + en desarrollo, que estará disponible para una vista previa técnica en enero. Esperan tener una versión de producción del producto a mediados de 2009. La compañía también está trabajando con AMD en una versión para los aceleradores FireStream y utilizará el SDK asociado para ese objetivo.

Puede haber un momento en que los pragms y la directiva se puedan eliminar por completo y el compilador solo pueda determinar cuándo generar el código de la GPU. Pero en este momento, la diferencia entre alto rendimiento y bajo rendimiento en estos aceleradores es tan grande que es mejor dejar que el programador dirija el compilador al código que requiere más procesamiento y, por lo tanto, la sobrecarga de transferir datos del host a la GPU vale la pena. . Es posible que a medida que la tecnología del compilador madura y las GPU se integran más estrechamente con las CPU, tanto la optimización del rendimiento como la aceleración automática pueden incluirse en el compilador.

CAPS Enterprise, con sede en Francia, espera que los compiladores nunca se vuelvan tan inteligentes. Al igual que PGI, CAPS ofrece un entorno de desarrollo de software heterogéneo, inicialmente dirigido a plataformas x86 con aceleradores de GPU. En este caso, sin embargo, la generación de código x86 se realizará a través de herramientas de terceros como los compiladores C y Fortran de Intel y GCC de GNU. Para que la oferta CAPS tenga sentido, la compilación del acelerador y la compilación de la CPU deben permanecer separadas.

La oferta CAPS, llamada HMPP, preprocesa sus propios pragms C y directivas Fortran para generar el código fuente del acelerador nativo, CUDA de NVIDIA o CAL de AMD. El código fuente del acelerador está contenido en un «codelet», que el desarrollador puede modificar posteriormente para una mayor optimización. Luego, el codelet se pasa a la cadena de herramientas del proveedor de GPU para crear el objeto binario, que se carga en la GPU. El código de CPU dejado atrás se compila con herramientas de compilación x86 de terceros, y el tiempo de ejecución de HMPP pega el código de CPU y GPU juntos.

La sintaxis general de los pragmas y directivas de HMPP es casi idéntica a las versiones de PGI: #pragma hmpp [, ]* [&] para C y! $ hmpp [, ]* [&] para Fortran.

Los pragms / directivas de CAPS fueron diseñados para un control de bajo nivel de la GPU con el fin de permitir al desarrollador optimizar operaciones como transferencias de datos, ejecución síncrona / asincrónica, precarga de datos y administración de dispositivos. PGI también ha definido algunas directivas de nivel inferior. (Consulte el Libro blanco del acelerador de PGI en http://www.pgroup.com/lit/pgi_whitepaper_accpre.pdf para más detalles.)

CAPS actualmente admite todas las GPU habilitadas para NVIDIA CUDA y hardware AMD FireStream y planea lanzar una versión compatible con Cell en el primer trimestre de 2009. La compañía también está trabajando en el soporte para Java, que se espera que se lance aproximadamente al mismo tiempo. . CAPS ya tiene varios clientes que utilizan la herramienta para clústeres equipados con GPU. Total, una multinacional de energía con sede en Francia, está utilizando HMPP para acelerar los cálculos de RTM en una máquina basada en Xeon conectada a un Tesla S1070 de 4 GPU. Los resultados iniciales demostraron velocidades de 3.3x por GPU en comparación con los 8 núcleos Xeon.

Puedes compartir en tu Facebook para que tus amigos lo consulten

??? ? ? ???

Comparte