Diez formas de engañar a las masas al ofrecer resultados de rendimiento de GPU - Calendae | Informática, Electrónica, CMS, Ciberseguridad

Diez formas de engañar a las masas al ofrecer resultados de rendimiento de GPU

Hola otra vez. Yo soy Simón Sánchez y hoy vamos a hablar sobre Diez formas de engañar a las masas al ofrecer resultados de rendimiento de GPU

El potencial de rendimiento de la informática con GPU ha generado un entusiasmo considerable en la comunidad de HPC. Sin embargo, como fue el caso con la llegada de la computación paralela hace décadas, la tecnología naciente no beneficia por igual a todas las aplicaciones, ni siquiera a todos los componentes de una sola aplicación. Desafortunadamente, los modestos aumentos de velocidad de la aceleración de la GPU rara vez son dignos de publicación, un hecho que a veces lleva a los fanáticos de la GPU a adoptar técnicas científicamente dudosas para aumentar artificialmente la ventaja de rendimiento de la computación GPU a niveles más impresionantes.

En este renacimiento moderno de la relación clásica de David Bailey, «Doce formas de engañar a las masas al ofrecer resultados de rendimiento en equipos paralelos, «Presento diez formas de negligencia experimental que he encontrado repetidamente en publicaciones científicas, que pueden usarse para hacer que los principiantes de GPU (y los líderes puntiagudos) crean que las GPU pueden mejorar mágicamente el rendimiento de cualquier aplicación de múltiples órdenes. Con esta lista como su vademécum, los lectores aprenderán a ser escépticos ante las afirmaciones exageradas sobre el rendimiento de la GPU.

¿Está listo para mejorar los resultados de rendimiento de la GPU informados sin aumentar el rendimiento real de la GPU? Sigue leyendo …

1. Informe los resultados de rendimiento con aritmética de coma flotante de 32 bits únicamente, no aritmética de 64 bits.

Las GPU obtienen el doble de rendimiento cuando se utiliza aritmética de precisión simple. ¿Quién necesita más de ocho lugares decimales de precisión, de todos modos? No hace falta decir que la versión de CPU del código con el que está comparando solo debería usar aritmética de 64 bits porque, bueno, así es como la gente escribe el código de la CPU (aunque las CPU también duplican su tasa de flop cuando usan l Aritmética SIMD de 32 bits).

2. No programe el movimiento de datos ni la sobrecarga de invocación del kernel.

Copiar datos entre la memoria de la CPU y la memoria de la GPU es lento y reduce la cantidad de rendimiento de la GPU que puede reclamar. Por lo tanto, para que sus GPU se vean bien, asegúrese de iniciar el reloj después de que todos los datos del programa ya se hayan transferido a la memoria de la GPU y el kernel ya se haya iniciado y detenga el reloj antes. los resultados se vuelven a copiar en la memoria de la CPU. Hay dos corolarios de esta regla:

Corolario 1: Nunca, nunca informe el rendimiento de una aplicación que se ejecuta en más de un nodo acelerado por GPU. Esto requiere todo tipo de comunicación manejada por la CPU, y * esto * requiere movimiento de datos y llamadas de kernel adicionales – malo para números más rápidos.

Corolario 2: Informe siempre el rendimiento de los núcleos individuales, no las aplicaciones completas. Esto es especialmente cierto para aplicaciones que contienen subrutinas que son importantes pero difíciles de acelerar.

3. Indique el costo y la ubicuidad de la GPU para componentes de gama baja. Mida el rendimiento en componentes de alta gama.

Aquí hay un texto que puede adaptar según sea necesario: «Las GPU son una plataforma importante para lograr porque cuestan menos de $ 100 y son estándar en todos los sistemas informáticos modernos. Para nuestros experimentos, medimos el rendimiento en una NVIDIA Tesla M2090 … «

4. Especifique el ancho de banda de la memoria hacia / desde la memoria GPU integrada únicamente, no hacia / desde la memoria principal.

Impresione a su audiencia con la capacidad de su GPU de gama alta para realizar transferencias de memoria a 177 GB / s. Siempre que nunca necesite memorizar, transferir o usar el resultado de sus cálculos, es un número perfectamente honesto para citar.

5. Desactive las comprobaciones de memoria ECC.

Las GPU se ejecutan más rápido y brindan más capacidad de memoria utilizable cuando no tienen que esforzarse tanto para producir datos correctos. Además, ¿qué kernel de GPU funciona lo suficiente como para que esto sea un problema?

6. Compare el rendimiento de GPU completo (o incluso múltiple) con un solo núcleo de CPU.

Siempre compare lo que comenzó con (un programa de CPU secuencial) con lo que terminó produciendo (un programa de GPU paralelo). Un aumento de 10 veces en el código de la GPU sobre el código de la CPU ciertamente se ve mucho más impresionante si olvida mencionar que su sistema host contiene dos sockets de CPU de ocho núcleos, que * podría * haber usado en su lugar.

