NVIDIA hace agujeros en la historia Manycore de Intel - Calendae | Informática, Electrónica, CMS, Ciberseguridad

NVIDIA hace agujeros en la historia Manycore de Intel

Hola de nuevo. Te escribe Simón Sánchez y esta vez te voy a contar sobre NVIDIA hace agujeros en la historia Manycore de Intel

Mientras la próxima GPU Tesla de grado Kepler de NVIDIA se prepara para luchar con el Knight Corner de Intel, las empresas están ocupadas formulando sus respectivas historias de aceleradores HPC. Si bien NVIDIA ha disfrutado del beneficio de tener productos de campo de los que hablar, Intel ha logrado captar la atención de algunos cuidadores al garantizar una alta programabilidad, recompilaciones simples y escalabilidad transparente para sus coprocesadores Many Integrated Core (MIC). . Pero según Steve Scott de NVIDIA, tales promesas ignoran ciertas verdades duras sobre cómo funciona realmente la computación basada en aceleradores.

Durante los últimos dos años, Intel ha dicho a los aspirantes a usuarios de MIC que su próximo coprocesador Knights Corner ofrecerá el rendimiento de una GPU sin los desafíos de tener que adoptar un nuevo modelo de programación: CUDA OpenCL o lo que sea. Y debido a que la arquitectura MIC está basada en x86 (esencialmente núcleos Pentium simples pegados a unidades vectoriales extra anchas), desarrollar aplicaciones Knights Corner no será tan diferente de programar una CPU Xeon multinúcleo.

Aprovechando esta característica común, Intel afirma que su compilador podrá generar ejecutables MIC a partir del código fuente HPC heredado. Y lo hará para aplicaciones basadas en MPI y OpenMP, los dos marcos de programación paralela más populares utilizados en la informática de alto rendimiento. Esencialmente, Intel promete un puerto gratuito para MIC.

No tan rápido, dice Scott, el ex alumno de Cray que se unió a NVIDIA el año pasado, su director de tecnología del negocio Tesla. Según él, portar aplicaciones a MIC, o incluso desarrollar nuevas aplicaciones, no será más fácil que programar GPU, o para el caso, cualquier acelerador. en un Blog publicado el martes, describió los problemas con la narrativa de muchos núcleos de Intel y sus afirmaciones de superioridad sobre la computación GPU.

Scott no está discutiendo contra el MIC como un acelerador, per se. Él y la mayoría de la comunidad están convencidos de que HPC necesita computación híbrida (o heterogénea) para mejorar el rendimiento sin consumir cantidades excesivas de energía. Las CPU tradicionales, cuyos núcleos están optimizados para un rendimiento de un solo subproceso, no están diseñadas para trabajos que requieran un alto rendimiento. Para ese tipo de procesamiento, se puede lograr una eficiencia energética mucho mejor utilizando núcleos más simples, más lentos pero más numerosos. Tanto las GPU como las MIC se adhieren a este paradigma; llegan al problema desde diferentes genealogías arquitectónicas.

El problema es que la ejecución del código de rendimiento en un procesador en serie consume demasiada energía, que es la situación que enfrentan muchos usuarios en la actualidad con CPU convencionales. Por el contrario, ejecutar código en serie en un procesador de rendimiento es demasiado lento y anula el propósito de tener un acelerador en primer lugar.

Si bien el bajo rendimiento de un solo subproceso no fue un problema, los aceleradores de hoy viven en tarjetas PCIe con cantidades limitadas de memoria (generalmente solo un puñado de gigabytes) que existen al final de un bus PCIe. Entonces, si toda la aplicación se ejecutara en el acelerador, todos sus datos e instrucciones tendrían que transferirse desde la memoria principal en trozos. Tenga en cuenta que hoy, con solo una parte de la aplicación viviendo en la GPU, el cuello de botella PCIe aún puede obstaculizar el rendimiento. Llenar todo el calendario en el acelerador empeoraría las cosas.

Entonces, la razón principal de la crítica de Scott es que para que la computación híbrida funcione, es necesario dividir inteligentemente la aplicación entre el host de la CPU y el acelerador. Eso es cierto, dice, ya sea que se trate de un acelerador basado en x86 como MIC o uno basado en gráficos como Tesla. «Todo el juego es ahora cómo ofrecemos rendimiento de la manera más eficiente posible», dijo a Calendae.

