Exploitation de la réutilisation de données en cache

Analyse du cas d’utilisation EP La figure 5.5 montre le temps de complétion du cas d’utilisation EP-EP en utilisant Halley sur des blocs de tailles différentes, avec un buffer de données de taille de 8192x8192, avec et sans barrière (cf. chapitre4). Le côté gauche de la figure contient des cas qui n’ont pas besoin de repartitionnement entre les deux codes EP (même taille de bloc) et les cas du côté droit ceux qui nécessitent un repartitionnement en raison de la taille différente des blocs entre les deux codes EP. Les tailles de blocs relatives au premier EP sont désignées par BM t1

5.3. ÉVALUATION DES PERFORMANCES 111

1024x1024-1024x1024^{1024x512-1024x5121024x256-1024x2561024x128-1024x1281024x64-1024x641024x32-1024x321024x16-1024x16}

1024x8-1024x8

1024x1024-2048x512^{1024x512-2048x2561024x256-2048x1281024x128-2048x641024x64-2048x321024x32-2048x16}

1024x16-2048x81024x8-2048x4 Taille des blocs

0.00 0.25 0.50 0.75 1.00 1.25 1.50 1.75 2.00 Temps de complétion (s) avec barrière sans barrière

Figure 5.5 – Temps de complétion du cas d’utilisation EP-EP pour différentes tailles de blocs avec un buffer de taille 8192x8192. Les tailles de blocs des méta-tâches Mt1 et Mt2 sont représentées sous la forme BM t1 ´ BM t2. Les versions sans repartitionnement se trouvent à gauche et celles avec repartitionnement à droite. et celles du second par BM t2.

La partie gauche de la figure5.5 montre que les versions sans barrière surpassent toujours les versions avec barrière si aucun repartitionement n’est nécessaire. Dans certains cas, l’éviction de la barrière permet une amélioration des performances d’un facteur 1,809. Cette amélioration provient de la réutilisation des données du cache entre les tâches générées à partir de la métatâche Mt1 et celles de Mt2. La réutilisation des données n’est possible que lorsque les fragments sont suffisamment petits pour être intégrés au cache. En pratique, l’absence de barrière permet à l’ordonnanceur de suivre les dépendances entre les tâches de Mt1 et Mt2 : lorsqu’une tâche de Mt1 se termine, il exécute directement les tâches de Mt2 prêtes (celles dont les prédécesseurs se sont terminés). A contrario, la version avec barrière force le calcul de toutes les tâches de Mt1 avant Mt2. Puisque l’ensemble des données ne peut pas tenir dans le cache (L3), quasiment aucune réutilisation de cache n’est possible.

Des temps de complétion plus rapides sont observés lorsqu’il y a suffisamment de tâches pour éviter une situation de famine (p. ex. avec une taille de blocs fixée à 1024x128). Une situation de famine survient lorsque l’ordonnanceur n’affecte pas bien les tâches sur les unités de calculs (due à une forte connexité du graphe de dépendances rendant l’ordonnancement des tâches difficile), ou qu’il est trop lent à réaliser cette affectation, ou même lorsque le nombre de tâches soumises est faible. Dans cette expérience, lorsque la taille de blocs est plus grande que 1024x64, la soumission des tâches commence à devenir trop lente, car elle est réalisée séquentiel-lement comme cela a été évoqué précédemment (ce phénomène est visible sur le cas

ST présenté par la figure 5.7). Une soumission des tâches trop lente par rapport à l’exécution des tâches peut agir comme une barrière si les tâches Mt1 sont terminées avant la soumission des tâches Mt2 : l’ordonnanceur n’est pas en mesure de tirer parti des dépendances entre les tâches.

