# Chapitre 3

## Données partagées pour les machines hétérogènes réparties

L'essor des architectures hétérogènes est porté par plusieurs vagues technologiques et innovations d'usage, à l'instar des processeurs many-cœurs traités dans le chapitre 2. Dans les années 2000, l'hétérogénéité est souvent représentée par un système intégré comprenant un processeur généraliste hôte et un accélérateur matériel. Cette organisation est rendue populaire avec le détournement des cartes de rendu vidéo GPU pour effectuer du calcul numérique classique, permettant ainsi de démultiplier la vitesse d'exécution des codes parallèles réguliers en comparaison d'un CPU (Central Processing Unit). Si ce modèle perdure largement dans les systèmes HPC comme en témoignent les classements du TOP500 faisant la part belle aux GPGPU de Nvidia, la miniaturisation des composants, l'accélération du développement des systèmes embarqués grand public et l'évolution des contextes applicatifs nomades sont à l'origine de nouvelles architectures hétérogènes et distribuées. Ce constat est aujourd'hui étayé par le déferlement des applications touchant à l'IA, que ce soit pour des phases d'apprentissage machine ou d'inférence. Il est désormais courant d'utiliser dans le quotidien des systèmes embarqués composés de multiples unités de calcul dédiées à des tâches spécifiques et dont l'architecture est spécialisée en conséquence.

Dans une plateforme distribuée l'hétérogénéité intervient à différents niveaux : hétérogénéité des architectures de calcul (CPU, GPU, FPGA...), hétérogénéité des liens réseaux (Ethernet, Infiniband, Wifi, USB...), hétérogénéité des systèmes d'exploitation et des bibliothèques logicielles. À titre d'exemple, les processeurs basse-consommation basés sur l'architecture ARM (Acorn/Advanced Risc Management/Machine), développés à l'origine dans les années 1980 par Acorn (avec la participation d'Apple quelques années plus tard), présentent un jeu d'instructions et une organisation matérielle étudiés pour être plus économe en énergie que les processeurs traditionnels. Ceci justifie leur adoption massive à partir de 2010 dans les smartphones, les tablettes, les cartes de développement, les kits de robotique (Raspberry Pi, Odroid), plus récemment dans les ordinateurs portables Chromebook et Apple MacBook (avec la puce M1) et même dans les super-calculateurs du TOP500 comme c'est le cas pour le processeur Fujitsu A64FX [Okazaki et al., 2020]. Des infrastructures hybrides proposant des processeurs classiques (x86) et basse-consommation ARM permettent d'adapter au plus juste les performances applicatives et la consommation d'énergie, c'est le cas pour les micro-serveurs HPE Moonshot [HPE, 2014]. Ainsi, les applications peuvent être déployées sur des processeurs adaptés aux contraintes du moment. L'hétérogénéité intervient ici sur deux plans : 1) les architectures x86 et ARM sont dotées de jeux d'instruction différents et parfois d'adressage mémoire différents (32 et 64 bits) ce qui implique des versions du logiciel adaptées pouvant mener à des comportements et des résultats différents. 2) Ces deux architectures processeur visent des objectifs différents pour les performances calculatoires et la consommation énergétique, deux critères bien souvent antagonistes. Même si ces divergences tendent à s'estomper, cet exemple de plateforme hétérogène reflète la problématique de la portabilité entre nœuds de calcul.

Un autre exemple exhibant de l'hétérogénéité est représenté par les accélérateurs dédiés : Dans le contexte des tâches d'IA, de nombreuses puces GPGPU, ASIC, FPGA et many-cœurs sont proposées dans les serveurs et systèmes embarqués, comme par exemple les puces A100, T4 et Tegra de Nvidia, les TPU (Tensor Processing Unit) et CPU Tensor Core de Google, les dongles USB Movidius Myriad d'Intel, les processeurs reprogrammables Arria d'Intel, Vitis AI de Xilinx ou le many-cœur MPPA Coolidge de Kalray. Ces accélérateurs sont exploités par des suites logicielles spécifiques et bien souvent non-interopérables, ce qui rend le déploiement d'une application inter-accélérateurs compliqué techniquement.

> Pourtant, ces systèmes hétérogènes répondent à un enjeu de taille : comment concilier la performance calculatoire nécessaire aux nouveaux usages tout en restant dans une enveloppe énergétique contrainte par la technologie des batteries ou la dépense raisonnée des ressources.

Les travaux présentés au sein du chapitre s'inscrivent dans ce contexte technologique, à la croisée de plusieurs
thématiques de recherche souvent étudiées de manière indépendante : les systèmes embarqués, le calcul sur ressources hétérogènes et le partage de données dans les systèmes distribués. L'ensemble apporte de nouvelles hypothèses de travail qui nécessitent des contributions innovantes pour exploiter au mieux ces nouvelles architectures. L'approche proposée ici est d'aborder la problématique à travers le prisme de la gestion des données partagées. Pour illustrer cette problématique, deux plateformes sont présentées dans la figure 3.1. La première plateforme est un micro-serveur industriel RECS\Box 3 commercialisé par Christmann (figure 3.1a) en partie développé au sein des projets H2020 FiPS [Griessl et al., 2014] puis M2DC [Oleksiak et al., 2017] dans lesquels le CEA a contribué pour l'intégration des FPGA ainsi que pour des modèles de programmation. Cette plateforme est composée d'un châssis au format 1U comprenant les réseaux pour les données, la distribution d'énergie et les capteurs. Des emplacements sont prévus pour des cartes d'extension dédiées au calcul hétérogène, permettant de mixer processeurs haute-performance, processeurs basse-consommation et accélérateurs GPU et FPGA. L'ensemble forme une plateforme très intégrée et modulaire. La deuxième plateforme est un bac-à-sable expérimental (figure 3.1b) assemblé au CEA pour évaluer des intergiciels pour les calculs distribués. Cette plateforme est constituée d'un ensemble de cartes de développement embarquées interconnectées par un réseau Ethernet. Ces cartes sont représentatives des architectures de calcul embarquées dans les smartphones, la robotique et les véhicules autonomes.

<figure><img src="image_51.png" /><figcaption>(a) Christmann RECS\Box 3 (Antares).</figcaption></figure>

<figure><img src="image_52.png" /><figcaption>(b) Machine hétérogène bac-à-sable.</figcaption></figure>

Christmann RECS\Box 3 (Antares 1U)

<table><thead><tr><th>Nœud</th><th>Processeur</th><th>Cœurs</th><th>Mémoire</th><th>Disque</th><th>Réseau</th><th>#</th></tr></thead><tbody><tr><td>1 & 6</td><td>Intel Core i7 4700-EQ</td><td>4</td><td>16GB</td><td>mSATA SSD</td><td>Gb Ethernet</td><td>2</td></tr><tr><td>2</td><td>ARM Cortex A9 Xilinx XC7Z045</td><td>2</td><td>16GB</td><td>SD</td><td>USB 2.0</td><td>1</td></tr><tr><td>3 & 4</td><td>ARM Cortex A15 Exynos 5250</td><td>2</td><td>4GB</td><td>eMMC</td><td>USB 2.0</td><td>8</td></tr></tbody></table>

Machine hétérogène bac-à-sable

<table><thead><tr><th>Nœud</th><th>Processeur</th><th>Cœurs</th><th>Mémoire</th><th>Disque</th><th>Réseau</th><th>#</th></tr></thead><tbody><tr><td>Gateway</td><td>Intel Core i7 6800K</td><td>6</td><td>64GB</td><td>SATA SSD</td><td>Gb Ethernet</td><td>1</td></tr><tr><td>Raspberry Pi 3B+</td><td>ARM Cortex A53</td><td>4</td><td>1GB</td><td>SD</td><td>USB 2.0</td><td>2</td></tr><tr><td>Odroid XU4</td><td>ARM Cortex A15/A7</td><td>4/4</td><td>2GB</td><td>SD</td><td>USB 3.0</td><td>1</td></tr><tr><td>Odroid XU3</td><td>ARM Cortex A15/A7</td><td>4/4</td><td>2GB</td><td>SD</td><td>USB 2.0</td><td>1</td></tr><tr><td>HiKey Kirin 970</td><td>ARM Cortex A73/A53</td><td>4/4</td><td>6GB</td><td>UFS</td><td>USB 3.0</td><td>2</td></tr><tr><td>Nvidia Jetson TX2</td><td>Denver/ARM Cortex A57</td><td>2/4</td><td>8GB</td><td>eMMC</td><td>Gb Ethernet</td><td>1</td></tr><tr><td>Adapteva Parallella</td><td>ARM Cortex A9 Xilinx 7020/Epiphany III</td><td>2/16</td><td>1GB</td><td>SD</td><td>Gb Ethernet</td><td>1</td></tr></tbody></table>

(c) Description des nœuds de calcul pour les deux machines hétérogènes. # indique le nombre de nœuds de chaque type.

<caption>FIGURE 3.1 – Les deux machines hétérogènes utilisées dans les expérimentations présentées dans ce manuscrit.</caption>

Dans ces plateformes, l'hétérogénéité se traduit aussi par des performances calculatoires et des consommations d'énergie très différentes. Par exemple la consommation instantanée passe de quelques watts pour un processeur ARM Cortex A9 à plusieurs dizaines de watts pour un Intel i7 et jusque plusieurs centaines de watts pour certains gros accélérateurs (par exemple la carte Nvidia A100 SXM a une enveloppe thermique de 400 watts). En contrepartie, le temps de calcul est largement favorable au processeur i7 ou au GPU (pour peu que l'application exploite correctement le parallélisme), ce qui donne lieu à des budgets énergétiques nécessaires pour compléter le calcul et pouvant être
comparés (par exemple en joules). Bien que conçues pour des environnements opérationnels éloignés (en production ou pour de la recherche), ces deux plateformes partagent les mêmes problématiques de programmabilité. Et dans ce cas, cette problématique ne se limite pas à la simple utilisation des ressources pour distribuer le calcul sur les nœuds : elle consiste aussi à faire des choix sur le déploiement de l'application afin de respecter des contraintes à l'exécution (performance calculatoire) et remplir des objectifs opérationnels (réduire l'empreinte énergétique).

L'approche présentée dans ce manuscrit est de proposer un modèle de programmation unifié en mémoire partagée à l'échelle de la plateforme hétérogène distribuée, et de fournir des outils pour établir de manière semi-automatique un compromis entre performance calculatoire et dépense énergétique. Ces contributions répondent aux problématiques de la programmabilité et de l'exploitation rationnelle des ressources.

**Unification des mémoires physiquement réparties.** L'une des principales difficultés pour la programmation d'une plateforme telle que présentée en figure 3.1 est la gestion des données partagées entre les nœuds de calcul d'une part et entre les processeurs hôtes et les accélérateurs d'autre part. Classiquement, ces plateformes sont exploitées selon un modèle de programmation hybride constitué d'une couche de gestion haut-niveau pour la coordination des nœuds et de programmes spécifiques déployés sur chaque nœud prenant en compte le modèle de programmation et l'environnement de développement utilisé par l'accélérateur. Ce choix logiciel nécessite un effort de programmation non négligeable entraînant une mise au point du code plus difficile, avec le risque d'obtenir des performances dégradées en effectuant des choix peu avisés sur le placement des données ainsi que des copies mémoires inutiles. La programmation hybride requiert donc une expertise pointue dans différents langages ainsi qu'une connaissance fine de l'architecture matérielle ciblée. Il y a donc un intérêt à rendre la gestion des données transparente pour le développeur, d'unifier les interfaces sur chaque nœud de calcul et de fournir des outils d'optimisation pour orchestrer les transferts de données.

Les mémoires virtuellement partagées logicielles consistent à fédérer des mémoires physiquement réparties sur des nœuds distants. Elles permettent de conserver le modèle de programmation en mémoire partagée au dessus d'une architecture dépourvue de mémoire physique centrale, c'est-à-dire principalement qui ne rentre pas dans le cadre des multi-cœurs et des machines NUMA. Pour cela, un intergiciel est déployé entre d'une part le code métier et d'autre part des bibliothèques de communication ou de passage de message. Les MVP offrent un haut niveau d'abstraction, comme illustré en figure 3.2a : un espace d'adressage logique est rendu accessible pour tous les processus, et cet espace est construit indépendamment des mémoires physiques sous-jacentes. Un deuxième point est que la localisation exacte des données pointées par l'espace logique est géré par la MVP, ce qui inclut la potentielle réplication des données. Ces deux points rendent les systèmes MVP plus génériques que les systèmes PGAS (Patitioned Global Address Space) dans lesquels la localisation des données et les transferts entre mémoires restent à la charge du code applicatif.

Les MVP ont connu un développement rapide à la fin des années 80 avec la mise en réseau des stations de travail dans les instituts (les clusters Beowolf) et le déploiement de réseaux de communication entre centres de recherche. La MVP IVY [Li, 1988] est souvent citée en exemple comme ayant introduit des concepts toujours utilisés dans les implémentations modernes. Cependant, il apparaît rapidement que ces systèmes souffrent d'un problème de passage à l'échelle au-delà de quelques dizaines de nœuds. Dans cette période et jusqu'à la fin des années 90, de nombreuses MVP sont proposées [Nitzberg and Lo, 1991] : les innovations ne portent pas tant sur le concept lui-même, mais bien souvent sur le protocole de cohérence des données, dont le comportement détermine les performances du système à grande échelle. C'est par exemple le cas avec les modèles de cohérence relâchés implémentés dans les MVP Munin [Carter et al., 1991], Midway [Bershad et al., 1993] et TreadMarks [Keleher et al., 1994]. Une autre problématique classiquement rencontrée à l'époque concerne la représentation des entiers (l'endianness) pouvant différer d'une machine à l'autre et source de contributions [Zhou et al., 1992, Rinard et al., 1992] pour prendre en compte cette forme d'hétérogénéité (les MVP concernées partagent des pages système, et non des objets). Dans les années 2000, avec l'introduction du concept de grille de calcul informatique [Foster and Kesselman, 2004] mutualisant les ressources des centres de recherche à l'échelle d'un continent, de nouveaux systèmes MVP sont proposés [Antoniu et al., 2005, Nicolae et al., 2011] faisant cette fois l'hypothèse de ressources homogènes. Enfin, quelques systèmes à mémoire partagée ciblent des architectures hétérogènes composées d'un processeur hôte et d'un accélérateur [Gelado et al., 2010, Lin et al., 2012], sans pour autant généraliser à une plateforme distribuée. Les contributions suivantes s'inscrivent dans l'évolution des architectures de calcul, de la grappe de calculateurs au micro-serveur. Les aspects hétérogènes et embarqués introduisent de nouvelles hypothèses de travail et relancent les recherches sur l'usage des MVP dans ce contexte.

**Contributions pour la programmabilité des machines hétérogènes réparties.** Dans la ligne directe des projets européens H2020 FiPS et M2DC portant sur la conception de micro-serveurs hétérogènes, je propose en 2016 d'évaluer la pertinence de l'emploi d'une MVP logicielle afin d'abstraire la complexité des machines. Cette initiative conduit à l'implémentation d'une MVP complète dénommée SAT pour Share Among Things, ainsi qu'à la réalisation de nombreux travaux satellites et collaboratifs reposant sur le système développé. Au final, sur la période 2016 à 2020, ces travaux donneront lieu à une dizaine de publications dans des conférences nationales et internationales, ainsi qu'à un article de journal. Parmi les thématiques abordées, certaines traitent de la conception de SAT [Cudennec, 2017] et de son évaluation [Cudennec and Trabelsi, 2020], du modèle de programmation hybride en mémoire partagée et événementiel [Cudennec, 2018], de l'intégration d'une méthode de chiffrement par attributs [Stan et al., 2020], de l'exploration
des configurations de déploiement sur machine hétérogène [Trabelsi et al., 2019], de l'efficacité énergétique des communications [Cudennec, 2020] et encore de l'intégration d'un FPGA dans la MVP [Lenormand et al., 2021]. SAT servira de plus de support technique pour la thèse d'Erwan Lenormand [Lenormand, 2022], soutenue en 2022, que j'ai proposée et co-dirigée avec Henri-Pierre Charles (CEA), et dont le sujet porte sur la simplification de l'utilisation des FPGA à l'aide de mémoires partagées.
<figure><img src="image_53.png" /></figure>

## 3.1 Une MVP pour micro-serveur hétérogène

> “Cudennec, L. (2017). Software-distributed shared memory over heterogeneous micro-server architecture. In Heras, D. B., Bougé, L., Mencagli, G., Jeannot, E., Sakellariou, R., Badia, R. M., Barbosa, J. G., Ricci, L., Scott, S. L., Lankes, S., and Weidendorfer, J., editors, Euro-Par 2017 : Parallel Processing Workshops - Euro-Par 2017 International Workshops, Santiago de Compostela, Spain, August 28-29, 2017, Revised Selected Papers, volume 10659 of Lecture Notes in Computer Science, pages 366–377. Springer.
> 
> [Cudennec, 2017] CEA LIST.
> 
> Contributions | initiative | idées | implémentation | expérimentations | rédaction | présentation”

Le développement des activités sur la cohérence des données pour les architectures many-cœurs présentées dans le chapitre 2 a démontré l'importance de disposer de moyens d'évaluation et d'expérimentation au plus proche des plateformes cibles. La MVP que j'ai conçue et implémentée, dénommée SAT (pour *Share Among Things*), est à l'origine pensée pour dérouler fonctionnellement le comportement des protocoles de cohérence sur le principe d'un simulateur dirigé par les évènements. Mais à l'arrivée c'est une mémoire virtuellement partagée logicielle complète qui a été développée, reposant sur les techniques d'algorithmique répartie. SAT répond à deux objectifs : 1) permettre la programmation d'architectures de calcul hétérogènes et distribuées, à cheval entre le monde HPC et l'embarqué et 2) offrir un socle commun pour mener des développements dans le cadre de travaux de recherche sur le partage de données.

Pour le premier objectif, la MVP SAT a permis de déployer diverses applications sur la machine hétérogène distribuée Christmann RECS3, ainsi que sur des machines hétérogènes embarquées plus exploratoires, à des fins de démonstration, notamment au forum Teratec et au salon ISC en 2018. Ces démonstrations consistent à effectuer du traitement vidéo en temps réel en utilisant différentes configurations matérielles composées de nœuds de calcul haute-performance, de nœuds basse-consommation et d'accélérateurs. Ces configurations peuvent être changées dynamiquement et l'application est en mesure d'afficher les nouvelles performances de traitement (en images par seconde) et de consommation instantanée (en watts). L'application a été développée sur SAT sans aucune considération de la plate-forme matérielle, en reposant sur le haut degré d'abstraction offert par le paradigme de programmation en mémoire partagée. Un deuxième objectif atteint par SAT consiste à offrir un environnement exploratoire pour différents projets de R&D. C'est le cas par exemple pour les travaux visant à intégrer des FPGA dans les systèmes distribués, effectués dans le cadre de la thèse d'Erwan Lenormand (section 3.2.3). Dans ces travaux, SAT est utilisée pour reconstituer des flux de données à partir de données partagées massives et ainsi alimenter les FPGA malgré leur mémoire physique embarquée limitée. Un autre exemple est l'étude de systèmes d'aide à la décision pour le dimensionnement et la configuration d'applications distribuées en présence de contraintes multicritères (le compromis performance-énergie). Dans ce travail SAT est utilisée pour évaluer les performances des solutions explorées par le système de décision, de par la grande malléabilité des tâches sur la MVP (à l'instar des threads classiques) et la facilité de reconfiguration du déploiement. De nombreuses instances de SAT ont pu être lancées afin de construire une base de connaissance permettant de caractériser le comportement énergétique des applications sur des architectures hétérogènes distribuées comme nous le verrons dans la section 3.2.1. Dans la suite de chapitre, nous présentons différentes contributions construites autour de SAT et qui auraient été difficilement réalisables sans la maîtrise complète de la MVP tant sur le plan théorique que sur le plan de l'implémentation.
### 3.1.1 Éléments de conception de la MVP.

“Cudennec, L. (2020). Software-distributed shared memory for heterogeneous machines : Design and use considerations. CoRR, abs/2009.01507.

[Cudennec, 2020] CEA LIST, DGA MI.

Contributions | ■ initiative ■ idées ■ implémentation ■ expérimentations ■ rédaction

<figure><img src="image_54.png" /></figure>

<figure><img src="image_55.png" /><figcaption>(a) Espace d'adressage logique projeté sur les mémoires physiques.</figcaption></figure>

<figure><img src="image_56.png" /><figcaption>(b) Topologie logique de la MVP sous forme de réseau super-pair semi-structuré.</figcaption></figure>

<caption>FIGURE 3.2 – Principe et organisation de la MVP développée pour les machines hétérogènes.</caption>

Prendre la décision de concevoir et implémenter un système distribué aussi complexe qu'une MVP soulève des questions similaires à celles évoquées dans la section 2.1 avec la réalisation d'une chaîne de compilation pour un nouveau langage de programmation. Ce choix découle de plusieurs éléments de motivation : 1) la capacité à concevoir une MVP sur mesure, en ligne avec les objectifs thématiques de l'institut LIST au CEA (adéquation logiciel-matériel, efficacité énergétique, embarquabilité, hétérogénéité), 2) la maîtrise du code et la possibilité de disposer d'une brique technologique en dehors de toute propriété intellectuelle externe et 3) la montée en compétence pour rejoindre l'état de l'art sur le partage de données en environnement distribué. Le développement des fonctionnalités essentielles de SAT a nécessité 1,5 années-homme financées sur le projet H2020 M2DC [Oleksiak et al., 2017], dont la moitié est consacrée à la mise au point des algorithmes distribués pour la synchronisation et la gestion de la cohérence des données. Le système résultant est caractérisé par les points suivants.

- Un modèle de tâches parallèle, en mémoire partagée, similaire aux threads Posix, dans lequel les calculs sont organisés sous forme d'un ensemble de processus pouvant accéder à un espace logique commun. Les processus jouent différents rôles définis par le développeur et chaque rôle peut être instancié plusieurs fois lors du déploiement,

- La gestion transparente de l'espace logique, ce qui inclut la localisation et le transfert des données ainsi que la possible réplication de celles-ci sur différents nœuds (figure 3.2a).

- Un modèle pour l'accès aux données partagées inspiré de la cohérence à l'entrée [Bershad et al., 1993], dans lequel les accès sont conditionnés par l'acquisition d'un verrou en lecture, en écriture ou en lecture-écriture. Ce modèle garantit que les données sont disponibles et dans un état cohérent, en accord avec le modèle de cohérence choisi, dans la portée de code encadrée par la prise de verrou (acquire) et sa libération (release). En dehors de cette portée, la donnée est considérée dans un état indéterminé,

- Des objets et opérations collectives permettant la synchronisation des tâches tels que les rendez-vous, les barrières et les sémaphores,

- Une conception modulaire pour faciliter l'ajout de nouveaux protocoles de cohérence et de nouvelles fonctionnalités. SAT est une MVP multi-protocoles de cohérence, dans laquelle il est possible de déployer plusieurs protocoles en même temps pendant l'exécution d'une application et d'assigner dynamiquement un protocole spécifique à une donnée partagée lors de son allocation,

- Une implémentation portable permettant le déploiement sur différents types de machines opérées par différents systèmes d'exploitation. SAT représente 10 000 lignes de code ANSI C, reposant sur l'API minimale de
MPI (envoyer et recevoir des messages) et s'exécutant au niveau utilisateur. Ces choix techniques permettent de faciliter la compilation de SAT sur différents systèmes et de choisir une implémentation de MPI adaptée à l'infrastructure (SAT a été déployée sur les implémentations Open MPI [Gabriel et al., 2004], MPICH [Thakur and Gropp, 2007] et MPC [Pérache et al., 2008]),

- **Une organisation logique transparente** pour l'application, du déploiement à la terminaison : les intergiciels MPI et SAT prenant en charge les phases de démarrage (bootstraping), de construction du réseau logique (overlay) et de propagation du front de terminaison.

Plusieurs éléments sur la conception de SAT sont décrits dans le rapport [Cudennec, 2020] et seuls les points nécessaires à la compréhension des contributions présentées dans ce manuscrit sont donnés ici.

