Performances SIMD dans FTP

Le code SIMD présenté ci-dessus a été intégré dans notre code FTP. Cependant, pour des rai- sons de temps, nous n’avons pu compléter toutes les implémentations nécessaires à une com- paraison directe aux implémentations scalaires. Nous avons donc uniquement intégré le code SIMD dans l’implémentation Exhaust et uniquement pour des pièces à surface unique. Nous allons donc présenter des benchmarks portant uniquement sur des reconstructions d’une pièce plane et d’une pièce cylindrique.

Ayant validé les performances de la parallélisation de l’algorithme FTP ainsi que celles de l’implémentation SIMD sur un processeur Nehalem, nous avons jugé qu’il serait intéressant d’observer le comportement sur une machine AMD disposant d’un nombre de coeurs plus im- portant. Nous avons donc effectué nos benchmarks sur une machine AMD disposant de quatre processeurs Opteron 6284 SE, de 2x8 coeurs chacun, faisant un total de 64 coeurs.

Le tableau 3.18 présente les performances obtenues pour l’exécution de FTP sur deux jeux de données : un cas plan, et un cas cylindrique. Les jeux de données DATA1 pour le cas plan et DATA2 pour le cas cylindrique sont utilisés. En revanche, nous n’avons pas pu réutiliser une CAO2D dans la mesure où nous n’avons pas eu le temps de mettre le code à niveau : nous n’avons donc pas pu tester les jeux de données DATA3 et DATA4. Le compilateur utilisé est ICC 13.1 et l’environnement de benchmark est sous Linux.

Tableau 3.18 – Performances des implémentations scalaires et SIMD FTP sur une machine 64 coeurs AMD.

DATA1 (ms) Mono Multi (64) Gain OpenMP

Scalar F32 26 125 699 ×37,3

SSE F32 9 094 283 ×32,1

Scalar F64 27 872 881 ×31,6

SSE F64 10 733 338 ×31,8

DATA2 (ms) Mono Multi (64) Gain OpenMP

Scalar F32 49 567 1 310 ×37,8

SSE F32 12 229 499 ×24,6

Scalar F64 98 630 2 515 ×39,2

Les gains observés sont loins d’être ceux que nous attendions initialement. En effet, le pas- sage à l’échelle au delà de 32 thread est extrêmement peu efficace et le meilleur facteur obtenu n’atteint qu’un×39,2 pour DATA2 dans le cas scalaire F64. Dans le cas cylindrique SIMD F32, le gain est très faible et n’atteint qu’un facteur×24,6. Ce dernier nous semble difficile à expli- quer. Cependant, ce problème de passage à l’échelle sur l’architecture Bulldozer semble être une problématique connue comme expliqué ici [Frey, 2012]. Selon le compilateur et les options de compilation, le problème de passage à l’échelle au delà de 32 threads peut apparaitre. Il serait donc nécessaire de tester d’autres compilateurs pour valider cette hypothèse. Parmi les tests à réaliser, il serait intéressant de réaliser une implémentation AVX car les coeurs de l’ar- chitecture Bulldozer peuvent soit exploiter deux flux SSE, soit utiliser la FPU partagée entre les deux coeurs pour exécuter un flux AVX. Il est tout à fait possible que le facteur 2 manquant vienne d’une mauvaise exploitation des instructions SSE.

Pour illustrer les différents problèmes rencontrés dans ces benchmarks, voici une sélection de ratios comprenant les gains apportés par le SSE, les gains apportés par le F32 par rapport au F64 et le gain total, par jeu de données. Le tableau 3.19 présente ces ratios.

Tableau 3.19 – Comparaisons de performances entres différentes valeurs issues du tableau 3.18. Plan (ratios) Gain SSE

Mono Gain SSE 64 threads Gain F32 Mono Gain F32 64

threads Gain Total

Scalar F32 - - - - -

SSE F32 ×2,9 ×2,5 - - ×92,3

Scalar F64 - - ×1,1 ×1,3 -

SSE F64 ×2,6 ×2,6 ×1,2 ×1,2 ×82,6

Cylindre( ratios) Gain SSE Mono Gain SSE 64 threads Gain F32 Mono Gain F32 64

threads Gain Total

Scalar F32 - - - - -

SSE F32 ×4,0 ×2,6 - - ×99,2

Scalar F64 - - ×2,0 ×1,9 -

SSE F64 ×3,0 ×2,8 ×2,7 ×1,8 ×107,9

Commençons par observer les gains obtenus en SSE. Dans le cas plan, ils sont respective- ment de ×2,9 et ×2,6 en F32 et F64. Cet écart se retrouve aussi dans le cas cylindrique. La raison pour laquelle le F64 est plus lent n’est pas évidente de prime abord et nécessiterait une meilleure compréhension de l’architecture pour valider ces résultats, d’autant plus qu’une fois parallélisé, ce sont les implémentations F64 qui obtiennent de meilleurs résultats.

Les gains obtenus du fait du passage en F32 sont relativement faibles pour le cas plan, tan- dis qu’ils sont autour d’un facteur 2 en cylindrique. Cela est dû à la quantité de calcul du cas cylindrique qui est plus importante permettant de mieux profiter de l’accélération de la partie calculatoire SSE. Le facteur 2,7 obtenu en monothread n’est pas non plus simplement explicable et nécessiterait de mieux comprendre l’architecture.

couple SSE et parallélisation sur 64 threads à l’aide d’OpenMP. Si on observe le gain obtenu entre l’implémentation scalaire F64 monothread et l’implémentation SSE F32 multithreadée, on peut observer un gain avoisinant le facteur 200 (gain non calculé dans les tableaux précé- dents).

Nous concluons la partie SIMD d’une manière abrupte. Il serait nécessaire d’effectuer plus de benchmark de l’architecture AMD du fait des performances relativement mauvaises obte- nues, à la fois en terme de passage à l’échelle en parallélisation, mais aussi dans certains cas SSE où nous n’avons pas d’explications quant à certains comportements. Nous allons maintenant passer à l’analyse générale comprenant les résultats obtenus sur GPP et sur GPU.

3.7

Analyse générale GPP multicoeurs et GPU

Dans cette section, nous allons comparer les résultats obtenus dans les sections précédentes en comparant les résultats GPP et GPU. Nous avons effectué un récapitulatif des transforma- tions apportées à l’algorithme de référence au sein de la figure 3.29. Par manque de temps, seul le groupement de pixels sur GPP n’a pas été réalisé. Cette transformation aurait permis d’amé- liorer les performances de l’implémentation Exhaust sur GPP, mais n’aurait de toutes façons pas pu rattraper l’implémentation Interp étant donné que la quantité de calculs sera toujours plus importante en Exhaust pour les dimensions de problèmes qui nous intéressent.

Les implémentations basée sur le code SIMD ne sont pas présentes dans la figure citée ci- dessus et ne sont pas comparées dans le tableau principal du fait des différences majeures entre les codes. Les implémentations n’étant pas complètes en termes de fonctionnalités, d’al- gorithmie et d’optimisations, nous allons comparer les performances obtenues dans un second tableau.