Historia de dos modelos de Computación GPU - Calendae | Informática, Electrónica, CMS, Ciberseguridad

Historia de dos modelos de Computación GPU

Hola y mil gracias por leerme. Soy Simón Sánchez y hoy hablaremos sobre Historia de dos modelos de Computación GPU

Hubo mucha computación GPU en el flujo de noticias de HPC esta semana, pero me centraré en dos anuncios, ya que están algo en desacuerdo entre sí, pero no del todo.

El primero es el gran anuncio de Cray de su super XK6 equipado con Tesla. La compañía ha estado hablando de este sistema durante un tiempo y finalmente tuvo la oportunidad de revelar detalles al respecto gracias al lanzamiento de NVIDIA de la tecnología Fermi GPU de segunda generación la semana pasada.

Sin embargo, el sistema no es su grupo de GPU de jardín. La cuchilla XK6 es una variante del XE6 y, al igual que su hermano, que solo tiene CPU, está diseñada para encajar bien en el territorio de múltiples petaflop. Un solo estante proporcionará aproximadamente 70 teraflops. La hoja en realidad usará el X2090, una variante de factor de forma compacto de la nueva pieza M2090, pero las agallas son supuestamente idénticas.

Cray, sin embargo, apunta a su entorno de software como la tecnología que hace que el XK6 sea realmente especial. Aunque el CUDA SDK de NVIDIA viene de serie con todos los sistemas, Cray también está desarrollando su propio compilador de GPU para C y Fortran, basado en las extensiones OpenMP para aceleradores. Su compilador todavía está en un estado de preproducción, pero Cray lo distribuirá a clientes selectos para patear los neumáticos.

La idea es proporcionar a los programadores un entorno de lenguaje basado en pautas estándar para la computación GPU. Dado que el desarrollador solo necesita ingresar las directivas para decirle al compilador qué fragmentos se van a convertir en GPU, es mucho más fácil convertir códigos de CPU existentes que hacer un puerto CUDA. La fuente mejorada de la directiva resultante se puede trasladar a otras plataformas de aceleración, asumiendo que también son compatibles con las extensiones de acelerador OpenMP. O las directivas se pueden eliminar si todo lo que tiene es una plataforma de CPU estándar.

Cray también es compatible con el compilador compatible con GPU de PGI, que también se basa en directivas, pero no es un estándar abierto como OpenMP. Las empresas PGI y CAPS (que tienen sus propias pautas HMPP para la computación GPU) obviamente podrían adoptar las directivas del acelerador OpenMP, y sin duda lo harían si esa versión se convirtiera en la elección de los desarrolladores. Dado que OpenMP tiene muchos seguidores en la comunidad HPC, no me sorprendería que los desarrolladores opten por esta solución en particular.

Además, dado que tanto PGI como CAPS están en la junta directiva de OpenMP, me atrevo a decir que habrá una reunión de mentes sobre las directivas del acelerador en un futuro no muy lejano. Por cierto, Intel también está en la placa, por lo que es concebible que la aceleración OpenMP también sea compatible con el próximo procesador MIC de Knights Ferry.

La única advertencia para un enfoque basado en directivas para la programación de GPU es el rendimiento. Algo como CUDA u OpenCL puede acercarse mucho al silicio y, por lo tanto, ofrecer un mejor rendimiento si sabe lo que está haciendo. El problema es que muchos desarrolladores no saben lo que están haciendo -como ex ingeniero de software, lo digo sin sonrojarme- y, en cualquier caso, preferirían no tener que preocuparse por los detalles esenciales de la programación de la GPU. Además, por las razones mencionadas anteriormente, la creación de códigos de GPU en un entorno de lenguaje de alto nivel independiente del hardware conlleva importantes beneficios.