Dans les grandes lignes, SAT est une MVP logicielle qui se présente comme un intergiciel entre le programme métier et l'environnement de communication de type MPI. En pratique, c'est donc un programme MPI, formé d'une couche utilisateur faisant appel à l'API de SAT (une interface orientée mémoire partagée), et située au dessus de la couche SAT en charge de traduire ces appels en directives MPI sur le principe d'un automate réparti. L'organisation logique de SAT est un réseau super-pair semi-structuré dans lequel un ensemble de clients sont rattachés à un réseau pair-à-pair de serveurs (figure 3.2b). Les clients exécutent du code utilisateur (un rôle) et ont accès à l'API de SAT. Chaque client est rattaché à un serveur. Les serveurs sont en charge du stockage des données et de la gestion des métadonnées. Cette organisation classique se retrouve dans de nombreux systèmes distribués pour la gestion de fichiers (Ceph [Weil et al., 2006], Gfarm [Tatebe et al., 2002]) ou d'objets partagés (OceanStore [Kubiatowicz et al., 2000], JuxMem [Antoniu et al., 2005]).

<figure><img src="image_57.png" /><figcaption>FIGURE 3.3 – Espace d'adressage logique, allocation et stockage en mémoire physique dans la MVP SAT.</figcaption></figure>

**Découpage des données en chunks.** Dans SAT les données sont représentées sous forme de chunks, des unités atomiques comprenant les données brutes ainsi que des métadonnées. La figure 3.3 illustre les relations entre l'espace d'adressage logique, l'allocation et le stockage des données en mémoire physique. Sur la gauche, l'espace d'adressage logique est constitué d'un ensemble d'adresses, ici définies par un entier représenté sur 64 bits. Les chunks sont identifiés par une unique adresse de cet espace logique. Une donnée partagée peut être décomposée en plusieurs chunks de tailles différentes et les adresses de ces chunks ne sont pas nécessairement contiguës dans l'espace logique. À droite de la figure sont représentées les allocations en mémoire pour deux nœuds. Sur le nœud 1, les chunks *G* et *O* sont alloués de manière indépendante et se retrouvent à des adresses arbitraires en mémoire physique. Sur le nœud 2, les chunks *B*, *O* et *G* sont alloués d'un seul tenant, sous forme d'une chaîne circulaire double, ce qui implique dans le modèle SAT que les données soient allouées de manière contiguë en mémoire physique. Au niveau applicatif, il est donc possible d'effectuer de l'arithmétique de pointeurs au sein d'un chunk, mais aussi sur toute la longueur d'une chaîne de chunks. Cette organisation permet de dissocier la granularité des données exprimée par l'application de celle optimisée par le stockage dans la MVP. Elle permet de plus d'exprimer simplement des réorganisations de données telles que les transposées de matrice en allouant une chaîne de chunks correspondant à l'ordre dans lesquels les éléments doivent apparaître. En charge alors pour SAT d'effectuer la localisation et le transfert des chunks de manière transparente pour l'application.

**Modèle de programmation en mémoire partagée.** Les chunks sont des objets exposés au développeur d'application mais dont la gestion est effectuée par la MVP SAT. Ils font partie intégrante du modèle de programmation. Allouer une donnée dans SAT revient à allouer un ou plusieurs chunks (une chaîne de chunks). L'extrait de code présenté en
listing 4 montre comment allouer une donnée partagée de taille *size*, régie par le protocole de cohérence MESI à l'adresse *chunkid* de l'espace d'adressage logique. Dans le cas d'une chaîne de *chunks*, le *chunk* retourné par la primitive *MALLOC* est le premier de la chaîne (aussi nommé *head*). Les primitives *WRITE* et *RELEASE* délimitent une section de code dans laquelle le pointeur *chunk->data* est initialisé et les données pointées sont considérées comme cohérentes. En dehors de cette portée, ce pointeur ne doit pas être accédé car l'intergiciel est susceptible de le désalouer afin de rationaliser la mémoire physique locale. Ce type d'accès aux données partagées est le plus courant, mais il existe d'autres méthodes décrites dans la documentation [Cudennec, 2020], notamment 1) la projection d'une zone mémoire locale dans l'espace logique de SAT, en utilisant la primitive *MAP* qui prend en paramètre un pointeur fourni par l'utilisateur pour renseigner *chunk->data*. Ce champ reste alors accessible en dehors des portées de cohérence, sans pour autant offrir des garanties sur la cohérence des données qui y sont écrites. Et 2) la possibilité de construire une table des symboles effectuant une association entre une chaîne de caractères quelconque (pouvant représenter un UUID, un chemin dans un système de fichiers...) et une adresse dans l'espace logique de SAT. Dans ce cas, la *MVP* est en mesure de choisir les adresses des *chunks* et donc d'apporter un niveau d'abstraction supplémentaire au dessus de l'espace d'adressage logique.

<caption>Listing 4 - Allocation et accès à une donnée partagée dans la MVP SAT.</caption>

1 Consistency_t * consistency = newHomeBaseMESI();
2 Chunk_t * chunk = MALLOC(consistency, chunkid, N * sizeof(unsigned int));
3 unsigned int i = 0;
4
5 WRITE(chunk)
6 for(i = 0; i < N; i++) {
7 chunk->data[i] = i;
8 }
9 RELEASE(chunk)

**Les primitives de synchronisation** permettent d'effectuer des opérations collectives nécessaires au bon déroulement d'une application distribuée qui doit respecter certaines relations de causalité. Ces primitives incluent les barrières (tous les processus doivent atteindre cette instruction avant de poursuivre), les rendez-vous (n sur m processus, n ≤ m, doivent atteindre cette instruction avant que les m processus puissent poursuivre) et les signaux (un processus émet un signal pour autoriser les processus endormis sur ce signal à poursuivre). Ces algorithmes ont été implémentés en suivant les recommandations formalisées dans [Raynal, 2013]. Un exemple de schéma de synchronisation très répandu est le producteur-consommateur cadencé. Dans ce schéma, un processus producteur écrit sur une variable partagée des valeurs qui sont lues par un processus consommateur. Sans cadencement, l'ordre entre les écritures et les lectures est considéré indéterminé et chaque exécution peut générer un entrelacement différent. Dans ce cas il n'est pas possible de garantir que le consommateur puisse lire toutes les valeurs écrites par le producteur. En utilisant deux objets de synchronisation de type rendez-vous, il est possible de cadencer les lectures et les écritures : un premier rendez-vous est utilisé pour s'assurer que le producteur a bien écrit une nouvelle valeur avant d'autoriser le consommateur à lire la donnée partagée. Un deuxième rendez-vous est utilisé pour s'assurer que le consommateur a bien lu la donnée partagée avant d'autoriser le producteur à écrire une nouvelle. Bien que peu optimisé, ce schéma est très connu car il permet notamment d'implémenter des canaux de communication FIFO en mémoire partagée entre des processus, par exemple pour une application flot-de-données.

Cependant, si l'usage des objets de synchronisation s'avère être efficace pour exprimer des schémas statiques et réguliers tels que le maître-esclave, ils sont en revanche peu adaptés au développement d'applications plus dynamiques, par exemple en présence d'un nombre de processus variable et au comportement volatile, comme c'est le cas pour un modèle basé sur des services. Dans ce cas, le développeur doit créer et gérer dynamiquement des objets de synchronisation au gré des requêtes, ce qui constitue une tâche complexe et l'éloigne du code métier. C'est la raison pour laquelle un modèle de programmation événementiel est proposé pour étendre le modèle en mémoire partagée de SAT.
3.1.2 Modèle de programmation événementiel

“Cudennec, L. (2018). Merging the publish-subscribe pattern with the shared memory paradigm. In Menca-gli, G., Heras, D. B., Cardellini, V., Casalicchio, E., Jeannot, E., Wolf, F., Salis, A., Schifanella, C., Manumachu, R. R., Ricci, L., Beccuti, M., Antonelli, L., Sánchez, J. D. G., and Scott, S. L., editors, Euro-Par 2018 : Parallel Processing Workshops - Euro-Par 2018 International Workshops, Turin, Italy, August 27-28, 2018, Revised Selected Papers, volume 11339 of Lecture Notes in Computer Science, pages 469–480. Springer.
[Cudennec, 2018] CEA LIST.”

Contributions | ■ initiative ■ idées ■ implémentation ■ expérimentations ■ rédaction ■ présentation

<figure><img src="image_58.png" /><figcaption>FIGURE 3.4 – Application de traitement de flux vidéo *videostream* implémentée sur la MVP SAT en tirant partie du modèle de programmation hybride mémoire partagée/programmation événementielle. Une tâche de décodage d'un flux vidéo écrit les images dans des tampons alloués dans la MVP et partagés avec les tâches de traitement. Ces tâches sont notifiées d'une nouvelle image à traiter puis écrivent le résultat dans un tampon partagé en sortie. Le cadencement du traitement et l'ordonnancement des calculs sur les tâches sont obtenus par construction (sans code utilisateur spécifique) en se reposant sur les mécanismes de synchronisation du protocole de cohérence des données et du modèle événementiel.</figcaption></figure>

Dans le modèle de programmation événementiel PS (*Publish-Subscribe*), les lecteurs s'abonnent auprès d'un objet partagé et sont ensuite notifiés dès lors qu'un écrivain effectue une modification sur cet objet. Le modèle est par nature dynamique et volatile : les lecteurs peuvent s'abonner et se désabonner pendant l'exécution de l'application. Ce modèle repose sur des synchronisations relâchées et asynchrones, contrairement aux synchronisations fortes et bloquantes implémentées dans le modèle à mémoire partagée : Les processus peuvent effectuer des calculs et recevoir les notifi-cations en parallèle, pour être traitées en même temps ou à la fin du calcul, ce qui apporte un degré de parallélisme supplémentaire pour les tâches.

Si les systèmes à MVP et les systèmes événementiels ont été largement étudiés dans leurs domaines applicatifs res-
pectifs, une approche hybride offrant ces deux modèles de programmation au sein d'un même système n'apparaît pas
de manière aussi directe dans la littérature. Certains protocoles de cohérence des données, notamment basés sur des
politiques d'invalidation et de mise-à-jour, présentent des mécanismes événementiels : les mémoires détenant une copie
d'une donnée reçoivent des notifications, ce qui s'apparente à un abonnement. Cependant, les actions déclenchées suite
à ces notifications sont déterminées par le protocole de cohérence et ne sont donc pas modifiables pas l'application. La
partie événementielle est donc un mécanisme sous-jacent, et non pas un élément constitutif du modèle de programma-
tion. Dans [Mazzucco et al., 2009] une MVP est implémentée en utilisant le modèle de programmation événementiel de
JAVA, ce qui est là encore un mécanisme sous-jacent et non une hybridation des modèles.
Les motivations pour fusionner les modèles à mémoire partagée et événementiels sont multiples : un premier exemple est le couplage de code entre d'une part des nœuds de calcul HPC sur lesquels un code de calcul numérique s'exécute, et d'autre part une infrastructure orientée service utilisée pour surveiller l'avancement des calculs ou permettre à des applicatifs tierces d'interagir avec la simulation. Un exemple concret est donné dans le projet H2020 Lexis [Goubier et al., 2020b] dans lequel un code de simulation de propagation de tsunami (écrit pour machines à mémoire partagée NUMA) est optimisé pour remonter des alertes au plus tôt dans les régions géographiques concrènées, en se basant sur des compromis entre le temps de calcul et la précision de la simulation. Un couplage de code naturel s'opère donc entre la simulation numérique et le système d'alerte événementiel. Un deuxième exemple est le déploiement de nouvelles architectures pour l'automobile et les véhicules autonomes, comme étudiées dans le projet FACE [Design Spot, 2018], un projet commun entre le CEA et l'alliance Renault-Nissan-Mitsubishi. Ces architectures sont constituées d'un ensemble de calculateurs hétérogènes sur lesquels des applications critiques et non-critiques cohabitent pour apporter des fonctionnalités liées à la conduite autonome et au divertissement. Dans ce contexte applicatif, des codes numériques s'exécutent sur des accélérateurs et des modèles événementiels sont utilisés entre les nœuds, comme cela est le cas avec l'intergiciel SOME/IP [Völker, 2013] intégré dans la norme automobile AUTOSAR.

L'introduction du modèle PS dans SAT repose sur une idée simple : un *chunk* est un objet partagé mutable sur lequel les tâches peuvent s'abonner et être ainsi notifiées dès lors que l'une d'entre elles effectue une écriture -selon le modèle de programmation en mémoire partagée- sur ce *chunk*. L'interface de programmation proposée par SAT comprend une primitive d'abonnement **SUBSCRIBE** prenant en paramètres un *chunk* ainsi qu'un pointeur vers une fonction *handler* à appeler lorsque ce *chunk* est modifié. Une seconde primitive permet à l'inverse de se désabonner des modifications opérées sur un *chunk*. Si l'interface utilisateur s'avère être simple, la complexité de l'approche est en contrepartie reléguée dans l'intergiciel système. Et cette complexité détermine certains choix effectués dans le modèle de calcul.

- Les notifications sont enregistrées dans une file puis traitées séquentiellement. Ce mécanisme interdit d'appeler la fonction *handler* lors d'une notification si le code *utilisateur principal* ou une autre fonction *handler* est en cours d'exécution. Ce choix a pour conséquence de limiter le parallélisme dans les processus, mais il permet une implémentation plus robuste dans l'intergiciel SAT et offre un modèle de calcul plus simple pour l'utilisateur. La raison principale est que le parallélisme dans les processus est susceptible d'introduire un entrelacement complexe des requêtes émises et des résultats reçus par le protocole de cohérence qui doit alors arbitrer localement à quel fil d'exécution transmettre les données et les privilèges d'accès, ce qui revient à concevoir un protocole de cohérence hiérarchique. Un tel protocole hiérarchique est coûteux à développer et difficile à mettre au point.

- Les notifications ne contiennent pas la donnée modifiée. Le mécanisme de notification fonctionne donc en mode *pull*, c'est à dire que le processus notifié doit effectuer une demande d'accès au *chunk* de sa propre initiative, dans la fonction *handler* par exemple (si cet accès est requis). Le mode *push* consiste à joindre la donnée modifiée avec la notification. Ce mode pose des problèmes de cohérence car il n'est pas encadré par un accès classique en mémoire partagée, et donc par une prise de verrou dans une portée de code. Dès lors, la donnée transférée échappe à toute relation de causalité en lien avec les autres évènements de cohérence, et il n'est pas possible de garantir un niveau de fraîcheur sur la version de la donnée lors de sa mise à disposition en mode *push*. Pour cette raison, ce mode de notification n'est pas proposé dans SAT. Un mode hybride peut être proposé qui consiste à associer à une notification la prise de verrou. Dans ce mode, le code *utilisateur appelé* dans le *handler* s'exécute avec l'assurance que le *chunk* est déjà accessible, ce qui permet de simplifier le protocole en supprimant une étape. La contrepartie est cependant d'introduire du délai dans le mécanisme, la notification ne pouvant être délivrée au code *utilisateur tant que la prise de verrou sur le chunk* n'est pas effective, ce qui peut s'avérer être inadapté dans le cas d'un système nécessitant de la réactivité.

L'application de traitement de flux vidéo *videostream* est une base de code permettant de prendre un flux vidéo en entrée (en ligne, à partir d'une caméra ou hors-ligne, à partir d'un fichier), d'appliquer un traitement d'image sur chaque *frame*, puis d'écrire la séquence obtenue dans un fichier ou de l'afficher sur un écran. Cette base de code a été portée sur la MVP SAT, en tirant partie du modèle de programmation hybride en mémoire partagée et événementiel. Le principe, illustré en figure 3.4, est le suivant : pour chaque instance de rôle de traitement d'image, un tampon partagé est déclaré pour contenir l'image d'origine et un tampon partagé est déclaré pour contenir le résultat du traitement. Ces tampons sont donc implémentés par un *chunk* ou par une chaîne de *chunks* dans SAT. Deux implémentations sont évaluées : 1) une implémentation en mémoire partagée (dénommée RR) dans laquelle des rendez-vous sont utilisés pour synchroniser les productions et consommations, ce qui donne lieu à une répartition équitable des images sur les tâches de traitement et suivant un ordonnancement de type tourniquet. 2) une implémentation hybride (dénommée PS et représentée en figure 3.4) dans laquelle les tampons sont accédés en écriture selon le modèle en mémoire partagée classique et accédés en lecture selon le modèle événementiel. Une boucle de rétropropagation est obtenue en abonnant la tâche d'acquisition aux tampons de sortie des tâches de traitement. Dès lors, lorsqu'une tâche de traitement écrit un résultat sur son tampon de sortie, une notification est envoyée par SAT à la tâche d'acquisition qui peut alors
<table><caption>TABLE 3.1 – Temps de calcul en secondes et consommation instantanée estimée en watts pour différentes topologies (A-F) de l'application de traitement vidéo implémentée sur SAT en utilisant les objets classiques de synchronisation en mémoire partagée (un ensemble de rendez-vous permettant la distribution des images sur les tâches de traitement selon la méthode du tourniquet Round-Robin) et en utilisant le modèle de programmation événementiel publish-subscribe. Résultats obtenus sur la machine Christmann RECS\Box 3 présentée en figure 3.1a, en utilisant jusqu'à 8 processeurs ARM Cortex A15 et 2 processeurs Intel Core i7.</caption><thead><tr><th>Topologie</th><th>A</th><th>B</th><th>C</th><th>D</th><th>E</th><th>F</th></tr></thead><tbody><tr><td>RR - Round-Robin (s)</td><td>220</td><td>177</td><td>286</td><td>233</td><td>221</td><td>286</td></tr><tr><td>PS - Publish-Subscribe (s)</td><td>218</td><td>153</td><td>401</td><td>359</td><td>209</td><td>198</td></tr><tr><td>Consommation (watts)</td><td>58</td><td>58</td><td>85</td><td>114</td><td>114</td><td>114</td></tr></tbody></table>

décider d'écrire une nouvelle image dans son tampon d'entrée, ce qui constitue un cadencement par construction. La répartition des images sur les tâches de traitement s'effectue alors en fonction de la disponibilité de ces tâches, sur le modèle de l'ordonnancement glouton. Cette approche est intuitivement adaptée aux architectures de calcul hétérogènes distribuées, dans lesquelles les unités de calcul effectuent les traitements à des vitesses différentes.

Pour vérifier cette intuition, l'application videostream a été évaluée dans les versions RR et PS sur le micro-serveur hétérogène Christmann RECS3, composé de 8 nœuds ARM Cortex A15 et 2 nœuds Intel Core i7. La table 3.1 présente les résultats obtenus pour différentes topologies (A-F) définies par le nombre de tâches de traitement, le nombre de serveurs SAT et la projection de ces instances sur les ressources de calcul (les détails sont donnés dans [Cudennec, 2018]). La consommation instantanée en watts induite par la topologie est indiquée à titre indicatif. Le temps de calcul est donné en secondes pour les configurations RR et PS. La figure 3.5 complète ces résultats en indiquant la répartition des images sur les tâches de traitement. Une première conclusion est qu'il existe des configurations dans lesquelles le modèle événementiel PS n'est pas la meilleure solution. Ce résultat contre-intuitif est illustré par les topologies C et D, dans lesquelles les communications induites par les messages de contrôle du modèle événementiel deviennent problématiques : les liens réseaux entre les nœuds ARM sont basés sur le protocole USB2 (un contrôleur partagé par 4 processeurs ARM) et souffrent d'une latence élevée (~1 ms), ce qui dégrade les performances en générant des temps d'attente au niveau des tâches de traitement. A l'inverse, l'implémentation RR permet de trouver un régime établi dans l'entrelacement des communications (en comparaison du comportement dynamique de PS), ce qui se traduit par des performances nettement meilleures.

Une deuxième conclusion est que la distribution de la gestion des données et des métadonnées de la MVP sur plusieurs serveurs SAT permet de contrebalancer les faibles performances des liens réseaux. Ce cas est illustré par les topologies E et F, toutes deux basées sur la topologie D mais avec respectivement 2 et 4 serveurs SAT là où la topologie D n'en contient qu'un. L'augmentation du nombre de serveurs SAT s'accompagne d'une amélioration significative du temps de calcul pour l'implémentation PS, portée par une meilleure répartition des messages de contrôle du modèle événementiel entre les nœuds. À l'inverse, les performances de l'implémentation RR diminuent, l'utilisation de plusieurs serveurs SAT s'accompagnant d'un nombre de rebonds (hops) plus grand pour certaines requêtes de cohérence.

**En conclusion**, le modèle de programmation événementiel couplé au modèle de programmation en mémoire partagée apporte une couche d'abstraction supplémentaire quant à la gestion des synchronisations et des accès aux données. Cette approche est particulièrement adaptée pour la programmation des architectures hétérogènes qui par nature demandent plus de flexibilité dans la gestion des tâches et des données contrairement à des architectures homogènes dans lesquelles les calculs peuvent être déployés de manière plus uniforme. Dans certaines configurations, cette contribution permet d'obtenir de meilleures performances calculatoires en simplifiant le motif de communication.

La programmation événementielle est aussi utilisée dans le cadre d'une application de réseau de capteurs visant à offrir un consensus-ε [Irofti, 2020], c'est-à-dire un consensus dans lequel les participants ne s'accordent pas sur une valeur unique, mais font en sorte que les valeurs locales convergent en un temps fini. L'implémentation du consensus sur SAT repose sur le mécanisme événementiel pour faire en sorte que les voisins d'un capteur soient notifiés d'une nouvelle valeur et ainsi affiner leur prédiction. Des expérimentations ont été menées en collaboration avec Dîna Irofti (EDF) sur des bases de données d'AirParif dans lesquelles la perte d'un ou plusieurs capteurs est simulée pour observer la résilience du système. Un deuxième exemple est la possibilité d'utiliser le système événementiel pour faciliter les interactions entre la MVP logicielle et une extension déployée sur un FPGA. Ce cas d'utilisation fait l'objet des travaux de thèse d'Erwan Lenormand (CEA) que je co-dirige avec Henri-Pierre Charles (CEA) et qui sont décrits dans la section 3.2.3.

Ces exemples applicatifs montrent qu'au delà d'offrir un intergiciel de gestion de données partagées, SAT a permis d'effectuer une réflexion sur le modèle de programmation, un élément déterminant pour l'adhésion des développeurs. Cependant, l'abstraction offerte au niveau de l'API est obtenue en contrepartie du déploiement d'un intergiciel complexe, souvent accompagné de surcoûts principalement dans les communications et pouvant entraîner une baisse des performances applicatives.
<figure><img src="image_59.png" /></figure>

FIGURE 3.5 – Répartition du nombre d’images traitées sur chaque tâche de l’application de traitement vidéo implé- mentée sur SAT en utilisant la mémoire partagée (répartition équitable selon la méthode du tourniquet, RR) et son extension au modèle de programmation événementiel (répartition à la demande selon le modèle *publish-subscribe*, PS), pour différentes topologies (A-F). Résultats obtenus sur la machine Christmann RECS|Box 3 présentée en figure 3.1a, en utilisant jusqu’à 8 processeurs ARM Cortex A15 et 2 processeurs Intel Core i7. Pour chaque tâche de traitement, l’implémentation déployée est indiquée par un code couleur.

3.1.3 Comparaison des performances de la MVP avec MPI et ZeroMQ

“ Cudennec, L. and Trabelsi, K. (2020). Experiments using a software-distributed shared memory, MPI and 0mq over heterogeneous computing resources. In Balis, B., Heras, D. B., Antonelli, L., Bracciali, A., Gruber, T., Hyun-Wook, J., Kuhn, M., Scott, S. L., Unat, D., and Wyrzykowski, R., editors, Euro-Par 2020 : Parallel Processing Workshops - Euro-Par 2020 International Workshops, Warsaw, Poland, August 24-25, 2020, Revised Selected Papers, volume 12480 of Lecture Notes in Computer Science, pages 237–248. Springer.

[Cudennec and Trabelsi, 2020] CEA LIST, DGA MI.

Contributions | initiative | idées | implémentation | expérimentations | rédaction | présentation

<figure><img src="image_60.png" /></figure>

Dans la littérature, les mémoires virtuellement partagées logicielles sont régulièrement décriées pour les faibles performances obtenues en comparaison de systèmes de programmation plus proches de la machine. Plusieurs études montrent en effet qu'une application écrite sur une MVP est significativement plus lente qu'une même application écrite sur un intergiciel de passage de messages. La table 3.2 regroupe un certain nombre de ces études, du début des années 90 à aujourd'hui. À la fin des années 1980, [Li, 1988] montre que la MVP Ivy, système précurseur dans les grappes de calculateurs, ne passe pas à l'échelle au delà de quelques dizaines de nœuds, ce qui limite son utilisation à des petits déploiements et ne permet pas d'obtenir des accélérations parallèles importantes. Dans la même temporalité, au début des années 1990, le standard MPI [Walker, 1992] est proposé pour programmer les environnements distribués. Le passage de messages devient alors - et reste aujourd'hui encore - le principal modèle de programmation utilisé sur les super-calculateurs, ne laissant que peu de place pour la programmation en mémoire partagée sur des déploiements inter-nœuds.

