Analyse d’Applications Flot de Données pour la Compilation Multiprocesseur

Analyse d’Applications Flot de Données pour la
Compilation Multiprocesseur

Les systèmes embarqués

 Un système embarqué est un équipement électronique et informatique spécialisé dans une tâche précise. Il est autonome et limité en taille, en consommation électrique, et en dissipation thermique. Les premiers systèmes embarqués firent leur apparition dans les années soixante ; ils étaient particulièrement coûteux, et n’étaient utilisés que dans les domaines de l’aérospatiale et de l’armement. Par la suite, ces systèmes furent appliqués à des domaines bien plus vastes, aujourd’hui ils sont incontournables. Qu’il s’agisse d’un simple réveil-matin ou d’une automobile, d’un téléphone ou d’un téléviseur, tous ces équipements contiennent un ou plusieurs systèmes embarqués ou, plus communément, System on Chip (SoC). Un système embarqué se divise en deux parties, l’une matérielle (l’électronique), l’autre logicielle (l’informatique). Le matériel délimite les interfaces et les performances du système tandis que le logiciel définit la ou les fonctions réalisées par ce système. La complexité matérielle de ces équipements n’a cessé de croître, et les systèmes embarqués actuels comptent souvent plusieurs unités de calcul leur permettant de traiter des opérations en simultané. Ce sont des Multi-Processor System on Chip (MPSoC). La société Kalray propose notamment une architecture embarquée composée de plus de 256 cœurs de calcul et plus d’une vingtaine d’interfaces différentes. Avec une dissipation thermique proche de 5 Watt, ce processeur est alors parmi les plus performants du marché. Cependant, les outils de conception logicielle actuels ne sont pas adaptés à ces architectures multicœurs. Pour cette raison, la société Kalray a aussi fait le choix de proposer la chaîne de compilation AccessCore. Il s’agit d’un outil de conception adapté à cette architecture. Il est accompagné d’un langage de programmation dit dataflow (ou flot de données) appelé le ΣC. 

La programmation dataflow 

Les modèles de programmation standards sont généralement séquentiels. Ils définissent un programme par une succession d’opérations. Dans le programme de la Figure 1.1 page ci-contre, les opérations op1, op2, op3 et op4 vont ainsi se succéder infiniment. Des dépendances entre ces opérations sont induites par cet ordre d’exécution. L’exécution parallèle de ces opérations n’est donc pas naturelle. 2 1 while ( true ) { 2 out1 = op1 ( input) ; 3 out2 = op2 ( out1) ; 4 out3 = op3 ( out1) ; 5 output = op4 ( out2 , out3) ; 6 } C. La modélisation dataflow pallie ce problème de parallélisation en permettant de spécifier clairement les dépendances de données entre les différentes opérations. Un dataflow modélise une application sous forme d’un graphe dans lequel, chaque nœud est une tâche (ou un ensemble d’opérations), et les arcs sont des canaux de communication entre ces tâches. La Figure 1.2 est un exemple de dataflow. On remarque que ces différentes tâches peuvent alors s’exécuter en parallèle.Pour certains modèles dataflows, les quantités de données produites et consommées dans ces canaux sont prédéterminées : on parle de modèles statiques. Le principal intérêt de ces modèles statiques est de permettre leur analyse sans avoir à effectuer de simulation. Le langage ΣC (proposé par la société Kalray) permet de décrire des applications sous forme d’un dataflow statique particulier : le modèle Cyclo-Static Dataflow Graph (CSDFG). La chaîne de compilation AccessCore est ainsi en mesure d’évaluer a priori les performances d’un programme ou l’espace mémoire nécessaire à son exécution. Cependant, les CSDFG extraits à partir des applications ΣC sont trop grands pour nous permettre d’utiliser des techniques d’analyse exactes. La complexité de ces méthodes est trop élevée. L’objectif principal de cette thèse est d’apporter des solutions d’analyse efficaces pour la chaîne de compilation AccessCore. Compte tenu de l’ampleur de ce travail, nous avons concentré nos efforts sur trois axes distincts : – le test de vivacité, – l’évaluation du débit maximal, 3 CHAPITRE 1. INTRODUCTION – et le dimensionnement mémoire. La vivacité Lorsqu’il n’y a pas suffisamment de données pour exécuter les tâches d’un dataflow, celui-ci peut atteindre un état de blocage. Si cet état de blocage n’existe pas, on dit alors qu’une application est vivante. Nous proposons une méthode efficace pour vérifier cette propriété pour le modèle CSDFG. L’évaluation du débit maximal Si chaque tâche d’une application dataflow a une durée d’exécution maximale connue (souvent nommée le Worst Case Execution Time), il est possible d’évaluer la vitesse de fonctionnement maximale de cette application. Nous proposons une solution d’évaluation approchée de cette valeur. Le dimensionnement mémoire L’espace disponible pour faire circuler des données dans les canaux de communication d’un dataflow est en théorie infini. Ce n’est plus vrai pour de véritables applications. Nous cherchons alors à déterminer la quantité minimale de mémoire nécessaire pour qu’une application puisse fonctionner correctement et atteigne les performance attendues. Nous proposons différents algorithmes dans ce sens.

 Plan de la thèse et contributions 

