Implémentation sur GPU

L’utilisation des GPU pour réaliser des calculs d’ordre général est devenue plus populaire au fil des années. Plusieurs travaux récents portent alors sur l’accélération de la SpMV sur GPU.

Bell et Garland [18] ont présenté différentes représentations de matrices creuses ainsi que leurs implémentations respectives de la SpMV en langage CUDA. Les formats de représentation présen- tés sont ceux qui se retrouvent à la section 2.2, ainsi qu’un format appelé Paquet (PKT). Deux ensembles de matrices ont été utilisés, des matrices dites structurées qui ont une forme diagonale

et des matrices dites non structurées dont l’emplacement des éléments non nuls ne répond pas à une structure de matrice connue. Pour le premier ensemble, le format DIA performe le mieux en termes du nombre d’opérations à virgule flottante par seconde. Pour le deuxième ensemble, c’est le format HYB qui performe le mieux.

Pour le format CSR en particulier, Baskaran et Bordawekar [36] ont présenté plusieurs optimisa- tions. Ils ont pris en compte différents aspects : les problèmes de synchronisation entre les fils d’exécution, la distribution du travail entre les fils, les accès à la mémoire globale et la réutilisation des données. Ils ont comparé leurs résultats à ceux obtenus avec le format HYB [18] et, dépendam- ment du nombre d’éléments non nuls par ligne de la matrice, leur implémentation performe jusqu’à 15% mieux. Ainsi, non seulement il faut choisir le bon format, il faut aussi optimiser l’implémen- tation du noyau.

Un autre exemple d’optimisation de la distribution du travail entre les fils d’exécution est présenté par Wu et al. [37] sur des processeurs graphiques AMD. Ils ont testé plusieurs configurations de distribution des tâches et c’est celle qui utilisait un mélange entre un et plusieurs fils par ligne de la matrice qui a donné le plus grand nombre d’opérations à virgule flottante par seconde.

Plusieurs auteurs proposent plutôt de créer un tout autre format de représentation pour accélérer l’algorithme de multiplication entre une matrice creuse et un vecteur. C’est le cas de Vázquez et al. [19] qui ont proposé le format ELLPACK-R. Ce format est identique au format ELL, à la diffé- rence qu’un vecteur est ajouté pour stocker les tailles de chaque ligne de la matrice. Ceci permet alors de tirer avantage du format ELL, qui offre de meilleures performances que le format usuel CSR dans plusieurs cas, sans perdre de temps sur les éléments nuls qui se trouvent dans les matrices

data et indices de la représentation du format ELL. Vázquez et al. ont aussi proposé une modifica-

tion de l’implémentation de ce format sur une plateforme parallèle nommée ELLR-T [38] où T représente le nombre de fils d’exécution qui s’occupent d’une ligne de la matrice creuse. Monakov et al. [39] ont présenté un format nommé ELLPACK en tranches (sliced ELLPACK) qui sépare le format ELL en sections formées de lignes consécutives ayant chacune un K différent afin de tenter de régler le même problème que le format précédent en stockant moins d’éléments nuls dans la mémoire. Puis, à partir de tous ces formats, Dziekonski et al. [40] ont proposé un format nommé ELLR-T en tranches (sliced ELLR-T). Le format permet alors de stocker moins d’éléments nuls

comme le format ELLPACK en tranche, permettant ainsi d’avoir besoin de presque aussi peu d’es- pace de mémoire que le format CSR selon les matrices testées. De plus, le format permet d’accé- lérer l’exécution de l’algorithme en omettant de réaliser les opérations de multiplication sur les éléments nuls, tout comme le format ELLPACK-R, et en assignant plusieurs fils d’exécution à une même ligne, tout comme le format ELLR-T.

Un autre format ayant fait l’objet d’améliorations est le format COO. Dang et Schmidt [41] ont proposé le format COO en tranches (sliced COO). Ce format est obtenu en tranchant le format COO en sections de lignes consécutives. Les lignes sont placées en ordre de longueur au préalable afin que des fils d’exécution consécutifs aient une charge de travail semblable. Les éléments non nuls de la même colonne sont placés les uns à la suite des autres dans le vecteur de valeurs afin d’avoir des appels à la mémoire plus coalescents. Le format a été comparé aux formats de la librai- rie CUSP [14] et il donne de bons résultats en général. Pour les opérations à simple précision, le format COO en tranches est exécuté en moins de temps que le format COO, CSR et HYB sur des matrices non structurées [18].

Une autre façon d’accélérer la SpMV est de réduire la taille des données à accéder en mémoire. Tang et al. [42] ont proposé pour cela de compresser les formats de représentation avant de les placer dans la mémoire du GPU. Afin de réaliser une multiplication entre un élément non nul de la matrice et le vecteur x, le format COO doit lire quatre adresses en mémoire et le format ELL trois. Réduire la taille des données à lire permettrait de rééquilibrer le rapport élevé du nombre d’instruc- tions de mémoire par instruction de calcul. Ainsi, les auteurs ont compressé les formats ELL, COO et HYB et, par rapport aux formats non compressés, des économies d’espaces allant parfois jusqu’à 90 % et une accélération en moyenne de 1.5× ont été observées.

Choi et al. [43] ont présenté un article qui propose un nouveau format appelé BELLPACK. Ce format est similaire au format ELL, mais il regroupe les éléments non nuls en blocs comme le format BSR. De plus, ces auteurs ont proposé un modèle permettant d’ajuster les paramètres de leur format afin que leur implémentation finale soit optimale et qu’elle offre le temps d’exécution le plus court. Leur modèle estime le temps d’exécution avec une précision d’en moyenne 86.5 %. Les tests qui ont permis d’estimer cette précision ont été réalisés sur des matrices qui formaient des blocs de valeurs non nulles les plus denses possible, c’est-à-dire qu’ils ont environ le même nombre d’éléments non nuls sur chaque ligne.