Cray ya está optimizando el rendimiento de su compilador de GPU basado en OpenMP. Con su conocimiento de todo sobre el transportista, espero que eventualmente lleguen a un lugar feliz en términos de desempeño. Por supuesto, si un modelo de programación de este tipo puede reducir el tiempo de desarrollo en unos pocos meses o incluso unas semanas, tiene muchos más ciclos con los que jugar simplemente porque tiene un programa de trabajo en la mano.

La segunda noticia de GPU de alto perfil de esta semana involucró un puerto GPU exitoso de un algoritmo de aprendizaje automático del Pittsburgh Supercomputing Center (PSC) y HP Labs. En este caso, lo que quiero decir con éxito es que los investigadores lograron una velocidad de algoritmo 10 veces más rápida utilizando CUDA y un sistema basado en GPU NVIDIA, en comparación con el código equivalente dirigido a un clúster de CPU. El sistema constaba de tres nodos, con tres GPU y dos CPU por nodo. MPI se utilizó para conversaciones de nodo a nodo.

El algoritmo en cuestión, llamado agrupamiento de k-medias, se usa en el aprendizaje automático para descubrir patrones o asociaciones dentro de grandes conjuntos de datos. En este caso, utilizaron el conjunto de datos «Books N-gram» de Google para agrupar todos los conjuntos de cinco palabras de las mil palabras más utilizadas que aparecen en todos los libros publicados en 2005. Con su implementación de GPU, los investigadores pudieron agrupar todo el conjunto de datos (15 millones de puntos de datos y 1000 dimensiones) en menos de nueve segundos.

Si bien esa aplicación en particular puede no ser la más útil jamás inventada, el aprendizaje automático ocupa un lugar importante en el análisis de datos en general. Esto incluye una gran cantidad de trabajo informático de tipo HPC: genómica, proteómica, etc. También existe el equivalente en humanidades, llamado culturomics, que es esencialmente el análisis de conjuntos de datos que tienen que ver con culturas humanas. Básicamente, cualquier aplicación que realice correlaciones de datos en grandes conjuntos de datos puede utilizar este método.

La versión CUDA de este algoritmo de aprendizaje automático no solo superó la implementación de la CPU (C directa) en un factor de 10, sino que fue 1000 veces más rápida que una implementación de lenguaje de alto nivel no especificada utilizada en la investigación informática. aprendizaje automático.

Ren Wu, investigador principal del Centro de Investigación CUDA en HP Labs, desarrolló el código de agrupación en clústeres k-means para las GPU utilizadas por PSC. En el anuncio tenía muchas cosas buenas que decir sobre CUDA:

“Creo que el modelo de programación CUDA es un marco muy agradable, bien equilibrado en abstracción y expresión de poder, fácil de aprender pero con suficiente control para diseñadores de algoritmos avanzados y respaldado por hardware con un rendimiento excepcional (en comparación con otras alternativas). La clave de cualquier algoritmo de alto rendimiento en la arquitectura moderna de varios núcleos es minimizar el movimiento de datos y optimizar la jerarquía de la memoria. Con esto en mente, CUDA es más fácil, si no más fácil, que cualquier otra alternativa «.

Es discutible si Wu podría haber obtenido un rendimiento similar de una implementación de programación de acelerador OpenMP o algo similar. Claramente, habrá situaciones en las que se justifique el uso de CUDA (u OpenCL). Esto será especialmente cierto para las rutinas / algoritmos de biblioteca utilizados en una amplia variedad de aplicaciones y cuya velocidad es fundamental para el rendimiento de la aplicación. Para algoritmos de datos locales paralelos para aplicaciones específicas, un enfoque de nivel superior puede ser el camino a seguir.

Ciertamente hemos estado aquí antes con código ensamblador y lenguajes de alto nivel. Ambos han establecido su lugar en el desarrollo de software. Del mismo modo, veremos que los marcos de programación de GPU de alto y bajo nivel avanzan juntos y dependerá del programador saber cuándo aplicarlos.

Recuerda compartir en en tu Twitter y Facebook para que tus amigos lo lean

??? ? ? ???

Comparte