Depuis une quinzaine d'années, la tendance générale montre que le surcoût introduit par l'utilisation d'un intergiciel complexe tel qu'une MVP tend à s'estomper. Aujourd'hui, les applications déployées sur les MVP à l'état de l'art offrent des performances proches de celles déployées sur du passage par message. Dans certains cas, la MVP permet même d'obtenir de meilleures performances, ce qui est par exemple constaté avec JuxMem [Antoniu et al., 2007] dès 2007 sur la plateforme Grid'5000 [Bolze et al., 2006], ainsi que plus récemment avec Grappa [Nelson et al., 2015] et Argo [Kaxiras et al., 2015] en 2015 sur des grappes de calculateurs interconnectées par des réseaux Mellanox InfiniBand. Dans ces trois travaux, le nombre de noeuds utilisés pour évaluer les performances est raisonnablement grand, de l'ordre de la centaine, et permet d'apprécier le passage à l'échelle. Il reste cependant très en dessous des grands déploiements pouvant être menés sur des super-calculateurs, notamment pour de grandes simulations physiques impliquant des milliers, voire des dizaines de milliers de nœuds. Malgré cela, l'usage de système MVP est désormais envisageable, et est même devenu un élément de réussite déterminant pour certaines architectures, par exemple pour offrir un cache logique unifié dans les puces many-cœurs comme présenté dans la section 2.2. Si la MVP n'est pas candidate pour des
<table><caption>TABLE 3.2 – Deux décennies d’évaluation de performances entre l’utilisation d’une MVP et l’utilisation d’un intergiciel de passage de message (MP). Certains systèmes* sont déployés au dessus de systèmes MP et sont considérés équivalents à une implémentation MP. # indique le nombre de nœuds utilisés dans les expérimentations. Les résultats sont retranscris tels que indiqués dans les papiers cités et ne peuvent faire l’objet d’une comparaison directe en l’absence d’une méthodologie expérimentale commune. Il est cependant possible d’observer la tendance générale des performances obtenues entre les systèmes MVP et MP au fil des avancées technologiques.</caption><thead><tr><th>Référence</th><th>Système MP</th><th>Système MVP</th><th>#</th><th>Performance de la MVP</th></tr></thead><tbody><tr><td>[Lu et al., 1995]</td><td>PVM</td><td>TreadMarks</td><td>8</td><td>15% of PVM speedup to 5% slower</td></tr><tr><td>[Scales and Gharachorloo, 1997]</td><td>Oracle database*</td><td>Shasta</td><td>2</td><td>2-4 times slower</td></tr><tr><td>[Bader and Jájá, 1999]</td><td>MPICH</td><td>CVM</td><td>8</td><td>10 times slower</td></tr><tr><td>[Werstein et al., 2003]</td><td>PVM, MPI</td><td>TreadMarks</td><td>32</td><td>slower, except for Mandelbrot kernel</td></tr><tr><td>[Antoniu et al., 2007]</td><td>GridRPC*</td><td>JuxMem</td><td>53</td><td>3 times faster</td></tr><tr><td>[Gelado et al., 2010]</td><td>CUDA*</td><td>GMAC ADSM</td><td>2</td><td>match</td></tr><tr><td>[Dimakopoulos and Hadjidoukas, 2011]</td><td>MPI</td><td>MOME, MOCHA</td><td>16</td><td>6-8 times slower</td></tr><tr><td>[Lin et al., 2012]</td><td>SysLink</td><td>Reflex</td><td>3</td><td>83% less energy, 2.5% slower</td></tr><tr><td>[Nelson et al., 2015]</td><td>MapReduce*, GraphLab*</td><td>Grappa</td><td>128</td><td>1.3 times faster</td></tr><tr><td>[Kaxiras et al., 2015]</td><td>MPI</td><td>Argo</td><td>128</td><td>match or exceed</td></tr><tr><td>[Beri et al., 2017]</td><td>StarPu*, SUMMA*</td><td>Unicorn</td><td>10</td><td>performs quite close</td></tr></tbody></table>

déploiements sur de grandes infrastructures, elle devient pertinente pour des systèmes intermédiaires, notamment des architectures hétérogènes pouvant bénéficier d’une couche d’abstraction logicielle visant à masquer la complexité en terme de programmabilité.

Les raisons de cette évolution des performances sont multiples : un premier constat repose sur le développement de réseaux de communication de plus en plus performants, que ce soit à l’échelle des grappes de calcul et des puces dans lesquels les réseaux haute-performance et les NoC bénéficient de technologies innovantes telles que la fibre optique, l’empilement 3D ou la normalisation des accès directs aux mémoires distantes des accélérateurs matériels. Le deuxième constat est l’augmentation de la taille des mémoires physiques et des mémoires caches, permettant aux systèmes MVP d’offrir de grands espaces logiques implémentés dans des mémoires rapides, favorisant la réutilisation des données. Ainsi, à l’origine pénalisée par l’utilisation de protocoles de communication entraînant un grand nombre de messages et des synchronisations bloquantes, la MVP peut désormais être vue comme un grand cache unifié inter-nœuds, sur lequel un modèle de programmation à mémoire partagée est employé.

La comparaison entre une application déployée sur MVP et son équivalent sur MP n’est pas évidente à réaliser : notamment parce qu’il est difficile de déterminer si les performances de deux implémentations effectuées avec des modèles de programmation différents peuvent être rigoureusement comparées. D’inévitables biais dans la réalisation de la démonstration interviennent : les deux implémentations ont-elles reçu le même niveau d’optimisation ? Ont-elles accès aux même capacités matérielles ? Le noyau de calcul est-il adapté aux deux modèles de programmation ? Il n’y a pas à notre connaissance de méthodologie définie et normalisée pour comparer deux modèles de programmation. Ainsi, les comparaisons établies dans l’état de l’art sont le résultat, comme bien souvent, de retours d’expérience obtenus après des cycles de développements et de déploiements effectués dans divers contextes d’utilisation.

**Déploiement et comparaison de ZeroMQ, MPI et SAT.** La MVP SAT a été utilisée pour déployer des applications parallèles, notamment l’application de traitement vidéo videostream présentée en section 3.1.2, sur des architectures hétérogènes distribuées. Dans ce travail [Cudennec and Trabelsi, 2020], cette application a été réécrite en se basant sur les versions C d’OpenMPI et de ZeroMQ, deux implémentations d’intergiciels de passage de messages largement utilisées dans les systèmes HPC et HPEC. ZeroMQ<fnref n="1" /> est une bibliothèque récente (2010) visant des applications embarquées et dont l’intergiciel est conçu de manière minimale en comparaison des implémentations classiques de MPI. L’API repose sur des motifs de communication haut-niveau (request-reply, publish-subscribe, ...) contrairement à l’approche send-receive orientée message de OpenMPI. En contrepartie, la construction du réseau logique de ZeroMQ permettant aux processus de communiquer n’est pas transparente et doit être exprimée au niveau applicatif, en renseignant les adresses réseau des processus avec lesquels communiquer, plutôt que de se baser sur des identifiants logiques et des groupes de communication comme le propose MPI. ZeroMQ, OpenMPI et SAT représentent donc trois niveaux croissants d’abstraction de la plateforme matérielle, ce qui usuellement se traduit par une baisse de l’efficacité calculatoire. L’objectif du portage de l’application de traitement vidéo est de comparer les approches en termes de complexité de programmation et de performances calculatoires. La figure 3.6 présente une vue synthétique des résultats obtenus par ces trois implémentations déployées sur les nœuds de la machine hétérogène bac-à-sable présentée en figure 3.1b. Le temps de calcul est mesuré pour trois résolutions d’une même vidéo (UHD, UHD-1 et UHD-2).

<footnote n="1">1. ZeroMQ https://zeromq.org</footnote>
<figure><img src="image_61.png" /><figcaption>FIGURE 3.6 – Comparaison des temps de calcul mesurés pour l’application de traitement vidéo *videostream* implémentée au dessus de la MVP SAT (S-DSM), de OpenMPI et de ZeroMQ, pour différentes résolutions de flux vidéo (HD, UHD-1 et UHD-2), chaque image non compressée de la vidéo pesant respectivement 2 Mo, 8 Mo et 33 Mo. La plateforme de calcul est une grappe hétérogène présentée en figure 3.1b composée d’un serveur et de cartes de développement embarquées, interconnectées par un réseau Ethernet.</figcaption></figure>

> Les résultats montrent que l'application portée sur ZeroMQ est la plus performante et que la version portée sur la MVP SAT (dont les mécanismes de communication sont implémentés sur OpenMPI) est jusqu'à deux fois plus rapide que celle écrite sur OpenMPI exclusivement.

Différentes variantes du code OpenMPI ont été testées : MPI Sync signifie que les primitives de communication sont bloquantes, c'est-à-dire qu'OpenMPI assure que le message a bien été délivré avant de permettre au processus de continuer son exécution. MPI Async indique que les primitives de communication sont asynchrones, c'est-à-dire qu'elles ne sont pas bloquantes et permettent de continuer l'exécution pendant la livraison du message. Cette approche nécessite une autre forme de synchronisation dans le code utilisateur afin de ne pas écraser le tampon d'envoi lors d'un prochain appel à la primitive. single buffer indique qu'un seul tampon d'envoi est alloué pour transférer les images aux processus de traitement. Enfin, multiple buffers indique qu'un tampon partagé est alloué par processus de traitement, ce qui augmente le degré de parallélisme. Ces quatre variantes du code représentent des versions de plus en plus complexes à écrire (gestion de tampons partagés, gestion d'objets de synchronisation entre les fils d'exécution) dans le seul but d'augmenter le degré de parallélisme et d'obtenir de meilleures performances applicatives. Ce travail d'optimisation du code porté sur MPI est aussi l'illustration de l'expertise et de l'effort de développement à fournir pour obtenir une application suffisamment optimisée.

Plusieurs déploiements du code porté sur SAT ont été effectués : ces déploiements consistent notamment à faire varier la topologie de la MVP en augmentant le nombre de serveurs de métadonnées et le placement sur les ressources de calcul. Pour un même code, ces configurations ont une influence importante sur les performances à l'exécution : du simple au double pour le traitement du flux UHD-2 entre SAT en mode journalisation des évènements et 1 serveur de métadonnées, et le mode sans journalisation avec 4 serveurs de métadonnées. Certaines configurations de la MVP permettent d'obtenir de meilleures performances que les implémentations optimisées sur MPI. Ceci est expliqué par un effet de cache logiciel inter-nœuds : les données écrites dans la MVP sont stockées sur les serveurs SAT et ne viennent pas saturer directement les mémoires physiques des nœuds comme cela est le cas pour les implémentations sur OpenMPI.

**En conclusion,** la MVP SAT permet de déployer efficacement des applications en mémoire partagée sur des infrastructures de calcul distribuées. Les mesures effectuées consolident les bonnes performances obtenues par les systèmes MVP modernes tels que Grappa et Argo. Dans ce travail, l'aspect hétérogène de l'architecture de calcul montre de plus que MPI n'est pas adapté pour un déploiement sur des nœuds embarqués, le principal obstacle étant la mémoire physique limitée, insuffisante pour réaliser une gestion efficace des files de messages. Un second obstacle est la stratégie de
réception des messages par attente active implémentée dans la plupart des distributions MPI et qui rend le déploiement très inefficace sur les architectures embarquées : ce point est développé dans la section 3.2.2, en lien avec la gestion de l'énergie. Bien que écrite au dessus d'OpenMPI, la MVP SAT permet d'obtenir de meilleures performances en équilibrant les données sur les mémoires physiques en fonction des capacités de chaque nœud. Cette propriété est aussi observée avec la MVP Argo, elle aussi écrite au dessus de MPI.

Pour les applications distribuées et/ou massivement parallèles, écrire un code performant n'est pas la seule pro-
blématique : la préparation et la configuration du déploiement, c'est-à-dire le dimensionnement de l'application, la
sélection des ressources matérielles et l'assignation des tâches sur les ressources constituent des éléments détermi-
nants dans la réussite du calcul. Ces éléments sont bien souvent à la charge de l'utilisateur, même dans les grands
centres de calcul, ce qui se traduit par des déploiements inefficaces, par exemple pour assurer un taux d'utilisation des
ressources matérielles raisonnable. C'est un constat qui est partagé dès lors qu'une application est déployée sur une
infrastructure parallèle et distribuée. De plus, le volet énergétique d'une exécution est devenu un critère d'évaluation
au même titre que la performance calculatoire, pour les environnements opérationnels contraints en énergie comme
l'embarqué mais pas seulement : les grands centres de calcul proposent aussi des rapports d'exécution incluant le coût
en énergie du calcul (par exemple en kJ) comme c'est le cas pour le TGCC (Très Grand Centre de Calcul). Dans le
contexte de la MVP SAT devant la complexité des architectures hétérogènes distribuées et l'organisation logique de la
mémoire partagée, un outil d'aide à la décision basé sur des techniques exploratoires et d'apprentissage machine est
proposé, dont l'approche est présentée dans la suite. Cet outil vise à offrir un compromis entre la performance calcu-
latoire et la consommation d'énergie de l'application. La section suivante présente les contributions liées à la maîtrise
de la dépense énergétique dans la MVP.

## 3.2 Maîtrise de la consommation d'énergie dans une MVP

La dépense d'énergie d'une mémoire virtuellement partagée répartie est un sujet d'étude complexe car le système interagit avec de nombreux éléments matériels susceptibles de consommer de l'énergie de manière significative s'ils sont utilisés peu efficacement. C'est le cas par exemple pour les équipements de communication si le protocole de cohérence génère de nombreux messages, ou des unités de calcul si les tâches génèrent des accès peu optimisés à la mémoire partagée. Si la gestion de la consommation d'énergie a été étudiée dans des grands intergiciels distribués, il n'existe pas à notre connaissance de contributions visant à réduire l'empreinte énergétique d'une MVP logicielle lorsque celle-ci est déployée sur une plateforme hétérogène embarquée. Dans les travaux suivants, trois axes ont été explorés afin d'apporter des solutions au niveau 1) de la configuration de la MVP, 2) de la gestion des communications et 3) de l'intégration de ressources de calcul efficaces sur le plan énergétique. Le premier axe consiste en la recherche d'un compromis entre performance calculatoire et consommation d'énergie. Cet axe présenté en section 3.2.1 propose un outil d'aide à la décision pouvant être généralisé à d'autres systèmes distribués. Le deuxième axe consiste en la réduction de la consommation d'énergie lors des phases d'attentes actives sur la réception des messages. Cet axe présenté en section 3.2.2 vise à améliorer l'adéquation entre l'intergiciel de passage de messages et les capacités matérielles embarquées possiblement limitées. Enfin, un troisième axe consiste à étendre la MVP sur des accélérateurs reconfigurables afin de favoriser des phases calculatoires efficaces du point de vue de l'énergie. Cet axe présenté en section 3.2.3 consiste en la proposition d'un modèle de programmation pour exploiter de manière transparente une architecture hybride logicielle et matérielle.

### 3.2.1 Aide à la décision pour la configuration d'une MVP

> Trabelsi, K., Cudennec, L., and Bennour, R. (2019). Application topology definition and tasks mapping for efficient use of heterogeneous resources. In Schwardmann, U., Boehme, C., Heras, D. B., Cardellini, V., Jeannot, E., Salis, A., Schifanella, C., Manumachu, R. R., Schwamborn, D., Ricci, L., Sangyoon, O., Gruber, T., Antonelli, L., and Scott, S. L., editors, Euro-Par 2019 : Parallel Processing Workshops - Euro-Par 2019 International Workshops, Göttingen, Germany, August 26-30, 2019, Revised Selected Papers, volume 11997 of Lecture Notes in Computer Science, pages 258–269. Springer.
> 
> [Trabelsi et al., 2019] CEA LIST.
> 
> Contributions | ★ initiative ■ idées ☐ implémentation ■ expérimentations ■ rédaction ☐ présentation

Déployer une application parallèle sur une machine de calcul distribuée est un problème complexe, bien souvent sous-estimé et réalisé à la main par l'utilisateur. Cette thématique de recherche n'est pas nouvelle et a été théorisée et étudiée dès l'apparition des machines parallèles, par exemple à travers la méthode PCAM (Partition Communicate Agglomerate Map) proposée par Ian Foster en 1995 [Foster, 1995]. Cette méthode décompose le déploiement en quatre phases : 1) la décomposition du calcul permet d'exhiber le parallélisme de tâches ou de données, sans considérations dimensionnantes de la plateforme matérielle ciblée, 2) les communications entre tâches sont établies pour construire un graphe, 3) les tâches sont regroupées ou fusionnées par affinité et enfin 4) les groupes de tâches sont projetés
<figure><img src="image_62.png" /><figcaption>FIGURE 3.7 – Temps de calcul mesurés pour une application de traitement d'image distribuée sur le serveur Christmann RECSBox 3 présenté en figure 3.1a pour 4 configurations du déploiement de la MVP SAT. Les serveurs de métadonnées SAT sont représentés par des cylindres verts et les processus de traitement par des flèches bleues. Les barres bleues horizontales représentent l'association entre une tâche de traitement et un serveur de métadonnées SAT. Une analyse plus complète de ces résultats est donnée dans [Cudennec, 2017].</figcaption></figure>

sur les ressources matérielles. J'ai eu l'occasion d'étudier ce sujet dans le contexte opérationnel de la grille de calcul Grid'5000 pour le déploiement de la MVP JuxMem en multi-sites [Cudennec, 2009], puis dans le cadre de la chaîne de compilation Σ-C présentée en section 2.1.1 et dans laquelle une étape d'optimisation est dédiée au dimensionnement de l'application [Cudennec and Sirdey, 2012] et au placement des tâches par recuit simulé sur les PE du many-cœur [Galea and Sirdey, 2012]. Dans le contexte de la MVP SAT, différentes configurations de déploiement d'une même application sur une architecture hétérogène peut donner lieu à des performances variables comme cela est illustré par la figure 3.7. Ces résultats montrent l'importance de disposer d'outils et de l'expertise nécessaire à la configuration du déploiement pour utiliser efficacement les ressources matérielles.

De nombreux outils permettent d'automatiser le déploiement, ce qui a été facilité par les méthodes de virtualisation, de conteneurisation ainsi que des intergiciels de gestion de ressources tels que OpenStack. Si les étapes de configuration des nœuds de calcul, de recopie des données d'entrée et de lancement de l'exécution du code utilisateur sont prises en charge, la phase de pré-planification du déploiement est plus difficilement assistée et repose sur l'expertise de l'utilisateur. La pré-planification consiste à dimensionner l'application, c'est-à-dire pour simplifier, définir le nombre de processus et décider du placement individuel sur les ressources matérielles. Un objectif classique de cette phase est de minimiser le temps de calcul. Mais les contraintes opérationnelles transforment rapidement ce problème en une optimisation multicritères, dans laquelle la consommation d'énergie ou le nombre de ressources allouées doivent aussi être minimisés. Comme dans tout bon problème d'optimisation, ces critères sont bien souvent antinomiques et un compromis doit être trouvé.

Dans le contexte d'utilisation de la MVP SAT, la complexité de la pré-planification provient de deux aspects : 1) l'aspect multirôles joué par l'application dans laquelle des serveurs de métadonnées SAT et divers rôles définis par l'utilisateur cohabitent et 2) l'aspect hétérogène des plateformes ciblées dans lesquelles certaines contraintes d'association entre nœud de calcul et type de rôle dirigent la phase de placement de tâches (par exemple la présence d'un CPU basse consommation, d'un GPU, d'une quantité suffisante de mémoire physique...). Une solution de déploiement d'une application sur SAT consiste donc à instancier l'application (définir le nombre d'instances de chaque rôle à déployer), construire la topologie (comment les instances des rôles utilisateur sont connectées aux instances du rôle de serveur de métadonnées SAT) et comment projeter chaque instance sur les ressources matérielles en respectant des contraintes de placement. Cette solution de déploiement est alors évaluée selon divers critères, principalement le temps de calcul et la consommation d'énergie. L'objectif du travail mené dans [Trabelsi et al., 2019] est de fournir un outil d'aide à la décision pour semi-automatiser la configuration la plus adaptée pour un déploiement.

Dans la littérature, de nombreux travaux traitent du problème du placement des tâches sur des ressources hétérogènes en présence de contraintes de performance et d'énergie. Cette thématique de recherche s'est développée depuis une quinzaine d'années avec l'arrivée d'architectures hybrides composées d'un CPU et d'un GPU. Par exemple, un algorithme populationnel bi-objectif est utilisé dans [Friese et al., 2013] pour sélectionner les solutions dominantes présentées sous forme d'un front de Pareto et ainsi aider les administrateurs système à déployer des applications. D'autres contributions proposent des approches itératives [Legrand et al., 2004] pour construire une solution ou des techniques de partitionnement des tâches pour rechercher des solutions à plusieurs niveaux de hiérarchie [Uçar et al., 2006]. D'autres approches concernent le placement et l'ordonnancement des tâches lorsque l'application peut être représentée sous la forme d'un DAG (Directed Acyclic Graph), par exemple dans [Aba et al., 2020].
Cependant, ces travaux portent sur l'optimisation d'une unique phase du modèle PCAM, principalement la projection sur les ressources physiques. Les autres phases doivent être traitées avec d'autres méthodes et outils. Cette approche simplifie la complexité du problème mais peut induire des solutions globales moins optimisées en étant contrainte par les autres phases, ou en contraignant les autres phases. Dans les travaux menés sur la MVP SAT, une approche globale est proposée, prenant en compte toutes les phases de la méthodologie PCAM, du dimensionnement de l'application à la phase de projection sur les ressources matérielles.

<figure><img src="image_63.png" /><figcaption>FIGURE 3.8 – Processus d'optimisation combiné des phases de dimensionnement de l'application et de sa projection sur l'architecture de calcul. Le front de Pareto obtenu est un outil d'aide à la décision afin de déployer la configuration la plus adaptée au contexte opérationnel.</figcaption></figure>

La recherche de solutions par voisinage est une méthode d'exploration approchée offrant un compromis entre le temps de calcul (le coût de la recherche) et la qualité des solutions. Cette méthode est donc particulièrement bien adaptée aux problèmes complexes pour lesquels l'espace de recherche est considéré grand. Le principe est de générer un ensemble de solutions initiales, de les évaluer, puis de générer itérativement de nouvelles solutions basées sur les précédentes en appliquant des altérations. Dans ce travail, une solution est constituée 1) d'une topologie logique de la MVP telle que représentée en figure 3.2b et qui correspond aux deux premières phases de la méthode PCAM et 2) d'une projection de cette topologie sur les ressources matérielles en autorisant la colocation de certaines tâches avec leur serveur de métadonnées SAT sur le même nœud de calcul pour favoriser les communications, ce qui correspond aux deux dernières phases de la méthode PCAM. Cette approche est illustrée dans la figure 3.8 par une chaîne d'optimisation prenant en entrée une description de l'application et des ressources matérielles pour générer un ensemble de solutions à évaluer sur la plateforme cible.

Cette approche a été évaluée sur le micro-serveur Christmann RECSBox et les résultats sont présentés en figure 3.9. La figure de gauche 3.9a représente le positionnement des solutions évaluées sur la plateforme en fonction du temps de calcul et de la consommation d'énergie, pour les solutions initiales en rouge et les solutions voisines en vert. Cette représentation montre que de meilleures solutions ont été trouvées suite à l'exploration du voisinage, principalement sur le critère du temps de calcul et sur le compromis performance/énergie. Les détails des solutions constituant le front de Pareto sont donnés en figure 3.9b. Il est à noter que le nombre de tâches de traitement, la topologie de la MVP ainsi que la projection sur les ressources physiques peuvent différer entre deux solutions. La forme du Pareto obtenu après exploration du voisinage révèle de plus une solution offrant un excellent compromis entre le temps de calcul (328 s) et la consommation d'énergie (11,8 kJ).