Dans le chapitre 2, nous mettons en avant le contexte et les motivations de nos travaux. Nous y présentons l’architecture MPPA et la chaîne de compilation AccessCore, deux produits commercialisés par la société Kalray. Nous commençons par fournir une classification des différentes architectures embarquées existantes. Nous présentons ensuite les principaux outils disponibles pour programmer ces architectures. Dans un second temps, nous considérons la modélisation dataflow comme une solution efficace de la programmation parallèle, et nous énumérons quelques-uns des modèles dataflows utilisés aujourd’hui. Nous terminons alors sur la présentation de la chaîne de compilation AccessCore, et nous situons les étapes sur lesquelles portent nos contributions. Dans le chapitre 3, nous spécifions les problématiques concernées par nos travaux. Nous définissons tout d’abord des résultats d’analyse fondamentaux, puis nous énumérons un à un chaque problème étudié. Pour chacun, nous considérons les méthodes existantes pour 4 les résoudre. Nous remarquons alors que toutes les techniques d’analyse exactes appliquées aux CSDFG se basent sur un ordonnancement au plus tôt. Ce type d’ordonnancement exécute chaque tâche d’un dataflow dès qu’elle dispose de suffisamment de données en entrée. La suite de ce manuscrit s’articule en deux parties. La première partie traite de nos contributions les plus théoriques, qui portent sur l’ordonnancement des modèles dataflows. Dans la seconde partie, ces résultats sont appliqués à l’analyse des modèles CSDFG. Nous détaillons les travaux d’intégration de ces méthodes dans la chaîne de compilation AccessCore.

 Première partie

 Le premier chapitre de cette partie, le chapitre 4, présente une méthode polynomiale pour vérifier la faisabilité de l’ordonnancement périodique d’un CSDFG. Il s’agit d’une contribution fondamentale pour nos travaux, et pour le domaine de l’ordonnancement des modèles CSDFG. Contrairement aux ordonnancements au plus tôt, qui peuvent être de taille exponentielle, la définition d’un ordonnancement périodique est de taille polynomiale. Dans ce chapitre, nous prouvons que le calcul d’un ordonnancement périodique pour un CSDFG est un problème polynomial. Ce résultat est important ; il va nous permettre, dans la suite de nos travaux, d’appliquer les ordonnancements périodiques à l’analyse des dataflows, et de fournir des techniques approchées bien plus rapides que les méthodes exactes connues (puisque la complexité des ordonnancements périodiques est bien plus faible que celle des ordonnancements au plus tôt). La méthode d’ordonnancement précédemment proposée ne nous permet d’obtenir que des solutions d’analyse approchées. Pour améliorer nos résultats, nous étudions dans le chapitre 5 une nouvelle approche : les ordonnancements K-périodiques. Pour tout ordonnancement K-périodique, l’on doit définir un vecteur de périodicité K. Ainsi, plus les valeurs contenues dans ce vecteur sont pertinentes, plus l’ordonnancement K-périodique généré peut être précis. De cette manière, cette famille d’ordonnancement généralise les ordonnancements périodiques (avec un vecteur de périodicité minimal) et au plus tôt (avec un vecteur de taille maximale). Nous proposons une technique de calcul d’un  ordonnancement K-périodique pour un vecteur périodicité fixé, et nous étudions l’impact du vecteur de périodicité sur les performances des ordonnancements obtenus. Il est important de noter que le contexte industriel de nos travaux a fortement influencé la direction de ces recherches. Les résultats théoriques d’ordonnancement obtenus ici furent donc appliqués à l’analyse des applications ΣC. La seconde partie de cette thèse est consacrée à ces applications. 

Deuxième partie 

Le premier chapitre de cette partie, le chapitre 6, présente les différents problèmes d’analyse traités tout au long de cette thèse. Il définit différents algorithmes, et présente les expérimentations réalisées pour évaluer leurs performances. Dans un premier temps, nous proposons un nouvel outil utilisé pour générer nos jeux de test. Puis, dans la continuité des travaux de Benazouz [11], nous proposons une solution algorithmique pour tester la vivacité d’un CSDFG. Nous proposons ensuite une méthode d’évaluation du débit d’un CSDFG ainsi qu’une méthode de dimensionnement mémoire d’un CSDFG. Ces techniques appliquent alors directement les contributions exposées dans le chapitre 4. Après le développement de ces différentes solutions d’analyse, nous avons considéré leur intégration dans la chaîne de compilation AccessCore. Le chapitre 7 porte sur cette intégration. En effet, le langage dataflow proposé par la société Kalray est en perpétuelle évolution. Bien qu’il respecte toujours les contraintes d’un modèle statique, il ne correspond plus à la définition d’un modèle CSDFG. Certaines contraintes supplémentaires sur l’exécution des tâches furent notamment ajoutées. Pour intégrer avec succès les différentes méthodes d’analyse proposées dans le chapitre précédent, il était donc nécessaire d’étendre nos méthodes à ce modèle plus expressif. Pour finir, dans le chapitre 8, nous concluons ce manuscrit et proposons différentes pistes d’amélioration. Nous envisageons également l’application de nos approches à d’autres domaines. Dans les dernières pages, nous proposons également un index des notations utilisées dans ce mémoire.