Intel ha revelado muy poco sobre el rendimiento de las aplicaciones en futuras partes de MIC y no ha abordado realmente cómo funcionará la división de aplicaciones de manera programática, o incluso si es necesario. Hasta la fecha, ellos y algunos de los primeros en adoptar MIC han hablado principalmente de recompilar código existente, basado en OpenMP y / o MPI, y ejecutar el ejecutable resultante de forma nativa en MIC.

Ejecutar código MPI en una arquitectura de muchos núcleos es particularmente problemático. Primero está el problema de la capacidad de memoria mencionado anteriormente (cada proceso MPI usa muchos datos). Y luego está el hecho de que una vez que el número de procesos MPI excede el número de núcleos del acelerador, más de 50 para Knights Corner, la aplicación debe usar la NIC del nodo del servidor para comunicarse con los procesos MPI. ejecutándose en otros nodos. Como señala Scott en su blog, hay demasiados procesos MPI para una interfaz de red típica; toda la contienda abrumaría el ancho de banda disponible.

OpenMP tiene el problema opuesto, ya que la mayoría de los programas que utilizan este modelo no escalan más allá de 4 a 8 tareas. Como resultado, la mayoría de las aplicaciones OpenMP no tendrían forma de utilizar los 50 núcleos esperados en los nodos equipados con Knights Corner. Y una vez más está el problema de la capacidad de memoria. Al igual que MPI, OpenMP espera vivir en las ranuras relativamente espaciosas de la memoria principal de la CPU.

Scott dice que si va a utilizar un compilador para transformar su aplicación existente para que se ejecute en el MIC, no está haciendo el cálculo híbrido en absoluto. Más importante aún, ejecutar todo el código en el acelerador no tiene en cuenta el rendimiento. Después de todo, la idea es acelerar la aplicación, no solo recompilarla para que funcione de manera funcional. «No creemos que sea legítimo hablar de facilidad de programación sin hablar de rendimiento», dice.

Scott sostiene que para que las aplicaciones aprovechen estos nuevos procesadores de rendimiento, los programadores deberán profundizar en una especie de modelo de programación híbrido que separe el código de rendimiento paralelo del código en serie. Para las GPU NVIDIA, el paralelismo se puede exponer con CUDA o con el conjunto emergente de directivas similares a OpenMP para aceleradores, conocido como OpenACC. Ya existe un puerto CUDA inicial para x86 desarrollado por PGI, por lo que esta es una opción. Pero es probable que el marco OpenACC llegue a una audiencia más amplia de desarrolladores, ya que ofrece un mayor nivel de abstracción que CUDA y parece que eventualmente se incorporará a la API OpenMP estándar de la industria.

La idea es que los programadores puedan usar OpenACC hoy para desarrollar aplicaciones aceleradas por GPU con la anticipación de poder usar el mismo código para otras plataformas de hardware basadas en aceleradores, como AMD’s MIC y Fusion o procesadores de GPU discretos. Intel y AMD aún no se han subido al carro de OpenACC, pero si se adoptara como estándar y sus clientes lo exigieran, ciertamente deberían admitirlo.

Sin embargo, OpenACC tampoco es una fórmula mágica. El programador todavía tiene que sumergirse en el código fuente y decirle al compilador dónde y cómo recortar el código paralelo para el acelerador. Y como admite Scott, esto puede suponer un esfuerzo significativo, especialmente para grandes aplicaciones HPC heredadas escritas para máquinas homogéneas solo con CPU.

Pero, argumenta, si está interesado en aprovechar el rendimiento que ofrecen los procesadores de rendimiento como GPU y MIC, el trabajo debe estar hecho. Es probable que los relojes de los procesadores no sean más rápidos de lo que son hoy. Entonces, la única forma de aumentar el rendimiento es mediante el paralelismo. Como dice Scott, «las computadoras no son cada vez más rápidas, solo se hacen más grandes».

Artículos relacionados

La jungla de la programación heterogénea

NVIDIA apunta a la era de la informática GPU posterior a CUDA

Intel promociona el coprocesador Manycore en la conferencia de supercomputación

Recuerda compartir en tus redes sociales para que tus colegas opinen

??? ? ? ???

Comparte