En conclusion, l'outil d'exploration pour le dimensionnement des applications écrites sur la MVP SAT ainsi que les projections possibles sur les ressources matérielles permet de rechercher des solutions contre-intuitives : dans les expérimentations, aucune configuration manuelle jusqu'alors utilisée pour déployer l'application de traitement vidéo sur la plateforme n'a été retenue dans le front de Pareto. Si cette approche est satisfaisante sur le plan de la qualité des solutions obtenues, elle souffre cependant d'un mode opératoire difficile à mettre en place : Dans cet exemple, l'évaluation d'une solution prend entre 5 et 15 minutes. Évaluer toutes les solutions entraîne donc un temps de calcul important, certainement impossible à réaliser tel quel sur un super-calculateur ou sur tout autre plateforme multi-utilisateurs. Plusieurs approches sont cependant envisageables pour réduire le temps de calcul ou améliorer la stratégie exploratoire.
<figure><img src="image_64.png" /></figure>

(a) Positionnement des solutions en fonction du temps de calcul et de l'énergie dépensée. Le front de Pareto obtenu met en valeur les solutions nouvellement trouvées par exploration du voisinage. Le phénomène de traînées provient de topologies proches structurellement, par exemple suite à l'ajout d'une tâche de traitement ou d'un serveur de métadonnées de la MVP SAT.

<table><thead><tr><th colspan="8">Solutions initiales</th></tr><tr><th>i7</th><th>A15</th><th>SAT</th><th>Temps (s)</th><th>FPS</th><th>kJ</th><th>FPS/kJ</th></tr></thead><tbody><tr><td>1</td><td></td><td>1</td><td>398</td><td>4.3</td><td>11.5</td><td>0.38</td></tr><tr><td>1</td><td>1</td><td>2</td><td>375</td><td>4.6</td><td>13.5</td><td>0.34</td></tr><tr><td>1</td><td></td><td>1</td><td>377</td><td>4.6</td><td>13.5</td><td>0.34</td></tr></tbody></table>

<table><thead><tr><th colspan="8">Exploration du voisinage</th></tr><tr><th>i7</th><th>A15</th><th>SAT</th><th>Temps (s)</th><th>FPS</th><th>kJ</th><th>FPS/kJ</th></tr></thead><tbody><tr><td>1</td><td>3</td><td>4</td><td>316</td><td>5.4</td><td>15.8</td><td>0.35</td></tr><tr><td>1</td><td>2</td><td>3</td><td>324</td><td>5.3</td><td>13.9</td><td>0.38</td></tr><tr><td>1</td><td>1</td><td>2</td><td>328</td><td>5.3</td><td>11.8</td><td>0.45</td></tr></tbody></table>

(b) Solutions appartenant au front de Pareto. Pour chaque solution sont indiqués dans l'ordre des colonnes : le nombre de processeurs Intel Core i7 et Arm Cortex A15 utilisés, le nombre de serveurs de métadonnées SAT, le temps de calcul, le nombre moyen d'images traitées par seconde, l'énergie dépensée pour le calcul ainsi que le ratio entre le nombre d'images par seconde et l'énergie.

FIGURE 3.9 – Solutions initiales et solutions obtenues par exploration du voisinage appartenant au front de Pareto - solutions non dominées sur le temps de calcul et la consommation d'énergie - pour l'application de traitement vidéo videostream déployée sur le serveur hétérogène Christmann RECS|Box 3 présenté en figure 3.1a.

Une première méthode est d'appliquer les évaluations de solution sur un sous-ensemble de l'application, par exemple un noyau de calcul considéré comme représentatif du comportement applicatif. Ceci est particulièrement adapté pour les applications exhibant un régime établi, c'est-à-dire un motif comportemental identifiable en terme de calculs et de communications. Cette première méthode doit pouvoir faire chuter le temps de calcul de manière significative. Une deuxième méthode est d'utiliser des outils d'optimisation d'hyperparamètres tels que Optuna [Akiba et al., 2019] qui permettent d'explorer de grands espaces en termes de nombre de variables et de domaines de recherche. Ces outils utilisent des stratégies adaptées, par exemple l'inférence bayésienne pour orienter les recherches. Cette deuxième méthode doit pouvoir limiter le nombre d'évaluations nécessaires pour converger vers les meilleures solutions. Une troisième méthode consiste à construire un modèle de prédiction des performances. Cette approche doit permettre d'obtenir une réponse instantanée lors de l'évaluation d'une solution de déploiement, et ainsi permettre 1) la construction du front de Pareto hors-ligne, c'est-à-dire sans évaluation sur la machine cible et 2) une exploration efficace, en utilisant une machine spécialisée pour les problèmes de RO (par exemple une machine NUMA plutôt que la machine hétérogène distribuée ciblée). La principale complexité de cette troisième approche consiste à construire un modèle prédictif précis : plusieurs possibilités sont envisagées pour la suite de ces travaux comme par exemple 1) l'utilisation de séries temporelles appliquées à des séquences de déploiements issues d'une exploration du voisinage (et donc ayant subi de petites altérations incrémentales) et 2) un apprentissage machine sur des bases de données contenant des rapports de déploiements déjà effectués. Dans les deux cas, le paramétrage du modèle est rendu complexe par le faible nombre de données disponibles suite à des déploiements. Cette problématique rejoint une thématique actuelle de recherche sur l'IA frugale, c'est-à-dire comment entraîner des modèles avec peu de données.

Enfin, une part de la complexité de l'exploration des configurations de déploiement provient de l'aspect multicritères de l'optimisation. Jusqu'à récemment ce type de problème était uniquement axé sur la performance calculatoire : de nombreuses publications démontrent l'intérêt de leur contribution en comparant exclusivement des résultats de benchmarks dans lesquels l'aspect énergétique n'est pas traité. Le classement GREEN500 des super-calculateurs performants sur le plan énergétique a débuté il y a moins de 10 ans, en juin 2013, ce qui est finalement récent (cf. la figure 2.5). Si les méthodes de recherche opérationnelle permettent de trouver des compromis satisfaisants entre la performance calculatoire et la dépense énergétique, il n'en reste pas moins que ces solutions sont tributaires des choix effectués lors de l'implémentation du système MVP. Un système non pensé pour limiter la dépense énergétique reste un système énergivore quelques soient les efforts menés pour le configurer. Les contributions suivantes portent donc sur la prise en compte de la dépense d'énergie dans la MVP au niveau calculatoire et au niveau des communications.
### 3.2.2 Économie d'énergie dans les communications MPI, application à la MVP

> “Cudennec, L. (2020). Adaptive message passing polling for energy efficiency: Application to software-distributed shared memory over heterogeneous computing resources. Concurr. Comput. Pract. Exp., 32(24).”
> 
> [Cudennec, 2020] CEA LIST, DGA MI.
> 
> Contributions | initiative | idées | implémentation | expérimentations | rédaction

<figure><img src="image_65.png" /><figcaption>FIGURE 3.10 – Exemple de diagramme de séquence illustrant l'enchâinement des communications entre les acteurs de la MVP SAT lors d'une requête en écriture sur une donnée en cours d'accès par un processus distant. les boîtes vertes correspondent à l'exécution du code utilisateur et les boîtes bleues à l'exécution du code MVP. Les pointillés correspondent aux lignes de vie. Lorsque les pointillés sont visibles, le processus est considéré comme inactif, c'est-à-dire en attente d'un évènement. Ce motif de communication présente un pire cas dans lequel le serveur responsable de la donnée (home-node) est différent des serveurs sur lesquels sont connectés les clients utilisateur.</figcaption></figure>

Une MVP peut être définie comme un ensemble d'automates répartis. Chaque participant, qu'il soit client ou serveur, est doté d'un état interne qui peut être modifié par des transitions. Ces transitions s'effectuent lors d'évènements tels que l'appel à une primitive de l'API utilisateur sur les serveurs ou la réception d'un message de contrôle sur les clients. Un certain nombre d'acteurs dans le système peuvent passer un temps significatif à attendre un évènement, comme cela est illustré en figure 3.10. Dans cet exemple, le client de gauche à l'initiative de la requête en écriture doit attendre le message d'acquittement et le transfert des données pour continuer le traitement. De la même manière, les serveurs de la MVP passent une grande partie du temps à attendre des messages de contrôle. La complexité calculatoire est très faible dans une MVP et le surcoût d'utilisation pour l'application est presque intégralement la conséquence du respect de dépendances causales entre évènements et de l'algorithmique répartie en général. Pendant ces phases d'attente, les cœurs de calcul exécutant les différents rôles peuvent changer de contexte et exécuter d'autres processus appartenant à d'autres applications. En pratique, lors d'un déploiement sur une infrastructure de production ou un super-calculateur, la colocalisation de processus sur un même cœur (aussi dénommé oversubscription dans la terminologie MPI) est rarement mis en place pour des raisons de performance, d'isolation (éviter les effets de bord, notamment la pollution des caches), et de problématiques de partage des ressources en général. Dès lors, ces phases d'inactivité peuvent mener à une sous-utilisation du cœur de calcul, ce qui doit être compensé par des économies d'énergie.

Dans le contexte de la MVP SAT, la couche de gestion des communications se conforme au standard MPI comme cela est motivé en section 3.1. La plupart des implémentations de MPI sont conçues pour le domaine du HPC dans lequel les applications sont classiquement caractérisées par un comportement régulier qui ne génère pas de temps d'attente significatifs comparé aux phases de calcul. Dès lors les primitives d'attente d'un message sont implémentées dans une boucle active afin de garantir un temps de réaction court entre la réception du message sur l'interface réseau et sa remise au niveau utilisateur. Malheureusement cette stratégie entraîne un fort taux d'utilisation du CPU et une consommation d'énergie importante. C'est ce qui est constaté avec les résultats expérimentaux présentés en figure 3.11. Dans ces expérimentations, une application composée d'un processus émetteur et d'un processus récepteur est écrite en MPI. Un message est envoyé toutes les 4 secondes, le processus récepteur se retrouve donc en attente de message la plupart du temps. Les figures de gauche présentent l'implémentation de référence sur 2 architectures matérielles et 3 implémentations de MPI (OpenMPI [Gabriel et al., 2004], MPICH [Thakur and Gropp, 2007] et MPC [Pérache et al., 2008]). Dans toutes ces configurations, la charge processeur correspond à un processus en attente active, proche de 100% pour OpenMPI et MPICH (ce qui est équivalent à un cœur en pleine utilisation), et jusqu'à 400% pour MPC dont
<figure><img src="image_66.png" /><figcaption>(a) Odroid XU4, Raspberry Pi 3B+, implémentation de référence</figcaption></figure>

<figure><img src="image_67.png" /><figcaption>(c) Intel Core i7 6800K (6 cœurs), implémentation de référence</figcaption></figure>

<figure><img src="image_68.png" /><figcaption>(d) Intel Core i7 6800K (6 cœurs), avec mécanisme de micro-siete</figcaption></figure>

FIGURE 3.11 – Journalisation de la charge processeur dédiée au processus MPI en attente de messages lors de l'exécution d'une application d'envoi et de réception de messages. Un message est émis toutes les 4 secondes et sa réception est indiquée par les barres verticales grises. L'application est déployée sur 2 configurations matérielles et 3 implémentations de MPI. Les figures 3.11a et 3.11c sont obtenues avec les implémentations par défaut. Les figures 3.11b et 3.11d sont obtenues en activant le mécanisme de micro-siete proposé dans [Cudennec, 2020] et dont le code source est mis à disposition dans le projet EEProbe (Energy Efficient Probe for MPI). https://github.com/lcudenne/eeprobe

l'implémentation est résolument parallèle. Afin de réduire ce taux d'utilisation processeur lors d'une phase de réception de message, un mécanisme de micro-siete a été proposé avec pour objectif d'offrir un compromis entre réactivité et consommation d'énergie.

Dans la littérature, les implémentations MPI ont -de manière assez surprenante- peu fait l'objet d'études pour rationaliser la consommation d'énergie. Quelques implémentations font cependant mention de tels travaux : MPC a été développé pour tirer parti des nœuds de calcul NUMA et permet à un ordonnanceur interne de donner la main à un autre fil d'exécution MPC lors de l'attente d'un message. Le taux d'utilisation du processeur obtenu en figure 3.11c montre cependant que ce mécanisme est pensé pour établir un partage efficace des cœurs entre les fils d'exécution MPC à des fins de performance calculatoire et non d'économie d'énergie. Un mécanisme similaire (oversubscription) est implémenté dans OpenMPI et MPICH dans le cas de la colocalisation de processus sur un même nœud. Là encore, l'ordonnanceur interne cherche à donner la main à un autre processus MPI et ne permet pas de restituer la ressource en cas d'attente d'un message. La contribution la plus proche de cette problématique est MVAPICH2-EA [Venkatesh et al., 2015] qui se base sur un modèle de prédiction pour décider de la transmission des données et de la configuration en ligne des commutateurs réseaux. L'approche repose sur des technologies matérielles particulières fournies par Infiniband et Intel Sandy Bridge, ce qui est peu adapté au contexte du calcul embarqué. Cependant, les auteurs montrent une diminution de la consommation de plus de 40% pour seulement 5% de perte de performance, ce qui constitue une avancée significative pour le contexte HPC.
D'autres initiatives visent à apporter des outils pour maîtriser la consommation d'énergie d'une application MPI, c'est par exemple le cas avec des orchestrateurs de déploiement pouvant décider de fusionner des processus (GEOPM [Eas-tep et al., 2017]) ou encore d'adapter la fréquence des processeurs pendant l'exécution (Green Queue [Tiwari et al., 2012], Transparent Scaling [Lim et al., 2006]). Ces approches rejoignent les travaux engagés sur la recherche d'une configuration de déploiement répondant à des objectifs de diminution de la consommation d'énergie comme présenté en section 3.2.1. Enfin, la problématique de la dépense énergétique dans MPI est aussi traitée à l'aide de simulateurs et de modèles, comme par exemple avec HAEC-SIM [Bielert et al., 2015] et [Heinrich et al., 2017]. Dans ce dernier, les auteurs soulèvent la difficulté de caractériser la consommation énergétique de la fonction MPI Iprobe justement dans le cas d'une attente active de messages, ce qui rejoint la problématique traitée dans cette section.

<figure><img src="image_69.png" /><figcaption>FIGURE 3.12 – Implémentation et évaluation du mécanisme de micro-sieste implémenté entre l'API MPI et la MVP SAT.</figcaption></figure>