7. Compare el código de GPU altamente optimizado con el código de CPU no optimizado.

Por supuesto, se ha asegurado de que el código de su GPU se ejecute lo más rápido posible al reestructurarlo para aprovechar el paralelismo de datos, la ubicación de la memoria y otras características del programa compatible con GPU. Ahora asegúrese de compararlo solo con el código original e ingenuo de la CPU, no con una versión que aproveche las instrucciones de la CPU SIMD, bloquee correctamente la caché, alinee de manera óptima las estructuras de datos o incluya cualquiera de las otras optimizaciones de rendimiento que usan los programadores. A las CPU rara vez les importa. Definitivamente no respalde los cambios de GPU a la CPU, o el aumento de velocidad informado será decepcionantemente menor.

8. Cambie el tamaño del problema para que se ajuste a la memoria de la GPU.

Esta recomendación va en ambos sentidos. Si su GPU tiene 6 GB de memoria integrada y el tamaño del problema de la aplicación es mayor que eso, reduzca la escala a 6 GB para evitar todas las sincronizaciones costosas y el desorden de almacenamiento doble que conduce a grandes problemas. Si su GPU tiene 6 GB de memoria integrada y el tamaño del problema de la aplicación es significativamente menor, escale el tamaño del problema, incluso más allá de los límites significativos, para que pueda aprovechar los beneficios de rendimiento de un mayor paralelismo. algunos datos. La siguiente recomendación desarrolla más este punto:

9. Sacrifique valores numéricos significativos por el rendimiento de la GPU.

Las GPU son reconocidas por su rendimiento computacional. Sin embargo, lograr el máximo rendimiento requiere la amortización de ese desagradable costo inicial de mover núcleos y datos a la GPU. Entonces, para demostrar un buen rendimiento de la GPU, ejecute siempre muchas más iteraciones de las típicas, necesarias, prácticas o incluso significativas para el uso en el mundo real, ¡maldita sea!

10. Seleccione los algoritmos que favorezcan a las GPU.

Los mejores algoritmos de CPU a menudo no crean los mejores algoritmos de GPU y viceversa. En consecuencia, siempre debe tomar el algoritmo que funcione mejor en la GPU y compararlo con una versión de la CPU. Lo bueno de este enfoque en comparación con la comparación del rendimiento del mejor algoritmo de CPU con el del mejor algoritmo de GPU es que conduce a una comparación «justa». Después de todo, ejecutó el mismo algoritmo en ambos sistemas, ¿verdad?

Pensamientos de separacion

La buena noticia es que los avances en la tecnología GPU están aliviando algunos de los costos que el engaño anterior intenta ocultar. Si bien algunas partes de mi lista pronto pueden parecer anacrónicas, todavía debería haber suficiente ambigüedad para satisfacer incluso al fanático de la GPU más exigente.

Como comentario final, en gran parte sin relación alguna, ¿podemos eliminar el sustantivo oxímoron «GPGPU» de nuestro léxico colectivo? Si un procesador se especializa en el procesamiento de gráficos, no es realmente un dispositivo genérico, ¿verdad?

Otras lecturas

[Bai91] David H. Bailey. «Perspectiva altamente paralela: Doce formas de engañar a las masas al ofrecer resultados de rendimiento en computadoras paralelas» Supercomputing Review, 4 (8): 54-55, agosto de 1991. ISSN: 1048-6836. También aparece como Informe técnico de NASA Ames RNR RNR-91-020.

[BBR10] Rajesh Bordawekar, Uday Bondhugula y Ravi Rao. «¿Pueden las CPU igualar a las GPU en rendimiento y productividad?: Experiencias con la optimización de una aplicación intensiva de FLOP en CPU y GPU». Informe técnico RC25033 del IBM TJ Watson Research Center (W1008-020). 5 de agosto de 2010.

[LKC+10] Victor W. Lee, Changkyu Kim, Jatin Chhugani, Michael Deisher, Daehyun Kim, Anthony D. Nguyen, Nadathur Satish, Mikhail Smelyanskiy, Srinivas Chennupaty, Per Hammarlund, Ronak Singhal y Pradeep Dubey. «Debunking the Myth of the 100X GPU vs. the CPU: An Assessment of CPU and GPU Computing Throughput», Actas del 37º Simposio Internacional Anual sobre Arquitectura de Computadoras (ISCA 2010), Saint-Malo, Francia, 19-23 de junio de 2010. ISBN: 978-1-4503-0053-7, DOI: 10.1145 / 1815961.1816021.

No te olvides compartir en tu Facebook para que tus amigos opinen

??? ? ? ???

Comparte