La partie droite de la figure 5.5 montre qu’avec le repartitionnement les mêmes effets sont observés : la version sans barrière est 1,631 fois plus rapide, sauf pour des petites tailles de blocs où elle est jusqu’à 1,281 fois plus lente. L’efficacité de la version sans barrière est moindre par rapport au cas sans repartitionnement. La raison de ce phénomène est double : premièrement, il est plus difficile d’exploiter le cache en présence d’un repartitionnement et deuxièmement, le repartitionnement engendre la soumission de tâches supplémentaires qui augmente le temps de soumis-sion qui constitue un goulot d’étranglement lorsque la taille des blocs est petite (dû au nombre imposant de tâches produites). En pratique, en présence d’un reparti-tionnement, le gain issu d’une exploitation efficace du cache est caché par les pertes provenant de la soumission séquentielle trop lente qui empêche toute exécution en-trelacée (étant donné que les tâches de la métatâche Mt1 sont en grande partie déjà exécutées avant même que la première tâche de la métatâche Mt2 soit soumise). Dans le cas extrême où la taille du bloc est trop petite, le temps de complétion est limité par le temps de soumission des tâches, qui est ralenti par les tâches de repartitionnement supplémentaires.

Ainsi, une exécution à grain fin, que ce soit avec ou sans repartitionnement fourni par Halley, peut fournir de meilleures performances dans le cas EP-EP que l’utilisation d’une simple barrière.

Analyse du cas d’utilisation ST La figure 5.6 montre les résultats obtenus avec le cas d’utilisation ST-ST de la même manière que les expériences EP-EP présentées dans la figure 5.5.

Globalement, la version sans barrière est jusqu’à 1,182 fois plus rapide sans repartitionnement et 1,070 fois plus rapide avec repartitionnement. Ceci est conforme aux résultats obtenus dans le cas EP-EP. Cependant, le gain provenant de l’éviction de la barrière est moins important, car les dépendances entre les tâches Mt1 et les tâches Mt2 sont plus complexes dans ST ce qui laisse moins de possibilités pour ordonnancer les tâches en fonction des dépendances afin augmenter la réutilisation des données en cache.

La figure 5.7 présente le planning d’exécution des tâches (diagramme de Gantt) d’une itération du cas d’utilisation ST-ST obtenu avec une taille de bloc 1024x64 et des buffers de taille 8192x8192. Au centre du diagramme de Gantt, un ordonnan-cement en profondeur est appliqué et les tâches Mt2 sont plus rapides qu’à la fin de l’exécution puisqu’elles réutilisent les données en cache. Cela ne se produit pas avant, car la phase de soumission prend du temps et qu’elle empêche ainsi la tâche d’être ordonnancée en profondeur plus tôt : à un instant donné, soit aucune tâche de Mt2 n’a été soumise pour le moment, soit des tâches ont été soumises, mais les données sur lesquelles elles opèrent ne sont plus en cache (dans ce cas, leur exécution est reportée à la fin de l’ordonnancement).

5.3. ÉVALUATION DES PERFORMANCES 113

1024x1024-1024x1024^{1024x512-1024x5121024x256-1024x2561024x128-1024x128}

1024x64-1024x641024x32-1024x321024x16-1024x16^{1024x8-1024x8}

1024x1024-2048x512^{1024x512-2048x2561024x256-2048x1281024x128-2048x641024x64-2048x321024x32-2048x161024x16-2048x81024x8-2048x4}

Taille des blocs 0.00 0.25 0.50 0.75 1.00 1.25 1.50 1.75 2.00 Temps de complétion (s) avec barrière sans barrière

Figure 5.6 – Temps de complétion du cas d’utilisation ST-ST pour différentes tailles de blocs avec des buffers de taille 8192x8192. Les tailles de blocs des méta-tâches Mt1 et Mt2 sont représentées sous la forme BM t1 ´ BM t2. Les versions sans repartitionnement se trouvent à gauche et celles avec repartitionnement à droite.

0 5 10 15 20 25 0.00 0.01 0.02 0.03 0.04 Temps d'exécution (s) ID d 'u n it é d e c a lc u l Mt1 Mt2 Soumission

Figure5.7 – Diagramme de Gantt de l’ordonnancement du graphe de tâches pour une seule itération du cas d’utilisation ST-ST obtenu avec une taille de blocs fixée à 1024x64 et des buffers de taille 8192x8192.

128-1024 ^{64-1024 32-512 16-512 8-256 4-256 2-128 1-128} Taille des blocs

0 1 2 3 4