(a) Journalisation de la charge processeur dédiée au processus MPI exécutant un rôle serveur de la MVP SAT pour deux modes de fonctionnement OpenMPI : Aggressive correspond au mode normal (boucle d'attente active) et degraded correspond à un mode spécifique (mpi yield _when_idle) pour le partage de ressources entre processus MPI. Les courbes violettes (Adaptive) correspondent à l'utilisation du mécanisme de micro-sieste.

Listing 5 – Pseudo-code pour la fonction de réception avec mécanisme de micro-sieste.

```c
void EERcv() {
    char * buffer = NULL;
    size_t size = 0;
    int flag = 0;
    unsigned long sleep_time = 0;
    while (flag == 0) {
        Iprobe(&flag, &size);
        if (flag == 0) {
            clock_nanosleep(sleep_time);
            sleep_time += sleep_time_step;
        }
    }
    buffer = malloc(size);
    Recv(buffer);
}
```

**Un mécanisme de micro-sieste pour relâcher l'attente active.** Économiser l'énergie dans les communications en utilisant une diminution de l'activité matérielle est un sujet qui a été étudié dans les grandes infrastructures de communication, notamment à travers le standard EEE (Energy Efficient Ethernet) qui permet d'éteindre sélectivement des ressources lorsque l'activité le permet [Cenedese et al., 2017]. Plus récemment, cette thématique trouve des applications dans les systèmes de calcul embarqués, l'informatique en périphérie de réseau et les réseaux d'objets communicants à très faible puissance de consommation [Djidi et al., 2021]. Appliquer certaines approches proposées dans ces thématiques de recherche doit permettre d'adapter MPI à de nouveaux contextes applicatifs, comme les machines hétérogènes embarquées.

Dans le contexte de la réception de messages MPI, le mécanisme de micro-sieste consiste à remplacer la boucle d'attente active implémentée notamment dans la fonction Recv par une boucle comprenant deux actions : la vérification de la présence de nouveaux messages (le polling) et l'endormissement pour un temps arbitraire (ce qui permet à l'ordonnanceur système de donner la main à un autre processus ou de diminuer la charge processeur). En pratique, un code de réception de message MPI est souvent composé de l'enchaînement d'un appel à la fonction synchrone Probe qui retourne lorsqu'un message est disponible, puis de la fonction Recv qui permet effectivement de délivrer le message. Ce même code est proposé en incluant le mécanisme de micro-sieste dans le listing 5. Dans cette implémentation simplifiée, le temps d'endormissement est augmenté à chaque itération jusqu'à la réception d'un message. Cette stratégie permet de conserver un comportement proche de l'attente active sur les premières itérations lors de l'appel à la fonction EERcv, et donc de ne pas pénaliser les phases de communication denses, et dans un second temps de relâcher progressivement la pression sur le processeur. L'application de cette stratégie est évaluée sur l'application MPI d'envoi et de réception de messages et les résultats sont présentés sur les figures 3.11b et 3.11d. La charge processeur est divisée par 5 sur les cartes embarquées et par 10 sur le processeur Intel pour les implémentations OpenMPI et MPICH. Elle est aussi réduite dans une moindre mesure pour MPC, ce qui peut être expliqué par une implémentation différente en terme de gestion des fils d'exécution.

Cette réduction de la charge processeur est aussi mesurable dans le contexte de la MVP SAT. La figure 3.12a présente la charge processeur du processus MPI supportant le rôle de serveur de la MVP pendant l'exécution d'une application
itérant sur des séquences de 1000 écritures en mémoire partagée espacées d'une seconde, pour un total de 180000 messages. Entre ces séquences d'écriture la charge processeur descend à 10% lorsque le mécanisme de micro-sieste est activé, contrairement à une utilisation de MPI plus classique qui reste à 100%. Ces améliorations sont aussi perceptibles lors de l'exécution de l'application de traitement vidéo, comme illustré en figure 3.13. Les résultats montrent une diminution significative de la charge processeur (figure 3.13a) pour les processus MPI exécutant les rôles de serveur et de gestionnaire d'entrées-sorties dans la MVP. Ces résultats sont expliqués par la décomposition du temps d'exécution par processus présenté en figure 3.13b qui révèle la part importante passée dans le mécanisme de micro-sieste. Ce résultat est d'autant plus intéressant que le temps de calcul reste inchangé dans toutes les configurations et que l'utilisation du mécanisme de micro-sieste ne nécessite aucune modification du code source d'OpenMPI, de la MVP SAT ou du code applicatif.

<figure><img src="image_70.png" /></figure>

(a) Variance de la charge processeur pour différents rôles de l'application *videostream* et pour différentes configurations du mécanisme de micro-siestes implémenté sur OpenMPI. *S-DSM* correspond à un rôle serveur de la *MVP* déployé sur un Intel Core i7, *Processing* à une tâche de traitement déployée sur une carte Odroid XU4 et *I/O* à un processus de gestion des entrées-sorties déployé sur le même Core i7.

<figure><img src="image_71.png" /></figure>

(b) Décomposition du temps d'exécution des processus de l'application *videostream*. *Sleep time* correspond au temps d'endormissement dans le mécanisme de micro-sieste, *Sync MP* au temps passé à attendre un message en attente active, *S-DSM code* au temps passé à exécuter le code de la *MVP* et *User code* le temps passé à exécuter le code utilisateur.

**FIGURE 3.13** – Analyse de la charge processeur et décomposition du temps passé par les processus de l'application *videostream* présentée en section 3.1.2 lors d'une déploiement sur la machine hétérogène présentée en figure 3.1b. *Adaptive* correspond au mécanisme de micro-sieste avec un temps d'endormissement variable. *Sleep* 0 et 100000 correspondent au mécanisme de micro-sieste avec un temps d'endormissement fixe exprimé en µs.

**Réduction de la consommation d'énergie dans une MVP.** Le mécanisme de micro-sieste permet de diminuer la charge processeur dans le cas où un processus MPI effectue une attente de message. Cette diminution de la charge processeur doit permettre de faire progresser d'autres processus ou de laisser le système d'exploitation décider si un changement de mode de fonctionnement du processeur est envisageable pour effectuer des économies d'énergie (par exemple la baisse de la fréquence d'horloge ou le changement d'état d'un cœur du processeur). Afin de mesurer finement la consommation d'énergie, des expérimentations ont été menées sur le micro-serveur RECS|Box : des sondes de consommation sont embarquées dans chacun des nœuds et peuvent être consultées au travers d'une interface REST (Representational State Transfer). La journalisation des mesures permet ensuite de calculer l'énergie dépensée par nœud pendant le calcul. Les résultats obtenus sont présentés en figure 3.14. Une première observation est que le mécanisme de micro-sieste permet de diminuer la consommation énergétique de manière significative : jusqu'à 20% d'économies à l'échelle de la plateforme. Une deuxième observation est que le mécanisme permet de surcroît de diminuer le temps de calcul de 5%. Ce résultat est plutôt contre-intuitif : classiquement le temps de calcul et la consommation d'énergie sont des critères d'optimisation antagonistes et l'amélioration de l'un des critères se fait en défaveur du second, suivant le principe du front de Pareto, comme cela a déjà été observé pour l'aide à la décision sur le déploiement de la MVP en section 3.2.1. Il apparaît que dans le contexte applicatif de SAT, le mécanisme de micro-sieste permette de jouer sur les deux tableaux, ce qui en fait un dispositif incontournable pour le déploiement de la MVP sur des architectures embarquées.

**En conclusion,** l'étude de la consommation d'énergie dans MPI est un axe de recherche qui s'est imposé lors d'expérimentations menées avec la MVP sur les machines hétérogènes. Lors de ces déploiements, il est rapidement apparu que la charge CPU et la consommation d'énergie des nœuds exécutant uniquement les rôles de serveurs de données et métadonnées de SAT étaient anormalement élevées dans les phases calculatoires. Lors de ces phases, aucun accès en
<figure><img src="image_72.png" /><figcaption>(a) Consommation énergétique en kJ mesurée sur différents nœuds de calcul avec sans activation du mécanisme de micro-sieste. Seuls deux nœuds ARM Cortex A15 sont représentés sur les quatre utilisés pour des raisons de lisibilité.</figcaption></figure>

<table><thead><tr><th></th><th>TIME</th><th>FPS</th><th>W</th><th>kJ</th><th>FPS/W</th></tr></thead><tbody><tr><td>12'52</td><td>2.23</td><td>60</td><td>44.39</td><td>0.037</td></tr><tr><td>12'40</td><td>2.26</td><td>66</td><td>47.68</td><td>0.034</td></tr><tr><td>12'13</td><td>2.35</td><td>52</td><td>36.98</td><td>0.045</td></tr><tr><td>12'42</td><td>2.26</td><td>52</td><td>38.16</td><td>0.043</td></tr></tbody></table>

(b) Temps de calcul (min), images traitées par seconde (FPS), consommation instananée moyenne (W), consommation totale (kJ) et performance énergétique (FPS/W). La solution *Adaptive Aggressive* correspond à l'activation du mécanisme de micro-siestes au desus d'OpenMPI configuré en mode standard (sans prise en compte de la colocalisation de processus sur un même nœud). Cette solution se démarque en offrant le meilleur temps et la meilleure efficacité énergétique.

**FIGURE 3.14** – Performance calculatoire et performance énergétique de l'application de traitement vidéo déployée sur le serveur Christmann RECS|Box avec et sans l'activation du mécanisme de micro-sieste (dénommé *Adaptive*).

mémoire partagée n'est effectué et aucune activité n'est donc déclenchée dans la MVP pouvant justifier une telle utilisation des ressources. Les différentes implémentations de MPI testées ainsi que les options de compilation et d'exécution étudiées n'ont pas permis de résoudre le problème de l'attente active. Le mécanisme de micro-sieste implémenté comme une couche logicielle interfacée entre le code applicatif et les primitives MPI est une solution répondant à plusieurs objectifs : 1) une diminution significative de la charge processeur dans les phases d'attente de messages considérées *longues*, c'est-à-dire à partir de plusieurs dizaines de millisecondes et 2) une mise-en-œuvre transparente pour l'utilisateur et qui ne nécessite pas de réécriture du code applicatif ni du code MPI. Cette approche permet d'obtenir 90% de diminution de charge CPU sur les phases d'attente de messages, 20% d'économies d'énergie et 5% d'amélioration du temps de calcul pour une application de traitement vidéo déployée sur un micro-serveur hétérogène.

Bien que d'une grande simplicité, le mécanisme de micro-sieste pose un certain nombre de problèmes reconnus pour être difficiles à résoudre, notamment celui du paramétrage des temps d'endormissement (temps minimum, temps maximum et incrément du temps d'endormissement). Le choix de ces paramètres conditionne les bonnes propriétés du mécanisme sur la capacité à s'endormir suffisamment longtemps pour observer une économie d'énergie tout en restant réactif dans les phases de communication plus denses. Dans ces travaux les paramètres ont été fixés de manière arbitraire et un axe d'amélioration consiste donc à proposer une méthode pour les déterminer à l'exécution, pour chaque processus MPI et pour des phases différentes du calcul. Une piste est de s'inspirer des techniques d'apprentissage par renforcement -le RL (*Reinforcement Learning*)- largement utilisées dans les contextes opérationnels et notamment mis en lumière avec l'apprentissage machine sur les jeux vidéos Atari [Mnih et al., 2013]. Dans un système RL, un environnement réel ou simulé est intégré dans la boucle d'apprentissage. Celui-ci prend en entrée des actions ou des commandes de la part d'un agent et retourne un score sanctionnant cette décision. Dans le contexte du mécanisme de micro-sieste, un tel système peut être déployé en considérant que les agents sont les processus MPI, les actions consistent à modifier les paramètres d'endormissement du mécanisme et que les critères d'évaluation sont dépendants du contexte opérationnel comme la charge processeur, la consommation d'énergie, la performance calculatoire ou la réactivité à la réception des messages.

Un deuxième axe d'étude consiste à évaluer le mécanisme de micro-sieste dans des contextes applicatifs issus du calcul haute-performance. Bien que principalement adapté pour des applications présentant des phases de synchronisation et des temps d'attente importants, le mécanisme doit pouvoir modifier le comportement de noyaux de calcul plus denses en permettant un meilleur partage des ressources matérielles lors d'un déploiement sur une machine à mémoire partagée multi-cœur ou NUMA. Ainsi, des travaux sont actuellement menés pour adapter automatiquement des benchmarks HPC tels que le NAS Parallel Benchmark [Bailey et al., 1991] en reposant sur la couche d'abstraction de micro-sieste EEProbe. Au delà des benchmarks, cette approche vise aussi les intergiciels d'apprentissage machine, notamment pour le RL en ligne dans un contexte embarqué et contraint par l'énergie.
### 3.2.3 Intégration d'accélérateurs matériels reprogrammables (FPGA) dans une MVP

“Lenormand, E., Goubier, T., Cudennec, L., and Charles, H.-P. (2021). Data management model to program irregular compute kernels on fpga: application to heterogeneous distributed system. In Euro-Par 2021 : Parallel Processing Workshops - Euro-Par 2021 International Workshops, Lisbon, Portugal, August 30 - September 3, 2021, Revised Selected Papers, Lecture Notes in Computer Science. Springer.”

[Lenormand et al., 2021] CEA LIST, DGA MI. Contributions | ★ initiative ■ idées ☐ implémentation ☐ expérimentations ☐ rédaction ☐ présentation

<figure><img src="image_73.png" /></figure>

“Lenormand, E., Goubier, T., Cudennec, L., and Charles, H.-P. (2020). A combined fast/cycle accurate simulation tool for reconfigurable accelerator evaluation: application to distributed data management. In 2020 International Symposium on Rapid System Prototyping, RSP 2020, Virtual Conference, September 24-25, 2020. IEEE.”

[Lenormand et al., 2020] CEA LIST, DGA MI. Contributions | ★ initiative ■ idées ☐ implémentation ☐ expérimentations ■ rédaction ☐ présentation

<figure><img src="image_74.png" /></figure>

Les FPGA sont des processeurs reprogrammables dont la logique interne peut être configurée simplement. Si à l'origine dans les années 1990 cette reconfiguration était basée sur une description bas-niveau de la circuiterie, elle est aujourd'hui prise en charge par des outils et des langages de conception permettant d'abstraire l'architecture de la puce tels que le HDL (Hardware Description Language). Sur le principe, les FPGA sont constitués d'une matrice de portes logiques programmables, d'un ensemble d'accélérateurs spécifiques de type DSP (Digital Signal Processor), de mémoire embarquée ainsi que de connecteurs d'entrées-sorties pour s'interfacer avec des liens de reconfiguration (JTAG (Joint Test Action Group)) et de transfert de données (PCIe). Ils sont souvent comparés aux circuits spécialisés, les ASIC, car ils remplissent des fonctionnalités proches : cependant, la possibilité de reprogrammation ouvre des domaines d'applications pour lesquels il est difficilement réalisable d'effectuer une mise à jour du matériel (par exemple un satellite) ou qui nécessite des mises à jour fréquentes (par exemple des tâches d'inférence en IA). L'évolution des technologies dans le domaine des semi-conducteurs a permis de rendre les FPGA plus efficaces [Kuon and Rose, 2007] en combinant les performances calculatoires et l'efficacité énergétique des architectures spécialisées face aux processeurs généralistes.

Aujourd'hui les FPGA sont utilisés dans divers domaines opérationnels se prêtant bien à l'architecture orientée traitement de flux de données en ligne : une utilisation classique est la reconnaissance d'expressions régulières dans les flux réseaux, par exemple pour de la détection d'attaques et d'intrusions qui nécessitent de l'analyse de paquets à haute fréquence [Sidhu and Prasanna, 2001]. Un autre exemple est l'utilisation des FPGA pour des tâches d'inférence IA basées sur des réseaux de neurones convolutionnels dans le contexte de l'embarqué [Abdelouahab et al., 2018], notamment avec l'essor du New Space et des formats de satellite CubeSat favorisant l'emploi de COTS (Components off-the-shelf) pour l'électronique embarquée [Arnold et al., 2012]. Les infrastructures cloud intègrent aussi des FPGA [Turan and Verbauwhede, 2021], par exemple dans le moteur de recherche Microsoft Bing [Putnam et al., 2015] ou chez les fournisseurs de service PAAS (Platform as a Service) comme cela est le cas avec l'offre Amazon Web Service [Amazon Web Service, 2016].

**Le FPGA dans le contexte du HPC.** De nombreuses contributions étudient cette possibilité depuis les années 2010, encouragées par la promesse d'architectures de calcul plus efficaces en énergie et le développement d'environnements de conception plus accessibles par les géants du secteur Altera/Intel et Xilinx/AMD. Par ailleurs le support d'OpenCL, un langage de programmation proche du flot-de-données déjà largement utilisé pour exploiter le parallélisme des GPU, permet de porter les codes numériques existants ou de les adapter plus simplement [Czajkowski et al., 2012]. De nombreux travaux visent à évaluer les performances calculatoires et énergétique de codes numériques exécutés sur des CPU, des GPU et des FPGA. Parmi les noyaux de calcul représentatifs du HPC ayant été évalués sur FPGA nous pouvons citer la mécanique des fluides avec des maillages non-structurés [Andres et al., 2009], les convolutions 3D [Zohouri et al., 2018], la mécanique du solide avec la méthode des éléments finis et les systèmes multicorps [Sozzo et al., 2017], la transformation de Fourier rapide 3D [Sanaullah and Herbordt, 2018] ou encore l'algèbre linéaire creuse [Zeni et al., 2021]. Dans ces travaux, il ressort que la vitesse de calcul des GPU et des FPGA est comprise entre 30 et 240 fois plus rapide que les CPU, les deux accélérateurs ne pouvant être départagés car les résultats sont très dépendants de la nature des calculs. Sur le plan de la consommation d'énergie cependant les FPGA sont considérés 1,8 à 2,7 fois plus efficaces que les GPU et 40 à 400 fois plus efficaces que les CPU.

Malgré leurs atouts indéniables, les FPGA n'ont véritablement pas intégré les grands systèmes de calcul, en témoigne leur absence visible des listes du TOP500 et du GREEN500. L'une des principales raisons réside dans le modèle de programmation bien éloigné des standards logiciels. Là où un développeur d'applications raisonne sur une séquence d'instructions et d'accès à des données (finalement largement basé sur l'architecture de Von Neumann), la programmation d'un FPGA nécessite une compréhension fine de l'organisation matérielle et de la logique régissant la propagation
<figure><img src="image_75.png" /><figcaption>(a) Représentation binaire de la matrice creuse F2 issue de la collection de matrices de l'Université de Floride [Davis and Hu, 2011]. Cette matrice carré contient 71505 lignes et 0.1% d'éléments non-nuls.</figcaption></figure>

<figure><img src="image_76.png" /><figcaption>(b) Représentation d'un maillage issu du Projet H2020 LEXIS [Goubier et al., 2020a], suivant la zone de subduction de la fosse de Java face à l'île de Sumatra. Les longueurs d'arêtes sont comprises entre 100 mètres et 15 km.</figcaption></figure>

<caption>FIGURE 3.15 – Deux exemples de structures de données utilisées dans le cadre de ces travaux sur les FPGA.</caption>

des signaux numériques. Les outils de CAO (Conception assistée par ordinateur) permettent aujourd'hui de gagner en abstraction, notamment en décrivant dans un langage haut-niveau l'interconnexion de blocs logiques sur étagère. Cependant les phases d'optimisation et de mise au point nécessitent de l'expertise métier afin de projeter efficacement la circuiterie sur la puce, de minimiser les latences bout-en-bout en évitant par exemple la génération de bascules (latch) introduisant plus de séquentialité dans le chemin et donc de la latence. Ce besoin d'expertise pointue dans un secteur de niche constitue un frein pour faire le choix du FPGA dans un projet opérationnel.

Dans la littérature, de nombreux travaux montrent qu'il existe un enjeu réel à proposer des outils permettant de rendre transparent l'utilisation des FPGA dans une base de code logicielle plus classique. Avec l'essor des pratiques liées à l'IA, de tels outils sont proposés pour des applications d'apprentissage machine et d'inférence de réseaux de neurones. C'est par exemple le cas avec la suite Xilinx Vitis AI [Kathail, 2020] ou l'environnement de conception N2D2 du CEA [CEA, 2017]. D'autres initiatives visent des applications plus larges pour du calcul numérique : un portage de certaines directives du langage de programmation parallèle OpenMP est proposé dans [Sommer et al., 2017]. Une contribution proche d'OpenMP est proposée par le BSC avec OmpSs [Filgueras et al., 2014]. Dans le domaine de l'informationique dans les nuages, Blaze [Huang et al., 2016] propose de mutualiser les FPGA au sien d'une même plateforme et de les exploiter avec des outils orientés service. Un dernier exemple est l'intergiciel d'orchestration et d'ordonnancement de tâches sur machines hétérogènes StarPu [Augonnet et al., 2011] dans lequel des travaux préliminaires ont été menés pour cibler les FPGA [Christodoulis et al., 2018]. Une validation fonctionnelle de l'approche a été effectuée dans le cadre de la multiplication de matrices. Il est aussi possible de distribuer StarPu sur plusieurs nœuds de calcul avec MPI [Augonnet et al., 2012], l'ensemble permettant alors d'abstraire pour le développeur une plateforme répartie comprenant des ressources de calcul hétérogènes. Enfin, de récents efforts portent sur la compilation automatique source-à-source pour proposer une alternative aux chaînes de compilation propriétaires avec le projet OpenFPGA [Tang et al., 2020].

À un niveau de développement plus proche du matériel, des protocoles de communication et des architectures réseau inter-puces ont été récemment proposés pour unifier les accès aux mémoires entre des processeurs et des accélérateurs localisés sur un même nœud de calcul. C'est par exemple le cas pour OpenCAPI [Stuecheli et al., 2018], Intel QuickPath Interconnect [Mutnury et al., 2010], AMD HyperTransport (avec une interface FPGA [Litz et al., 2009]) ainsi que pour les consortiums CXL/Gen-Z et CCIX. Ces technologies souffrent cependant d'un défaut de normalisation et de généralisation dans les systèmes de calcul : lorsque le consortium a dépassé le stade des spécifications, la solution est appliquée et distribuée pour une architecture processeur spécifique, à l'instar d'OpenCAPI principalement implémenté dans les processeurs IBM Power 9 et 10, peu répandus dans les infrastructures de calcul en comparaison des Intel Xeon et AMD Epyc.

D'une manière plus générale, les systèmes présentés dans cette section ne permettent pas de considérer le FPGA comme une unité de traitement à part entière, au même titre qu'un CPU : il reste cantonné au rôle d'accélérateur piloté par un processeur hôte. Les contributions suivantes visent à rendre le FPGA acteur du traitement, notamment à travers
<figure><img src="image_77.png" /><figcaption>FIGURE 3.16 – Architecture logicielle et matérielle conçue pour intégrer un FPGA dans une MVP. Le code utilisateur exécuté sur le CPU du nœud A et le circuit utilisateur (bitstream) chargé sur le FPGA du nœud B accèdent au même espace logique de la MVP et peuvent accéder aux données partagées en utilisant les identifiants uniques ID.</figcaption></figure>

la possibilité d'initier des accès aux données partagées, tout en offrant une interface unifiée avec les autres PE. En cela, l'utilisation d'une MVP permet d'abstraire la couche de gestion des données et de poser les bases d'un modèle de programmation commun.

### Intégrer un FPGA dans une MVP.
L'une des difficultés inhérentes à l'utilisation des FPGA réside dans le modèle de programmation hybride composé d'un coté par le constructeur de la puce (VHDL, Verilog, SystemC) et de l'autre par l'applicatif en charge de son intégration vers l'extérieur. L'un des points bloquant pour briser le modèle de programmation hybride est l'accès aux données : la plupart des architectures hétérogènes composées de processeurs hôtes et d'accélérateurs nécessitent d'exprimer séparément les accès entre processeurs et les accès entre processeurs et accélérateurs. C'est par exemple le cas pour des applications MPI+CUDA dans lesquelles les données sont explicitement déplacées entre les nœuds avec l'API MPI puis chargées dans le GPGPU à l'aide d'une seconde API.

Intégrer un FPGA dans une MVP dépasse le cadre de la simplification et de l'uniformisation des accès aux données partagées : c'est un moyen de rendre le noyau de calcul déployé sur l'accélérateur capable d'initiatives. Cette approche s'oppose au modèle maître-esclave dans lequel le FPGA subit les données à traiter en entrée, comme un simple processeur de flux. Si la logique programmable ne permet pas de concevoir des programmes avec le même degré d'expressivité qu'un logiciel exécuté sur un CPU<fnref n="2" />, il n'en reste pas moins que donner l'initiative d'accès à des données ouvre de nouvelles possibilités d'implémentation de noyaux de calcul. C'est notamment le cas des noyaux présentant des accès irréguliers tels que la multiplication de matrices creuses (figure 3.15a) ou des opérations sur des maillages non-structurés (figure 3.15b). Dans ces deux exemples, les accès aux éléments lors d'une itération du calcul dépendent d'une itération précédente, les rendant difficilement prévisibles. Dans le cas réaliste où les données (les matrices, les maillages) ne peuvent être intégralement chargées dans la mémoire locale de l'accélérateur, sa capacité à exprimer et initier les prochains accès devient un atout.

Une architecture permettant d'intégrer un FPGA dans la MVP SAT est proposée dans [Lenormand et al., 2019] et les grands principes sont exprimés dans la figure 3.16. Ce travail a été réalisé dans le cadre de la thèse d'Erwan Lenormand [Lenormand, 2022], soutenue en 2022, que j'ai proposée et co-encadrée, et qui s'est déroulée sous la direction d'Henri-Pierre Charles au CEA. Dans cette proposition, un nœud FPGA est intégré à la MVP par le truchement d'un client SAT logiciel, sur le principe du proxy. En lieu et place du code utilisateur, une interface mixte logicielle-matérielle SAT FPGA est en charge de traduire les requêtes d'accès à des chunks émises dans des files matérielles par le noyau de calcul utilisateur (le bitstream déployé sur le FPGA), en une séquence de primitives de l'API SAT sur le client logiciel. Cette approche présente deux bonnes propriétés : 1) pour la MVP SAT, le FPGA est vu comme un client classique et de ce fait, aucun traitement particulier, notamment sur les protocoles de cohérence des données, n'est requis. L'intégration est donc transparente et 2) pour le noyau de calcul déployé sur le FPGA, le moyen de désigner les données partagées repose sur le même espace logique que la MVP (les ID dans la figure 3.16). Il y a donc continuité de l'espace logique entre les processeurs et les accélérateurs qui ne nécessite pas de traduction d'adresses, et donc un surcoût pour gérer des tables associatives (à l'instar d'une TLB (Translation Lookaside Buffer)).

Si cette architecture n'a pu être implémentée intégralement pour des raisons de temps et d'ampleur de la tâche, la démarche a donné lieu à plusieurs contributions fondamentales pour sa mise en place. Une première contribution

<footnote n="2">2. Sur le plan de la programmabilité et non de la théorie.</footnote>
consiste à proposer un outil de simulation pour caractériser le comportement d'un noyau de calcul sur FPGA et ainsi dimensionner les interfaces avec la MVP. Une deuxième contribution est un modèle de gestion des données visant à structurer et réorganiser les données en un flux utilisé pour masquer la latence d'accès entre le FPGA et la MVP.

**Problématiques pour l'intégration du FPGA.** Prendre en compte un accélérateur dans un code numérique nécessite de l'expertise et de la mise au point pour obtenir les performances espérées. Un problème classique rencontré est la famine de données, dans lequel les unités de traitements de l'accélérateur se retrouvent sous-utilisées faute de données suffisantes transférées au bon moment pour faire avancer le calcul. Pour les GPU, une pratique courante est de charger les données en mémoire interne de l'accélérateur, de lancer le calcul, de récupérer le résultat puis de recommencer. Ainsi, le noyau de calcul dispose de toutes les données en mémoire physique. Cette approche est limitée par la taille de la mémoire, de l'ordre de quelques dizaines de gigaoctets pour les plus grosses cartes. Une autre approche est d'alimenter l'accélérateur sous forme de flux, ce qui pose notamment deux problèmes : 1) un problème de dimensionnement du matériel : par exemple les canaux de communication, la profondeur des files de transfert (FIFO) et 2) un problème de réutilisation des données pour profiter des effets de cache : par exemple la granularité adaptée pour la représentation des données.

<figure><img src="image_78.png" /><figcaption>FIGURE 3.17 – Du logiciel au matériel : architecture d'un circuit déployable sur FPGA correspondant à une étape du noyau de calcul implémenté dans le code numérique TsunAWI [Goubier et al., 2020b] développé par l'institut Alfred Wegener (AWI). TsunAWI permet de simuler, par la méthode des éléments finis, la propagation des vagues dans le cas d'un séisme afin d'anticiper les vagues de submersion sur le littoral. Ces figures sont issues du manuscrit de thèse d'Erwan Lenormand [Lenormand, 2022].</figcaption></figure>

**Un outil de simulation précis au cycle.** Un simulateur de noyau de calcul sur FPGA a été proposé pour répondre à la question du dimensionnement matériel [Lenormand et al., 2020]. L'enjeu est de pouvoir alimenter le noyau en données tout en limitant la taille du circuit, c'est-à-dire le nombre d'unités reconfigurables à allouer sur le FPGA. Le simulateur est précis au cycle et déroule les différentes étapes d'un circuit logique cadencé sur une horloge globale. Les latences de communication, largeur de bus de communication et les fréquences de fonctionnement sont paramétrées suivant les spécifications de puces FPGA documentées. L'utilisation du simulateur est hybride : la MVP SAT est déployée sur une infrastructure distribuée et un ou plusieurs clients s'interfacent avec une instance du simulateur, reproduisant le comportement du noyau de calcul sur un FPGA. Cette approche hybride permet de reproduire une dispersion réaliste des données sur les serveurs de la mémoire partagée, et donc d'obtenir des statistiques légitimes sur les transferts induits par le calcul. L'usage du simulateur permet de plus une approche exploratoire dans laquelle les paramètres du FPGA émulé peuvent être adaptés et évalués.

Cette approche a été évaluée sur deux applications : un noyau de multiplication de matrices creuses (plus d'informations sur ce cas d'étude sont disponibles dans [Lenormand, 2022]) et TsunAWI [Goubier et al., 2020b], un code de simulation de propagation de vagues dans le cadre d'un programme d'alerte vague-submersion développé par l'institut Alfred Wegener (AWI) en Allemagne. Ce travail a été effectué dans le cadre du projet H2020 LEXIS [Goubier et al., 2020a] dont l'un des objectifs est d'accélérer ce code numérique. La figure 3.17 illustre comment à partir d'un maillage
<figure><img src="image_79.png" /><figcaption>FIGURE 3.18 – Résultats de simulation hybride entre la MVP SAT et le simulateur précis au cycle de noyau de calcul sur FPGA. Le noyau simulé correspond au calcul du gradient dans le code TsunAWI. Évaluation effectuée sur 5 maillages de taille et de granularité différentes.</figcaption></figure>

triangulaire (3.17a) et d'un algorithme de calcul de gradient (3.17b) un circuit logique (3.17c) est proposé pour porter cette étape du calcul de TsunAWI sur un FPGA en utilisant l'interface d'accès aux chunks de la MVP SAT. Le découpage du maillage en chunks est un point déterminant pour obtenir de bonnes performances calculatoires, et ce pour plusieurs raisons : 1) une granularité trop faible (un petit nombre de triangles par chunk) implique plus d'accès distants et donc de latence pour le noyau de calcul. 2) Une granularité trop importante expose au problème du faux-partage dans la MVP. Enfin, 3) le choix de colocaliser certains sommets du graphe dans un même chunk a une conséquence directe sur le nombre d'accès à la MVP pour reconstituer les triangles dans le noyau de calcul. Ce dernier point a motivé des travaux sur l'ordonnancement des sommets des graphes non-structurés à l'aide d'une courbe de remplissage continue de Hilbert [Hilbert, 1935] visant à améliorer la localité spatiale des triangles [Lenormand et al., 2021].

Sur cet exemple, la problématique du dimensionnement consiste à 1) déterminer la taille des FIFO de préchargement des chunks et 2) déterminer le nombre d'instances de ce circuit à déployer pour paralléliser le traitement tout en évitant de saturer le bus de données entre le contrôleur mémoire du FPGA et les PE. La figure 3.18 présente les résultats de simulation obtenus pour le code TsunAWI sur 5 maillages classés par taille croissante, de 230000 à 5 millions de triangles. Le FPGA choisi pour calibrer la simulation est un Xilinx Virtex-7 fonctionnant à 200 MHz. Pour chaque maillage, le nombre d'instances du circuit de traitement évalués, le degré de parallélisme, est de 1 à 16 PE. La figure 3.18a indique les performances calculatoires en nombre de triangles traités par seconde et la figure 3.18b représente le taux d'occupation du contrôleur mémoire sur le FPGA.

Cette expérience a permis de montrer que pour ce noyau de calcul, une accélération est obtenue jusqu'à un parallélisme de 4. Au delà, un phénomène de famine de données apparaît pour les PE, provoqué par la saturation du contrôleur mémoire pour les maillages volumineux et par la latence d'accès aux données pour les plus petits maillages. Des expériences additionnelles sont présentées dans [Lenormand, 2022], permettant d'encadrer la taille des FIFO et de caractériser le comportement du système lorsque les chunks sont présents ou non sur le nœud hôte. Enfin, ces expérimentations ont montré l'importance d'organiser et de structurer les données de telle sorte à limiter les transferts mémoire, le faux partage, et à l'inverse bénéficier de la localité spatiale des accès. Si ce problème est largement étudié pour les processeurs multi-cœurs, son application à un système hybride composé d'une MVP logicielle et d'un circuit matériel sur FPGA reste novateur.

