Contrôle d’exécution

Le code Sigma-C généré par notre chaîne de compilation comporte généralement plu- sieurs subgraphs non connexes, qui sont tous placés sur les cœurs de calcul du MPPA. Afin de lancer le bon subgraph au bon moment et pour contrôler les entrées et sorties des ap- plications, nous avons développé un environnement d’exécution en C. Ce dernier s’exécute sur la machine hôte, à côté de l’application Sigma-C générée, et communique via des Unix

6. Le modèle flot de données

anr999 antibi o

burn er

deblocking_licenseP late retin a toggl e GMEAN 0 2 4 6 Speed up → C générique ASM générique C spécifique

Figure 6.12 – Speedups pour différentes implémentations des cœurs de boucles des agents morphologiques : (1) implémentation C générique (référence) ; (2) implémentation géné- rique en assembleur VLIW ; (3) implémentation C spécifique à l’élément structurant via évaluation partielle lors de la génération de code Sigma-C

Clusters E/S Agents Sigma-C hôte

Code de contrôle Clusters de calcul

U nix pipes PCI e N oC lancement calcul envoi lecture réception écriture transfert transfert transfert écriture envoi lecture réception traitement n traitement i traitement 1

Figure 6.13 – Environnement d’exécution pour applications Sigma-C

Notre environnement d’exécution remplit les fonctions suivantes : — allocation des images dans la mémoire DDR attachée au MPPA ; — libération de la mémoire allouée dans la DDR attachée ;

— transfert d’une image depuis la mémoire de l’hôte vers la DDR attachée ; — transfert d’une image depuis la DDR attachée vers la mémoire de l’hôte ; — lancement d’un subgraph de calcul.

Pour chacune de ces fonctions, un subgraph dédié est exécuté sur l’hôte et un cluster 94

6.3. Une nouvelle cible pour FREIA

d’entrée/sortie, afin de relayer les commandes et les données à la puce. Notre environnement d’exécution gère également la lecture et l’écriture des différents formats d’images depuis le disque dur de la machine hôte. Il s’appuie, pour ce faire, sur une bibliothèque de traitement d’images purement logicielle appelée Fulguro [26], mais peut également utiliser SMIL à la place.

Optimisation des transferts de données

Afin d’améliorer les performances de notre environnement d’exécution, nous avons réalisé deux optimisations notables des transferts de données entre hôte et accélérateur.

Transferts directs depuis l’hôte La puce MPPA de 1re_{génération « Andey » souffre de}

temps d’accès élevés vers la mémoire DDR attachée aux clusters d’entrée/sortie. Nous avons donc altéré notre environnement d’exécution pour ne plus stocker les images dans la DDR, mais à la place les transférer directement depuis et vers l’hôte au début et à la fin de l’exécution de nos subgraphs de calcul. La figure 6.14 représente le speedup obtenu en transférant les images via PCI-Express plutôt que de les stocker temporairement dans la DDR. Les gains sont compris entre ×1.1 et ×11 pour une moyenne de ×2.5. Ainsi, il est donc plus efficace de transférer directement les images depuis l’hôte que de les stocker dans la DDR attachée. La seconde génération de la puce MPPA, « Bostan », résout censément ce problème en diminuant les temps d’accès à la DDR attachée. Malheureusement, l’absence de support de Sigma-C sur cette nouvelle puce nous empêche de le confirmer.

anr999 antibi o

burn er

deblocking_licenseP late retin a toggl e GMEAN 0 2 4 6 8 10 12 Speed up → stockage dans la DDR transferts via PCIe

Figure 6.14 – Speedups pour le stockage temporaire des images : (1) utilisation de la mémoire globale attachée au processeur MPPA (référence) ; (2) transfert direct des images depuis l’hôte via l’interface PCI-Express

Déroulement de la reconstruction géodésique L’opérateur de reconstruction géodésique,

déjà présenté en section 6.3.1, est souvent utilisé dans nos applications de traitement d’images. Il est caractérisé par une bouclewhile, illustrée en extrait 6.7, autour d’une transformation dont la suite est mathématiquement convergente. Comme la condition de

6. Le modèle flot de données

boucle dépend des données, il est impossible de déterminer le nombre d’itérations à la compilation, donc de dérouler totalement cette boucle. Le langage Sigma-C ne permet pas de gérer une telle construction. C’est notre environnement d’exécution qui s’en charge : chaque itération correspond à un subgraph, ce qui génère beaucoup de transferts de données depuis et vers l’hôte et diminue drastiquement les performances. Cependant, puisque la suite de transformations est convergente, réaliser des itérations supplémentaires n’a pas d’influence sur l’image résultante : il est donc possible de dérouler partiellement cette boucle sans en connaître le nombre d’itérations, ce qui diminue d’autant les transferts de données, tout en occupant plus de cœurs sur le MPPA. Nous avons ainsi réutilisé la passe de déroulage déjà implémentée pour le projet FREIA [29] dans notre compilateur source-à-source en amont de notre générateur de code Sigma-C. Nous représentons en figure 6.15 les speedups obtenus sur une collection d’applications utilisant l’opérateur de reconstruction géodésique, pour différents facteurs de déroulement. Dérouler d’un facteur 8 divise ainsi en moyenne les temps d’exécution d’un facteur ×3.5. Au delà d’un facteur 8, le gain de performance n’est plus significatif : le nombre d’itérations supplémentaires tend à réduire le gain issu du déroulement, tandis que l’occupation d’un plus grand nombre de cœurs peut également avoir un impact négatif sur les performances.

antibi o burn er retin a GMEAN 0 2 4 6 Speed up →

sans déroulage facteur 2 facteur 4 facteur 8 facteur 16

Figure 6.15 – Speedups pour différents facteurs de déroulage de la reconstruction géo- désique : (1) pas de déroulage de boucle (référence) ; (2) déroulage d’un facteur 2 ; (3) déroulage d’un facteur 4 ; (4) déroulage d’un facteur 8 ; (5) déroulage d’un facteur 16

Exécution sur l’hôte

La chaîne de compilation Sigma-C de Kalray permet de cibler également l’architecture x86 de la machine hôte. Nous avons donc mesuré les temps d’exécution de nos applications de test sur le processeur hôte Intel Core i7-3820 disposant de huit cœurs logiques. Chaque agent Sigma-C étant compilé sous la forme d’un thread, le nombre limité de cœurs du processeur hôte ne permet pas d’obtenir des performances similaires à la puce MPPA, comme le montre la figure 6.16. Nos applications s’exécutent ainsi en moyenne trois fois plus rapidement sur l’accélérateur de Kalray que sur l’hôte. Les applications comportant de profonds pipelines d’opérateurs morphologiques tirent particulièrement parti du MPPA face au processeur Intel. 96

6.3. Une nouvelle cible pour FREIA

anr999 antibi o

burn er

deblocking_licenseP late retin a toggl e GMEAN 0 2 4 6 8 Speed up →

Sigma-C sur i7 Sigma-C sur MPPA

Figure 6.16 – Speedups de l’exécution d’applications Sigma-C sur différentes architectures : (1) exécution sur CPU hôte Intel Core i7-3820 (référence) ; (2) exécution sur MPPA