FT-BLAS: Leistung und Fehlerresistenz

Um zu checken, wie gut unsere neue Version von BLAS (FT-BLAS genannt) ist, vergleichen wir sie mit drei bekannten Bibliotheken: Intel oneMKL, OpenBLAS und BLIS. Die Tests wurden auf mehreren Computern durchgeführt, darunter ein Intel Gold 5122 Skylake Prozessor mit 3,60 GHz und 96 GB RAM sowie ein Intel Xeon W-2255 Cascade Prozessor mit 3,70 GHz und 32 GB RAM. Ausserdem haben wir FT-BLAS auf einem AMD Ryzen7 3700X Prozessor getestet, der mit 3,60 GHz und 32 GB RAM läuft.

Wir haben jeden Test zwanzig Mal wiederholt und die durchschnittlichen Ergebnisse berechnet. Bei einfachen Operationen (Level-1) haben wir die Leistung über verschiedene Array-Grössen gemittelt. Für komplexere Operationen (Level-2 und Level-3) haben wir über verschiedene Matrix-Grössen gemittelt. Wir haben den icc 19.0 Compiler mit dem Optimierungsflag -O3 verwendet.

#Leistung von FT-BLAS ohne Fehlertoleranz

Bevor wir Fehlertoleranz-Funktionen hinzugefügt haben, bietet FT-BLAS eine neue BLAS-Implementierung, die genauso gut oder sogar schneller ist als die aktuellen Bibliotheken. Wir nennen diese Version FT-BLAS: Ori.

#Verbesserung von Level-1 BLAS

Level-1 BLAS Operationen sind oft durch die Geschwindigkeit des Speichers limitiert. Um sie schneller zu machen, haben wir drei Hauptstrategien verwendet: 1) Nutzung von erweiterten Befehlssätzen für parallele Verarbeitung, 2) Schleifen-Unrolling für bessere Leistung und 3) Prefetching von Daten zur Verbesserung des Speicherzugriffs. Unsere Tests zeigen, dass OpenBLAS einige Routinen nicht gut optimiert hat, wie DSCAL und DNRM2. Durch das Hinzufügen von Prefetching zu DSCAL konnten wir die Geschwindigkeit im Vergleich zu OpenBLAS und BLIS verbessern. Für DNRM2, das OpenBLAS nur mit älteren Anweisungen unterstützt, brachte unsere aktualisierte Version signifikante Leistungsgewinne. Insgesamt ermöglichten unsere Optimierungen, die Leistung von Intels Closed-Source MKL zu erreichen oder zu übertreffen.

#Verbesserung von Level-2 BLAS

Bei Level-2 BLAS Routinen haben wir uns darauf konzentriert, Daten wiederzuverwenden, um sie schneller zu machen. Unsere DGEMV-Operation übertraf OpenBLAS und BLIS. Im Gegensatz zu OpenBLAS, das einen ähnlichen Ansatz verwendet, zeigte unsere Version von DGEMV eine bessere Effizienz. Ähnlich fanden wir bei DTRSV, dass die Nutzung der schnellsten Level-2 Routine (DGEMV) uns geholfen hat, alle anderen Bibliotheken zu übertreffen.

#Verbesserung von Level-3 BLAS

Bei Level-3 BLAS, insbesondere DGEMM, haben wir traditionelle Methoden zum Caching und Packen von Daten angewendet. Unsere DGEMM-Implementierung schnitt ähnlich ab wie OpenBLAS, übertraf jedoch sowohl MKL als auch BLIS. Für DTRSM haben wir eine hochoptimierte Routine erstellt, die die Leistung im Vergleich zu OpenBLAS und BLIS erheblich verbesserte, mit einem kleinen Vorteil gegenüber MKL.

#Leistung von FT-BLAS mit Fehlertoleranz

Nachdem wir eine starke Leistung ohne Fehlertoleranz festgestellt hatten, führten wir Funktionen zur Fehlerbehandlung ein. Für Level-1 und Level-2 Routinen haben wir eine neue Verifizierungsmethode entwickelt, die die Auswirkungen der Fehlertoleranz auf die Geschwindigkeit minimierte. Für Level-3 Routinen kombinierten wir Fehlerüberprüfung mit unseren regulären Berechnungen, was den Bedarf an zusätzlichem Datentransfer begrenzte und die Leistung hoch hielt.

#Optimierung von DSCAL mit und ohne Fehlertoleranz

Wir haben die Effizienz und die Auswirkungen unserer Fehlertoleranz-Methoden auf DSCAL bewertet. Zunächst hatten wir eine einfache Version, die wenig Leistung brachte. Durch schrittweises Anwenden von Optimierungen konnten wir den Leistungsabfall durch die fehlertoleranten Funktionen reduzieren. Die verbesserte Version zeigte beträchtliche Geschwindigkeit, insbesondere als wir fortschrittlichere Techniken wie Schleifen-Unrolling und Prefetching hinzufügten. Am Ende dieses Prozesses erreichte unsere nicht-fehlertolerante Version die Leistung von OpenBLAS.

#Optimierung von DGEMM mit Fehlertoleranz