**En conclusion,** l'adoption massive des processeurs programmables dans les contextes HPC et embarqués reste conditionnée par la mise à disposition d'outils de programmation et de déploiement suffisamment haut-niveau pour ne plus reposer sur l'expertise pointue en architecture matérielle, ce qui s'avère bien éloigné du domaine applicatif et du génie logiciel. Aujourd'hui, de tels efforts sont concédés par les grands acteurs du secteur (Altera/Intel et Xilinx/AMD) dans le domaine de l'apprentissage machine et de l'inférence, notamment portés par les applications IA. Un autre élément moteur est la concurrence ouverte menée par les géants du numérique sur le secteur des environnements d'apprentissage machine et des accélérateurs matériels pour l'IA. C'est par exemple le cas avec Google (TensorFlow, Tensor Processing
Unit, Tensor Chip), Facebook (PyTorch), Uber (Horovod) ou encore Amazon (AWS ML). Il faut donc des contraintes opérationnelles sérieuses pour faire le choix du FPGA et de son écosystème fermé, plutôt que de reposer sur des environnements de développement libres, suivis par une grande communauté d'utilisateurs et ciblant des architectures matérielles plus conventionnelles (CPU et GPU).

Dans ce contexte, les travaux menés pendant la thèse d'Erwan Lenormand contribuent à rendre l'utilisation des FPGA plus simple, en traitant cette problématique à travers le prisme de la gestion des données partagées. Cette approach nécessite toujours un développement des noyaux de calcul dans un langage spécialisé HDL mais les mécanismes d'accès aux données distantes, sur le processeur hôte ou sur un autre nœud, sont rendus transparents pour le développeur et ne nécessitent plus de transferts explicites. Les études préliminaires montrent que pour obtenir une implémentation efficace de SAT FPGA, l'architecture doit reposer sur de nouvelles technologies de gestion des communications et de la mémoire, notamment des mémoires à grande bande passante reposant sur la technologie HBM (High-Bandwidth Memory), ou sur des protocoles de communication pair-à-pair pour participants hétérogènes tels que OpenCAPI.

Une piste d'étude prometteuse reste l'intégration de l'intergiciel de passage de message MPI -sur lequel repose la MVP SAT- directement sur le FPGA, permettant ainsi de supprimer les intermédiaires entre le circuit utilisateur et les serveurs de la MVP. Ainsi, un client SAT peut être directement implémenté sur le FPGA, comprenant l'automate complet pour envoyer et recevoir des messages de contrôle et de données avec les serveurs. Un tel portage est complexe car en quelques dizaines d'années, l'API MPI s'est beaucoup étoffée avec des primitives collectives et des communications unidirectionnelles. Quelques initiatives visent cependant à porter une partie de l'API sur des FPGA : Dans [Williams et al., 2006] un portage de MPI est réalisé sur un processeur softcore, c'est-à-dire un processeur instancié dans la logique du FPGA et donc capable d'exécuter un système d'exploitation complet. L'approche est intéressante car elle permet de déployer du logiciel sur la puce. Cependant cette facilité a un coût important en performance et en empreinte mémoire. D'autres approches [Gao et al., 2009, Arap and Swany, 2014] ciblent des opérations collectives telles que les barrières ou les jointures de résultats. Ces contributions rejoignent les efforts récents pour l'intégration de calculs intermédiaires sur les flux de données directement dans les routeurs réseaux, comme cela est le cas pour les processeurs de données Nvidia Mellanox BlueField [Sarkauskas et al., 2021]. Il semble que la contribution la plus complète soit proposée dans TMD-MPI [Saldaña and Chow, 2006] avec un NoC spécifique déployé sur le FPGA pour échanger des messages MPI entre les nœuds, et développé pour un calculateur multi-FPGA dédié à l'étude de la dynamique moléculaire à l'Université de Toronto. Toutes ces initiatives montrent qu'il reste du chemin à parcourir pour rendre le FPGA attractif et en faire un choix naturel au même titre qu'un accélérateur GPGPU. Cela passera probablement par des standards ouverts et des environnements de développement accessibles offrant un haut-niveau d'abstraction du matériel.

## 3.3 Discussion

Le développement de la MVP logicielle SAT s'est déroulé dans le contexte de projets européens visant à concevoir des serveurs de calcul hétérogènes. Ceci a permis d'identifier les points techniques durs à résoudre pour offrir un environnement de programmation qui utilise efficacement les ressources. En ce sens, SAT répond à deux problématiques principales : 1) elle offre un modèle de programmation unifié à l'échelle de la plateforme et masque la gestion des données partagées et 2) les outils d'aide à la décision répondent à la problématique de l'utilisation efficace des ressources en offrant des compromis entre performance calculatoire et consommation d'énergie rendus possibles par la diversité des unités de traitement. Face à des intergiciels plus classiquement déployés sur les machines distribuées, nous avons démontré que la MVP offre une alternative sérieuse, en témoignent les démonstrations effectuées sur les machines Christmann dans les différents salons technologiques (ISC, Teratec). Pour cela, plusieurs thématiques de recherche et développement ont dû être menées pour obtenir une pile logicielle complète : 1) un modèle de programmation en mémoire partagée basé sur un partitionnement des données en chunks, 2) une chaîne de compilation pour le dimensionnement de SAT, la sélection des ressources et le placement des tâches, 3) un intergiciel distribué implémentant un système de stockage et des protocoles de cohérence des données. Si le cœur de la conception de SAT a pu être réalisé seul, l'ensemble des contributions menant au succès du projet est le fruit de collaborations ayant alimenté de nombreuses réflexions, notamment sur le plan de l'optimisation, de la recherche opérationnelle, de la sécurité des données et des technologies FPGA.

**Travaux inachevés.** [À propos d'une API haut-niveau] SAT propose un modèle de tâches et une API spécifique basée sur la cohérence à l'entrée (entry/scope consistency qui nécessite l'acquisition et la libération de verrou dans le code utilisateur. Les applications doivent donc être écrites ou adaptées pour son utilisation. Ce constat est partagé avec les systèmes d'entrées-sorties pour le HPC : les applications doivent par exemple être écrites spécifiquement pour utiliser les systèmes de fichiers distribués HDF5, Lustre ou FTI. Afin d'abstraire les interactions avec ces systèmes, l'intergiciel PDI [Roussel et al., 2017] développé au CEA (Maison de la Simulation) propose une interface unique et un système de greffons pour les différentes technologies. Dans ce travail mené avec Julien Bigot (CEA), un greffon PDI a été développé pour SAT en C++ permettant de transférer de manière transparente les appels aux systèmes de fichiers classiques vers du stockage en mémoire partagée. Cette approche vise notamment le couplage de codes de calcul numériques afin d'accélérer les échanges de données souvent réalisés par système de fichiers à chaque pas de simulation et qui peuvent
dans ce cas bénéficier d'une solution en mémoire physique.

[À propos de la sécurité des données] Les accès aux données partagées dans la MVP SAT peuvent être effectués par toute instance de client déployée dans l'application. Par défaut, seuls les identifiants des données dans l'espace d'adressage logique sont nécessaires pour effectuer un accès, ce qui constitue un secret raisonnable dans un contexte lié à l'expérimentation, mais peu envisageable dans un contexte opérationnel. Un premier travail a consisté à offrir une couche de gestion des adresses logiques en se basant sur une fonction de hachage. Ainsi, à chaque écriture d'un chunk, un nouvel identifiant est calculé en appliquant la fonction Bernstein hash djb2 [Yigit, 2003] sur le contenu (le champ data). Cette stratégie apporte deux propriétés : 1) les accès sont par construction en lecture seule car toute modification d'une donnée partagée est stockée à une adresse logique différente (des collisions peuvent cependant intervenir) et 2) la fonction de hachage offre une répartition uniforme des adresses logiques, ce qui rend plus complexes les attaques par force brute. Un deuxième travail [Stan et al., 2020] a été effectué avec Oana Stan (CEA) pour gérer les autorisations d'accès aux données partagées à l'aide du chiffrement par attributs (ABE). Ce chiffrement est asymétrique et permet, à partir d'un ensemble d'attributs et de clés privées d'appliquer une politique d'accès, par exemple basée sur des rôles. Ce travail a été réalisé lors du stage de Master de Louis Syoen (Université Paris-Diderot).

**Retour d'expérience.** Parfois, pour avancer, il est nécessaire de déconstruire, puis de tout recommencer. Alors que faut-il retenir des choix de conception effectués dans SAT ?

[À propos de MPI] Le retour d'expérience est ici mitigé : MPI apporte une grande facilité d'implémentation pour l'algorithme répartie, notamment pour la phase de construction du réseau logique des participants. Les opérations collectives et les communications unidirectionnelles n'ont pas été utilisées, ce qui laisse des possibilités d'amélioration sur le plan des performances. L'implémentation sur MPI s'accompagne d'une topologie statique : il n'est pas possible d'ajouter ou de supprimer des processus en cours d'exécution. La conséquence pour SAT est de ne pas pouvoir s'étendre sur des nœuds au gré des besoins applicatifs, ou à l'inverse se rétracter pour laisser la place à d'autres applications. Cette propriété n'a pas été nécessaire pour le déploiement de SAT sur des micro-serveurs hétérogènes, mais d'autres usages peuvent nécessiter de la dynamicité, notamment en présence de ressources volatiles et de systèmes massivement multi-utilisateurs. Le standard MPI permet de la malléabilité sur les processus, ce qui peut être considéré pour une future implémentation. Deux autres pistes peuvent être envisagées : 1) celle explorée par JuxMem qui consiste à utiliser un intergiciel pair-à-pair dynamique, avec un coût de construction du réseau logique élevé et une grande latence lors des phases de découverte des nœuds et 2) la piste du réseau logique construit au dessus de ZeroMQ pour bénéficier des performances dans les communications mais au prix d'un important effort de développement.

[À propos du langage C] Dans le monde de l'embarqué et du logiciel critique le langage C, et à fortiori le ANSI C (C89), est un critère de réussite pour obtenir un code sûr, performant et portable. Ce choix a en effet permis un déploiement rapide et sans surprise de SAT sur toutes les plateformes rencontrées, quelque soit l'architecture processeur et le système d'exploitation (en base Unix). Le langage C a de plus autorisé une gestion fine de la mémoire physique, par exemple dans le cas d'une allocation contiguë de plusieurs chunks. Pour autant, entre 2016 et 2022, le paysage des langages et environnements de programmation a profondément changé, bousculé par la nécessité de déployer du code portable performant sur des architectures de plus en plus embarquées. Aujourd'hui, implémenter une MVP logicielle en langage C n'est pas pertinent, pour plusieurs raisons : 1) Une MVP a une complexité calculatoire très faible qui ne nécessite pas un langage proche de la machine. La performance du système repose entièrement sur l'efficacité des protocoles de cohérence et le choix d'un réseau de communication adapté. 2) Le temps de développement en C est très long et la mise au point accablante, focalisée sur des opérations bas-niveau (la manipulation de chaînes de caractères) alors que l'essentiel de la difficulté se trouve dans l'algorithme répartie, à un niveau de conception bien plus abstrait. 3) Il existe désormais des langages haut-niveau tels que Python ayant atteint une maturité suffisante pour être performant sur le plan calculatoire tout en permettant d'écrire des algorithmes avec un grand degré de concision. De nombreuses bibliothèques Python permettent d'exploiter le parallélisme (RAY [Moritz et al., 2018]) et les infrastructures distribuées (Mpi4Py [Smith, 2016]), ce qui s'avère être aujourd'hui un bon choix pour prototyper une MVP moderne, en phase avec les applications en IA et en science des données actuelles. De plus, les nouveaux types et structures de données introduits par des logiciels tels que TensorFlow et PyTorch peuvent servir de base pour un découpage efficace en chunks et ainsi optimiser l'espace mémoire et la disponibilité des données dans les calculs distribués, notamment pour l'apprentissage fédéré.

[À propos de la propriété intellectuelle] Le développement de SAT a été réalisé sur le modèle propriétaire, c'est-à-dire que le code source n'a pas fait l'objet d'une autorisation de publication sous licence publique. Cette stratégie est difficilement défendable dans le contexte de projets européens et constitue un frein évident pour la mise en place de collaborations, pour la reproductibilité des résultats publiés, ainsi que pour la pérennité de la brique technologique. Depuis une quinzaine d'années maintenant, être moteur de l'innovation, et à fortiori dans le milieu de la recherche, ne consiste plus à garder un logiciel secret : cela consiste au contraire à créer une masse critique autour du projet incluant la communauté scientifique, à construire l'expertise en interne et à capitaliser sur les retours d'expérience dans le temps long. De cette manière il est possible de provoquer l'émergence d'idées nouvelles tout en conservant une avance stratégique.

<figure><img src="image_80.png" /></figure>
# Chapitre 4

# Conclusion et perspectives

## 4.1 Conclusion

Pour un projet de recherche, une dizaine d'années représente une période longue et courte à la fois. Cette période a été marquée par le développement rapide des systèmes embarqués à forte capacité calculatoire peu avant 2010, avec des processeurs économes en énergie pour les smartphones, les objets connectés et les véhicules autonomes, ainsi que des architectures massivement parallèles conçues pour optimiser le coût de calcul par watt. À partir de 2014 les architectures hétérogènes constituent une évolution logique de ces systèmes embarqués en agrégeant différentes unités de calcul dédiées à des tâches spécifiques. Enfin, l'avènement de l'intelligence artificielle dans tous les domaines du quotidien met l'accent sur des accélérateurs spécialisés ou reprogrammables dont il faut assurer une intégration efficace dans les systèmes existants. Dans cette temporalité, l'étude des machines parallèles, réparties et hétérogènes a donné lieu à de nombreuses thématiques et pistes de réflexion sur les aspects matériels et logiciels. Différentes architectures à l'état de l'art ont été traitées, du processeur massivement parallèle au micro-serveur distribué hétérogène. La nouveauté de ces architectures provient de deux stratégies différentes : l'accumulation massives des unités de traitement pour les many-cœurs en comparaison des multi-cœurs, et l'intégration de nombreux nœuds de calcul et de stockage hétérogènes dans un même rack pour les micro-serveurs en comparaison des architectures homogènes des grappes de calcul. Bien que conçues selon des mécanismes connus, l'accumulation et la diversification des ressources, ces deux architectures souffrent de la même problématique de programmabilité : comment exploiter efficacement les unités de calcul tout en masquant la complexité de l'architecture matérielle aux utilisateurs ?

Les travaux présentés dans ce manuscrit apportent des éléments de réponse sur deux plans : le modèle de programmation et le modèle de gestion des données partagées. Ces deux plans sont en pratique intimement liés et les contributions de l'un impliquent bien souvent des contributions dans le second. Pour les architectures many-cœurs, deux modèles de programmation ont été traités : le flot-de-données et la mémoire partagée. Ces deux modèles offrent une haute abstraction de la puce, le premier se focalisant sur le modèle de tâches et le second sur les accès mémoire. La complexité est nécessairement prise en charge par des éléments tiers tels que une chaîne de compilation, un intergiciel d'exécution ou un protocole de cohérence des caches. De tels outils tiers ont été proposés et validés par le tissu industriel (Kalray) et la communauté scientifique. Pour les architectures hétérogènes, un modèle en mémoire partagée a été proposé et une mémoire virtuellement partagée logicielle a été conçue, implémentée et validée dans des démonstrateurs sur plateforme industrielle (Christmann). L'animation de cette thématique ne s'est pas limitée à la MVP : de nombreuses contributions satellites ont été proposées pour faciliter son utilisation et son intégration dans un contexte opérationnel sobre en énergie (modèle de programmation haut-niveau, extension au modèle événementiel, exploration de la configuration du déploiement, maîtrise de l'activité des communications MPI et prise en compte de FPGA).

Le retour d'expérience obtenu sur l'utilisation des many-cœurs et des micro-serveurs est très similaire : proposer un outil d'exploitation de l'architecture de calcul n'est pas suffisant, des outils d'aide à la décision sont bien souvent nécessaires pour guider l'utilisateur. Ainsi, après avoir proposé plusieurs protocoles de cohérence des caches paramétrables, le choix du protocole et sa configuration ne peuvent être laissés à la charge du développeur : une chaîne de compilation pour l'aide à la décision a donc été proposée. Il en va de même pour le déploiement de la MVP SAT dont la topologie logique détermine la performance calculatoire et l'empreinte énergétique. Le choix de cette topologie est complexe et parfois contre-intuitif. Là encore, un outil d'aide à la décision est proposé pour orienter l'utilisateur vers les solutions offrant les meilleurs compromis. Il y a donc à chaque fois un enjeu majeur à offrir des systèmes d'aide à la décision permettant d'accompagner l'expert métier. Ces outils reposent aujourd'hui sur des techniques classiques de recherche opérationnelle : méthodes populationnelles et exploration du voisinage. Il semble cependant naturel que l'optimisation des systèmes pour le HPC et le HPEC bénéficient des méthodes prédictives offertes par l'IA.
## 4.2 Perspectives

Depuis une quinzaine d'années l'intelligence artificielle rencontre un nouvel essor rendu possible par des avancées notables sur le plan théorique, algorithmique et technologique. Ceci est visible à travers deux faits : 1) l'avènement de l'apprentissage profond, reconnu par un prix Turing en 2018 (LeCun, Bengio et Hinton) et 2) les avancées technologiques spectaculaires sur le plan des architectures de calcul. Ces nouvelles architectures, en partie étudiées dans ce manuscrit, permettent un apprentissage machine à partir d'un grand volume de données dans un temps devenu raisonnable. Elles sont aussi présentes au sein des systèmes embarqués en général, permettant de déployer des tâches d'inférence au plus proche du contexte opérationnel. L'une des particularités de l'IA est de s'immiscer *positivement* dans tous les domaines : la conception assistée par ordinateur, la recherche de solutions optimisées et bien sûr tous les applicatifs métier présentant des tâches fastidieuses, répétitives et suffisamment complexes pour ne pas pouvoir être réalisées par un programme informatique classique.

Fin 2019 je rejoins la Direction Générale de l'Armement (DGA Maîtrise de l'Information) dans un département en cours de création et traitant des problématiques liées à l'IA, à la RO et à la gestion de grands volumes de données (datascience). La création de ce département s'inscrit dans la volonté de moderniser les Armées, de faire le lien entre les univers académiques, industriels et les problématiques rencontrées par les opérationnels. Dans ce contexte, mes travaux s'inscrivent dans diverses missions : 1) une première mission est la mise en place de moyens de calculs conséquents dédiés à l'apprentissage machine, la fouille de données, la simulation et l'optimisation. Ceci inclut le choix du matériel à l'état de l'art et son intégration dans un environnement logiciel calqué sur les installations classiques des super-calculateurs. Ceci implique aussi d'adapter les pratiques liées aux activités IA aux outils permettant une exploitation efficace du parallélisme massif de l'infrastructure. 2) Une deuxième mission est la proposition et le suivi de projets au service de la modernisation des Armées. 3) Enfin une troisième mission consiste en l'animation scientifique, ce qui inclut la direction de thèse, le montage de projets avec des partenaires académiques et l'aide pour l'utilisation des mécanismes dédiés à l'innovation (AID).

Les activités menées au sein de la DGA constituent une continuation logique et cohérente des travaux effectués au CEA sur l'exploitation des machines parallèles, distribuées et hétérogènes. L'intelligence artificielle est par nature un client grand compte des environnements de calcul massivement répartis et hétérogènes. L'apprentissage machine nécessite de la puissance de calcul et des systèmes efficaces pour le partage des données : un exemple est l'identification des poids dans un réseau de neurones, ce qui s'effectue aujourd'hui principalement sur des machines multi-GPU à mémoire partagée. Lorsque de telles machines, complexes et donc coûteuses, ne suffisent plus, ce processus calculatoire est distribué sur plusieurs nœuds. L'apprentissage machine fédéré est une thématique de recherche en plein essor car deux aspects théoriques durs se rejoignent : les calculs probabilistes attachés aux réseaux de neurones et le non-déterminisme dans l'ordre des évènements inhérents aux systèmes répartis. Il en résulte un système dont les résultats sont difficilement reproductibles. Cette propriété de reproductibilité est pourtant fondamentale pour la **qualification et la certification** des applications IA dans les contextes opérationnels. Une initiative est menée à travers le projet franco-allemand E2Clab [Rosendo et al., 2020] visant à offrir une plateforme d'exploration et de dimensionnement des applications pour la **reproductibilité des calculs**.

E2Clab est aussi une plateforme qui doit permettre d'explorer différentes configurations de déploiement des applications IA. Que ce soit en apprentissage ou en inférence, les environnements de développement et de calcul IA sont particulièrement récents et reposent rarement sur les outils classiques du calcul haute-performance (par exemple MPI). Ils sont aussi pensés pour exprimer l'algorithmique à un plus haut-niveau d'abstraction, plus proche du métier d'expert en mégadonnées que de l'expert en HPC. Dès lors, les choix technologiques et leurs conséquences sur les divers critères de performances sont peu documentés. Il existe donc un besoin de fournir dans un futur proche des outils de décision pour choisir un environnement de développement et configurer son déploiement sur l'infrastructure de calcul. Dans ce travail préliminaire [Prigent et al., 2022], nous avons proposé une **méthodologie pour explorer des compromis** entre le temps de calcul, la qualité du résultat et la dépense énergétique. Cette méthodologie est appliquée sur un cas d'étude concret : elle permet d'orienter le choix de la politique d'apprentissage par renforcement pour paramétrer un système de guidage de parachute autonome.

Un deuxième axe de recherche est la capacité à délocaliser l'apprentissage machine vers les nœuds de calcul embarqués. Cette inversion du flux du savoir répond à plusieurs objectifs : 1) la possibilité de générer de l'information localement, par exemple pour de l'apprentissage en ligne, accessible dans un temps très court, 2) la rationalisation des communications, l'information échangée entre les participants revêtant un caractère sémantique plus concis, par exemple les poids d'un réseau de neurones plutôt qu'un flux d'images et 3) la possibilité de maîtriser la confidentialité des informations brutes localement et de remonter une information non protégée, par exemple un résultat de classification plutôt qu'un modèle. Aujourd'hui, avec la miniaturisation des composants électroniques, l'amélioration de l'autonomie des batteries et la maîtrise de la consommation d'énergie, l'IOT (Internet of Things) s' annonce comme un support naturel de décentralisation massive, replaçant le calcul au plus près des utilisateurs. Un exemple est le déploiement de tâches de reconnaissance et de classification d'objets dans le domaine du spatial : l'IA bord. Dans cet exemple, les contraintes liées à l'embarqué sont augmentées par les spécificités du domaine spatial qui impliquent de respecter un facteur de forme, une consommation d'énergie limitée et une architecture matérielle durcie à l'environnement (vibrations, température, radiations). Une approche étudiée actuellement est l'utilisation de FPGA dans les satellites
d'observation afin de bénéficier de son efficacité énergétique et des possibilités de reconfiguration de la circuiterie en cours de mission. L'une des problématiques est d'établir un compromis entre l'empreinte mémoire du noyau de calcul et la qualité des résultats. Dans ce contexte, la thèse de Cédric Gernigon dirigée par Olivier Sentieys (INRIA Rennes) à laquelle je participe aux cotés du CNES, explore les techniques de réduction de précision de la représentation des poids dans les réseaux de neurones pour en diminuer l'empreinte mémoire sur un FPGA. Si ces travaux concernent aujourd'hui les phases d'inférence, ils ouvrent cependant la voie à l'embarquabilité de tâches plus complexes sur plan calculatoire, et notamment l'apprentissage machine en ligne.

Un troisième axe de recherche consiste à étudier le continuum informatique, c'est-à-dire la continuité de la gestion des calculs et des données entre grands systèmes hétérogènes. Avec la miniaturisation des équipements numériques, plusieurs grandes architectures système ont émergées ces 20 dernières années : par exemple le cloud computing à l'échelle des centres de calcul, le fog computing à l'échelle des équipements intermédiaires dans le réseau et le edge computing à l'échelle des équipements au plus proche des utilisateurs. Ces systèmes diffèrent sur de nombreuses caractéristiques matérielles et environnementales. Une conséquence est de constater que les méthodes et outils utilisés pour les exploiter sont spécifiques. Dans ce contexte, les applications sont développées et déployées sur un unique système. Si des exemples montrent des interactions entre applications exécutées sur des systèmes différents, il est plus rare de trouver une même application déployée sur plusieurs systèmes hétérogènes. Certains scénarios reposent cependant sur la possibilité de migrer une application d'un système à un autre. Par exemple un apprentissage en ligne est initié sur un essaim de drones puis est migré dynamiquement sur un centre HPC, en relocalisant les tâches d'apprentissage sur les ressources du centre de calcul et en redirigeant les flux de données issus des capteurs des drones. Cette thématique sur le continuum informatique est l'objet de la thèse de Cédric Prigent dirigée par Gabriel Antoniu (INRIA Rennes) et que je co-encadre avec Alexandru Costan (INSA Rennes).