Table des matières

Liste des tableaux
Table des figures
1 Introduction
2 Contexte
2.1 Les architectures matérielles en informatique
2.1.1 Classification de Flynn
2.1.2 Classification de Raina
2.1.3 L’architecture multiprocesseur MPPA
2.2 La programmation parallèle
2.2.1 Les normes POSIX et MPI
2.2.2 Des interfaces de plus haut niveau
2.2.3 Le langage ΣC
2.3 Modélisation dataflow
2.3.1 Historique
2.3.2 Les modèles dataflows de référence
2.4 Compilation dataflow à destination d’un multiprocesseur
2.4.1 L’exécutif : charnière d’une chaîne de compilation
2.4.2 Des exemples de chaînes de compilation dataflow
2.4.3 La chaîne de compilation AccessCore
3 État de l’art et Problématiques
3.1 Ordonnancement des modèles dataflows statiques
3.1.1 Définition d’un ordonnancement
3.1.2 Relation de précédence
3.1.3 Ordonnancement au plus tôt
3.1.4 Ordonnancement périodique
3.2 Propriétés et transformations des dataflows
3.2.1 Consistance
3.2.2 Vecteur de répétition
3.2.3 Notion de jeton utile
3.2.4 Normalisation
3.2.5 Expansion
3.3 Problématiques
3.3.1 Test de vivacité
3.3.2 Évaluation de la fréquence de fonctionnement
3.3.3 Dimensionnement mémoire
3.4 Nos contributions
3.4.1 Ordonnancement et analyse statique .
3.4.2 Intégration
3.4.3 Générateur d’instances aléatoires
I Contributions à l’ordonnancement des dataflows
4 Ordonnancement périodique
4.1 Ordonnancement périodique d’un CSDFG
4.2 Relation de précédence
4.2.1 Définition d’une relation de précédence
4.2.2 Formulation de l’existence d’une relation de précédence
4.3 Périodicité des relations de précédence
4.3.1 Une condition d’existence nécessaire
4.3.2 Une condition d’existence suffisante
4.4 Une condition nécessaire et suffisante de validité
4.4.1 Caractérisation des contraintes périodiques
4.4.2 Validité d’un ordonnancement périodique
5 Ordonnancement K-périodique
5.1 Ordonnancement K-périodique d’un SDFG
5.1.1 Fréquence de fonctionnement
5.1.2 Définition d’une relation de précédence
5.2 Caractérisation d’une contrainte de précédence
5.2.1 Condition d’existence d’une relation de précédence
5.2.2 Caractérisation d’une contrainte de précédence
5.3 Validité d’un ordonnancement K-périodique
5.3.1 Condition suffisante d’existence d’une relation de précédence
5.3.2 Une condition nécessaire et suffisante de validité
5.4 Évaluation du débit maximal XII
5.5 Influence du vecteur de périodicité
5.5.1 Étude des solutions K-périodiques par l’exemple
5.5.2 Un ordonnancement K-périodique de débit maximal
5.5.3 Une non-linéarité des solutions K-périodiques
5.5.4 Un ensemble de solutions dominantes
5.6 Ordonnancement K-périodique d’un CSDFG
II Application à la compilation dataflow
6 Analyse statique des CSDFG
6.1 Nos jeux de test
6.1.1 Les jeux de test existants
6.1.2 Contribution à la génération aléatoire
6.1.3 Notre sélection de CSDFG
6.2 Vivacité
6.2.1 Évaluation des conditions SC1 et SC2
6.2.2 Un algorithme d’évaluation de la vivacité
6.2.3 Résultats expérimentaux
6.3 Évaluation du débit
6.3.1 Calcul du débit périodique maximal d’un CSDFG
6.3.2 Résultats expérimentaux
6.4 Dimensionnement mémoire
6.4.1 Dimensionnement minimal garantissant la vivacité
6.4.2 Dimensionnement minimal sous contrainte de débit
7 Support du langage ΣC
7.1 Les seuils d’exécution
7.1.1 Computation Graph
7.1.2 Thresholded CSDFG
7.2 Les phases d’initialisation
7.2.1 Initialized CSDFG
8 Conclusion
Bibliographie

projet fin d'etude

Télécharger le document complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *