FT-BLAS : Performance et tolérance aux pannes

Pour voir comment notre nouvelle version de BLAS (appelée FT-BLAS) fonctionne, on l'a comparée à trois bibliothèques bien connues : Intel oneMKL, OpenBLAS et BLIS. Les tests ont été faits sur plusieurs ordinateurs, notamment un processeur Intel Gold 5122 Skylake à 3,60 GHz avec 96 Go de RAM, et un processeur Intel Xeon W-2255 Cascade à 3,70 GHz avec 32 Go de RAM. On a aussi testé FT-BLAS sur un processeur AMD Ryzen7 3700X qui tourne à 3,60 GHz avec 32 Go de RAM.

On a répété chaque test vingt fois et calculé les résultats moyens. Pour des opérations simples (Niveau-1), on a fait la moyenne des performances sur différentes tailles de tableaux. Pour les opérations plus complexes (Niveau-2 et Niveau-3), on a fait la moyenne sur différentes tailles de matrices. On a utilisé le compilateur icc 19.0 avec un drapeau d'optimisation à -O3.

#Performance de FT-BLAS Sans Tolérance aux Erreurs

Avant d'ajouter des fonctionnalités de tolérance aux erreurs, FT-BLAS propose une nouvelle implémentation de BLAS qui est tout aussi bonne, voire plus rapide que les bibliothèques actuelles. On appelle cette version FT-BLAS : Ori.

#Amélioration du BLAS de Niveau-1

Les opérations de BLAS de Niveau-1 sont souvent limitées par la vitesse de la mémoire. Pour les rendre plus rapides, on a utilisé trois stratégies principales : 1) utiliser des ensembles d'instructions avancées pour le traitement parallèle, 2) dérouler les boucles pour de meilleures performances, et 3) précharger les données pour améliorer l'accès à la mémoire. Nos tests montrent qu'OpenBLAS n'a pas bien optimisé certaines routines, comme DSCAL et DNRM2. En ajoutant le préchargement à DSCAL, on a réussi à obtenir des améliorations de vitesse par rapport à OpenBLAS et BLIS. Pour DNRM2, qu'OpenBLAS ne prend en charge qu'avec des instructions plus anciennes, notre version mise à jour a fourni des gains de performance significatifs. Dans l'ensemble, nos optimisations nous ont permis d'égaler ou de dépasser les performances de la MKL d'Intel.

#Amélioration du BLAS de Niveau-2

Pour les routines de BLAS de Niveau-2, on s'est concentré sur la réutilisation des données pour les rendre plus rapides. Suivant nos stratégies, notre opération DGEMV a dépassé OpenBLAS et BLIS. Contrairement à OpenBLAS, qui utilise une approche similaire, notre version de DGEMV a montré une meilleure efficacité. De même, pour DTRSV, on a découvert que l'utilisation de la routine de Niveau-2 la plus rapide (DGEMV) nous a aidés à surpasser toutes les autres bibliothèques.

#Amélioration du BLAS de Niveau-3

Dans le cas du BLAS de Niveau-3, en particulier DGEMM, on a appliqué des méthodes traditionnelles de mise en cache et de regroupement des données. Notre mise en œuvre de DGEMM a bien fonctionné, similaire à OpenBLAS, mais a réussi à surpasser MKL et BLIS. Pour DTRSM, on a créé une routine hautement optimisée qui a considérablement amélioré les performances par rapport à OpenBLAS et BLIS, avec un petit avantage sur MKL.

#Performance de FT-BLAS Avec Capacité de Tolérance aux Erreurs

Après avoir établi de bonnes performances sans tolérance aux erreurs, on a introduit des fonctionnalités pour gérer les erreurs. Pour les routines de Niveau-1 et de Niveau-2, on a créé une nouvelle méthode de vérification qui minimisait l'impact de la tolérance aux erreurs sur la vitesse. Pour les routines de Niveau-3, on a combiné le contrôle d'erreurs avec nos calculs habituels, ce qui a limité le besoin de déplacements de données supplémentaires et maintenu la performance élevée.

#Optimisation de DSCAL Avec et Sans Tolérance aux Erreurs

On a évalué l'efficacité et l'impact de nos méthodes de tolérance aux erreurs sur DSCAL. On a commencé par une version simple, qui avait de faibles performances. En appliquant progressivement des optimisations, on a réduit la perte de performance due aux fonctionnalités de tolérance aux erreurs. La version améliorée a montré une vitesse considérable, surtout quand on a ajouté des techniques plus avancées comme le déroulement de boucles et le préchargement. À la fin de ce processus, notre version sans tolérance aux erreurs a égalé la performance d'OpenBLAS.

#Optimisation de DGEMM Avec Tolérance aux Erreurs

On a comparé deux approches pour intégrer la tolérance aux erreurs dans l'opération DGEMM : améliorer la MKL existante et intégrer nos contrôles directement dans le calcul. La version basée sur MKL a montré un overhead plus élevé quand des erreurs étaient injectées, tandis que la méthode fusionnée avait un impact beaucoup plus faible. Cette approche signifie qu'on pouvait gérer des erreurs sans ralentissements significatifs.

#Comparaison Générale des Performances

Nos comparaisons ont montré que la version FT-BLAS avec capacité de tolérance aux erreurs restait performante. L'overhead supplémentaire pour les routines dépendantes de la mémoire était mineur, la plupart restant en dessous de 3 %. Pour les routines de Niveau-3, on a maintenu un faible overhead similaire à travers différentes implémentations. Dans l'ensemble, notre FT-BLAS est resté compétitif, voire plus rapide que les bibliothèques leaders.

#Benchmarking sur Processeur Intel Cascade Lake

Tester FT-BLAS sur un processeur Intel Cascade Lake a montré qu'il fonctionnait bien en continu, similaire aux résultats du processeur Skylake. L'overhead supplémentaire pour les routines dépendantes de la mémoire était minimal. Les stratégies fusionnées fonctionnaient très bien, maintenant la performance compétitive contre les bibliothèques bien connues.

#Activation du Support Parallèle

Après avoir activé le support pour le traitement parallèle, on a constaté que les routines de Niveau-1 et de Niveau-2 maintenaient leur faible overhead, similaire aux implémentations à un seul thread. Notamment, OpenBLAS ne prend pas en charge le traitement parallèle pour toutes les routines, et cette limitation signifie que notre conception parallèle peut le surpasser.

#Extension aux Processeurs AMD

On a aussi testé nos routines sur un processeur AMD R7 3700X. Étant donné que ce processeur a moins de registres disponibles, on a décidé de ne faire la détection d'erreurs que pour les routines plus simples. Les résultats ont confirmé que nos méthodes de tolérance aux erreurs fonctionnaient toujours bien, avec très peu d'overhead par rapport aux bibliothèques existantes.

#Expériences d'Injection d'Erreurs

Pour valider encore plus nos fonctionnalités de tolérance aux erreurs, on a introduit des erreurs directement dans nos processus de calcul et vérifié les résultats par rapport à MKL. En injectant des erreurs au niveau du code, on visait à minimiser tout impact sur la performance. On a injecté 20 erreurs dans chaque routine, et pour nos routines de Niveau-3, ce processus était assez simple. On pouvait facilement modifier des éléments de matrice à des points spécifiques.

Pour les routines de Niveau-1 et de Niveau-2, où du code assembleur était utilisé, injecter des erreurs nécessitait des méthodes plus complexes. On a développé un mécanisme pour introduire des fautes et comparer les résultats pour identifier les erreurs. La récupération impliquait de recomputer rapidement les sections défectueuses.

#Performance Sous Injection d'Erreurs sur Skylake

Nos tests ont montré que même dans des conditions d'injection d'erreurs, FT-BLAS maintenait de bonnes performances avec un overhead minimal. Dans tous les cas, nos routines surpassaient les bibliothèques existantes, confirmant que les méthodes de tolérance aux erreurs avaient un impact limité sur la vitesse.

#Performance Sous Injection d'Erreurs sur Cascade Lake

Sur le processeur Cascade Lake, notre stratégie de tolérance aux erreurs a aussi bien fonctionné, continuant de surpasser d'autres bibliothèques même sous injection d'erreurs. Le temps pris pour différentes tailles de matrices a confirmé que FT-BLAS pouvait tolérer efficacement de nombreuses erreurs sans affecter significativement la performance.

#Performance Parallèle Sous Injection d'Erreurs sur Cascade Lake

Quand parallélisées, notre routine DGEMV a toujours surpassé OpenBLAS et MKL, même sous conditions d'erreurs. Notre DGEMV optimisé FT était nettement plus rapide que le BLIS non threadé, confirmant que nos techniques s'adaptent bien même avec une complexité supplémentaire.

#Performance Sous Injection d'Erreurs sur AMD Zen2

Enfin, on a examiné la performance de FT-BLAS sous injection d'erreurs sur le processeur AMD Zen2 Ryzen. On a trouvé que la performance globale restait compétitive avec les bibliothèques leaders, même dans des conditions d'erreurs. Cela a confirmé que nos méthodes fonctionnent bien sur différentes plateformes matérielles.