FT-BLAS: Rendimiento y Tolerancia a Fallos

Para comprobar qué tan bien funciona nuestra nueva versión de BLAS (llamada FT-BLAS), la comparamos con tres bibliotecas conocidas: Intel oneMKL, OpenBLAS y BLIS. Hicimos estas pruebas en varias computadoras, incluyendo un procesador Intel Gold 5122 Skylake a 3.60 GHz con 96 GB de RAM y un procesador Intel Xeon W-2255 Cascade a 3.70 GHz con 32 GB de RAM. También probamos FT-BLAS en un procesador AMD Ryzen7 3700X, que corre a 3.60 GHz con 32 GB de RAM.

Repetimos cada prueba veinte veces y calculamos los resultados promedio. Para operaciones simples (Level-1), promediamos el rendimiento con diferentes tamaños de arreglos. Para operaciones más complejas (Level-2 y Level-3), promediamos con diferentes tamaños de matrices. Usamos el compilador icc 19.0 con una bandera de optimización establecida en -O3.

#Rendimiento de FT-BLAS sin Tolerancia a Fallos

Antes de agregar características de tolerancia a fallos, FT-BLAS proporciona una nueva implementación de BLAS que es igual de buena o incluso más rápida que las bibliotecas actuales. Llamamos a esta versión FT-BLAS: Ori.

#Mejora del BLAS Level-1

Las operaciones BLAS Level-1 a menudo están limitadas por la velocidad de la memoria. Para hacerlas más rápidas, utilizamos tres estrategias principales: 1) usar conjuntos de instrucciones avanzadas para procesamiento paralelo, 2) desenrollar bucles para un mejor rendimiento y 3) prefetching de datos para mejorar el acceso a la memoria. Nuestros tests muestran que OpenBLAS no optimizó algunas rutinas bien, como DSCAL y DNRM2. Al agregar prefetching a DSCAL, logramos mejoras de velocidad sobre OpenBLAS y BLIS. Para DNRM2, que OpenBLAS solo soporta con instrucciones más antiguas, nuestra versión actualizada proporcionó mejoras significativas en rendimiento. En general, nuestras optimizaciones nos permitieron igualar o superar el rendimiento del MKL de Intel.

#Mejora del BLAS Level-2

Para las rutinas BLAS Level-2, nos enfocamos en reutilizar datos para hacerlas más rápidas. Siguiendo nuestras estrategias, nuestra operación DGEMV superó a OpenBLAS y BLIS. A diferencia de OpenBLAS, que utiliza un enfoque similar, nuestra versión de DGEMV mostró mejor eficiencia. De igual manera, para DTRSV, descubrimos que usar la rutina Level-2 más rápida (DGEMV) nos ayudó a superar a todas las otras bibliotecas.

#Mejora del BLAS Level-3

En el caso del BLAS Level-3, particularmente DGEMM, aplicamos métodos tradicionales de caching y empaquetado de datos. Nuestra implementación de DGEMM tuvo un rendimiento similar al de OpenBLAS, pero logró superar tanto a MKL como a BLIS. Para DTRSM, creamos una rutina altamente optimizada que mejoró significativamente el rendimiento en comparación con OpenBLAS y BLIS, con una pequeña ventaja sobre MKL.

#Rendimiento de FT-BLAS con Capacidad de Tolerancia a Fallos

Después de establecer un rendimiento sólido sin tolerancia a fallos, introdujimos características para manejar Errores. Para las rutinas Level-1 y Level-2, creamos un nuevo método de verificación que minimizó el impacto de la tolerancia a fallos en la velocidad. Para las rutinas Level-3, combinamos la verificación de errores con nuestros cálculos regulares, lo que limitó la necesidad de movimiento de datos extra y mantuvo un alto rendimiento.

#Optimización de DSCAL Con y Sin Tolerancia a Fallos

Evaluamos la eficiencia y el impacto de nuestros métodos de tolerancia a fallos en DSCAL. Comenzamos con una versión simple, que tenía bajo rendimiento. Al aplicar optimizaciones gradualmente, reducimos la pérdida de rendimiento debido a las características de tolerancia a fallos. La versión mejorada mostró una velocidad considerable, particularmente cuando añadimos técnicas más avanzadas como desenrollado de bucles y prefetching. Al final de este proceso, nuestra versión sin tolerancia a fallos igualó el rendimiento de OpenBLAS.

#Optimización de DGEMM con Tolerancia a Fallos

