2.6.1 Implémentations GPP multicoeurs
La parallélisation pour GPP multicoeurs est, comme nous l’avons mentionné précédemment, basée sur un partage des calculs de trajets. Chaque couple trajet/signal est indépendant des autres couples, du moment que les threads de calcul n’écrivent pas de manière simultanée sur la même image. Pour cela, on va utiliser une image différente par threads, puis les fusionner par réduction une fois les calculs de projection terminés.
Tâches de calcul (trajet/ signal) Tâches parallélisées sur p threads p images intermédiaires Fusion des images
FIGURE 2.13 – Schéma de la parallélisation GPP pour l’algorithme IVC. Chaque carré à coin arrondi représente une tâche de calcul correspondant à un couple trajet/signal. Chaque thread dispose d’une image privée pour éviter la synchronisation pendant les calculs. Une étape de fusion de ces images est nécessaire une fois les projections effectuées.
Une autre méthode de parallélisation serait d’utiliser une section critique, à l’aide par exemple d’OpenMP et du mot clé critical. Nous avons écarté cette possibilité car l’espace mémoire de l’image est complètement bloqué ; contrairement aux instructions atomiques des GPU qui ne bloquent l’accès qu’à l’espace mémoire accédé.
La figure 2.13 présente cette parallélisation. L’étape de fusion a été parallélisée et nous avons utilisé des instructions SIMD SSE pour accélérer le calcul. La boucle principale sur les trajets a été parallélisée à l’aide d’OpenMP. Les images intermédiaires ont été pré-allouées avant la boucle afin d’éviter une allocation dynamique dans les sections parallèles. Le reste des va- riables est privée, ou bien partagée, mais uniquement en lecture. Cela nous permet d’avoir une implémentation la plus efficace possible.
OpenCL a aussi été évalué à l’aide de l’implémentation réalisée sur GPU. Le portage n’a né- cessité aucun travail supplémentaire, dans la mesure où nous souhaitions tester l’adaptation d’un code développé pour le GPU sur GPP multicoeurs. Il est à noter que n’ayant pas native- ment d’instruction atomiques, les GPP utilisent l’instruction x86 lock. Ce type d’opération fait l’objet d’un intérêt particulier chez Intel puisque leur future architecture, Haswell, disposera d’une mémoire transactionnelle permettant d’accélérer ce type d’opérations.
2.6.2 Benchmarks et analyses de performances
Nous avons réalisé différents benchmarks pour vérifier l’efficacité de la parallélisation GPP multicoeurs via OpenMP et OpenCL. Nous commencerons par donner des résultats de passage à l’échelle d’OpenMP sur nos deux générations de GPP. Puis en second nous comparerons les résultats OpenMP, OpenCL AMD et OpenCL Intel.
2.6.2.1 Impact du passage en post-traitement du traitement d’images
Nous avons comparé le coût du traitement d’image entre l’implémentation GPP- A et GPP-B. Nous avons effectué ces tests sur notre quad-coeur pour les jeux de données EXZ et PMF. Le but est ici de valider l’optimisation du traitement d’image sur GPP.
Tableau 2.8 – Gains obtenus grâce à l’optimisation du traitement d’images sur GPP. GPP-A GPP-B GPP-A / GPP-B EXZ - 800x800 - Temps (s) Côté 5,02 1,16 ×4 Dessus 43,12 1,19 ×36 Face 14,07 1,22 ×12 PMF - 800x800 - Temps (s) Côté 18,6 4,19 ×4 Dessus 60,3 4,29 ×14 Face 62,2 4,30 ×14
Le tableau 2.8 présente les gains GPP entre l’algorithme GPP-A et GPP-B pour l’implémenta- tion GPP monothreadée. On constate comme sur GPU des gains très importants dépendants de la taille du traitement et donc dépendant du jeu de données. Si on normalise le temps de calcul par le nombre de projections on obtient : pour EXZ, 4,0· 10−8 secondes par projection, et pour PMF, 2,8· 10−8secondes par projection (en cycle d’horloge, cela représente respectivement 120 et 84 cycles par projection). On peut s’apercevoir que l’on se rapproche d’une implémentation dont le temps de calcul est prédictible. La différence qui existe entre les deux jeux de données et due à l’irrégularité des trajets du jeu de données EXZ.
2.6.2.2 Passage à l’échelle de l’implémentation OpenMP
On souhaite maintenant s’intéresser à la parallélisation en elle même et plus particulièrement à l’implémentation OpenMP. Le tableau 2.9 présente les résultats de parallélisation pour le jeu de données PMF sur les deux GPP testés.
Tableau 2.9 – Passage à l’échelle de l’implémentation OpenMP pour la projection de côté de PMF.
Temps (s) Gains
Nb threads / Ratios 1 4 12 24 4 : 1 12 : 1 24 : 1
E5472 4296 1105 - - ×3,9 - -
X5690 2705 680 267 169 ×4,0 ×10,1 ×16,0
On peut constater que les deux GPP passent presque parfaitement à l’échelle. Sur le X5690, on constate qu’avec 12 threads, on obtient un facteur d’accélération d’environ×10. Avec 24 threads, l’Hyperthreading permet d’obtenir un facteur d’accélération égal à ×16. On constate ici que l’Hyperthreading permet d’augmenter de 30% les performances que l’on pourrait at- tendre du fait du nombre de coeurs. Cette valeur n’est pas surprenante par rapport à ce qui est présenté dans la littérature et montre que les changements de contextes permettent de mieux remplir le pipeline et donc d’obtenir une meilleure efficacité de calcul des coeurs du GPP.
2.6.2.3 Comparatif OpenMP / OpenCL
Le tableau 2.10 présente un comparatif des temps de calculs entre OpenMP, OpenCL Intel et OpenCL AMD pour l’algorithme GPP-B. On présente ici les meilleurs résultats obtenus pour OpenCL en ayant fait varier les dimensionnements de workgroup (cf. présentation OpenCL en section 1.3.2.1).
On constate ici que les performances atteintes par OpenCL sont de l’ordre de 20% infé- rieures à celles d’OpenMP. Il faut rappeler ici qu’OpenMP n’a pas de gestion de concurrence à la volée comme l’implémentation OpenCL. Malgré cette différence de performances, on peut constater un gain par rapport à l’implémentation monothreadée de l’ordre d’un facteur×12, ce qui, malgré tout, reste très intéressant.
La raison principale de cet intérêt est l’absence de modification du code développé pour GPU, qui s’adapte de manière efficace, sans aucun travail particulier au GPP multicoeurs. Il n’est pas surprenant qu’OpenCL ne puisse pas toujours être aussi performant que les modèles de programmation natifs, mais dans le cas de l’algorithme IVC, OpenCL est une alternative
Tableau 2.10 – Temps de calcul en secondes sur X5690 pour l’algorithme GPP-B sur OpenMP, OpenCL AMD et OpenCL Intel
Vue Côté Dessus Face
OpenMP 169.3 172.0 170.7
OpenCL AMD 215.3 220.0 217.1
OpenCL Intel 217.3 214.7 218.3 OpenCL AMD / OpenMP -21% -22% -21% OpenCL Intel / OpenMP -22% -20% -22%
très intéressante.
Pour terminer cette partie, on peut aussi noter qu’entre OpenCL Intel et OpenCL AMD, les performances sont du même ordre de grandeur. Nous allons maintenant passer au comparatif GPP/GPU.