Wir haben zwei Ansätze verglichen, um Fehlertoleranz in die DGEMM-Operation zu integrieren: die Verbesserung des bestehenden MKL und die direkte Fusion unserer Überprüfungen in die Berechnung. Die Version, die auf MKL basierte, zeigte höhere Overheads, wenn Fehler eingeschleust wurden, während die fusionierte Methode einen viel geringeren Einfluss hatte. Dieser Ansatz bedeutete, dass wir Fehler ohne signifikante Verzögerungen behandeln konnten.

#Allgemeiner Leistungsvergleich

Unsere Vergleiche zeigten, dass die FT-BLAS-Version mit Fehlertoleranz immer noch gut abschnitt. Der zusätzliche Overhead für speichergebundene Routinen war gering, wobei die meisten unter 3% blieben. Für Level-3 Routinen hielten wir den ähnlichen niedrigen Overhead über verschiedene Implementierungen aufrecht. Insgesamt blieb unsere FT-BLAS wettbewerbsfähig und war sogar schneller als führende Bibliotheken.

#Benchmarking auf Intel Cascade Lake Prozessor

Die Tests von FT-BLAS auf einem Intel Cascade Lake Prozessor zeigten, dass es durchweg gut abschnitt, ähnlich wie bei den Skylake Prozessoren. Der zusätzliche Overhead für speichergebundene Routinen war minimal. Die fusionierten Strategien funktionierten grossartig und hielten die Leistung im Vergleich zu bekannten Bibliotheken wettbewerbsfähig.

#Aktivierung der parallelen Unterstützung

Nachdem wir die Unterstützung für parallele Verarbeitung aktiviert hatten, stellten wir fest, dass Level-1 und Level-2 Routinen ihren niedrigen Overhead beibehielten, ähnlich wie bei Single-Thread-Implementierungen. Besonders bemerkenswert ist, dass OpenBLAS nicht alle Routinen für parallele Verarbeitung unterstützt, und diese Einschränkung bedeutet, dass unser paralleles Design besser abschneiden kann.

#Erweiterung auf AMD Prozessoren

Wir haben unsere Routinen auch auf einem AMD R7 3700X Prozessor getestet. Da dieser Prozessor weniger verfügbare Register hat, haben wir uns entschieden, nur Fehlererkennung für einfachere Routinen durchzuführen. Die Ergebnisse bestätigten, dass unsere Fehlertoleranz-Methoden immer noch gut funktionierten, mit sehr geringem Overhead im Vergleich zu bestehenden Bibliotheken.

#Fehlerinjektionsexperimente

Um unsere Fehlertoleranz-Funktionen weiter zu validieren, haben wir Fehler direkt in unsere Berechnungsprozesse eingeführt und die Ergebnisse mit MKL verglichen. Indem wir Fehler auf Code-Ebene injizierten, wollten wir jegliche Auswirkungen auf die Leistung minimieren. Wir injizierten 20 Fehler in jede Routine, und für unsere Level-3 Routinen war dieser Prozess einfach. Wir konnten die Matrix-Elemente an bestimmten Punkten problemlos ändern.

Für Level-1 und Level-2 Routinen, bei denen Assembler-Code verwendet wurde, war das Injizieren von Fehlern etwas komplizierter. Wir entwickelten einen Mechanismus, um Fehler einzuführen und auch Ergebnisse zu vergleichen, um Fehler zu identifizieren. Die Wiederherstellung bestand darin, die fehlerhaften Abschnitte schnell neu zu berechnen.

#Leistung unter Fehlerinjektion auf Skylake

Unsere Tests zeigten, dass FT-BLAS selbst unter Bedingungen der Fehlerinjektion starke Leistung mit minimalem Overhead aufrechterhielt. In jedem Fall übertrafen unsere Routinen die bestehenden Bibliotheken und bestätigten, dass die Fehlertoleranz-Methoden nur einen begrenzten Einfluss auf die Geschwindigkeit hatten.

#Leistung unter Fehlerinjektion auf Cascade Lake

Auf dem Cascade Lake Prozessor schnitt unsere Fehlertoleranz-Strategie ebenso gut ab und übertraf weiterhin andere Bibliotheken trotz Fehlerinjektion. Die benötigte Zeit für verschiedene Matrixgrössen bestätigte, dass FT-BLAS effizient viele Fehler tolerieren konnte, ohne die Leistung signifikant zu beeinträchtigen.

#Parallelleistung unter Fehlerinjektion auf Cascade Lake

Wenn unsere DGEMV-Routine parallelisiert wurde, übertraf sie weiterhin OpenBLAS und MKL, selbst unter Fehlerbedingungen. Unser FT-optimiertes DGEMV war deutlich schneller als das nicht-threaded BLIS, was bestätigte, dass unsere Techniken auch bei zusätzlicher Komplexität gut skalieren.

#Leistung unter Fehlerinjektion auf AMD Zen2

Schliesslich haben wir die Leistung von FT-BLAS unter Fehlerinjektion auf dem AMD Zen2 Ryzen Prozessor untersucht. Wir fanden heraus, dass die Gesamtleistung wettbewerbsfähig mit führenden Bibliotheken blieb, selbst unter Fehlerbedingungen. Das bestätigte, dass unsere Methoden auf verschiedenen Hardware-Plattformen gut funktionieren.