Un quatrième axe de recherche se situe à la frontière entre l'apprentissage fédéré et le continuum informatique : il semble raisonnable de penser que les géants du numérique ont un intérêt opérationnel et financier à déporter les calculs liés à l'apprentissage machine sur les terminaux mobiles des utilisateurs. Dans ce contexte, la question de la confidentialité des données pour un apprentissage fédéré entre terminaux utilisateurs est un sujet d'intérêt, pouvant bénéficier de techniques calculatoires basées sur le **chiffrement homomorphe**. Ce type de chiffrement permet d'effectuer des calculs directement sur le chiffré et non sur le clair. Si de récentes avancées théoriques ont permis de rendre cette technique soutenable sur le plan de la complexité calculatoire, il n'est cependant pas possible d'en généraliser l'usage sur une application distribuée complète. Cependant, dans le cadre de l'apprentissage machine, la simplicité des opérations effectuées pour mettre à jour les poids d'un réseau de neurones (multiplication-accumulation) rend l'approche envisageable [Sébert et al., 2021, Boudguiga et al., 2021].

Ces quatre axes de recherche s'inscrivent dans les trois thématiques présentées en début de manuscrit : le **parallélisme** des tâches, la **distribution** des calculs et l'hétérogénéité des architectures. Le prisme utilisé n'est cependant plus la gestion des données partagées, mais le support des applications en intelligence artificielle. Ces applications sont porteuses de grandes avancées pratiques, d'innovations techniques et d'usage, ainsi que d'interrogations sociétales touchant à l'éthique. Ces changements sont largement perceptibles dans le quotidien et de nombreux contextes opérationnels vont bénéficier de ces nouvelles approches de résolution de problème. Néanmoins, les systèmes calculatoires sous-jacents pour l'IA partagent les mêmes problématiques que les systèmes complexes plus anciens, notamment pour concevoir des architectures adaptées à la résolution de problèmes de recherche opérationnelle et pour utiliser efficacement les ressources de calcul. Ainsi, les techniques en IA peuvent déjà aider à concevoir les architectures de calcul de demain et générer automatiquement des programmes informatiques efficaces. La prochaine évolution majeure se situe peut-être dans le domaine de la physique : pour le calcul haute-performance en général, il est possible qu'une innovation de rupture provienne de l'informatique quantique à travers un paradigme de programmation et un modèle de calcul résolument novateurs. Si les conséquences sur la cryptographie et la résolution de certains problèmes de recherche opérationnelle durs commencent à être entrevues, il est possible que la mécanique quantique réserve de nouvelles singularités à exploiter, comme par exemple l'absence de causalité entre les événements à très petite échelle [Letertre, 2021]. Cette propriété interroge sur la capacité-ou la pertinence- à écrire un ordonnanceur de tâches et un protocole de cohérence des données à l'échelle quantique, ces deux objets constituant la base des systèmes calculatoires tels que nous les connaissons aujourd'hui.

☐

<figure><img src="image_81.png" /></figure>
# Glossaire

<table>
  <tr>
    <td>API</td>
    <td>Interface de programmation (Application Programming Interface) 21, 38, 58, 59, 63, 65, 71, 73, 78, 81</td>
  </tr>
  <tr>
    <td>ARM</td>
    <td>Architecture processeur basée sur un jeu d'instruction RISC (Acorn/Advanced Risc Management/Machine) 53</td>
  </tr>
  <tr>
    <td>ASIC</td>
    <td>Circuit intégré spécialisé (Application-Specific Integrated Circuit) 21, 53, 76</td>
  </tr>
  <tr>
    <td>CAO</td>
    <td>Conception assistée par ordinateur 77</td>
  </tr>
  <tr>
    <td>CC</td>
    <td>Cohérence de cache (Cache Coherence) 15, 16, 42, 43, 45–51</td>
  </tr>
  <tr>
    <td>COTS</td>
    <td>Composants sur étagère (Components off-the-shelf) 76</td>
  </tr>
  <tr>
    <td>CPU</td>
    <td>Unité centrale de traitement (Central Processing Unit) 53, 77, 78, 80</td>
  </tr>
  <tr>
    <td>CSDF</td>
    <td>Cyclo-Static Data-Flow 10, 20–23, 25</td>
  </tr>
  <tr>
    <td>CSP</td>
    <td>Communicating Sequential Processes 13</td>
  </tr>
  <tr>
    <td>DAG</td>
    <td>Graphe orienté acyclique (Directed Acyclic Graph) 68</td>
  </tr>
  <tr>
    <td>DMA</td>
    <td>Accès direct à la mémoire (Direct Memory Access) 25, 34, 35</td>
  </tr>
  <tr>
    <td>DSL</td>
    <td>Langage dédié (Domain Specific Language) 21, 32, 35, 52</td>
  </tr>
  <tr>
    <td>DSP</td>
    <td>Processeur spécialisé dans le traitement du signal (Digital Signal Processor) 76</td>
  </tr>
  <tr>
    <td>EEE</td>
    <td>Norme ethernet optimisée sur le plan énergétique (Energy Efficient Ethernet, IEEE 802.3az) 73</td>
  </tr>
  <tr>
    <td>EoP</td>
    <td>Equivalence de pointeur (Equivalence of Pointer) 33–35</td>
  </tr>
  <tr>
    <td>FIFO</td>
    <td>First In First Out 21, 60, 79, 80</td>
  </tr>
  <tr>
    <td>FPGA</td>
    <td>Circuit logique programmable (Field-Programmable Gate Array) 21, 25, 53–57, 63, 75–81, 83–85</td>
  </tr>
  <tr>
    <td>GFLOPS</td>
    <td>Nombre d'opérations en virgule flottante par seconde, en million 10<sup>6</sup> (floating-point operations per second) 16</td>
  </tr>
  <tr>
    <td>GOPS</td>
    <td>Nombre d'opérations par seconde, en million 10<sup>6</sup> (operations per second) 16</td>
  </tr>
  <tr>
    <td>GPGPU</td>
    <td>Calcul générique sur processeur graphique (General-Purpose computing on Graphics Processing Unit) 13, 15, 17, 21, 53, 78, 81</td>
  </tr>
  <tr>
    <td>GPU</td>
    <td>Processeur graphique (Graphics Processing Unit) 13, 25, 53, 54, 77, 78, 80, 84</td>
  </tr>
  <tr>
    <td>HAL</td>
    <td>Couche d'abstraction matérielle (Hardware Abstraction Layer) 20, 25</td>
  </tr>
  <tr>
    <td>HBM</td>
    <td>Mémoire à large bande passante (High-Bandwidth Memory) 80</td>
  </tr>
  <tr>
    <td>HDL</td>
    <td>Langage de description de matériel (Hardware Description Language) 76, 80</td>
  </tr>
  <tr>
    <td>HN</td>
    <td>Noeud référent (Home-Node) 40–42</td>
  </tr>
  <tr>
    <td>HPC</td>
    <td>Calcul haute performance (High-Performance Computing) 13, 15, 17, 21, 38, 40, 53, 57, 62, 65, 71, 72, 75, 77, 80, 81, 83–85</td>
  </tr>
  <tr>
    <td>HPEC</td>
    <td>Calcul haute performance embarqué (High-Performance Embedded Computing) 13, 65, 83</td>
  </tr>
  <tr>
    <td>IA</td>
    <td>Intelligence artificielle 15, 51–53, 70, 76, 77, 80, 82–85</td>
  </tr>
  <tr>
    <td>IDE</td>
    <td>Environnement de développement (Integrated Development Environment) 20</td>
  </tr>
  <tr>
    <td>IOT</td>
    <td>Internet des objets (Internet of Things) 84</td>
  </tr>
  <tr>
    <td>IPS</td>
    <td>Nombre d'instructions par seconde 16</td>
  </tr>
  <tr>
    <td>ISS</td>
    <td>Simulateur de jeu d'instructions (Instruction Set Simulator) 21, 34, 35</td>
  </tr>
  <tr>
    <td>JIT</td>
    <td>Compilation à la volée (Just in time compilation) 41</td>
  </tr>
  <tr>
    <td>JTAG</td>
    <td>Port d'accès de test (Joint Test Action Group) 76</td>
  </tr>
  <tr>
    <td>KPN</td>
    <td>Kahn Process Network 21</td>
  </tr>
  <tr>
    <td>LoG</td>
    <td>Filtre Laplacien d'une Gaussienne (Laplacian of Gaussian) 30–32</td>
  </tr>
  <tr>
    <td>LVT</td>
    <td>Temps logique vectoriel (Logical Vector Time) 23</td>
  </tr>
  <tr>
    <td>MIPS</td>
    <td>Nombre d'instructions par seconde, en million 10<sup>6</sup> 16</td>
  </tr>
  <tr>
    <td>ML</td>
    <td>Apprentissage machine (Machine Learning) 15, 80</td>
  </tr>
  <tr>
    <td>MP</td>
    <td>Passage de message (Message Passing) 17, 20, 25, 65</td>
  </tr>
  <tr>
    <td>MPI</td>
    <td>Message Passing Interface 11, 20, 24, 59, 64–67, 71–75, 77, 78, 81–84</td>
  </tr>
  <tr>
    <td>MPPA</td>
    <td>Réseau de processeurs massivement parallèles (Multi Purpose Processor Array) 13, 15, 38, 52</td>
  </tr>
  <tr>
    <td>MRSW</td>
    <td>Lecteurs multiples, écrivain unique (Multiple Readers, Single Writer) 40</td>
  </tr>
</table>
<table>
   <tr>
    <td>MVP</td>
    <td>Mémoire virtuellement partagée (Distributed Shared Memory) 20, 45, 51, 55, 57-71, 73-75, 77-83</td>
   </tr>
   <tr>
    <td>NoC</td>
    <td>Réseau sur puce (Network on Chip) 13, 15, 17, 25, 28, 38-40, 42, 44-48, 65, 81</td>
   </tr>
   <tr>
    <td>NUMA</td>
    <td>Architecture mémoire non-uniforme (Non-Uniform Memory Architecture) 15, 19, 20, 40, 55, 62, 70, 72, 75</td>
   </tr>
   <tr>
    <td>PAAS</td>
    <td>Plate-forme en tant que service (Platform as a Service) 76</td>
   </tr>
   <tr>
    <td>PCAM</td>
    <td>Modèle de déploiement d'applications parallèles de Ian Foster proposé en 1995 (Partition Communicate Agglomerate Map) 67-69</td>
   </tr>
   <tr>
    <td>PCIe</td>
    <td>Bus local rapide d'interconnexion de cartes d'extension (Peripheral Component Interconnect Express) 37, 76</td>
   </tr>
   <tr>
    <td>PE</td>
    <td>Unité de calcul, cœur (Processing Element) 15, 17, 20, 28, 30, 38, 44, 45, 67, 77, 79, 80</td>
   </tr>
   <tr>
    <td>PGAS</td>
    <td>Espace d'addressage global partitionné (Partitioned Global Address Space) 55</td>
   </tr>
   <tr>
    <td>PS</td>
    <td>Modèle de programmation évènementiel publier-s'abonner (Publish-Subscribe) 61, 62</td>
   </tr>
   <tr>
    <td>REST</td>
    <td>Architecture logicielle pour les services web (Representational State Transfer) 74</td>
   </tr>
   <tr>
    <td>RL</td>
    <td>Apprentissage par renforcement (Reinforcement Learning) 75</td>
   </tr>
   <tr>
    <td>RO</td>
    <td>Recherche Opérationnelle 49, 70, 84</td>
   </tr>
   <tr>
    <td>SDF</td>
    <td>Static Data-Flow 22, 23, 25</td>
   </tr>
   <tr>
    <td>SSI</td>
    <td>Système à image unique (Single System Image) 20</td>
   </tr>
   <tr>
    <td>TCO</td>
    <td>Coût total de possession (Total Cost of Ownership) 19</td>
   </tr>
   <tr>
    <td>TGCC</td>
    <td>Très Grand Centre de Calcul du CEA accueillant des super-calculateurs 67</td>
   </tr>
   <tr>
    <td>TLB</td>
    <td>Traduction d'adresses virtuelles en adresses physiques (Translation Lookaside Buffer) 78</td>
   </tr>
   <tr>
    <td>TLM</td>
    <td>Modèle transactionnel (Transaction Level Modelling) 46, 47</td>
   </tr>
   <tr>
    <td>TPU</td>
    <td>Processeur de traitement des tenseurs, des structures de données vectorielles (Tensor Processing Unit) 53</td>
   </tr>
  </table>
Bibliographie

[Aba et al., 2020] Aba, M. A., Zaourar, L., and Munier, A. (2020). Efficient algorithm for scheduling parallel applications on hybrid multicore machines with communications delays and energy constraint. *Concurr. Comput. Pract. Exp.*, 32(15).

[Abdelouahab et al., 2018] Abdelouahab, K., Pelcat, M., Sérot, J., and Berry, F. (2018). Accelerating CNN inference on fpgas: A survey. *CoRR*, abs/1806.01683.

[Adapteva Inc., 2017] Adapteva Inc. (2017). A tflops scale 16nm 1024-core 64-bit risc-array processor. Hot Chips: A Symposium on High Performance Chips (HC29). https://www.hotchips.org/wp-content/uploads/hcArchives/hc29/HC29.23-Posters-Pub/HC29.23.p60-Adapteva.pdf.

[Akiba et al., 2019] Akiba, T., Sano, S., Yanase, T., Ohta, T., and Koyama, M. (2019). Optuna: A next-generation hyper-parameter optimization framework. In Teredesai, A., Kumar, V., Li, Y., Rosales, R., Terzi, E., and Karypis, G., editors, *Proceedings of the 25th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining, KDD 2019*, Anchorage, AK, USA, August 4-8, 2019, pages 2623-2631. ACM.

[Almaless, 2014] Almaless, G. (2014). *Conception et réalisation d'un système d'exploitation pour des processeurs manycores. (Operating System Design and Implementation for Single-Chip cc-NUMA Many-Core)*. PhD thesis, Pierre and Marie Curie University, Paris, France.

[Amarasinghe et al., 2005] Amarasinghe, S. P., Gordon, M. I., Karczmarek, M., Lin, J., Maze, D., Rabbah, R. M., and Thies, W. (2005). Language and compiler design for streaming applications. *Int. J. Parallel Program.*, 33(2-3):261-278.

[Amazon Web Service, 2016] Amazon Web Service (2016). Aws ec2 fpga development kit. GitHub Repository. https://github.com/aws/aws-fpga.

[AMD Inc., 2019] AMD Inc. (2019). Amd epyc 7742. AMD website. https://www.amd.com/fr/products/cpu/amd-epyc-7742.

[Andres et al., 2009] Andres, E., Widhalm, M., and Caloto, A. (2009). Achieving high speed cfd simulations: Optimization, parallelization, and fpga acceleration for the unstructured dlr tau code.

[Antoniu et al., 2005] Antoniu, G., Bougé, L., and Jan, M. (2005). Juxmem: An adaptive supportive platform for data sharing on the grid. *Scalable Comput. Pract. Exp.*, 6(3).

[Antoniu et al., 2007] Antoniu, G., Caron, E., Desprez, F., Fèvre, A., and Jan, M. (2007). Towards a transparent data access model for the gridrpcparadigm. In Aluru, S., Parashar, M., Badrinath, R., and Prasanna, V. K., editors, *High Performance Computing - HiPC 2007, 14th International Conference, Goa, India, December 18-21, 2007, Proceedings*, volume 4873 of *Lecture Notes in Computer Science*, pages 269-284. Springer.

[Arap and Swany, 2014] Arap, O. and Swany, M. (2014). Offloading MPI parallel prefix scan (mpi_scan) with the netfpga. CoRR, abs/1408.4939.

[ARM, 2017] ARM (2017). AMBA AXI and ACE Protocol Specification. ARM IHI 0022H (ID040120). https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/IHI0022H_amba_axi_protocol_spec.pdf.

[arm Limited, 2004] arm Limited (2004). ARM1176JZF-S technical reference manual. arm Developer. https://developer.arm.com/documentation/ddi0301/h/.

[Arnold et al., 2012] Arnold, S. S., Nuzzaci, R., and Gordon-Ross, A. (2012). Energy budgeting for cubesats with an integrated fpga. In *2012 IEEE Aerospace Conference*, pages 1-14.

[Astudillo-Salinas et al., 2016] Astudillo-Salinas, F., Barrera-Salamea, D., Rodas, A. V., and Solano-Quinde, L. D. (2016). Minimizing the power consumption in raspberry pi to use as a remote WSN gateway. In *8th IEEE Latin-American Conference on Communications, LATINCOM 2016, Medellin, Colombia, November 15-17, 2016*, pages 1-5. IEEE.

[Augonnet et al., 2012] Augonnet, C., Aumage, O., Furmento, N., Namyst, R., and Thibault, S. (2012). Starpu-mpi: Task programming over clusters of machines enhanced with accelerators. In Träff, J. L., Benkner, S., and Dongarra, J. J., editors, *Recent Advances in the Message Passing Interface - 19th European MPI Users' Group Meeting, EuroMPI 2012, Vienna, Austria, September 23-26, 2012. Proceedings*, volume 7490 of *Lecture Notes in Computer Science*, pages 298-299. Springer.
[Augonnet et al., 2011] Augonnet, C., Thibault, S., Namyst, R., and Wacrenier, P. (2011). Starpu : a unified platform for task scheduling on heterogeneous multicore architectures. *Concurr. Comput. Pract. Exp.*, 23(2):187-198.

[Bach et al., 2010] Bach, M., Charney, M., Cohn, R., Demikhovsky, E., Devor, T., Hazelwood, K. M., Jaleel, A., Luk, C., Lyons, G., Patil, H., and Tal, A. (2010). Analyzing parallel programs with pin. *Computer*, 43(3):34-41.

[Bader and JáJá, 1999] Bader, D. A. and JáJá, J. (1999). SIMPLE : A methodology for programming high performance algorithms on clusters of symmetric multiprocessors (smps). *J. Parallel Distributed Comput.*, 58(1):92-108.

[Bailey et al., 1991] Bailey, D. H., Barszcz, E., Barton, J. T., Browning, D. S., Carter, R. L., Dagum, L., Fatoohi, R. A., Frederickson, P. O., Lasinski, T. A., Schreiber, R., Simon, H. D., Venkatakrishnan, V., and Weeratunga, S. (1991). The nas parallel benchmarks. *Int. J. High Perform. Comput. Appl.*, 5(3):63-73.

[Banâtre et al., 2000] Banâtre, J., Fradet, P., and Métayer, D. L. (2000). Gamma and the chemical reaction model : Fifteen years after. In Calude, C., Paun, G., Rozenberg, G., and Salomaa, A., editors, *Multiset Processing, Mathematical, Computer Science, and Molecular Computing Points of View [Workshop on Multiset Processing, WMP 2000, Curtea de Arges, Romania, August 21-25, 2000]*, volume 2235 of *Lecture Notes in Computer Science*, pages 17-44. Springer.

[Banâtre et al., 2004] Banâtre, J., Fradet, P., and Radenac, Y. (2004). Higher-order chemical programming style. In Banâtre, J., Fradet, P., Giavitto, J., and Michel, O., editors, *Unconventional Programming Paradigms. International Workshop UPP 2004, Le Mont Saint Michel, France, September 15-17, 2004, Revised Selected and Invited Papers*, volume 3566 of *Lecture Notes in Computer Science*, pages 84-95. Springer.

[Banâtre and Métayer, 1990] Banâtre, J. and Métayer, D. L. (1990). The GAMMA model and its discipline of programming. *Sci. Comput. Program.*, 15(1):55-77.

[Barlas, 2015] Barlas, G. (2015). Chapter 1 - introduction. In Barlas, G., editor, *Multicore and GPU Programming*, pages 1 - 26. Morgan Kaufmann, Boston.

[Bartenstein and Liu, 2013] Bartenstein, T. and Liu, Y. D. (2013). Green streams for data-intensive software. In Notkin, D., Cheng, B. H. C., and Pohl, K., editors, *35th International Conference on Software Engineering, ICSE '13, San Francisco, CA, USA, May 18-26, 2013*, pages 532-541. IEEE Computer Society.

[Bell et al., 2008] Bell, S., Edwards, B., Amann, J., Conlin, R., Joyce, K., Leung, V., MacKay, J., Reif, M., Bao, L., III, J. F. B., Mattina, M., Miao, C., Ramey, C., Wentzlaff, D., Anderson, W., Berger, E., Fairbanks, N., Khan, D., Montenegro, F., Stickney, J., and Zook, J. (2008). TILE64 - processor : A 64-core soc with mesh interconnect. In *2008 IEEE International Solid-State Circuits Conference, ISSCC 2008, Digest of Technical Papers, San Francisco, CA, USA, February 3-7, 2008*, pages 88-89. IEEE.

[Benabderrahmane et al., 2010] Benabderrahmane, M., Pouchet, L., Cohen, A., and Bastoul, C. (2010). The polyhedral model is more widely applicable than you think. In Gupta, R., editor, *Compiler Construction, 19th International Conference, CC 2010, Held as Part of the Joint European Conferences on Theory and Practice of Software, ETAPS 2010, Paphos, Cyprus, March 20-28, 2010. Proceedings*, volume 6011 of *Lecture Notes in Computer Science*, pages 283-303. Springer.

[Benazouz et al., 2013] Benazouz, M., Kordon, A. M., Hujsa, T., and Bodin, B. (2013). Liveness evaluation of a cyclo-static dataflow graph. In *The 50th Annual Design Automation Conference 2013, DAC '13, Austin, TX, USA, May 29 - June 07, 2013*, pages 3:1-3:7. ACM.

[Beri et al., 2017] Beri, T., Bansal, S., and Kumar, S. (2017). The unicorn runtime : Efficient distributed shared memory programming for hybrid CPU-GPU clusters. *IEEE Trans. Parallel Distributed Syst.*, 28(5):1518-1534.