Comparamos dos enfoques para integrar la tolerancia a fallos en la operación DGEMM: mejorar el MKL existente y fusionar nuestras verificaciones directamente en el cálculo. La versión basada en MKL mostró mayor sobrecarga cuando se inyectaron errores, mientras que el método fusionado tuvo un impacto mucho menor. Este enfoque significó que podíamos manejar errores sin desaceleraciones significativas.

#Comparación General de Rendimiento

Nuestras comparaciones mostraron que la versión FT-BLAS con capacidad de tolerancia a fallos aún tenía un buen rendimiento. La sobrecarga adicional para rutinas limitadas por memoria fue menor, con la mayoría quedando por debajo del 3%. Para las rutinas Level-3, mantuvimos una sobrecarga baja similar en diferentes implementaciones. En general, nuestro FT-BLAS siguió siendo competitivo, si no más rápido que, las principales bibliotecas.

#Pruebas en Procesador Intel Cascade Lake

Las pruebas de FT-BLAS en un procesador Intel Cascade Lake mostraron un rendimiento consistente, similar a las pruebas en el procesador Skylake. La sobrecarga adicional para rutinas limitadas por memoria fue mínima. Las estrategias fusionadas funcionaron genial, manteniendo el rendimiento competitivo en comparación con bibliotecas conocidas.

#Habilitando Soporte Paralelo

Después de habilitar el soporte para procesamiento paralelo, encontramos que las rutinas Level-1 y Level-2 mantuvieron su baja sobrecarga, similar a las implementaciones de hilo único. Notablemente, OpenBLAS no soporta procesamiento paralelo para todas las rutinas, y esta limitación significa que nuestro diseño paralelo puede superarlo.

#Extendiendo a Procesadores AMD

También probamos nuestras rutinas en un procesador AMD R7 3700X. Dado que este procesador tiene menos registros disponibles, decidimos realizar solo detección de errores para rutinas más simples. Los resultados confirmaron que nuestros métodos de tolerancia a fallos aún funcionaron bien, con muy poca sobrecarga en comparación con las bibliotecas existentes.

#Experimentos de Inyección de Errores

Para validar aún más nuestras características de tolerancia a fallos, introdujimos errores directamente en nuestros procesos de cálculo y verificamos resultados contra MKL. Al inyectar errores a nivel de código, buscamos minimizar cualquier impacto en el rendimiento. Inyectamos 20 errores en cada rutina, y para nuestras rutinas Level-3, este proceso fue sencillo. Pudimos modificar fácilmente elementos de matrices en puntos específicos.

Para las rutinas Level-1 y Level-2, donde se utilizó código ensamblador, la inyección de errores requirió métodos más intrincados. Desarrollamos un mecanismo para introducir fallos y también comparar resultados para identificar errores. La recuperación involucró recomputar rápidamente las secciones defectuosas.

#Rendimiento Bajo Inyección de Errores en Skylake

Nuestras pruebas mostraron que incluso bajo condiciones de inyección de errores, FT-BLAS mantuvo un rendimiento sólido con mínima sobrecarga. En todos los casos, nuestras rutinas superaron a las bibliotecas existentes, confirmando que los métodos de tolerancia a fallos tienen un impacto limitado en la velocidad.

#Rendimiento Bajo Inyección de Errores en Cascade Lake

En el procesador Cascade Lake, nuestra estrategia de tolerancia a fallos funcionó igual de bien, superando a otras bibliotecas incluso bajo inyección de errores. El tiempo tomado para diferentes tamaños de matriz confirmó que FT-BLAS podía tolerar eficientemente muchos errores sin afectar significativamente el rendimiento.

#Rendimiento Paralelo Bajo Inyección de Errores en Cascade Lake

Cuando se paralelizó, nuestra rutina DGEMV aún superó a OpenBLAS y MKL, incluso bajo condiciones de error. Nuestro DGEMV optimizado para FT fue significativamente más rápido que el BLIS no multihilo, confirmando que nuestras técnicas escalan bien incluso con complejidades añadidas.

#Rendimiento Bajo Inyección de Errores en AMD Zen2

Finalmente, examinamos el rendimiento de FT-BLAS bajo inyección de errores en el procesador AMD Zen2 Ryzen. Descubrimos que el rendimiento general se mantuvo competitivo con las principales bibliotecas, incluso bajo condiciones de error. Esto confirmó que nuestros métodos funcionan bien en diversas plataformas de hardware.