exactement les mêmes avec GOMP (avec une variation inférieure à 1% du temps de complétion). Ces résultats sont exposés dans le tableau B.2 en annexe (page 184).
Les expériences de composition se comportent différemment avec GOMP par rapport à KOMP. Les figures 5.11 et 5.12 présentent respectivement les temps de complétion des cas d’utilisation EP-EP et ST-ST avec le support exécutif GOMP dans des conditions identiques aux figures5.5et5.6. Dans l’ensemble, la version sans barrière est légèrement plus rapide que la version avec, sur le cas d’utilisation EP- EP : jusqu’à 1,135 fois plus rapide sans repartitionnement et de 1,114 fois plus rapide à 1,277 fois plus lente avec repartitionnement. Dans le cas d’utilisation ST-ST, les performances des deux versions (avec et sans barrière) sont très proches. Sans tenir compte des valeurs extrêmes à droite des figures5.11et5.12, la version sans barrière est 1,031 fois plus rapide que celle sans barrière, avec et sans repartitionnement. Avec GOMP, il y a un petit gain à supprimer la barrière lors d’une composition. Cela est dû à une réutilisation réduite du cache, comme nous l’avons déjà mentionné.
Les résultats du cas d’utilisation TRANSP avec GOMP sont similaires à ceux avec KOMP. En effet, la version sans barrière est toujours plus rapide que celle avec : d’un facteur 1,044 à 1,161. GOMP répartit bien les accès à la mémoire en les superposant avec le calcul. Ces résultats sont exposés la figure B.13 en annexe (page 183).
Malgré quelques différences, les résultats obtenus avec GOMP sont similaires à ceux de KOMP ce qui laisse penser que les phénomènes observés précédemment peuvent être généralisés à d’autres supports exécutifs, bien qu’une étude sur plus de supports exécutifs soit nécessaire afin de confirmer cette analyse. Les résultats obtenus avec GOMP se révèlent cependant moins efficaces que ceux de KOMP.
Cette perte d’efficacité dans le cas de GOMP est due à un ordonnancement proche de l’ordre de soumission qui n’est pas propice à une réutilisation des données en cache. Ce point est étudié plus en détail dans la section suivante.
5.4 Discussion
Récapitulatif À partir des résultats précédents, nous pouvons conclure que les per- formances de Halley sont équivalentes aux versions de référence OpenMP écrite manuellement pour les cas d’utilisation évalués, en particulier lorsque des patrons de calcul simple sont utilisés (c.-à-d. cas d’utilisation synthétiques). Cela signifie que le modèleCometpeut être mis en œuvre sans introduire de surcoût conséquent à l’exé- cution sur des cas synthétiques. Avec la complexité croissante des patrons, surtout en présence de cas de compositions, Comet démontre ses avantages : l’expression de la composition reste simple tandis que la mise en œuvre Halley peut géné- rer automatiquement une exécution efficace en utilisant des synchronisations point à point entre les tâches sans aucune synchronisation globale (barrière OpenMP).
Cette solution est très efficace, même pour les petites tâches liées à la mémoire, pour exploiter la réutilisation du cache ainsi que pour utiliser efficacement les res-
1024x1024-1024x10241024x512-1024x5121024x256-1024x2561024x128-1024x1281024x64-1024x641024x32-1024x321024x16-1024x161024x8-1024x8
1024x1024-2048x5121024x512-2048x2561024x256-2048x1281024x128-2048x641024x64-2048x321024x32-2048x161024x16-2048x81024x8-2048x4
Taille des blocs 0
1 2 3 4 5
Temps de complétion (s)
avec barrière sans barrière
Figure 5.11 – Temps de complétion du cas d’utilisation EP-EP pour différentes tailles de blocs avec des buffers de taille 8192x8192 en utilisant le support exécutif GOMP. Les tailles de blocs des métatâches Mt1 et Mt2 sont représentées sous la forme BM t1´BM t2.
1024x1024-1024x10241024x512-1024x5121024x256-1024x2561024x128-1024x1281024x64-1024x641024x32-1024x321024x16-1024x161024x8-1024x8
1024x1024-2048x5121024x512-2048x2561024x256-2048x1281024x128-2048x641024x64-2048x321024x32-2048x161024x16-2048x81024x8-2048x4
Taille des blocs 0.0
0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0
Temps de complétion (s)
avec barrière sans barrière
Figure 5.12 – Temps de complétion du cas d’utilisation ST-ST pour différentes tailles de blocs avec des buffers de taille 8192x8192 en utilisant le support exécutif GOMP. Les tailles de blocs des métatâches Mt1 et Mt2 sont représentées sous la forme BM t1´BM t2.
5.4. DISCUSSION 119 sources partagées malgré la présence de partitionnement différent et l’usage d’une composition de codes de haut niveau.
Les résultats obtenus avec les supports exécutifs d’OpenMP de production sont, à première vue, décevants. GOMP (ainsi que le support exécutif d’Intel, dont les résul- tats ne sont pas présentés ici) ne tire pas parti de l’éviction de barrières permettant d’améliorer significativement les performances. Cependant, il est important de noter que plusieurs hypothèses ont été considérées avant que nous ne nous concentrions sur les performances deHalley.
Sérialisation et ordre de la soumission des tâches En sérialisant la soumission des tâches, le surcoût des tâches devient un facteur limitant : la granularité des tâches doit être revu à la hausse pour compenser les surcoûts [46]. Cela a pour effet d’impacter négativement l’ordonnancement des tâches en introduisant un comporte- ment similaire à la présence d’une barrière. En effet, les tâches qui peuvent exploiter la réutilisation du cache sont de facto soumises lorsque la plupart des tâches précé- dentes ont été exécutées. L’ordonnanceur ne peut donc pas exécuter les tâches en profondeur de manière à améliorer les performances des cas d’utilisation considérés (car il n’a qu’une version partielle du graphe de tâches à un instant donné).
Plusieurs solutions existent pour résoudre le problème de sérialisation de la sou- mission des tâches. L’une d’elles consiste à adapter Halley pour qu’il puisse sou- mettre des tâches dans un ordre proche de celui choisi par l’ordonnanceur à l’exé- cution afin de simplifier son travail (p. ex. soumission des tâches en profondeur), notamment en ayant recours à des stratégies d’ordonnancement statique (appliquée au moment de la compilation) ou en analysant la structure du graphe lors de la première exécution d’une section afin de soumettre les tâches des prochaines exé- cutions de la section de manière plus efficace. Cette approche requiert des change- ments majeurs dans Halley, car elle nécessite une analyse globale du graphe qui est le résultat de la composition de morceaux de graphes générés par des greffons indépendants variés (p. ex. greffons de relations et de repartitionnement), dont le comportement précis n’est pas connu par Halley. De plus, cette approche souffre de problèmes de passage à l’échelle : lorsque le nombre d’unités de calcul devient imposant, la soumission des tâches séquentielle risque d’être trop lente pour fournir suffisamment de travail à toutes les unités de calculs. Une solution plus prometteuse consiste à soumettre les tâches en parallèle. Cependant, la soumission de tâches in- terdépendantes en parallèle n’est pas actuellement supportée par OpenMP 4.5 (ni par la nouvelle version 5.0).
Efficacité des stratégies d’ordonnancement En soumettant en groupe les tâches issues des métatâches, l’ordonnanceur doit fournir un effort conséquent pour réor- ganiser les tâches de manière à les exécuter en profondeur dans les cas d’utilisation traités. Or, certains ordonnanceurs [26] ont recours à des stratégies employant des fenêtres glissantes pour n’analyser qu’une sous partie du graphe de tâches soumis afin de limiter les coûts en calculs ainsi que l’usage de la mémoire. D’autres [55]
décident d’exécuter les tâches lorsque trop de tâches ont été soumises (c.-à-d. cut
off) afin de réduire les surcoûts associés à la taille des structures de données [46].
C’est en particulier le cas de GOMP qui n’exécute plus les tâches en profondeur lorsque le graphe devient trop imposant (p. ex. seuil fixé expérimentalement à 64 tâches). KOMP supporte le vol de travail T.H.E. issu de Cilk [50] qui est basé sur des files d’attente illimitées de tâches. Cette stratégie de vol de travail est particu- lièrement bien adaptée à la manière dont fonctionneHalley car chaque métatâche engendre un ensemble de tâches potentiellement grand qui dépend des groupes pré- cédemment soumis. Toutefois, il est important de noter que l’exécution des tâches en profondeur n’est pas toujours la meilleure méthode d’ordonnancement, notamment lorsque les tâches d’une même métatâche travaillent sur des données partagées (ces cas d’utilisation sont moins sensibles aux problèmes évoqués).
Conception d’une interface efficace et portable pour les supports exécutifs Fournir une mise en œuvre de Cometau-dessus des supports exécutifs d’OpenMP de manière portable est un défi. Outre les problèmes d’ordonnancement de tâches, les supports exécutifs d’OpenMP supportent relativement mal un nombre important de tâches dépendantes (à grains fins). Les surcoûts introduits par GOMP sont plus importants que ceux du support exécutif d’Intel étendu par KOMP et limitent le passage à l’échelle de notre approche. Les dépendances sont la source de ces surcoûts.
Le passage des dépendances au support exécutif ainsi que leur résolution, ne peut pas être parallélisé avec OpenMP en raison de limitations dans la spécification [94]
qui impose une création séquentielle des tâches interdépendantes. Afin de surmonter cette limitation, nous cherchons à exporter des fonctions spécifiques aux supports exécutifs pour contourner les calculs de dépendances afin que les greffons de relations (cf.Section3.2) puissent les calculer lors de la compilation d’un assemblageHalley. Choix du nombre optimal de cœurs à utiliser Enfin, il est important de noter que nous avons fait des expérimentations en utilisant uniquement le nombre maxi- mum de cœurs présent sur une socket (cf.introduction de cette section). Le nombre de cœurs utilisé n’est pas optimal pour les cas d’utilisation limités par la mémoire dans lesquels une contention est observable, par exemple dans les résultats présentés sur ST-ST. Cependant, ce choix a été réalisé pour trois raisons.
Premièrement, de nombreuses applications de production (telles que Gysela) ayant recours à OpenMP utilisent toutes les unités de calcul disponibles. Dans ces applications, les performances optimales de chaque traitement séparé peuvent être atteintes avec un nombre variable d’unités de calcul. Par exemple, les traitements limités par la mémoire peuvent atteindre des performances optimales avec quelques unités de calcul alors que d’autres, plus intensifs, en termes de calcul peuvent de- mander l’ensemble des unités de calcul mises à disposition. Plus généralement, le choix du nombre d’unités de calcul pour un traitement dépend de sa capacité à passer à l’échelle. Ainsi, si l’adaptation du nombre d’unités de calcul est une solu- tion viable pour un unique traitement, cette méthode n’est souvent pas optimale à l’échelle d’une application. En effet, lorsque les traitements sont composés ensemble, certains groupes de traitements peuvent s’exécuter simultanément, chacun sur un
5.5. CONCLUSION 121