[Bershad et al., 1993] Bershad, B. N., Zekauskas, M. J., and Sawdon, W. A. (1993). The Midway distributed shared memory system. In *Proceedings of the 38th IEEE International Computer Conference (COMPCON Spring '93)*, pages 528-537, Los Alamitos, CA.

[Bielert et al., 2015] Bielert, M., Ciorba, F. M., Feldhoff, K., Ilsche, T., and Nagel, W. E. (2015). HAEC-SIM : a simulation framework for highly adaptive energy-efficient computing platforms. In Theodoropoulos, G., editor, *Proceedings of the 8th International Conference on Simulation Tools and Techniques, Athens, Greece, August 24-26, 2015*, pages 129-138. ICST/ACM.

[Bilsen et al., 1996] Bilsen, G., Engels, M., Lauwereins, R., and Peperstraete, J. (1996). Cycle-static dataflow. *IEEE Transactions on Signal Processing*, 44(2):397-408.

[Bohnenstiehl et al., 2017] Bohnenstiehl, B., Stillmaker, A., Pimentel, J. J., Andreas, T., Liu, B., Tran, A., Adeagbo, E., and Baas, B. M. (2017). Kilocore : A 32-nm 1000-processor computational array. *IEEE J. Solid State Circuits*, 52(4):891-902.

[Bolze et al., 2006] Bolze, R., Cappello, F., Caron, E., Daydé, M. J., Desprez, F., Jeannot, E., Jégou, Y., Lanteri, S., Leduc, J., Melab, N., Mornet, G., Namyst, R., Primet, P., Quétier, B., Richard, O., Talbi, E., and Touche, I. (2006). Grid'5000 : A large scale and highly reconfigurable experimental grid testbed. *Int. J. High Perform. Comput. Appl.*, 20(4):481-494.

[Boudguiga et al., 2021] Boudguiga, A., Stan, O., Fazzat, A., Labiod, H., and Clet, P. (2021). Privacy preserving services for intelligent transportation systems with homomorphic encryption. In Mori, P., Lenzini, G., and Furnell, S., editors, *Proceedings of the 7th International Conference on Information Systems Security and Privacy, ICISSP 2021, Online Streaming, February 11-13, 2021*, pages 684-693. SCITEPRESS.
[Buck et al., 2004] Buck, I., Foley, T., Horn, D. R., Sugerman, J., Fatahalian, K., Houston, M., and Hanrahan, P. (2004). Brook for gpus: stream computing on graphics hardware. *ACM Trans. Graph.*, 23(3):777–786.

[Carter et al., 1991] Carter, J. B., Bennett, J. K., and Zwaenepoel, W. (1991). Implementation and performance of munin. In Levy, H. M., editor, *Proceedings of the Thirteenth ACM Symposium on Operating System Principles, SOSP 1991, Asilomar Conference Center, Pacific Grove, California, USA, October 13-16, 1991*, pages 152–164. ACM.

[CEA, 2017] CEA (2017). N2d2, première plateforme européenne de deep learning en open source. CEA Espace Presse. https://www.cea.fr/presse/Pages/actualites-communiques/ntic/plateforme-n2d2-deep-learning.aspx.

[Cenedese et al., 2017] Cenedese, A., Tramarin, F., and Vitturi, S. (2017). An energy efficient ethernet strategy based on traffic prediction and shaping. *IEEE Trans. Commun.*, 65(1):270–282.

[Cho et al., 2003] Cho, J., Oh, S., Kim, J., Lee, H. H., and Lee, J. (2003). Neighbor caching in multi-hop wireless ad hoc networks. *IEEE Commun. Lett.*, 7(11):525–527.

[Christodoulis et al., 2018] Christodoulis, G., Broquedis, F., Muller, O., Selva, M., and Desprez, F. (2018). An FPGA target for the starpu heterogeneous runtime system. In Niar, S. and Saghir, M. A. R., editors, *13th International Symposium on Reconfigurable Communication-centric Systems-on-Chip, ReCoSoC 2018, Lille, France, July 9-11, 2018*, pages 1–8. IEEE.

[Creveuil, 1991] Creveuil, C. (1991). *Techniques d'analyse et de mise en oeuvre des programmes gamma*. PhD thesis. Thèse de doctorat dirigée par Le Métayer, Daniel Informatique Rennes 1 1991.

[Culler et al., 1999] Culler, D. E., Singh, J. P., and Gupta, A. (1999). *Parallel computer architecture - a hardware / software approach*. Morgan Kaufmann.

[Cutress and Shilov, 2019] Cutress, I. and Shilov, A. (2019). The larrabee chapter closes: Intel's final xeon phi processors now in eol. AnandTech. https://www.anandtech.com/show/14305/intel-xeon-phi-knights-mill-now-eol.

[Czajkowski et al., 2012] Czajkowski, T. S., Aydonat, U., Denisenko, D., Freeman, J., Kinsner, M., Neto, D., Wong, J., Yiannacouras, P., and Singh, D. P. (2012). From opencl to high-performance hardware on FPGAS. In Koch, D., Singh, S., and Tørresen, J., editors, *22nd International Conference on Field Programmable Logic and Applications (FPL), Oslo, Norway, August 29-31, 2012*, pages 531–534. IEEE.

[Dahmani, 2015] Dahmani, S. (2015). *Modèles et protocoles de cohérence de données, décision et optimisation à la compilation pour des architectures massivement parallèles. (Data Consistency Models and Protocols, Decision and Optimization at Compile Time for Massively Parallel Architectures)*. PhD thesis, University of Southern Brittany, Morbihan, France.

[Davis and Hu, 2011] Davis, T. A. and Hu, Y. (2011). The university of florida sparse matrix collection. *ACM Trans. Math. Softw.*, 38(1):1:1–1:25.

[de Dinechin, 2015] de Dinechin, B. D. (2015). Kalray mppa®: Massively parallel processor array: Revisiting DSP acceleration with the kalray MPPA manycore processor. In *2015 IEEE Hot Chips 27 Symposium (HCS), Cupertino, CA, USA, August 22-25, 2015*, pages 1–27. IEEE.

[de Dinechin et al., 2013a] de Dinechin, B. D., Ayrignac, R., Beaucamps, P., Couvert, P., Ganne, B., de Massas, P. G., Jacquet, F., Jones, S., Chaisemartin, N. M., Riss, F., and Strudel, T. (2013a). A clustered manycore processor architecture for embedded and accelerated applications. In *IEEE High Performance Extreme Computing Conference, HPEC 2013, Waltham, MA, USA, September 10-12, 2013*, pages 1–6. IEEE.

[de Oliveira Castro et al., 2010] de Oliveira Castro, P., Louise, S., and Barthou, D. (2010). A multidimensional array slicing DSL for stream programming. In Barolli, L., Xhafa, F., Vitabile, S., and Hsu, H., editors, *CISIS 2010, The Fourth International Conference on Complex, Intelligent and Software Intensive Systems, Krakow, Poland, 15-18 February 2010*, pages 913–918. IEEE Computer Society.

[Dennard et al., 1974] Dennard, R. H., Gaensslen, F. H., Yu, H., Rideout, V. L., Bassous, E., and LeBlanc, A. R. (1974). Design of ion-implanted mosfet's with very small physical dimensions. *IEEE Journal of Solid-State Circuits*, 9(5):256–268.

[Denolf et al., 2007] Denolf, K., Bekooij, M. J. G., Cockx, J., Verkest, D., and Corporaal, H. (2007). Exploiting the expressiveness of cyclo-static dataflow to model multimedia implementations. *EURASIP J. Adv. Signal Process.*, 2007.

[Design Spot, 2018] Design Spot (2018). FACE : Démonstrateur de l'architecture électronique du véhicule de demain. Design Spot, Université Paris-Saclay. https://www.designspot.fr/portfolio/face/.

[Dimakopoulos and Hadjidoukas, 2011] Dimakopoulos, V. V. and Hadjidoukas, P. E. (2011). HOMPI: A hybrid programming framework for expressing and deploying task-based parallelism. In Jeannot, E., Namyst, R., and Roman, J., editors, *Euro-Par 2011 Parallel Processing - 17th International Conference, Euro-Par 2011, Bordeaux, France, August 29 - September 2, 2011, Proceedings, Part II*, volume 6853 of *Lecture Notes in Computer Science*, pages 14–26. Springer.

[Djidi et al., 2021] Djidi, N. E. H., Gautier, M., Courtay, A., and Berder, O. (2021). Mees-wur: Minimum energy coding with early shutdown for wake-up receivers. *IEEE Trans. Green Commun. Netw.*, 5(3):1502–1513.
[Domke et al., 2019] Domke, J., Matsumura, K., Wahib, M., Zhang, H., Yashima, K., Tsuchikawa, T., Tsuji, Y., Podobas, A., and Matsuoka, S. (2019). Double-precision fpus in high-performance computing : An embarrassment of riches? In *2019 IEEE International Parallel and Distributed Processing Symposium, IPDPS 2019, Rio de Janeiro, Brazil, May 20-24, 2019*, pages 78–88. IEEE.

[Dongarra, 2016] Dongarra, J. (2016). Report on the sunway taihulight system. University of Tennessee, Oak Ridge National Laboratory, Tech Report UT-EECS-16-742. http://www.netlib.org/utk/people/JackDongarra/PAPERS/sunway-report-2016.pdf.

[Dongarra, 1987] Dongarra, J. J. (1987). The LINPACK benchmark : An explanation. In Houstis, E. N., Papatheodorou, T. S., and Polychronopoulos, C. D., editors, *Supercomputing, 1st International Conference, Athens, Greece, June 8-12, 1987, Proceedings*, volume 297 of *Lecture Notes in Computer Science*, pages 456–474. Springer.

[Dubrulle et al., 2012] Dubrulle, P., Louise, S., Sirdey, R., and David, V. (2012). A low-overhead dedicated execution support for stream applications on shared-memory cmp. In Jerraya, A., Carloni, L. P., Maraninchi, F., and Regehr, J., editors, *Proceedings of the 12th International Conference on Embedded Software, EMSOFT 2012, part of the Eighth Embedded Systems Week, ESWeek 2012, Tampere, Finland, October 7-12, 2012*, pages 143–152. ACM.

[Dybdahl and Stenström, 2007] Dybdahl, H. and Stenström, P. (2007). An adaptive shared/private NUCA cache partitioning scheme for chip multiprocessors. In *13th International Conference on High-Performance Computer Architecture (HPCA-13 2007), 10-14 February 2007, Phoenix, Arizona, USA*, pages 2–12. IEEE Computer Society.

[Eastep et al., 2017] Eastep, J., Sylvester, S., Cantalupo, C., Geltz, B., Ardanaz, F., Al-Rawi, A., Livingston, K., Keceli, F., Maiterth, M., and Jana, S. (2017). Global extensible open power manager : A vehicle for HPC community collaboration on co-designed energy management solutions. In Kunkel, J. M., Yokota, R., Balaji, P., and Keyes, D. E., editors, *High Performance Computing - 32nd International Conference, ISC High Performance 2017, Frankfurt, Germany, June 18-22, 2017, Proceedings*, volume 10266 of *Lecture Notes in Computer Science*, pages 394–412. Springer.

[Eker and Janneck, 2003] Eker, J. and Janneck, J. W. (2003). Cal language report specification of the cal actor language. Technical Report UCB/ERL M03/48, EECS Department, University of California, Berkeley. http://www.eecs.berkeley.edu/Pubs/TechRpts/2003/4186.html.

[Eskandari et al., 2006] Eskandari, H., Geiger, C. D., and Lamont, G. B. (2006). Fastpga : A dynamic population sizing approach for solving expensive multiobjective optimization problems. In Obayashi, S., Deb, K., Poloni, C., Hiroyasu, T., and Murata, T., editors, *Evolutionary Multi-Criterion Optimization, 4th International Conference, EMO 2007, Matsushima, Japan, March 5-8, 2007, Proceedings*, volume 4403 of *Lecture Notes in Computer Science*, pages 141–155. Springer.

[Filgueras et al., 2014] Filgueras, A., Gil, E., Jiménez-González, D., Álvarez, C., Martorell, X., Langer, J., Noguera, J., and Vissers, K. A. (2014). Ompss@zynq all-programmable soc ecosystem. In Betz, V. and Constantinides, G. A., editors, *The 2014 ACM/SIGDA International Symposium on Field-Programmable Gate Arrays, FPGA '14, Monterey, CA, USA - February 26 - 28, 2014*, pages 137–146. ACM.

[Foster, 1995] Foster, I. T. (1995). *Designing and building parallel programs - concepts and tools for parallel software engineering*. Addison-Wesley.

[Foster and Kesselman, 2004] Foster, I. T. and Kesselman, C., editors (2004). *The Grid 2 - Blueprint for a New Computing Infrastructure, Second Edition*. The Morgan Kaufmann Series in Computer Architecture and Design. Morgan Kaufmann.

[Friese et al., 2013] Friese, R., Khemka, B., Maciejewski, A. A., Siegel, H. J., Koenig, G. A., Powers, S., Hilton, M., Rambharos, J., Okonski, G., and Poole, S. W. (2013). An analysis framework for investigating the trade-offs between system performance and energy consumption in a heterogeneous computing environment. In *2013 IEEE International Symposium on Parallel & Distributed Processing, Workshops and Phd Forum, Cambridge, MA, USA, May 20-24, 2013*, pages 19–30. IEEE.

[Fujitsu Limited, 2020] Fujitsu Limited (2020). A64FX microarchitecture manual. Technical Report Edition 1.3, Fujitsu Limited. https://www.stonybrook.edu/commcms/ookami/support/_docs/A64FX_Microarchitecture_Manual_en_1.3.pdf.

[Gabriel et al., 2004] Gabriel, E., Fagg, G. E., Bosilca, G., Angskun, T., Dongarra, J. J., Squyres, J. M., Sahay, V., Kambadur, P., Barrett, B., Lumsdaine, A., Castain, R. H., Daniel, D. J., Graham, R. L., and Woodall, T. S. (2004). Open MPI : goals, concept, and design of a next generation MPI implementation. In Kranzlmüller, D., Kacsuk, P., and Dongarra, J. J., editors, *Recent Advances in Parallel Virtual Machine and Message Passing Interface, 11th European PVM/MPI Users' Group Meeting, Budapest, Hungary, September 19-22, 2004, Proceedings*, volume 3241 of *Lecture Notes in Computer Science*, pages 97–104. Springer.

[Galea and Sirdey, 2012] Galea, F. and Sirdey, R. (2012). A parallel simulated annealing approach for the mapping of large process networks. In *26th IEEE International Parallel and Distributed Processing Symposium Workshops & PhD Forum, IPDPS 2012, Shanghai, China, May 21-25, 2012*, pages 1787–1792. IEEE Computer Society.
[Gao et al., 2009] Gao, S., Schmidt, A. G., and Sass, R. (2009). Hardware implementation of mpibarrier on an FPGA cluster. In Danek, M., Kadlec, J., and Nelson, B. E., editors, *19th International Conference on Field Programmable Logic and Applications, FPL 2009, August 31 - September 2, 2009, Prague, Czech Republic*, pages 12–17. IEEE.

[Gelado et al., 2010] Gelado, I., Cabezas, J., Navarro, N., Stone, J. E., Patel, S. J., and Hwu, W. W. (2010). An asymmetric distributed shared memory model for heterogeneous parallel systems. In Hoe, J. C. and Adve, V. S., editors, *Proceedings of the 15th International Conference on Architectural Support for Programming Languages and Operating Systems, ASPLOS 2010, Pittsburgh, Pennsylvania, USA, March 13-17, 2010*, pages 347–358. ACM.

[Gordon et al., 2006] Gordon, M. I., Thies, W., and Amarasinghe, S. P. (2006). Exploiting coarse-grained task, data, and pipeline parallelism in stream programs. In Shen, J. P. and Martonosi, M., editors, *Proceedings of the 12th International Conference on Architectural Support for Programming Languages and Operating Systems, ASPLOS 2006, San Jose, CA, USA, October 21-25, 2006*, pages 151–162. ACM.

[Gordon et al., 2002] Gordon, M. I., Thies, W., Karczmarek, M., Lin, J., Meli, A. S., Lamb, A. A., Leger, C., Wong, J., Hoffmann, H., Maze, D., and Amarasinghe, S. P. (2002). A stream compiler for communication-exposed architectures. In Gharachorloo, K. and Wood, D. A., editors, *Proceedings of the 10th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS-X), San Jose, California, USA, October 5-9, 2002*, pages 291–303. ACM Press.

[Goubier et al., 2014] Goubier, T., Couroussé, D., and Azaiez, S. (2014). $\tau C: C$ with process network extensions for embedded manycores. In Abramson, D., Lees, M., Krzhizhanovskaya, V. V., Dongarra, J. J., and Sloot, P. M. A., editors, *Proceedings of the International Conference on Computational Science, ICCS 2014, Cairns, Queensland, Australia, 10-12 June, 2014*, volume 29 of *Procedia Computer Science*, pages 1100–1112. Elsevier.

[Goubier et al., 2020a] Goubier, T., Martinovic, J., Dubrulle, P., Ganne, L., Louise, S., Martinovic, T., and Slaninová, K. (2020a). Real-time model of computation over hpc/cloud orchestration - the LEXIS approach. In Barolli, L., Poniszewska-Maranda, A., and Enokido, T., editors, *Complex, Intelligent and Software Intensive Systems - Proceedings of the 14th International Conference on Complex, Intelligent and Software Intensive Systems (CISIS-2020), Lodz, Poland, 1-3 July 2020*, volume 1194 of *Advances in Intelligent Systems and Computing*, pages 255–266. Springer.

[Goubier et al., 2020b] Goubier, T., Rakowsky, N., and Harig, S. (2020b). Fast tsunami simulations for a real-time emergency response flow. In *IEEE/ACM HPC for Urgent Decision Making, UrgentHPC@SC 2020, Atlanta, GA, USA, November 13, 2020*, pages 21–26. IEEE.

[Goubier et al., 2011] Goubier, T., Sirdey, R., Louise, S., and David, V. (2011). $\Sigma c$: A programming model and language for embedded manycores. In Xiang, Y., Cuzzocrea, A., Hobbs, M., and Zhou, W., editors, *Algorithms and Architectures for Parallel Processing - 11th International Conference, ICA3PP, Melbourne, Australia, October 24-26, 2011, Proceedings, Part I*, volume 7016 of *Lecture Notes in Computer Science*, pages 385–394. Springer.

[Griessl et al., 2014] Griessl, R., Peykanu, M., Hagemeyer, J., Porrmann, M., Krupop, S., vor dem Berge, M., Kiesel, T., and Christmann, W. (2014). A scalable server architecture for next-generation heterogeneous compute clusters. In *12th IEEE International Conference on Embedded and Ubiquitous Computing, EUC 2014, Milano, Italy, August 26-28, 2014*, pages 146–153. IEEE Computer Society.

[Hascoet et al., 2017] Hascoet, J., Desnos, K., Nezan, J., and de Dinechin, B. D. (2017). Hierarchical dataflow model for efficient programming of clustered manycore processors. In *28th IEEE International Conference on Application-specific Systems, Architectures and Processors, ASAP 2017, Seattle, WA, USA, July 10-12, 2017*, pages 137–142. IEEE Computer Society.

[Hashemi et al., 2018] Hashemi, M., Swersky, K., Smith, J. A., Ayers, G., Litz, H., Chang, J., Kozyrakis, C., and Ranganathan, P. (2018). Learning memory access patterns. In Dy, J. G. and Krause, A., editors, *Proceedings of the 35th International Conference on Machine Learning, ICML 2018, Stockholm, Sweden, July 10-15, 2018*, volume 80 of *Proceedings of Machine Learning Research*, pages 1924–1933. PMLR.

[Heinrich et al., 2017] Heinrich, F. C., Cornebize, T., Degomme, A., Legrand, A., Carpen-Amarie, A., Hunold, S., Orgerie, A., and Quinson, M. (2017). Predicting the energy-consumption of MPI applications at scale using only a single node. In *2017 IEEE International Conference on Cluster Computing, CLUSTER 2017, Honolulu, HI, USA, September 5-8, 2017*, pages 92–102. IEEE Computer Society.

[Hennessy and Patterson, 2012] Hennessy, J. L. and Patterson, D. A. (2012). *Computer Architecture - A Quantitative Approach, 5th Edition*. Morgan Kaufmann.

[Herrero et al., 2010] Herrero, E., González, J., and Canal, R. (2010). Elastic cooperative caching: an autonomous dynamically adaptive memory hierarchy for chip multiprocessors. In Seznec, A., Weiser, U. C. and Ronen, R., editors, *37th International Symposium on Computer Architecture (ISCA 2010), June 19-23, 2010, Saint-Malo, France*, pages 419–428. ACM.

[Hilbert, 1935] Hilbert, D. (1935). Über die stetige abbildung einer linie auf ein flächenstück. In *Dritter Band : Analysis · Grundlagen der Mathematik · Physik Verschiedenes : Nebst Einer Lebensgeschichte*, pages 1–2, Berlin, Heidelberg. Springer Berlin Heidelberg.
[Holmedahl et al., 1998] Holmedahl, V., Smith, B., and Yang, T. (1998). Cooperative caching of dynamic content on a distributed web server. In *Proceedings of the Seventh IEEE International Symposium on High Performance Distributed Computing, HPDC '98*, Chicago, Illinois, USA, July 28-31, 1998, pages 243-250. IEEE Computer Society.

[Howard et al., 2011] Howard, J., Dighe, S., Vangal, S. R., Ruhl, G., Borkar, N., Jain, S., Erraguntla, V., Konow, M., Riepen, M., Gries, M., Droege, G., Lund-Larsen, T., Steibl, S., Borkar, S., De, V. K., and der Wijngaart, R. F. V. (2011). A 48-core IA-32 processor in 45 nm CMOS using on-die message-passing and DVFS for performance and power scaling. *IEEE J. Solid State Circuits*, 46(1):173-183.

[HPE, 2014] HPE (2014). Pioneering enterprise-class 64-bit arm server technology : Hp moonshot system on 64-bit arm. Hewlett-Packard Development Company Solution Brief. http://www.hp.com/hpinfo/newsroom/press_kits/2014/ARMmomentum/HP ARM SolutionBrief.pdf.

[Huang et al., 2016] Huang, M., Wu, D., Yu, C. H., Fang, Z., Interlandi, M., Condie, T., and Cong, J. (2016). Programming and runtime support to blaze FPGA accelerator deployment at datacenter scale. In Aguilera, M. K., Cooper, B., and Diao, Y., editors, *Proceedings of the Seventh ACM Symposium on Cloud Computing, Santa Clara, CA, USA, October 5-7, 2016*, pages 456-469. ACM.

[Intel, 2009] Intel (2009). An introduction to the Intel QuickPath Interconnect. Document Number 320412-001US. https://www.intel.fr/content/dam/doc/white-paper/quick-path-interconnect-introduction-paper.pdf.

[Irofti, 2020] Irofti, D. (2020). An anticipatory protocol to reach fast consensus in multi-agent systems. *Autom.*, 113:108776.

[ITRS, 2011] ITRS (2011). System driver chapter 2010 updates. International Technology Roadmap for Semiconductors, International Technology Working Group. http://www.itrs.net.

[ITRS2.0, 2015] ITRS2.0 (2015). Executive report. International Technology Roadmap for Semiconductors 2.0, International Technology Working Group. https://www.semiconductors.org/resources/2015-international-technology-roadmap-for-semiconductors-itrs/.

[Kahn, 1974] Kahn, G. (1974). The semantics of a simple language for parallel programming. In Rosenfeld, J. L., editor, *Information Processing, Proceedings of the 6th IFIP Congress 1974, Stockholm, Sweden, August 5-10, 1974*, pages 471-475. North-Holland.

[Karp et al., 1967] Karp, R. M., Miller, R. E., and Winograd, S. (1967). The organization of computations for uniform recurrence equations. *J. ACM*, 14(3):563-590.

[Kathail, 2020] Kathail, V. (2020). Xilinx vitis unified software platform. In Neuendorffer, S. and Shannon, L., editors, *FPGA '20: The 2020 ACM/SIGDA International Symposium on Field-Programmable Gate Arrays, Seaside, CA, USA, February 23-25, 2020*, pages 173-174. ACM.

[Kaxiras et al., 2015] Kaxiras, S., Klaftenegger, D., Norgren, M., Ros, A., and Sagonas, K. (2015). Turning centralized coherence and distributed critical-section execution on their head: A new approach for scalable distributed shared memory. In Kielmann, T., Hildebrand, D., and Taufer, M., editors, *Proceedings of the 24th International Symposium on High-Performance Parallel and Distributed Computing, HPDC 2015, Portland, OR, USA, June 15-19, 2015*, pages 3-14. ACM.

[Keleher et al., 1994] Keleher, P. J., Cox, A. L., Dwarkadas, S., and Zwaenepoel, W. (1994). Treadmarks: Distributed shared memory on standard workstations and operating systems. In *USENIX Winter 1994 Technical Conference, San Francisco, California, USA, January 17-21, 1994, Conference Proceedings*, pages 115-132. USENIX Association.

[Keltcher et al., 2002] Keltcher, C., Ahmed, A., Clark, M., Gao, H., Goveas, K., Haddad, R., Holloway, B., Hughes, B., Klass, R., Kroesche, D., Madrid, P., McGrath, K., Tan, T., White, S., Wood, T., and Zuraski, G. (2002). The amd hammer processor core. HotChips 14. https://webpages.eng.wayne.edu/~ad5781/ECECourses/ECE5620/Manuals/Hammer2_AMD.pdf.

[Kirchner et al., 2015] Kirchner, F., Kosmatov, N., Prevosto, V., Signoles, J., and Yakobowski, B. (2015). Frama-c: A software analysis perspective. *Formal Aspects Comput.*, 27(3):573-609.

[Kubiatowicz et al., 2000] Kubiatowicz, J., Bindel, D., Chen, Y., Czerwinski, S. E., Eaton, P. R., Geels, D., Gummadi, R., Rhea, S. C., Weatherspoon, H., Weimer, W., Wells, C., and Zhao, B. Y. (2000). Oceanstore: An architecture for global-scale persistent storage. In Rudolph, L. and Gupta, A., editors, *ASPLOS-IX Proceedings of the 9th International Conference on Architectural Support for Programming Languages and Operating Systems, Cambridge, MA, USA, November 12-15, 2000*, pages 190-201. ACM Press.

[Kuon and Rose, 2007] Kuon, I. and Rose, J. (2007). Measuring the gap between fpgas and asics. *IEEE Trans. Comput. Aided Des. Integr. Circuits Syst.*, 26(2):203-215.

[Lamport, 1978] Lamport, L. (1978). Time, clocks, and the ordering of events in a distributed system. *Commun. ACM*, 21(7):558-565.

[Lamport, 1979] Lamport, L. (1979). How to make a multiprocessor computer that correctly executes multiprocess programs. *IEEE Trans. Computers*, 28(9):690-691.