MÉMOIRE DE MASTER RECHERCHE EN INFORMATIQUE

MÉMOIRE DE MASTER RECHERCHE
EN INFORMATIQUE
présenté par
Nicolas Wojcik
le 16 Juin 2008
COHÉRENCE ET COMPLÉTUDE DES MODÈLES
DE PLACEMENT DE GASPARD2
Sous la direction de :
Pierre Boulet <[email protected]>
Université des Sciences et Technologies de Lille
LIFL - UMR 8022 - Cité Scientifique, Bât. M3 - 59655 Villeneuve d’Ascq
2
Remerciements
Je tiens en premier lieu à remercier Pierre Boulet pour m’avoir encadré au cours de stage, cette
expérience a été très enrichissante et m’a permis d’apprendre et de comprendre énormément de
choses.
Je remercie Jean-Luc Dekeyser pour son accueil au sein de l’équipe DaRT et pour ses questions
toujours pertinentes.
Merci aux nombreux pensionnaires du bureau 106 pour leur bonne humeur au quotidien et
pour les quelques franches rigolades que nous avons partagées.
Merci à Hanna pour ses nombreuses et précieuses relectures de ce mémoire ainsi que pour
toutes les corrections qu’elle y a apporté.
Merci à Rubot (et implicitement à son créateur : Guillaume), notre bot IRC pour ses annonces
salvatrices du menu du RU chaque midi, nous redonnant du courage avec la perspective d’un
repas bienvenu et mérité après une dure matinée de travail.
Cette année de Master Recherche fut longue et éprouvante, aussi je tiens à remercier Alban,
Anthony, Flori, Fred, Grégoire, Guillaume, Thomas, Tony pour les nombreux repas, pauses café
et autres joyeusetés que nous avons partagés tout au long de l’année. Mention spéciale à notre
apprenti ingénieur à trottinette Brieuc qui nous a servi de souffre douleur tout au long de ce stage.
4
Table des matières
1
Introduction
2
Contexte et problématique
2.1 Systèmes sur puces . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Co-conception . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Ingénierie dirigée par les modèles . . . . . . . . . . . . . . . . . .
2.2.1 Modélisation et méta-modélisation . . . . . . . . . . . . . .
2.2.2 Transformation de modèles . . . . . . . . . . . . . . . . . .
2.2.3 Modéliser avec UML . . . . . . . . . . . . . . . . . . . . . .
2.3 L’environnement Gaspard2 . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Le paquetage Component . . . . . . . . . . . . . . . . . . . .
2.3.2 Le paquetage Factorization . . . . . . . . . . . . . . . . . . .
2.3.3 Le paquetage Application . . . . . . . . . . . . . . . . . . . .
2.3.4 Le paquetage HardwareArchitecture . . . . . . . . . . . . . .
2.3.5 Le paquetage Association . . . . . . . . . . . . . . . . . . . .
2.4 Placement et parallélisme de données . . . . . . . . . . . . . . . .
2.4.1 Les langages de programmation à parallèlisme de données
2.4.2 Le placement dans Gaspard2 . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
9
10
11
12
13
14
15
17
18
23
26
27
28
30
34
Des langages à parallélismes de données vers Marte
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Représentation formelle de HPF . . . . . . . . . . . .
3.2.1 Représentation formelle des alignements . . .
3.2.2 Représentation formelle des distributions HPF
3.3 Méthodologie de construction . . . . . . . . . . . . . .
3.3.1 Alignements . . . . . . . . . . . . . . . . . . . .
3.3.2 Distribution . . . . . . . . . . . . . . . . . . . .
3.4 Exemples . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 Distribution (*,block) . . . . . . . . . . . . . . .
3.4.2 Distribution (block, block) . . . . . . . . . . . .
3.4.3 Distribution (cyclic, cyclic) . . . . . . . . . . .
3.4.4 Distribution (block, *, block) . . . . . . . . . . .
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
35
36
36
37
39
39
43
44
45
46
48
49
51
Validation d’un placement Gaspard2
4.1 Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Allocations répétitives . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2 Allocations hiérarchiques . . . . . . . . . . . . . . . . . . . . . . . .
53
53
54
56
3
4
7
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
TABLE DES MATIÈRES
4.2
4.3
5
4.1.3 Ordonnancement . . . . . . . . . . . . . .
Critères de validation d’un modèle d’association
4.2.1 Critère de complétude . . . . . . . . . . .
4.2.2 Critère de cohérence . . . . . . . . . . . .
Outil de vérification d’un placement . . . . . . .
4.3.1 Approches envisagées . . . . . . . . . . .
4.3.2 Plugin de validation Gaspard2 . . . . . .
Conclusion
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
59
60
61
61
62
62
65
69
Chapitre 1
Introduction
ES systèmes électroniques sont soumis à une évolution constante. Les progrès liés à la
l’augmentation de la finesse de gravure en sont à la base. Selon Moore, il est possible
de placer, tous les dix huit mois, deux fois plus de transistors sur une puce. Actuellement les puces sont gravées avec une finesse de 45nm. Cette augmentation de la finesse
de gravure permet donc de placer de plus en plus de composants sur une même puce.
Un domaine particulièrement friand de cette capacité est le domaine des « systèmes sur
puce » (System on Chip ou SoC), ces systèmes ne sont pas dédié à un certain type de
composant mais contiennent tous les composants nécessaires pour former un système informatique complet comprenant processeur, mémoire, réseaux d’interconnexion etc. Les
avantages qu’ils procurent en terme d’espace occupé, de consommation d’énergie et de
coût rendent ces systèmes particulièrement bien adaptés au domaine de l’informatique
embarquée. Cependant, l’utilisation de ce nombre de transistors toujours grandissant impose de disposer de plusieurs processeurs. Cette contrainte s’explique par la difficulté
à augmenter la fréquence de fonctionnement de la puce sans entrer en conflit avec les
contraintes physiques du système.
L
Parallèlement à cette évolution matérielle, les applications de ces systèmes embarqués ont elles aussi vu leur besoins se spécialiser au fil des ans, nécessitant toujours plus
de puissance. On retrouve généralement ces systèmes dans le domaine des transports
(avions, voitures etc.), dans le domaine des systèmes de détection (radars, sonars etc.) et
dans le domaine des systèmes multimédia (baladeurs, téléphones, télévision haute définition etc.). Toutes ces application se retrouvent autour d’un point commun : celui du
traitement de signal, désignant des applications effectuant des suites de calcul sur des flux
de données et qui se prêtent volontiers au calcul parallèle et répétitif.
Néanmoins, si les applications et le matériel évoluent, cela introduit un développement de plus en plus complexe, induisant des délais et des coût de plus en plus important. Il faut donc utiliser de nouvelles approches afin de limiter ces conséquences comme
la conception conjointe (co-conception) du matériel et de l’application. Dans cette approche, l’un des points critique se situe au niveau de l’association, étape permettant de
réunir application et architecture matérielle. Parmi les nombreuses combinaisons possibles, seul un petit nombre sera correct, permettant ainsi d’obtenir un code de simulation
fonctionnel.
C’est à ce niveau, correspondant au placement, que se situent les travaux de ce master
recherche. La méthodologie repose donc sur la co-conception associée avec une approche
7
8
CHAPITRE 1. INTRODUCTION
d’ingénierie dirigée par les modèles par l’intermédiaire de l’environnement Gaspard2. Nous
proposerons d’abord une méthodologie de construction permettant, à partir d’un placement défini dans un langage à parallélisme de données (HPF et Chapel en l’occurence),
d’obtenir le placement équivalent exprimé avec les concepts apportés par le méta-modèle
MARTE. Nous proposerons ensuite l’introduction de critères de vérification pour vérifier
qu’un placement exprimé dans Gaspard2 est valide, nous accompagnerons cette partie de
quelques propositions afin d’enrichir et de rendre moins ambigu le méta-modèle. Cette
vérification sera mise en œuvre par l’intermédiaire d’un outil que nous intégrerons à l’environnement Gaspard2.
Chapitre 2
Contexte et problématique
Sommaire
2.1
2.2
2.3
2.4
Systèmes sur puces . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Co-conception . . . . . . . . . . . . . . . . . . . . . . . . . .
Ingénierie dirigée par les modèles . . . . . . . . . . . . . . . . . .
2.2.1 Modélisation et méta-modélisation . . . . . . . . . . . . . .
2.2.2 Transformation de modèles . . . . . . . . . . . . . . . . . .
2.2.3 Modéliser avec UML . . . . . . . . . . . . . . . . . . . . . .
L’environnement Gaspard2 . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Le paquetage Component . . . . . . . . . . . . . . . . . . . .
2.3.2 Le paquetage Factorization . . . . . . . . . . . . . . . . . . .
2.3.3 Le paquetage Application . . . . . . . . . . . . . . . . . . . .
2.3.4 Le paquetage HardwareArchitecture . . . . . . . . . . . . . .
2.3.5 Le paquetage Association . . . . . . . . . . . . . . . . . . . .
Placement et parallélisme de données . . . . . . . . . . . . . . . .
2.4.1 Les langages de programmation à parallèlisme de données
2.4.2 Le placement dans Gaspard2 . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
10
11
12
13
14
15
17
18
23
26
27
28
30
34
de présenter les contributions apportées durant ce stage, nous allons dresser
un état de l’art des différents travaux relatifs à ce travail. Nous présenterons d’abord
le monde des systèmes dits sur puce, nous introduirons ensuite le domaine de l’ingénierie
dirigée par les modèles, nous continuerons avec la présentation de l’outil Gaspard2 et
nous parlerons enfin de placement et des différents langages à parallélisme de données.
A
VANT
2.1
2.1.1
Systèmes sur puces
Présentation
Un système sur puce (System-on-Chip ou SoC en anglais) désigne un système complet embarqué sur une même puce. Les technologies actuelles permettent d’embarquer
sur une même puce de silicium plusieurs millions de transistors. Cette densité importante permet de placer des systèmes de plus en plus complexes sur une unique puce,
ces systèmes pouvant accueillir des unités de calcul, de la mémoire, des réseaux d’interconnexion etc. On peut donc considérer qu’un système sur puce est l’équivalent d’un
ordinateur complet, mais tenant sur une seule puce matérielle. Toutefois, tandis qu’un
9
10
CHAPITRE 2. CONTEXTE ET PROBLÉMATIQUE
ordinateur traditionnel est conçu pour une utilisation globale, un système sur puce est
dédié à une application particulière : la partie matérielle du système ne contient que les
éléments nécessaires à la tâche choisie et en conséquence la partie logicielle de la puce est
conçue et adaptée à la partie matérielle. Cette spécialisation de la tâche pour un système
donné pose un problème majeur, celui du coût. En effet pour un nouvel usage, il devient
impossible de réutiliser le système, il faut donc en développer un nouveau. Cependant,
d’un autre point de vue, les gains sont multiples : l’utilisation d’une puce unique permet
d’obtenir un système complet très compact, elle permet donc de réduire l’espace utilisé
par cette dernière, caractéristique très prisée pour la conception de matériels comme les
téléphones portables ou les baladeurs numériques. De plus ce caractère compact impose
une proximité des différents composants qui forment le système, ce qui entraîne une
hausse des performances des communications et la consommation est également revue
à la baisse. Tous ces avantages font que l’on retrouve couramment les systèmes sur puce
dans les systèmes embarqués : de l’avionique/automobile, à l’électronique grand public,
en passant par l’électroménager (four, machine à laver etc.), il devient très difficile de
trouver un domaine ne les utilisant pas.
2.1.2
Co-conception
Cependant l’évolution matérielle et l’évolution des besoins rendent les systèmes sur
puce de plus en plus complexes, ce qui pose deux problèmes : la fiabilité de tels systèmes
devient plus complexe à assurer et le temps de conception s’en voit rallongé. D’un point
de vue commercial, ces deux critères doivent être maîtrisés. En effet il serait très dommageable de sortir un système moins fiable et plus tard que le système d’un concurrent. Une
solution pour respecter ces contraintes passe par la conception conjointe du matériel et
du logiciel également appelée co-conception (co-design en anglais). Dans cette approche
l’application, l’architecture et l’association entre les deux sont prises en compte, permettant de réduire l’effort de développement. Elle se base sur le modèle en «Y» de Gasjki et
Kuhn[1] : l’application et l’architecture matérielle sont développées en parallèle, pendant
qu’une équipe travaille sur l’application, une seconde équipe conçoit l’architecture matérielle. Les deux équipes ont des profils hétérogènes et le déroulement parallèle de leurs
travaux permet un gain de temps par rapport à une approche traditionnelle dans laquelle
on attendait que la partie matérielle soit terminée pour commencer à développer le logiciel. Quand le développement a atteint un certain niveau d’avancement, l’application est
associée au matériel : il s’agit de spécifier sur quel processeur sera exécutée chaque tâche
de l’application et sur quelles mémoires seront allouées les données. L’association possède donc un caractère topologique pour déterminer où seront placés les éléments et un
caractère temporel pour déterminer l’ordonnancement des tâches. Quand l’association
est terminée, on peut alors obtenir un code exécutable. La figure 2.1 illustre les étapes de
conception suivant un schéma en « Y ».
La co-conception préconise le respect de plusieurs principes :
– utiliser un même langage pour décrire application et architecture matérielle ;
– promouvoir la réutilisation ;
– utiliser des standards facilitant la sauvegarde, l’échange et la réutilisabilité ;
– utiliser un unique outil capable de centraliser tout le processus de co-conception.
L’une des approches répondant avec succès à ce cahier des charges est présentée dans
2.2. INGÉNIERIE DIRIGÉE PAR LES MODÈLES
11
F IG . 2.1 – Schéma de conception en « Y »
la section suivante.
2.2
Ingénierie dirigée par les modèles
Les systèmes devenant de plus en plus complexes, la compréhension de ces derniers
devient de plus en plus difficile. Une solution pour mieux comprendre un système et pouvoir mieux agir sur celui-ci consiste à disposer d’un modèle du système. Un modèle est
une représentation simplifiée de la réalité mettant en évidence certaines propriétés tout
en en abstrayant d’autres. Dans le cas des systèmes sur puce, les détails d’implémentation seraient par exemple abstraits. Merise[2], SSADM[3] et UML[4] sont des exemples
de méthodes de modélisation. Ces méthodes permettent de manipuler le concept de modèle appliqué à l’informatique en proposant des concepts et une notation permettant de
décrire le système à concevoir. Chaque étape du cycle de développement du système
produit un ensemble de documents le plus souvent constitués de diagrammes permettant aux différents acteurs du projet de partager leurs points de vue sur le système.
Leur lourdeur et leur déficit de souplesse en réaction à l’évolution rapide des logiciels
ont parfois été l’origine de critiques qui ont conduit à la notion de modèles contemplatifs
essentiellement destinés à la communication et à la compréhension. Ces modèles restent
toutefois passifs face à la production, contribuant à laisser, comme c’est le cas depuis plus
de cinquante ans, le code au cœur du processus de production logicielle.
L’ingénierie dirigée par les modèles tente de combler ce manque au niveau des méthodes traditionnelles de modélisation en fournissant un cadre de développement logiciel au sein duquel les modèles passent de l’état contemplatif (passif) à l’état productif
(actif), c’est à dire compréhensibles et interprétables par les machines, devenant ainsi les
éléments majeurs dans le processus de développement des logiciels. La séparation des
concepts métiers est permise dans un but de portabilité et de maintenabilité, la réutilisation des outils et des patrons de conceptions reconnus permettent également d’augmenter la productivité, tout cela permettant au final d’accélérer le développement tout
en réduisant les coûts de conception. Trois concepts fondent la base de l’ingénierie dirigée
par les modèles : les modèles, les méta-modèles et les transformations de modèles, c’est cette dernière notion qui donne le caractère productif à cette méthode.
12
CHAPITRE 2. CONTEXTE ET PROBLÉMATIQUE
Nous allons présenter les concepts fondamentaux qui constituent la base de l’Ingénierie
dirigée par les modèles, nous insisterons ensuite sur la notion qui apporte ce caractère productif à cette méthode puis nous introduirons des approches de méta-modélisation à
l’aide du méta-modèle UML.
2.2.1
Modélisation et méta-modélisation
Le composant de base de l’Ingénierie Dirigée par les Modèles est le modèle, entité permettant de représenter un ensemble d’informations et désignant une abstraction de la réalité
par l’association des symboles du modèle avec des concepts réels et par la description
de liens entre ces différents concepts. Contrairement à d’autres méthodes, l’Ingénierie
Dirigée par les Modèles utilise le modèle comme élément de base tout au long du processus de développement. Si le concept de modèle n’est pas nouveau, il reflète une manière
de penser de l’Homme que l’Ingénierie dirigée par les Modèles a adapté à l’informatique.
Il est maintenant nécessaire de rendre ces modèles interprétables par une machine,
pour cela il est indispensable de disposer d’un formalisme permettant d’exprimer ces modèles. C’est pour cela que le concept de méta-modèle a été introduit. Un méta-modèle permet de spécifier un langage d’expression de modèle, de définir les différents concepts et
leurs relations et il permet également de définir la syntaxe des modèles. Ainsi un modèle
qui est écrit suivant un méta-modèle sera qualifié de conforme à ce dernier, de la même
manière que nous rédigeons ce texte conformément à la grammaire française. Comme
son nom l’indique, un méta-modèle est également lui-même un modèle, c’est à dire qu’il
est conforme à un autre méta-modèle, ce qui est en accord avec la philosophie apportée
par l’Ingénierie Dirigée par les Modèles. Cependant dans cette situation, nous en arriverions, simplement pour exprimer un modèle à définir une infinité de méta-modèles, ce
qui bien sûr n’est pas envisageable. La solution passe par l’utilisation d’un méta-modèle
qui soit conforme à lui-même, c’est à dire exprimable à l’aide des seuls concepts qu’il définit. Les principaux méta-modèles ayant cette caractéristique couramment utilisés sont
Ecore[5] et MOF (Meta-Object Facility) [6].
Différents niveaux de modélisation ont été introduits afin de classer les différents modèles : les niveaux M0, M1, M2 et M3. La figure 2.2 illustre cette hiérarchie :
– M0 représente la réalité (un programme informatique). Dans notre exemple, les
variables Numéro et Solde sont affectées par des valeurs ;
– M1 correspond au premier niveau d’abstraction, c’est un modèle et c’est lui que
manipule un développeur. Pour cet exemple, le modèle contient la déclaration des
variables utilisées dans M0 et la notion de Compte. Un modèle de niveau M1 est
conforme à un métamodèle de niveau M2 ;
– M2 est le niveau dans lequel sont définis les concepts manipulés dans un modèle
de niveau M1 (c’est-à-dire les concepts manipulés par un développeur) . Dans cet
exemple, Compte est une classe tandis que les déclarations de variables sont des
Attributs de cette Classe. Classe et Attributs sont tous deux des concepts du métamodèle de niveau M2, qui est conforme à un métamodèle de niveau M3 ;
– M3 correspond au plus niveau d’abstraction, un méta-métamodèle de niveau M3
est conforme à lui même. Dans cet exemple, les concepts Classe et Attributs sont des
Méta-Classes, tandis que la notion de contenance est une Méta-Relation. Ce métaméta- modèle se décrit lui-même, la Méta-Classe et la Méta-Relation sont des MétaClasses et les relations source et destination qui les lient sont des Méta-Relations.
2.2. INGÉNIERIE DIRIGÉE PAR LES MODÈLES
13
F IG . 2.2 – Les différents niveaux de modélisation
Dans cette classification, Ecore et MOF se situent au niveau M3.
2.2.2
Transformation de modèles
La seconde notion importante de l’Ingénierie dirigée par les modèles est la transformation
de modèles. Elle consiste à passer d’un modèle source décrit à un certain niveau d’abstraction à un modèle destination, qui n’est pas forcément décrit au même niveau d’abstraction que le modèle source. Le modèle source (respectivement destination) est conforme
au méta-modèle source (respectivement destination). Le passage du modèle source au
modèle destination est décrit à l’aide de règles de transformation qui sont exécutées sur le
modèle source pour obtenir le modèle destination. La figure 2.3 illustre le processus de
transformation.
F IG . 2.3 – Transformation de modèle : passage d’un modèle source à un modèle destination
14
CHAPITRE 2. CONTEXTE ET PROBLÉMATIQUE
Tom Mens et al.[7] ont publié une taxonomie des transformations de modèles dans laquelle sont distinguées deux types de transformation : les transformations dites endogènes
pour lesquelles les modèles source et destination sont conformes au même méta-modèle,
si ce n’est pas le cas la transformation est qualifiée d’exogène. Sont également différenciées,
les transformations dites horizontales qui génèrent un modèle de destination au même niveau d’abstraction que le modèle source et les transformations verticales qui génèrent un
modèle destination avec un niveau d’abstraction différent que celui du modèle source.
Les règles de transformation constituent le cœur du processus de transformation de
modèle. Elles permettent de définir la manière dont un ensemble de concepts du métamodèle source est transformé en un ensemble de concepts du méta-modèle destination.
Les règles peuvent être exprimées à l’aide de langages déclaratifs décrivant le résultat
de la création par la règle et les langages impératifs décrivant comment une règle doit
être exécutée. Ce sont les langages déclaratifs qui sont les plus utilisés avec l’IDM car ils
permettent d’exprimer l’intention de la règle indépendamment de son exécution.
L’exécution d’une règle peut-être décomposée en trois étapes que sont la vérification,
l’exécution et la création. La vérification consiste à analyser le modèle source afin de détecter la présence d’un ensemble de concepts conformément à ce que la règle attend en
entrée. Une fois validée, la règle est exécutée par un moteur de transformation qui effectue une sauvegarde, à l’aide de variables, des éléments relatifs à l’ensemble de concepts
vérifié. Enfin la création permet de générer un ensemble de concepts dans le modèle
destination, les différents champs étant remplis à l’aide de la sauvegarde effectuée lors
de l’étape d’exécution. Cette décomposition en règle permet d’identifier des groupes de
concepts permettant de ne manipuler que les concepts nécessaires, elle apporte également une plus grande clarté au niveau des règles et encourage surtout à la réutilisation
de ces dernières, une même règle pouvant être utilisée plusieurs fois dans la même transformation.
Parmi les moteurs de transformations utilisés, on peut citer les outils basés sur le
standard QVT (Query View Transformation) comme SmartQVT ou QVTO. On peut également citer ATL (ATLAS Transformation Language).
2.2.3
Modéliser avec UML
L’un des méta-modèle les plus répandu dans la communauté est le méta-modèle UML
(Unified Modeling Language) [77], il a été standardisé par l’OMG et vise la modélisation
de systèmes informatiques de tout type. Ce caractère très généraliste, ainsi que le fait
qu’il soit très répandu et donc connu de beaucoup de gens constituent les principaux
atouts d’UML. Cependant, dans sa forme livrée, il ne permet pas une utilisation directe
dans un processus d’ingénierie dirigée par les modèles, en effet sa sémantique trop généraliste manque de précision et ne permet pas de produire directement un système. Plus
précisément, de nombreux points laissent apparaître une sémantique ambiguë, laissant
l’utilisateur comme seul décideur de la signification à leur apporter.
De nos jours, l’utilisation d’UML dans un cadre d’ingénierie dirigée par les modèles se
fait par l’intermédiaire de son mécanisme interne de méta-modélisation que l’on appelle
profil. Un profil est un ensemble d’extensions et de restrictions permettant la spécialisation
et la description d’un domaine particulier. Les extensions sont appelées Stéréotypes, elles
2.3. L’ENVIRONNEMENT GASPARD2
15
permettent de spécialiser une ou plusieurs classes UML et peuvent contenir de nouveaux
attributs appelés tagged values. L’utilisation des profils permet d’obtenir un pouvoir d’expression quasiment identique au pouvoir d’expression du MOF tout en ayant accès aux
concepts existants proposés par UML.
L’utilisation des profils permet donc d’utiliser ce mécanisme d’extension pour introduire les concepts manquants pour représenter un certain type de système et pour lever
les ambiguïtés pouvant apparaître d’un point de vue sémantique. Ainsi, un utilisateur familier avec UML peut facilement comprendre tout ou partie d’un modèle utilisant un profil. Un autre avantage est que de nombreux outils manipulant les modèles UML existent
et le plus souvent cette modélisation se fait à l’aide d’une représentation graphique. L’utilisation de profils UML permet aux concepteurs de travailler avec des outils standards et
de se baser sur des notions répandues. Le principal inconvénient reste que les modèles
réalisés avec un profil ne sont pas conformes au métamodèle mais à son implémentation
en UML : une transformation de l’un vers l’autre est donc nécessaire.
Bon nombre de standards de modélisation pour l’IDM voient donc le jour sous la
forme d’un profil UML. Nous allons en présenter deux : SysML et MARTE. SysML [8]
(System Modeling Language) est un profil UML standardisé par l’OMG qui fournit des
mécanismes génériques pour décrire des systèmes complexes sans se spécialiser aux systèmes embarqués. Au contraire le profil pour la modélisation et l’analyse des systèmes
embarqués et temps réel MARTE [9] (Modeling and Analysis of Real-Time and Embedded systems) fournit des concepts précis pour la description des détails d’architectures
matérielles dans les système sur puce. Dans les cas d’analogie avec des concepts SysML,
MARTE réutilise les stéréotypes introduits par SysML ou définit des éléments conceptuellement proche de SysML. Au niveau temporel, MARTE raffine les concepts proposés
par le profil SPT (Scheduling, Performance and Time) [10], permettant ainsi la modélisation du temps logique discret et continu. Il est également possible d’annoter les modèles
conformes au profil MARTE avec des propriétés non fonctionnelles afin d’exprimer des
contraintes que le système doit respecter (contraintes de temps, de consommation d’énergie, etc.).
2.3
L’environnement Gaspard2
Gaspard[11] est un environnement de développement permettant la co-conception
de systèmes sur puce dans un un cadre d’ingénierie dirigée par les modèles. Il est développé au sein de l’équipe DaRT et est orienté vers les applications de traitement de
signal intensif, applications que l’on retrouve le plus souvent dans les systèmes embarqués, qui sont parmi les plus gourmandes en terme de puissance de calcul et qui s’accordent généralement très bien avec la parallélisation des traitements. Gaspard permet
donc d’exploiter les principes de l’ingénierie dirigée par les modèles pour co-modéliser
des systèmes sur puce multiprocesseur ou massivement parallèle qui sera utilisé dans
une application de traitement de signal intensif. Gaspard adopte un flot de conception en
«Y», il permet donc aux concepteurs du système de modéliser de manière indépendante
l’application et l’architecture matérielle du système, ensuite l’étape d’association permet
de les réunir en plaçant l’application sur l’architecture. Ces trois modèles permettent,
par l’intermédiaire de transformations, de générer des simulations à des niveaux de précision de plus en plus important. La vérification formelle de la modélisation de l’application est rendue possible par la génération de langages synchrones déclaratifs [12]
16
CHAPITRE 2. CONTEXTE ET PROBLÉMATIQUE
comme Lustre [13] ou Signal [14], l’exécution concurrente de différents processus sur une
architecture multiprocesseur est rendue possible par la génération de langages procéduraux comme Fortran/OpenMP. La finalité étant de générer un code de simulation, avec
SystemC par exemple, prenant en compte à la fois les parties matérielle et logicielle du
système sur puce complet. La figure 2.4 illustre le processus de développement et l’agencement illustre le flot de conception en «Y».
F IG . 2.4 – Schéma du flot de conception en utilisant l’environnement Gaspard. L’architecture, l’application et l’association sont spécifiées sous forme de modèles.
Le premier méta-modèle à avoir été défini est le méta-modèle permettant de spécifier
les systèmes sur puces multiprocesseur. Ce méta-modèle s’inspire de standards de l’OMG
comme SPT [10] pour la représentation de l’architecture matérielle, SysML pour les mécanismes d’association et UML pour l’approche de modélisation par composants. Gaspard
offre également la possibilité de modéliser sous une forme factorisée des applications et
des architectures régulières ayant un caractère répétitif, cette expression est basée sur le
langage Array-OL (que nous présenterons dans la suite de cette section). Un mécanisme
de factorisation permettant de représenter de manière compacte les systèmes répétitifs
réguliers basé sur le langage Array-OL est présent. Enfin, précisons que le méta-modèle
Gaspard est en partie à la base du récent standard MARTE. Nous tenons à préciser que
dans le cadre de ce stage, nous avons utilisé l’ancienne version du métamodèle Gaspard
plutôt que la nouvelle qui est en cours de migration vers MARTE.
Dans le contexte de développement, ce n’est pas le méta-modèle Gaspard qui est directement manipulé mais le profil UML associé, ceci afin de permettre l’utilisation des
outils standards de modélisation graphique basés sur UML. Une fois modélisé, le modèle conforme au profil UML Gaspard est transformé vers un modèle conforme au métamodèle Gaspard à l’aide d’une transformation de modèles.
Nous allons maintenant présenter les principaux paquetages composants le métamodèle permettant de modéliser les notions de composants, de factorisation, d’application, d’architecture et d’association. Une description plus complète est disponible dans
le rapport technique du profil UML Gaspard2 [15]. La figure 2.5 illustre l’organisation
des différents éléments constitutifs du profil, agencés de manière à bien illustrer le «Y»
formé par les paquetages Application, HardwareArchitecture et Association.
2.3. L’ENVIRONNEMENT GASPARD2
17
F IG . 2.5 – Vue d’ensemble des différents paquetages constituant le profil Gaspard.
2.3.1
Le paquetage Component
Le paquetage Component constitue l’une des bases du méta-modèle Gaspard, il permet de définir l’approche orientée composants qui sera utilisée pour la modélisation. Il
apporte les outils nécessaires pour construire des applications et des architectures matérielles sous une forme structurelle. Adoptant les concepts apportés par UML, il permet
de mettre en œuvre différents mécanismes. Un mécanisme d’encapsulation permet de
rendre la définition d’un composant indépendante de l’environnement dans lequel il est
utilisé, une séparation est donc tracée entre l’intérieur du composant (son implémentation), et la façon dont il perçoit son environnement, ou la façon dont il est perçu par son
environnement. Un mécanisme de composition et d’assemblage apporte une couche hiérarchique pour organiser l’intérieur du composant : un composant peut être composé de
plusieurs composants, afin de par exemple simplifier les fonctionnalités, l’assemblage de
ces composants permet alors d’implémenter des comportements plus complexes.
Le concept de base du paquetage est le Component, c’est l’élément réutilisable manipulé au sein d’un modèle Gaspard. Un Component est défini par un ensemble d’interfaces proposées par l’intermédiaire de Ports et par sa structure composée par un assemblage d’Instances reliées par des Connectors. Si un composant A contient une instance d’un
composant B, cela signifie que le composant A utilise B dans son implémentation. Si un
composant ne contient aucune instance, il est qualifié d’ElementaryComponent, on peut
rapprocher ce type de composant avec une « boîte noire », désignant un niveau de précision à partir duquel le modèle n’apporte plus d’informations. La figure 2.6 illustre ces
différents concepts avec une exemple d’unité de calcul ProcessingUnit définie à l’aide de
trois composants élémentaires : un processeur MIPS, une mémoire Memory et un crossbar
Crossbar4.
Les ports utilisés peuvent être qualifiés de In ou Out, précisant si l’interface est capable de recevoir ou d’émettre des données. En l’absence de qualificatif, l’interface est
capable d’émettre et de recevoir. Les qualificatifs des ports sont très importants vis à
vis des connexions, en effet les connecteurs de délégations, reliant un composant à une
18
CHAPITRE 2. CONTEXTE ET PROBLÉMATIQUE
F IG . 2.6 – Un exemple de composant Gaspard, ProcessingUnit est composé de trois souscomposants instanciés sous les noms cb, mem et mips. Les ports et les connecteurs indiquent les relations entre les instances.
instance, ne peuvent connecter que des ports ayant la même orientation tandis que les
connecteurs d’assemblage, reliant deux instances, ne peuvent connecter que des ports
ayant des orientations opposées.
2.3.2
Le paquetage Factorization
Le paquetage Factorization est l’un des points essentiels du méta-modèle Gaspard. En
effet, les concepts introduits rendent le méta-modèle particulièrement bien adapté aux
systèmes massivement parallèles réguliers. Ces concepts permettent de représenter sous
une forme très compacte la répétition d’un ensemble de composants identiques. Il propose au développeur de systèmes sur puce multiprocesseurs les concepts apportés par
Array-OL, mais généralisés afin d’en permettre l’utilisation pour modéliser les applications mais également les architectures matérielles et les associations.
2.3.2.1
La notion de Shape
Le concept de Shape permet d’indiquer qu’un élément possède une multiplicité, il peut
être appliqué à une instance ou à un port. L’élément sur lequel est appliqué le Shape est
alors vu comme une collection composée d’un nombre d’éléments qu’il détermine. Cette
collection est structurée avec un tableau multidimensionnel et son expression se fait par
l’intermédiaire d’un vecteur de nombres entiers strictement positifs, chaque composante
du vecteur déterminant la taille, c’est-à-dire le nombre d’éléments, de la dimension du
tableau associé. La figure 2.7 illustre ce concept avec un exemple représentant 4 instances
d’un composant organisées sous la forme d’un tableau bidimensionnel de 2 x 2 instances.
À noter qu’une dimension peut être déclarée comme infinie en spécifiant le symbole ∼ à
la place d’un entier, cette spécificité ne s’appliquant évidemment qu’à l’application pour
représenter un traitement répété de manière infinie dans le temps, définir un composant
matériel aux ressources physiques illimitées n’ayant bien sûr pas de sens.
2.3. L’ENVIRONNEMENT GASPARD2
19
F IG . 2.7 – Représentation d’un composant Gaspard2 avec une multiplicité bidimensionnelle (sur la gauche) et son équivalent en UML2 (sur la droite).
2.3.2.2
La notion de Tiler
La notion de Tiler a été créée afin d’apporter un moyen simple, compact et élégant
d’accéder aux éléments des tableaux multidimensionnels caractérisés par une Shape. L’idée
générale est d’identifier au sein de ces tableaux des ensembles d’éléments que l’on appelle
motifs. Cet ensemble de points correspondant à un motif est appelé une tuile (en anglais
tile). Ces motifs sont caractérisés par un espacement régulier des différents points, c’est
ce que l’on appelle l’ajustage (en anglais fitting). Avec un ensemble de motifs il est donc
possible de parcourir tout le tableau afin d’en récupérer tous les éléments. Tout comme
les éléments des motifs, les différentes tuiles sont caractérisées par un espacement entre
elles, c’est ce qu’on appelle le pavage (en anglais paving). La couverture complète d’un
tableau nécessite trois informations supplémentaires : une origine, point faisant office de
référence, un espace de répétition délivrant une information concernant le nombre de tuiles
à utiliser afin de parcourir tout le tableau et la taille du motif (le nombre de points à considérer pour chaque dimension du tableau). Derrière ces notions se cache en fait le modèle
de calcul Array-OL.
Pour un motif donné, l’identification d’une tuile se fait à partir d’un élément de référence dans le tableau, nous l’appellerons ref. L’espacement des différents éléments au
sein de la tuile est déterminé par l’intermédiaire de la matrice d’ajustage et en rapport avec
le point de référence. Le nombre de lignes de la matrice correspond au nombre de dimensions du tableau et le nombre de colonnes correspond au nombre de dimensions du motif
que l’on veut récupérer. Chaque élément ei de la tuile étant déterminé par la somme des
coordonnées du point de référence et de la multiplication de la matrice d’ajustage par les
coordonnées i de l’élément du motif, comme exprimé dans la formule suivante :
∀i, O ≤ i < Spattern , ei = ref + F · i mod Sarray
(2.1)
Spattern représentant la forme du motif, Sarray représentant la forme du tableau et F étant
20
CHAPITRE 2. CONTEXTE ET PROBLÉMATIQUE
la matrice d’ajustage.
Les figures 2.8 et 2.9 présentent deux exemples afin d’illustrer cette notion de motif. Le
premier exemple montre l’utilisation d’une tuile récupérant six points contigus à l’intérieur d’un motif rectangulaire et le second exemple montre l’utilisation d’une tuile creuse
pour récupérer six points non contigus sur chaque dimension avec un motif trapézoïdal.
( 02 ) ( 12 )
( 01 ) ( 11 )
( 00 )
F =
( 10 )
1 0
0 1
!
!
spattern =
2
3
F IG . 2.8 – La tuile a un motif bidimensionnel et contient 6 éléments, la matrice d’ajustage permet de sélectionner des éléments de manière contiguë pour obtenir un rectangle
régulier.
( 12 )
( 02 )
( 01 )
( 00 )
( 11 )
( 10 )
F =
2 1
0 1
!
spattern =
2
3
!
F IG . 2.9 – Cet exemple illustre le fait qu’une tuile peut être creuse. La matrice d’ajustage
permet en effet de sélectionner des éléments qui ne sont pas forcément contigus dans le
tableau et de manière non parallèle aux axes.
Pour chaque répétition, le pavage permet de préciser la position de l’élément de référence utilisé pour positionner la tuile dans le tableau. Le placement de ces éléments se
fait de manière analogue à la construction d’une tuile, il est déterminé par l’intermédiaire
d’une matrice de pavage. Le nombre de ligne de cette matrice correspond au nombre de dimensions du tableau et le nombre de colonnes correspond au nombre de dimensions de
l’espace de répétition. Initialement, l’élément de référence de la répétition de base correspond à l’origine o. Pour une répétition r donnée, les coordonnées de refr sont obtenues
en faisant la somme de l’origine et du produit de la matrice de pavage par r, comme
exprimé dans la formule suivante :
∀r, 0 ≤ r < Srepetition , refr = o + P · r
mod Sarray
(2.2)
P étant la matrice de pavage et Srepetition la forme de l’espace de répétition.
La figure 2.10 illustre le processus complet de pavage d’un tableau, le tableau a deux
dimensions : neuf éléments sur la première dimension et huit éléments sur la seconde.
La tuile utilisée est un rectangle contenant trois éléments sur la première dimension et
2.3. L’ENVIRONNEMENT GASPARD2
7
7
0
7
0
7
7
0
0 r = (2) 8
1
o=
0
0
P =
3 0
0 4
7
0
0 r = (0) 8
0
F =
1 0
0 1
0
0 r = (1) 8
1
0 r = (0) 8
1
21
!
!
spattern =
3
4
sarray =
9
8
srepetition =
3
2
!
!
!
!
0
0 r = (1) 8
0
0 r = (2) 8
0
F IG . 2.10 – Pavage complet du tableau par une tuile de dimension {3,4}
quatre éléments sur la seconde dimension. Pour couvrir complètement le tableau, il est
donc nécessaire de répéter l’opération trois fois pour la première dimension et deux fois
pour la seconde. Pour chaque répétition, le point de référence se déplace, soit de trois
unités sur la première dimension, soit de quatre unités sur la seconde dimension ou soit
la combinaison des deux déplacements.
Ainsi, l’ajustage permet de décrire les coordonnées des points d’une tuile relativement
à un point de référence, le pavage permet de décrire l’ensemble des points de référence
des tuiles relativement à l’origine. Le parcours complet d’un tableau est donc rendu possible avec les trois informations que sont l’origine (représentée par un vecteur d’entiers),
la matrice d’ajustage (contenant des entiers) et la matrice de pavage (contenant des entiers). Pour une tuile d’indice r dans l’espace de répétition, l’ensemble des points sont
énumérés à partir d’un point d’indice i dans le motif avec la formule suivante :
o+ F
r
P ·
i
!
mod Sarray
(2.3)
F étant la matrice d’ajustage, P la matrice de pavage, o l’origine du tableau et Sarray
la forme du tableau.
Cette formule garantie que :
– les points de la tuile sont régulièrement espacés car ils sont construits depuis le
point de référence de la tuile par combinaison linéaire des vecteurs colonnes de la
matrice d’ajustage ;
– les points de référence des tuiles sont régulièrement espacés car ils sont construits
depuis l’origine par combinaison linéaire des vecteurs colonnes de la matrice de
pavage ;
– tous les points de la tuile sont des points du tableau : les calculs sont effectués modulo la taille du tableau.
La figure 2.11 illustre un exemple de tiler dans une application. Prenons le cas du
connecteur situé entre les ports m1 et A, le port m1 a une dimension 128x128 et le port A
a une dimension de 8x8, Le Tiler permet de découper le tableau situé sur m1 par blocs de
8x8 éléments contigus.
22
CHAPITRE 2. CONTEXTE ET PROBLÉMATIQUE
F IG . 2.11 – Illustration de la notion de Tiler.
2.3.2.3
La notion de Reshape
Le concept de Reshape a été introduit afin de permettre la liaison élément par élément de deux tableaux ayant des formes différentes. Au niveau conceptuel, un Reshape
se contente simplement d’associer deux Tilers l’un après l’autre, le premier Tiler ayant
pour tâche de rassembler par motifs les éléments du premier tableau vers un motif intermédiaire et le second Tiler ayant pour fonction de répartir les éléments du motif intermédiaire sous une nouvelle forme dans le tableau de sortie. En plus des deux Tilers,
le Reshape apporte les notions de PatternShape et de RepetitionSpace, le PatternShape permettant de représenter la forme du motif intermédiaire et le RepetitionSpace permettant
d’exprimer l’espace de répétition parcouru afin de complètement remplir le tableau de
sortie. La figure 2.12 illustre un exemple de Reshape. Dans cet exemple, il y a deux tâches
t1 et t2, chaque ligne du tableau de sortie de t1 est rangée dans une colonne du tableau
d’entrée de t2. On passe donc d’un tableau de dimension 3 x 2 à un tableau de dimension
2 x 3.
F IG . 2.12 – Un exemple de Reshape.
Cette notion de Reshape apporte donc une représentation plus compacte permettant
d’éviter l’introduction d’une tâche «fantôme» ne faisant que consommer les motifs d’un
tableau d’entrée pour ensuite les ranger dans un tableau de sortie par l’intermédiaire de
2.3. L’ENVIRONNEMENT GASPARD2
23
Tiler comme le montre la figure 2.13
F IG . 2.13 – Reshape exprimé à l’aide d’une « tâche fantôme »
2.3.2.4
Les notions d’InterRepetition et de Defaultlink
Les derniers concepts apportés par le paquetage Factorization concernent les notions
d’ InterRepetition et de DefaultLink. InterRepetition permet de qualifier les liens existants
entre plusieurs éléments membres du même tableau. InterRepetition permet de définir
des dépendances de données entre les différentes itérations ou des liens de communications en ce qui concerne les éléments d’une grille par exemple 2.14. DefaultLink permet
quant à lui d’exprimer des connexions irrégulières pouvant se situer sur les bords d’un
tableau d’éléments.
2.3.3
Le paquetage Application
Le paquetage Application apporte les notions nécessaires pour indiquer qu’un composant représente une partie de l’application et qu’en tant que tel, il est nécessaire d’y
associer une sémantique propre. La notion principale introduite étant la classe ApplicationComponent. Avec cette sémantique, les applications peuvent être représentées par un
langage de flot de données s’appuyant sur les concepts définis dans les paquetages Component et Factorization. Ce langage est très fortement inspiré de Array-OL dont nous allons présenter les concepts principaux liés à son modèle de calcul [16, 17] et utilisé dans
le cadre du paquetage Application. Rappelons également, que par Application, on définit
le comportement du système en fonction des entrées qu’on lui fournit, tout ou partie de
l’application peut donc être sous une forme logicielle ou matérielle.
L’objectif du paquetage Application est de permettre l’expression d’applications de
traitement de signal intensif travaillant avec des tableaux multidimensionnels. La dif-
24
CHAPITRE 2. CONTEXTE ET PROBLÉMATIQUE
F IG . 2.14 – Illustration des liens InterRepetition, à gauche le composant Gaspard représentant une grille, à droite son équivalent UML
ficulté dans la mise au point de telles applications ne provient pas des fonctions élémentaires constituant l’application (pour la plupart, ce sont des fonctions répandues ou
disponibles par l’intermédiaire de bibliothèques) mais de leur association ainsi que de la
manière d’accéder aux tableaux de données utilisés. La finalité de tels systèmes étant d’en
ressortir des performances, il est indispensable d’utiliser le parallélisme potentiel offert
par l’application, de manière à l’associer au parallélisme disponible offert par l’architecture matérielle.
Dans cette optique, un certain nombre de principes de base ont été choisis pour constituer le langage :
– tout le parallélisme potentiel est exprimé ;
– toutes les dépendances de données sont explicites ;
– les tableaux sont à assignation unique, chaque élément peut être lu plusieurs fois
mais ne peut être écrit qu’une seule fois ;
– il n’y a pas de différentiation dans le traitement des dimensions spatiale et temporelle dans les tableaux.
L’application est alors vue comme un graphe de dépendances, chaque nœud représentant une tâche et chaque arête correspondant à une dépendance entre deux tâches. Le
graphe possède un caractère hiérarchique, chaque nœud pouvant contenir lui-même un
graphe de dépendances, l’application est donc un ensemble de tâches connectées par l’intermédiaire de ports. Au niveau du méta-modèle Gaspard, les tâches sont représentées
par des instances de ApplicationComponents et les ports par des Ports.
On recense trois types de tâches :
– les tâches élémentaires, représentées par des instances d’ElementaryComponent et
qui correspondent à des fonctions cachées à l’intérieur de boîtes noires ;
– les tâches composées, représentées par l’instance d’un Component contenant plusieurs instances, de telles tâches correspondent à des graphes de dépendances ;
– les tâches répétées, représentées par des instances de Component sur lesquelles des
Shape ont été spécifiées.
2.3. L’ENVIRONNEMENT GASPARD2
25
Les tâches communiquent par l’intermédiaire de tableaux multidimensionnels qui
peuvent avoir une dimension infinie, chaque tableau étant spécifié par une Shape pour
préciser sa taille. Les Ports sont également spécifiés avec une shape et avec le type des
éléments du tableau auquel il accède.
2.3.3.1
Parallélisme de tâches
La notion de parallélisme de tâches n’a de sens que dans le contexte de tâches composées. Dans ce cas, la composition interne d’un composant correspond à un graphe acyclique orienté, chaque nœud du graphe correspond à une tâche et chaque arête correspond à une dépendance reliant deux ports de même taille et de même type, un nœud
représentant une instance et une arête un connecteur reliant port de sortie et port d’entrée. Aucune contrainte n’est définie concernant le type et la taille des ports d’entrée et
de sortie d’une tâche, une tâche pouvant lire deux tableaux à une dimension pour ne produire qu’un tableau à deux dimensions. La figure 2.15 illustre cette notion de parallélisme
de tâches avec un exemple contenant 4 tâches : un producteur, deux consommateurs et un
agrégateur. L’agrégateur a possède une dépendance sur les consommateurs c1 et c2. Les
ports de chaque composants sont orientés, imposant l’exécution du producteur p avant
les autres tâches. Les deux consommateurs c1 et c2 peuvent être exécutés en parallèles.
F IG . 2.15 – Exemple d’une tâche composée dans Gaspard, elle est constituée de quatre
sous-tâches : p, c1, c2 et a. La tâche a possède deux dépendances sur c1 et c2, possédant
elles-même chacune une dépendance sur p. Les tâches c1 et c2 peuvent être exécutée de
manière parallèle.
Lors de son exécution, un tâche lit ses tableaux d’entrée un par un et écrit le résultat de
son exécution dans ses tableaux de sortie, ce qui correspond à un graphe de dépendance
permettant l’ordonnancement des tâches ainsi que l’expression du parallélisme potentiel
de l’application. En effet, si deux tâches A et B ont leurs dépendances de satisfaites, il est
possible de les exécuter de manière parallèle.
26
2.3.3.2
CHAPITRE 2. CONTEXTE ET PROBLÉMATIQUE
Parallélisme de données
Le parallélisme de données est toujours lié à l’expression des répétitions de tâches,
l’idée étant que chaque répétition de la tâche est indépendante : il n’y a pas d’ordre imposé pour l’exécution, les tâches peuvent donc être exécutées en parallèle. Les Connectors
qui interviennent ne peuvent être spécifiés qu’avec des Tilers, ils vont permettre de découper les tableaux présents sur les ports du composant père, pour en faire des motifs
qui seront présents sur les ports du composant lui-même. Chaque répétition de tâche
n’accède donc qu’à un sous ensemble des tableaux du composant. La figure 2.16 illustre
un exemple d’application mettant en œuvre le parallélisme de données. Le composant
AplusB contient une tâche Sum répétée 16 x 16 fois et prenant en entrée les données de
deux matrices pour en sortir un résultat. Chaque répétition de la tâche va s’occuper de
traiter deux motifs des tableaux d’entrée.
F IG . 2.16 – Parallélisme de données.
Les notions de sémantique apportées par le paquetage Application permettent donc
de représenter les dépendances entre les tâches et les répétitions de tâches. Il est également possible de déterminer les dépendances entre un élément du tableau de sortie et les
éléments du tableau d’entrée. Toutes ces informations permettent au final, de déduire un
ordre d’exécution des tâches.
2.3.4
Le paquetage HardwareArchitecture
Le paquetage hardwareArchitecture apporte les éléments nécessaires au concepteur
pour définir la composition de l’architecture matérielle du système sur puce. La représentation est toujours assurée à un haut niveau grâce aux notions du paquetage Component qui permet de représenter la structure et la hiérarchie du matériel. Les liaisons directes entre composants sont représentées par les ports et les connecteurs, un connecteur
étant équivalent à une connexion de transaction, c’est-à-dire qu’il représente un ensemble
de fils. Les différents éléments de l’architecture matérielle ont été classifiés dans quatre
catégories : Processor, Memory, Communication et IO. Chaque catégorie étant elle-même
décomposée en un ensemble de sous-types plus précis assurant un niveau de détails suffisant pour représenter de manière globale l’architecture du système afin d’y associer une
2.3. L’ENVIRONNEMENT GASPARD2
27
application. Le comportement de l’architecture se situe au niveau des «boîtes noires» représentant les composants matériels élémentaires. La figure 2.17 illustre un exemple de
composant matériel.
F IG . 2.17 – Un exemple de composant Gaspard, ProcessingUnit est composé de trois souscomposants instanciés sous les noms cb, mem et mips correspondant respectivement à un
crossbar, une mémoire et un processeur.
À noter également que les concepts introduits par le paquetage Factorization concernant les multiplicités peuvent être appliqués aux composants matériels, la figure 2.18
illustre la spécification d’une grille de processeur, et ce d’une manière très compacte.
F IG . 2.18 – Composant matériel Gaspard représentant une grille de 16 unités de calcul
réparties sur 2 dimensions.
2.3.5
Le paquetage Association
Le paquetage Association est le dernier paquetage du méta-modèle MARTE, il apporte les notions nécessaires pour compléter le modèle en «Y» et établir un lien entre
une application et une architecture matérielle servant de support d’exécution. L’association consiste donc à placer les éléments de l’application sur des éléments de l’architecture
28
CHAPITRE 2. CONTEXTE ET PROBLÉMATIQUE
matérielle. Les allocations peuvent être de plusieurs types : une TaskAllocation permet de
décrire l’association d’une tâche sur une ressource de calcul (processeur, accélérateur matériel), une DataAllocation permet d’exprimer l’allocation de données sur une mémoire et
une CommunicationAllocation permet d’indiquer comment synchroniser deux mémoires,
son utilisation est indiquée lorsque plusieurs tâches partagent des données allouées sur
différentes mémoires de la plate-forme d’exécution et dans ce cas, les données sont copiées en suivant l’information concernant la route donnée par l’allocation. Ces différentes
notions d’allocation ne permettent néanmoins de ne spécifier que des placements spatiaux d’application. La gestion du caractère temporel du placement est confiée au compilateur qui a la charge de prendre ces décisions. La figure 2.19 illustre un exemple d’allocation simple d’une tâche sur un processeur.
F IG . 2.19 – Allocation de la tâche appli sur le processeur proc.
Ces notions d’allocations ne concernent toutefois que des éléments simples, pour
prendre en compte les aspects introduits par le paquetage Factorization et leur utilisation pour les éléments d’une application et d’une architecture matérielle, la notion de
Distribution a été introduite. Elle permet de distribuer une tâche répétée sur un ensemble
de processeurs mais également de spécifier le placement d’un tableau de données sur un
ensemble de mémoires. La figure 2.20 illustre cette notion avec un exemple de distribution de tâches sur un élément d’une architecture matérielle.
2.4
Placement et parallélisme de données
Le développement du calcul scientifique a été accompagné depuis de nombreuses décennies par le développement de divers langages de programmation. Le premier d’entre
eux à avoir permis au programmeur d’être exempté de la tâche visant à porter un algorithme en code machine est Fortran. Il a vu le jour en 1956 et a rapidement été suivi
par l’arrivée d’Algol de Pascal, du C et d’Ada. Dans le même temps, d’autres langages
ont été développés pour des domaines différents, le COBOL dédié aux les entreprises,
le Prolog et le LISP pour l’intelligence artificielle et PL/1 pour le traitement de données,
PL/1 étant l’un des langages les plus larges, couvrant des domaines d’application allant
des systèmes à la programmation scientifique. Ensuite sont apparus les langages orientés
2.4. PLACEMENT ET PARALLÉLISME DE DONNÉES
29
F IG . 2.20 – Distribution d’une tâche répétée sur une grille de 16 unités de calcul.
objet comme C++, Java et Smalltalk. Ces derniers ont contribué à ce que l’accent soit davantage mis sur la philosophie de conception du programme, faisant de ces langages des
outils très généralistes. On recense également les langages de scripts comme Basic, Perl,
Python ou Ruby.
Cependant, avec l’avènement du calcul parallèle, l’un des principaux objectifs était de
concevoir des compilateurs capables de faire de la parallélisation automatique, ce qui est
plutôt difficile. Plusieurs projets ont été menés afin d’ajouter de manière transparente au
compilateur des directives qu’il serait libre d’appliquer ou non. L’un d’entre eux est High
Performance Fortran qui contient des directives pouvant être assimilées à des commentaires par un compilateur ou donner des suggestions sur la manière d’exploiter le parallélisme à l’intérieur du code. Cependant ces directives se sont révélées insuffisantes pour
décrire les algorithmes qui émergeaient. Sont alors apparues des librairies comme MPI
ou PVM permettant d’ajouter de la communication et de la coopération entre différents
processeurs. Ces fonctionnalités sont définies à l’extérieur du langage de programmation
et sont accessibles via des bindings fournis par l’API. Récemment, de nouveaux langages
intégrant des notions de parallélisme sont apparus : CAF, UPC, Titanium, réutilisant des
langages existants : Fortran95, C, et Java en proposant des ajouts pour supporter les parallélisations basées sur le PGASM.
Le projet HPCS (High Productivity Computing Systems) a été fondé en 2002 par le
DARPA (l’agence américaine pour les projets de recherche avancée de défense) dans le
but de créer une nouvelle génération d’environnement de programmation, d’outils logiciels et de nouvelles architectures matérielles. L’un des objectifs du projet est le développement de nouveaux langages supportant ces environnements de calcul à forte productivité. Trois langages que sont Fortress, Chapel et X10 ont ainsi été définis dans le cadre
30
CHAPITRE 2. CONTEXTE ET PROBLÉMATIQUE
du projet. Ces différents langages devraient à terme prendre la place du vieillissant HPF,
devenant au fil des ans de moins en moins utilisé.
2.4.1
2.4.1.1
Les langages de programmation à parallèlisme de données
HPF
High Performance Fortran est un langage à parallélisme de données, sa première
ébauche fût le fruit de nombreuses discussions initiées lors d’une réunion du High Performance Fortran Forum, consortium composé de constructeurs et de vendeurs de compilateurs. Le but étant de définir un langage adapté au calcul scientifique et respectant
diverses contraintes comme :
– la compatibilité avec le langage Fortran ;
– une orientation générale pour ne pas se restreindre à un modèle d’architecture particulier ;
– une mise en oeuvre facilitée du parallélisme garantissant des performances quelle
que soit l’architecture cible.
La version 1.0 de HPF, apparue en 1993, repose sur un Fortran 90 complété par un
ensemble de directives permettant d’exprimer les notions de parallélisation. Un noyau
minimum appelé subset HPF permettant des extensions progressives.
Le modèle d’exécution le plus adapté au modèle de programmation du langage est le
modèle SPMD1 . La contrainte de généralité a donc été « effacée » au profit du parallélisme
de données pour des raisons de simplicité et de performances : en effet, le parallélisme
de tâches serait trop difficile à manipuler et l’exprimer sans perte de performances serait
très compliqué.
La version 2.0 du langage, apparue en 1997, ajoute une série d’extensions approuvées,
d’autres fonctionnalités sont également ajoutées comme les distributions généralisées ou
les notions de sous-ensembles de processeurs.
Le langage HPF est donc un Fortran que l’on complète par l’ajout de directives de
parallélisation et de placement de données. L’ajout de ces directives n’entravent pas la
syntaxe du programme si on le soumet à un compilateur standard Fortran, en effet elles
prennent la forme de commentaires et ne sont ainsi pas évaluées lors d’une compilation
en Fortran traditionnel.
En ce qui concerne le placement, HPF distingue ce processus suivant deux aspects de
la répartition des données sur différents nœuds :
– les alignements qui consistent à placer des tableaux les uns par rapport aux autres
dans un but de réductions des communications ;
– les distributions qui consistent à spécifier comment seront réparties ces ensembles
de données afin d’équilibrer la charge des processeurs.
Un alignement est une information concernant la manière dont un tableau doit être aligné sur un template, un template étant un tableau fictif sur lequel sont alignés d’autres tableaux. Différents types d’alignements sont proposés, dont certains permettant soit d’im1
Simple Program Multiple Data
2.4. PLACEMENT ET PARALLÉLISME DE DONNÉES
31
poser une réplication des données, soit un effondrement des données selon le contexte
dans lequel l’alignement est défini.
Derrière le terme distribution se cache le fait de répartir régulièrement les éléments
d’un tableau (ou d’un template) sur les éléments d’une processors, un processor étant une
structure abstraire définie par HPF et qui modélise une machine cible virtuelle. Une grille
multidimensionnelle et homogène de processeurs abstraits2 forme la structure d’un processor. Cette répartition s’effectuant pour chaque dimension source sur les dimensions successives du processors cible.
Une répartition peut être de l’un des types suivants : Block, Cyclic, Block(n), Cyclic(n) ou *
correspondant à ce qu’on appelle l’effondrement d’une dimension.
2.4.1.2
Fortress
Le langage Fortress [18] est développé par Sun Microsystems et vise à être un langage
généraliste pour les applications à hautes performances avec un haut niveau de programmabilité. C’est un objectif important et le langage est large et complexe en conséquence.
Par son nom, Fortress tend à évoquer l’idée d’un « Fortran sécurisé » , combinant les
idéaux de Fortran concernant le calcul haute performance avec l’abstraction et les types
sécurisés inhérents aux langages modernes comme C++ ou Java. Pourtant Fortress n’est
pas une évolution de Fortran, c’est un langage développé à partir de zéro. Afin d’explorer
des approches en rupture avec les tendances actuelles, Fortress n’a pas été mis au point
en vue de respecter une syntaxe ou une sémantique particulière. Tous les aspects du calcul haute performance ont ainsi été repensés depuis l’origine.
Les concepts de base de Fortress sont les objets et les traits [19]. Les objets font partie de la programmation orientée objet traditionnelle, ils sont composés d’attributs et de
méthodes. Les traits, quant à eux, sont des unités composables de comportement qui permettent la réutilisation de méthodes entre classes non apparentées. Ils mettent l’accent
sur le pouvoir de composition en essayant d’être le moins contraignant possible, contrairement aux limitations des mécanismes comme l’héritage ou les mixins [20].
Fortress est capable de prendre en compte des spécifications telles que des transactions, des spécifications de localisation et du calcul parallèle implicite, comme des spécifications entières construites et incluses dans le coeur du langage. Des spécifications
telles que le système d’extension (ou de composantes) de Fortress ou son environnement
de test, facilitent l’assemblage du programme et sa mise à l’essai, et permettent de puissantes optimisations du compilateur à travers les librairies.
Même la syntaxe et le système d’entrée de Fortress sont taillés sur mesure pour la
programmation d’applications de calcul hautes performance modernes, en acceptant les
notations mathématiques et la vérification statique de propriétés telles que les unités physiques ou les dimensions. De plus, Fortress a été mis au point dans l’intention d’être
un langage évolutif, en supportant l’ajout futur de nouvelles spécifications du langage.
En fait, la plupart du langage Fortress lui même (y compris la définition de tableaux et
d’autres types de base) est codée dans des librairies fondées sur un langage cœur relativement léger.
2
processeurs élémentaires
32
CHAPITRE 2. CONTEXTE ET PROBLÉMATIQUE
En ce qui concerne le placement, Fortress introduit le concept de région. Chaque tâche,
chaque objet et chaque élément d’un tableau Fortress (correspondant au stockage physique de l’élément) se voit attribuer une région. Les régions décrivent de manière abstraite la structure de la machine sur laquelle le programme est exécuté. Ces régions sont
organisées hiérarchiquement pour former un arbre, on distingue la région globale qui représente la racine de la hiérarchie des régions. Les différents niveaux de l’arbre illustrent la structure de la machine comme les processeurs, les mémoires partagées par des
groupes de processeurs ou des ressources distribuées à travers la machine entière. Dans
un contexte multi processeurs à mémoire distribuée, chaque région serait représentée par
un couple processeur-mémoire. La distribution de données à travers les régions est définie par défaut par la librairie Fortress, elle est relative à la taille et à la forme du tableau
mais également aux caractéristiques de taille et de localité de l’architecture matérielle sur
laquelle est exécuté le programme. Le programmeur peut également décider d’une distribution des données particulière en utilisant la distribution des traits. Plusieurs distributions prédéfinies sont proposées : sequential permettant d’allouer des blocs de données
contigus sur des régions, par permettant d’allouer une adresse à chaque région de manière cyclique, blocked consistant à diviser de manière régulière l’espace de données en
plusieurs segments et subdivided découpant en deux morceaux et de manière récursive
l’espace d’adressage.
2.4.1.3
Chapel
Chapel [21] est un langage développé par Cray, il vise à mettre en relation le développement d’algorithmes et le déploiement dans le domaine du calcul hautes performances.
Les concepts adoptés proviennent de pratiques de programmation modernes comme la
programmation orientée objet, néanmoins certains compromis ont été faits dans le but
d’atteindre un certain niveau de performance.
L’approche adoptée par Chapel est guidée par quatre concepts clés tirés de technologies des langages :
– multithreading : la programmation parallèle multi tâches apporte un support pour
le parallélisme à grain fin ainsi qu’une virtualisation des ressources ;
– locality-awareness : fournit un moyen de distribuer des structures de données partagées sans avoir à fragmenter les structures de contrôle, dans le style de HPF ;
– object-orientation : apporte la couche objet permettant de gérer plus facilement la
complexité en séparant les fonctions communes afin de faciliter la réutilisation ;
– generic programming : associé avec un système d’inférence de type, simplifie le système de type proposé à l’utilisateur. Ce système de types est requis par le calcul
hautes performances pour fournir des détails des structures de données permettant une implémentation efficace.
Le langage en lui-même est un langage orienté objet fortement typé supportant les
domaines, les tableaux dérivés de Fortran, les structures de données générales, les opérations à parallèlisme de données et un contrôle explicite de la localité. La base du langage repose sur le modèle de vue global de HPF, enrichie avec des structures objet de
données arbitraires et de la programmation multi tâches générale. Les domaines sont des
ensembles nommés, ils peuvent être combinés avec des distributions, en association avec
2.4. PLACEMENT ET PARALLÉLISME DE DONNÉES
33
des structures de données et fournissant une base pour la formulation de processus itératifs. Ce sont des objets majeurs pouvant survenir comme des éléments de structures de
données et pouvant jouer le rôle d’argument ou de retour avec les fonctions. Une sousclasse importante des domaines est la Cartesian product domains, les domaines de ce type
supportent les tableaux réguliers de structures de données comme en Fortran et forment
une grande partie de la famille de distributions. De tels domaines peuvent également être
dynamiquement remaniés et redistribués.
En ce qui concerne les distributions, Chapel reprend les distributions de données des
extensions de HPF-2, incluant les distributions general block et indirect. Sont également
supportées les spécifications de distributions définies par l’utilisateur. L’une des nouveautés est la general tiling distribution, généralisant la distribution general block en permettant le partitionnement d’un ensemble multidimensionnel pour obtenir des sous domaines rectangulaires appelés tuiles.
2.4.1.4
X10
Les langages modernes comme Java et C# ont rendu la programmation concurrente
et distribuée accessible aux développeurs d’applications, privilège qui était réservé jusqu’alors aux programmeurs systèmes. Deux types de plate-forme ont été supportées : les
plates-formes mono processeur et les plates-formes multiprocesseurs à mémoire partagée
(SMP). Cependant, les dernières tendances au niveau des technologies matérielles, avec
les difficultés de montée en fréquence, laissent à penser que les systèmes vont rapidement
migrer du mono processeur vers le multiprocesseur. Le parallélisme est donc en train de
supplanter la course à la fréquence d’horloge pour constituer la base en termes de performances de calcul. Dans cette optique, IBM pense que les futurs systèmes, notamment
pour les serveurs, seront constitués de nœuds multi-cœurs SMP avec des hiérarchies de
mémoires non uniformes inter-connectés dans des clusters évolutifs. De tels systèmes
sont qualifiés de NUCC3 , soulignant les caractères relatifs aux systèmes NUMA (NonUniform Memory Access) et aux clusters qu’ils empruntent.
Ce sont ces notions de non-uniformité que les langages orientés objet ne supportent
pas, dans l’état actuel des choses. L’état de l’art de la programmation de systèmes NUCC
provient de la communauté HPC (High Performance Computing) et repose sur l’utilisation de librairies comme MPI. IBM considère donc qu’il y a un besoin urgent de disposer
d’un modèle de programmation orienté objet et adapté aux NUCC, un tel modèle permettrait également de rendre la programmation concurrente et distribuée sur les architectures actuelles accessibles aux développeurs d’applications.
X10 [22] est un nouveau langage expérimental actuellement développé par IBM et la
communauté académique. Il fait partie du projet IBM PERCS (Productive Easy-to-use Reliable Computer Systems) visant à délivrer de nouveaux systèmes adaptables et évolutifs
et apportant une amélioration de la productivité dans le développement d’applications
parallèles d’un facteur 10. Le projet PERCS utilise pour ce faire, une approche de coconception matérielle logicielle. L’accent a été mis sur l’augmentation de la productivité
du programmeur de NUCC sans faire de compromis sur les performances. X10 se veut
être un langage sûr, moderne, parallèle et orienté objets distribués supportant le calcul
3
Non-Uniform Cluster Computing
34
CHAPITRE 2. CONTEXTE ET PROBLÉMATIQUE
hautes performances avec des tableaux multidimensionnels distribués.
Le respect de la productivité et des performances des systèmes NUCC passe par
quatre objectifs majeurs :
– Safety : le modèle de programmation doit être sûr, les erreurs types doivent être
traitées à la conception ;
– Analyzability : les programmes X10 doivent être analysables par d’autres programmes ;
– Scalability : l’ajout de ressources de calcul doit conduire à une augmentation des
performances ;
– Flexibility : les applications doivent exploiter les formes multiples du parallélisme :
parallélisme de tâches, de données etc. Les structures de données, la concurrence et
les mécanismes de distribution doivent être flexibles et généraux.
Parallèlement à ces différents objectifs, cinq décisions clés portant sur la conception
ont été prises au début du projet X10 :
– l’introduction d’un nouveau langage de programmation plutôt que l’introduction
de librairies ou de canevas de conception ;
– l’extension des fondations d’un langage orienté objet moderne, en l’occurence Java,
afin de profiter des différents outils, librairies et documentations existants. De plus
il satisfait aux critères de sûreté, d’analysabilité et de flexibilité ;
– l’introduction d’un PGAS (Partitioned Global Adress Space) pour supprimer les
contraintes de Java vis à vis du modèle NUCC ;
– l’introduction d’activités dynamiques asynchrones en tant que fondation du langage pour les constructions concurrentes ;
– l’ajout d’un sous langage manipulant des tableaux afin de gérer les distributions de
tableaux multidimensionnels.
En ce qui concerne les distributions, un tableau est associé avec un ensemble de
points, éventuellement multidimensionnel, que l’on appelle région. Une distribution spécifiant la place, entité permettant de localiser les données et les tâches, que prend chaque
élément du tableau au sein de la région. Des distributions BLOCK ou BLOCK-CYCLIC
sont proposées de base par X10.
2.4.2
Le placement dans Gaspard2
Le modèle de placement de Gaspard2 se base sur le profil standard MARTE, en particulier ses paquetages allocation et modélisation de structures répétitives constitués de
notions reprises du profil Gaspard. Il permet le placement des tâches, des données et
des dépendances de données sur des ressources de calcul, de stockage et de communication. Le métamodèle permet de décrire avec souplesse une grande variété de placements
(distribution spatiale et ordonnancement temporel) mais parmi tous ceux qui sont exprimables, l’immense majorité ne conduit pas à des spécifications exécutables car incohérents ou non complètement spécifiés. L’objectif est donc de proposer une méthodologie
pour s’assurer du caractère complet et cohérent d’un placement. Cette méthodologie devra s’appuyer sur un outil permettant de vérifier un placement.
Chapitre 3
Des langages à parallélismes de
données vers Marte
Sommaire
3.1
3.2
3.3
3.4
3.5
3.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . .
Représentation formelle de HPF . . . . . . . . . . . .
3.2.1 Représentation formelle des alignements . . .
3.2.2 Représentation formelle des distributions HPF
Méthodologie de construction . . . . . . . . . . . . .
3.3.1 Alignements . . . . . . . . . . . . . . . . . . . .
3.3.2 Distribution . . . . . . . . . . . . . . . . . . . .
Exemples . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 Distribution (*,block) . . . . . . . . . . . . . . .
3.4.2 Distribution (block, block) . . . . . . . . . . . .
3.4.3 Distribution (cyclic, cyclic) . . . . . . . . . . .
3.4.4 Distribution (block, *, block) . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
36
36
37
39
39
43
44
45
46
48
49
51
Introduction
avons vu précédemment les différents concepts apportés par les langages de
programmation à parallélisme de données vis à vis de la distribution. Le profil
Marte proposes des notations pour exprimer de manière compacte des structures répétitives. Les notions apportées permettent d’appliquer une multiplicité à des éléments,
s’appliquant alors très bien aux applications basées sur un modèle à parallélisme de données. Il propose également une notation pour la distribution de telles applications sur
des architectures répétitives. Cette notation présente des similitudes avec les notations
apportés par les différents langages, nous laissant penser que MARTE est suffisamment
puissant afin d’exprimer toutes les distributions proposées par ces langages. Dans cette
optique, nous proposons une méthodologie de construction illustrant nos pensées, nous
allons dans le cadre de cette démonstration nous concentrer plus particulièrement sur
l’un d’entre eux : HPF, cette méthodologie est illustrée par plusieurs exemples. Le langage Chapel, reposant en partie sur le modèle de HPF et reprenant les distributions offertes par ce dernier, cette démonstration est donc en partie applicable à ce langage.
N
OUS
35
36 CHAPITRE 3. DES LANGAGES À PARALLÉLISMES DE DONNÉES VERS MARTE
3.2
Représentation formelle de HPF
High Performance Fortran est une extension de Fortran 90 qui apporte le support
du calcul parallèle par l’intermédiaire de directives de compilation spéciales. Il permet
les constructions parallèles en utilisant des opérations sur des tableaux. HPF possède
également un modèle de placement qui repose sur 2 notions :
– les alignements, proposent un moyen de spécifier comment un tableau doit être placés sur un autre tableau ;
– les distributions, proposent un moyen de spécifier comment un ensemble d’éléments
doivent être distribués sur une grille de processeurs.
Pierre Boulet et Xavier Redon[23] ont proposé un formalisme pour exprimer ces notions d’alignement et de distribution, nous le réutiliserons dans la suite de ce document.
A
alignment
B
distribution
T
P
F IG . 3.1 – Les différentes étapes d’une distribution HPF. Les données des tableaux A et B
sont d’abord alignées sur le template T avant d’être distribuées par blocs sur la grille de
processeurs P .
3.2.1
Représentation formelle des alignements
Pour spécifier la manière dont les données doivent être placées les unes par rapport
aux autres, la notion de template a été introduite : un template est un tableau virtuel avec
un certain nombre de dimensions et une taille donnée pour chacune d’entre elles. Un template sert de référence pour le placement des tableaux, un alignement consiste justement à
définir la manière de placer les éléments d’un tableau source sur un template.
Dans l’exemple d’alignement suivant, le tableau A est aligné avec la première ligne du
template T et le tableau B est aligné avec la seconde ligne du template B, la figure 3.2
illustre cet alignement.
!HPF$ PROCESSORS P(2,2)
!HPF$ TEMPLATE T(16,2)
real A(16)
real B(16)
!HPF$ ALIGN A(i) WITH T(i,1)
!HPF$ ALIGN B(i) WITH T(i,2)
...
En HPF les alignements peuvent être de trois types possibles, correspondants à :
3.2. REPRÉSENTATION FORMELLE DE HPF
37
A
align
T
B
F IG . 3.2 – Le tableau A est aligné sur la première ligne du template T et le tableau B est
aligné sur la seconde ligne du template T .
– : signifie que le placement concerne la colonne entière relative à la dimension ;
– une variable : i, j ou une expression 1 − i signifie que le placement sur le template
sera relatif à cette variable/expression ;
– ∗ signifie que la dimension correspondante est soit effondrée soit répliquée :
– si ∗ apparaît dans le tableau source, la dimension correspondant sera effondrée ;
– si ∗ apparaît dans le template, les éléments seront répliqués sur la dimension associée.
Les alignements HPF peuvent être exprimés en utilisant des transformations linéaires.
Dans le meilleur des cas, une seule transformation est suffisante mais l’existence de ∗,
donc des réplications et des effondrements pose problème, par exemple :
!HPF$ ALIGN A(i) WITH T(i,1)
L’alignement peut être défini avec la transformation linéaire γ :
!
γ : i 7→
i
.
1
(3.1)
Mais l’alignement suivant ne peut être représenté avec une unique transformation :
!HPF$ ALIGN A(i) WITH T(i,*)
La réplication impose l’utilisation d’une seconde transformation δ :
γ : i 7→ i, δ :
i
j
!
7→ i.
(3.2)
Ainsi, l’alignement HPF sera représenté par :
{J | J ∈ DT , γ(I) = δ(J)} = δ −1 (γ(I)).
(3.3)
I est un élément du tableau A aligné avec le template T . γ est la transformation qui
défini la partie réplication de l’alignement. J est l’élément de T sur lequel est placé A(I)
3.2.2
Représentation formelle des distributions HPF
Une distribution HPF consiste à sélectionner des éléments par blocs pour chaque dimension depuis un tableau pour les placer sur des éléments d’un tableau de destination.
38 CHAPITRE 3. DES LANGAGES À PARALLÉLISMES DE DONNÉES VERS MARTE
Le tableau source est représenté par le template T et le tableau destination correspond à la
grille de processeurs P .
La selection des dimensions à distribuer est déterminée par la projection ρT .
La taille des blocs pour une dimension donnée est déterminée en rapport avec le type
de distribution, dans le cas d’une distribution par blocs, la taille sera donnée par le calcul
suivant :
&
Timax − Timin + 1
(kT )i =
Pimax − Pimin + 1
'
(3.4)
Amin (respectivement Amax ) est le vecteur des bornes inférieures (respectivement supérieures) de A. kT est le vecteur contenant les tailles des blocs pour chaque dimension.
Nous pouvons alors représenter une distribution avec la fonction suivante :
πT (J) = P min + (ρT (J − T min ) ÷ kT )%(P max − P min + 1)
3.2.2.1
(3.5)
Exemple
!HPF$ PROCESSORS P(10,10)
!HPF$ TEMPLATE T(n,m,p)
!HPF$ DISTRIBUTE T(BLOCK,*,CYCLIC(k)) ONTO P
Dans cet exemple, trois directives sont définies et déclarent :
– une grille de processeurs bi-dimensionnelle P de dimensions {10,10} ;
– un template tri-dimensionnel T de dimensions {n,m,p} ;
– la distribution du template sur la grille de processeur : la première dimension de T
sera distribuée par blocs sur la première dimension de P , la seconde dimension de
T sera entièrement placée en mémoire et la troisième dimension de T sera distribuée de manière cyclique par blocs de k éléments sur la seconde dimension de P .
Dans cet exemple, la projection ρT sera :
 
j1
 
j2  7→
j3
j1
j3
!
La distribution se fait en blocs sur la première dimension et cycliquement sur la troisième
dimension, ce sont donc les seules dimensions à être distribuée, la seconde dimension est
placée en mémoire.
Le vecteur kT sera :
!
n
10
k
La première dimension distribuée sera découpée en blocs de
dimension distribuée sera découpée en blocs de k éléments.
Ainsi la fonction de distributionπT sera :
 
j1
 
j2  7→
j3
!
n
1 + ((j1 − 1) ÷ 10
)%10
1 + ((j3 − 1) ÷ k)%10
n
10
éléments, la seconde
3.3. MÉTHODOLOGIE DE CONSTRUCTION
3.3
39
Méthodologie de construction
Dans [24], Boulet et al. ont illustré les mécanismes d’allocation et de distribution offerts
par MARTE avec quelques exemples. Ils ont avancé le résultat selon lequel MARTE était
suffisamment puissant pour exprimer toutes les distributions offertes par HPF. Nous propons une méthodologie de construction pour, à partir d’une distribution HPF, obtenir une
distribution MARTE. Cette méthode est accompagnée de plusieurs exemples afin de clairement illustrer le processus.
3.3.1
Alignements
Un alignement consiste à récupérer tous les éléments depuis un tableau source, pour
les placer dans un tableau destination, n’ayant pas forcément la même forme. C’est exactement le rôle du concept de Reshape. Nous allons donc illustrer, à travers quelques exemples
couvrant les différentes possibilités d’alignement offertes par HPF, la construction de Reshape à partir de ces derniers.
3.3.1.1
Exemples
Formalisme visuel
Nous utilisons un formalisme permettant d’illustrer graphiquement les alignements.
En voici la description avec un exemple proposé sur la figure 3.3 :
align
A
T
F IG . 3.3 – Formalisme pour l’alignement
Le tableau A à aligner est sur la gauche de la figure, le template T est sur la droite.
Le tableau A et le template T sont de dimensions 2 x 2, chaque case du tableau A étant
un élément. Dans cet exemple, le tableau A est constitué de trois éléments, chaque élément disposant d’une couleur particulière. L’élément rouge du tableau A, correspond au
point de coordonnées (0,0), est aligné sur la case rouge du template T , correspondant
au point de coordonnées (3,3). L’élément bleu du tableau A, correspondant au point de
coordonnées (1,0), est aligné sur la case bleue du template T , correspond au point de coordonnées (1,0) et l’élément vert du tableau A, correspondant au point de coordonnées
(1,0) est aligné sur la case verte du template T , correspondant au point de coordonnées
(2,0).
Alignement identité/implicite
!HPF$ Template T(4,4)
real A(4,4)
!HPF$ ALIGN A(i,j) with T(i,j)
Dans cet exemple, nous avons déclaré un template bi-dimensionnel T , nous avons également déclaré un tableau bi-dimensionnel de réels A que nous alignons sans modifications
sur le template T : A(i, j) sera placé sur T (i, j).
40 CHAPITRE 3. DES LANGAGES À PARALLÉLISMES DE DONNÉES VERS MARTE
align
A
T
F IG . 3.4 – ALIGN A(i,j) with T(j,i)
Forme du motif et espace de répétition
L’alignement ne modifie pas le placement des éléments, nous pouvons donc effectuer une
distribution en utilisant un seul bloc contenant tous les éléments du tableau A, ce qui ne
nécessite qu’une seule opération.
!
!
i
1
Forme du motif :
, Espace de répétition :
.
j
1
Tiler origine
Le tiler origine doit donc prendre tous les éléments de A. Sur la première dimension il faut
donc récupérer i éléments ce qui implique que le pavage vaut i pour cette dimension, sur
la seconde dimension, il faut récupérer j éléments ce qui implique que le pavage vaut j
pour cette dimension. Les éléments sont pris de manière contiguë, l’ajustage vaut donc 1
pour chaque dimension.
!
!
!
0
1 0
i 0
Origine :
, Matrice de pavage :
, Matrice d’ajustage :
.
0
0 1
0 j
Tiler destination
Nous voulons placer le tableau A exactement sur le template T sans aucune modification,
avec le tiler source nous allons récupérer un bloc complet représentant A, il suffit donc
de paver sur la première dimension i éléments et sur la seconde dimension j éléments,
les éléments sont toujours contigus, l’ajustage vaut donc 1 sur chaque dimension.
!
!
!
0
1 0
i 0
Origine :
, Matrice de pavage :
, Matrice d’ajustage :
.
0
0 1
0 j
Alignement transposé
!HPF$ Template T(4,4)
real A(4,4)
!HPF$ ALIGN A(i,j) with T(j,i)
Dans cet exemple, le tableau A est aligné sur le template T en appliquant une transposée :
l’élément A(i, j) sera placé sur l’élément T (j, i).
Forme du motif et espace de répétition
L’alignement transpose les éléments du tableau A, une manière possible d’effectuer l’alignement consiste à prendre les éléments de A par colonne, et de placer chaque colonne
comme une ligne de T . Ainsi il faudra répéter l’opération pour chaque colonne, soit i fois
pour la première dimension 1 fois pour la seconde dimension.
!
!
1
i
Forme du motif :
, Espace de répétition :
.
j
1
3.3. MÉTHODOLOGIE DE CONSTRUCTION
41
align
A
T
F IG . 3.5 – ALIGN A(i,j) with T(j,i)
Tiler source
Le tiler source récupère les éléments de A par colonne, sur la première dimension le
pavage vaut 1 et sur la seconde dimension le pavage vaut j. On récupère les éléments
de manière contiguë sur la seconde dimension, l’ajustage vaut donc 1.
!
!
!
0
0 0
1 0
Origine :
, Matrice d’ajustage :
, Matrice de pavage :
.
0
0 1
0 j
Tiler destination
Pour appliquer la transposer, le tiler destination doit donc placer les colonnes qu’il reçoit
du tiler source sur les lignes de T . Les éléments sont contigus, l’ajustage vaut donc 1 pour
les lignes. Au lieu de paver les colonnes, nous allons paver les lignes : le pavage vaut donc
j sur la première dimension et 1 sur la seconde dimension.
!
!
!
0
1 0
j 0
Origine :
, Matrice d’ajustage :
, Matrice de pavage :
.
0
0 1
0 1
Alignement avec effondrement
!HPF$ Template T(4)
real A(4,4)
!HPF$ ALIGN A(i,*) with T(i)
Dans cet exemple, le tableau A est aligné avec le template T en effondrant la seconde
dimension de A, chaque élément A(i, j) sera placé sur l’élément T (i).
align
A
T
F IG . 3.6 – ALIGN A(i,*) with T(i)
Forme du motif et espace de répétition
Chaque colonne de A est effondrée et placée sur le template T , nous allons donc récupérer
les éléments par colonnes donc des blocs de {1,j} éléments, opération qu’il faut répéter i
fois relativement au nombre de colonnes.
!
!
1
i
Forme du motif :
, Espace de répétition :
.
j
1
42 CHAPITRE 3. DES LANGAGES À PARALLÉLISMES DE DONNÉES VERS MARTE
Tiler source
Le tiler source récupère les éléments de A par colonne, sur la première dimension le
pavage vaut 1 et sur la seconde dimension le pavage vaut j. On récupère les éléments
de manière contiguë sur la seconde dimension, l’ajustage vaut donc 1.
!
!
!
0
0 0
1 0
Origin :
, Fitting matrix :
, Paving matrix :
.
0
0 1
0 j
Tiler destination
Chaque colonne est placé sur un élément de T , le pavage vaut donc 1 sur la première
dimension, et l’ajustage vaut 0.
!
0
Origin :
, Fitting matrix : 0 0 , Paving matrix : 1 0 .
0
Alignement avec réplication
!HPF$ Template T(4,4)
real A(4)
!HPF$ ALIGN A(i) with T(i,*)
Dans cet exemple, le tableau A est aligné avec le template T en utilisant la réplication,
chaque élément A(i, j) sera placé sur l’élément T (i, j).
align
A
T
F IG . 3.7 – ALIGN A(i) with T(i,*)
Forme du motif et espace de répétition
Chaque élément du tableau A sera répliqué sur la colonne entière correspondante de T ,
on peut donc procéder récupérant la ligne entière de A et en la répliquant un nombre de
fois valant le nombre de lignes sur le template T .
!
!
i
1
, Espace de répétition :
.
Forme du motif :
j
1
Tiler source
Le tiler source récupère la ligne complète, le pavage vaut donc i et l’ajustage vaut 1.
!
0
Origine :
, Matrice d’ajustage : 1 0 , Matrice de pavage : i 0 .
0
Tiler destination
Le tiler destination doit donc répliquer chaque colonne qu’il reçoit sur toutes les lignes
du template T . Le pavage vaut donc i sur la première dimension et 1 sur la seconde, les
éléments étant contigus, l’ajustage vaut 1 sur les 2 dimensions.
!
!
!
0
1 0
i 0
Origine :
, Matrice d’ajustage :
, Matrice de pavage :
.
0
0 1
0 1
3.3. MÉTHODOLOGIE DE CONSTRUCTION
3.3.2
3.3.2.1
43
Distribution
Forme du motif
La forme du motif est représentée par un vecteur dont la taille correspond au nombre
de dimension du template T et pour lequel chaque composante du vecteur correspond
au nombre d’éléments présents sur chaque dimension. Son calcul est exprimé par l’algorithme 1.
Algorithm 1 Calcul de la forme du motif
if distribution(i) = ∗ then
mi = size(dimension(i))
else
mi = (kT )i
end if
3.3.2.2
Espace de répétition
L’espace de répétition est un vecteur dont la taille correspond au nombre de dimensions du template T , chaque composante ri du vecteur est calculée avec :
ri =
3.3.2.3
size(Ti )
(kT )i
Tiler source
Origine
L’origine du tiler source correspond à l’origine du template T .
Calcul de la matrice d’ajustage
Pour chaque dimension di du template T , on associe un vecteur f calculé en fonction
du type de distribution avec l’algorithme 2
Algorithm 2 Calcul de la matrice d’ajustage
for i in dimensions(T ) do
if distribution(i) = CY CLIC or BLOCK(1) then
f =∅
else f = 0 · · · 0 and fi = 1
end if
end for
Calcul de la matrice de pavage
Pour chaque dimension di du template T , on associe un vecteur f calculé suivant le type
de distribution avec l’algorithme 3
3.3.2.4
Tiler destination
Calcul de la matrice de pavage
Pour chaque dimension di de la grille de processeur P , on associe un vecteur p dont
44 CHAPITRE 3. DES LANGAGES À PARALLÉLISMES DE DONNÉES VERS MARTE
Algorithm 3 Calcul de la matrice de pavage
p = 0 ··· 0
for i in dimensions(T ) do
if distribution(i) = ∗ then
pi = size(di )
else if di = CY CLIC then
pi = 1
else if di = BLOCK then
pi = (kT )i
else
di = CYCLIC(n) or BLOCK(n) andpi = n
end if
end for
la taille correspond au nombre de dimension de di , de valeur nulle et pour lequel la
composante pi vaut 1.
Exemples :


1 0 0
1 0


Une dimension : 1 , Deux dimensions :
, Trois dimensions : 0 1 0.
0 1
0 0 1
!
Calcul de la matrice d’ajustage
La matrice d’ajustage est une matrice nulle dont le nombre de dimensions correspond
au nombre de dimensions de P , chaque dimension ayant pour taille celle de la forme du
motif.
Exemple :
Par exemple, si on a une grille de processeur P de dimensions {8,8} avec un motif de
forme {2,2}, la matrice d’ajustage sera de dimension bidimensionnelle et chaque dimension sera de taille 2 :
!
0 0
0 0
3.4
Exemples
Formalisme visuel
Nous utilisons un formalisme permettant d’illustrer graphiquement les distribution. En
voici la description avec un exemple proposé sur la figure 3.8 :
Le template T à distribuer est sur la gauche de la figure, la grille de processeurs P est
sur la droite. Le template T est de dimension 16 x 16 et la grille de processeurs P est de
dimension 2 x 2, à chaque case du template T correspond un bloc de quatre éléments (2 x
2), une couleur est affectée à chaque blocs d’éléments. Chaque bloc de couleur est alloué
sur le processeur ayant la même couleur. Les éléments du template appartenant au bloc
rouge, correspondant aux points (0,0) - (1,0) - (0,1) et (1,1) sont placés sur le processeur de
même couleur, même procédé pour les éléments des blocs vert et bleu.
3.4. EXEMPLES
45
16
12
4
3
distribute
8
2
1
4
0
0
4
8
12
1
3
2
4
16
T
P
F IG . 3.8 – Formalisme visuel pour la distribution
3.4.1
Distribution (*,block)
!HPF$ PROCESSORS P(4)
!HPF$ TEMPLATE T(256,256)
!HPF$ DISTRIBUTE T(*, BLOCK) ONTO P
Cet exemple montre la distribution d’un template bi-dimensionnel T sur un grille de
processeur mono-dimensionnelle P . La première dimension est placée en mémoire tandis
que la seconde dimension est distribuée par blocs sur l’unique dimension de P . La figure
3.9 illustre graphiquement cette distribution.
256
192
distribute
128
0
1
2
3
4
64
0
256
T
P
F IG . 3.9 – Distribution {*,block} : la première dimension du tableau est placée en mémoire
et la seconde dimension est distribuée par blocs sur la grille de processeurs.
46 CHAPITRE 3. DES LANGAGES À PARALLÉLISMES DE DONNÉES VERS MARTE
Distribution
j1
j2
ρT :
!
7→ j2
kT : 64
πT :
j1
j2
!
7→ 1 + ((j2 − 1) ÷ 64)%4
Motif et espace de répétition :
Avec des blocs de 256 éléments et un template avec 256 éléments sur la première dimension, l’opération doit être faite 1 fois. Avec des blocs de 64 éléments et un template de 64
éléments sur la seconde dimension, l’opération doit être faite 4 fois. Les blocs sont formés
de 256 éléments sur la première dimension et de 64 éléments sur la seconde dimension.
!
!
256
1
Forme du motif :
, Espace de répétition :
.
64
4
Tiler source :
Dans cet exemple, le template T est un tableau bi-dimensionnel. Le tableau source sera
donc le template T , son origine sera l’origine de T . La première dimension est entièrement
placée en mémoire par blocs de 256 éléments (distribution *) et la seconde dimension est
distribuée par blocs de 64 éléments. Les blocs sont composés d’éléments contigus, l’ajustage vaut donc 1 sur chaque dimension. Le pavage vaut 256 sur la première dimension et
64 sur la seconde.
!
!
!
0
1 0
256 0
Origine :
, Ajustage :
, Pavage :
.
0
0 1
0 64
Tiler destination :
La grille de processeurs P est un tableau mono-dimensionnel. Le tableau de destination
sera la grille P . Son origine sera l’origine de P . Les blocs seront distribués sur 1 élément
de P à chaque fois. Le pavage vaut donc 1.
Origine : 0 , Pavage : 1 0 , Ajustage : 0 0 .
3.4.2
Distribution (block, block)
!HPF$ PROCESSORS P(4,4)
!HPF$ TEMPLATE T(16,16)
!HPF$ DISTRIBUTE T(BLOCK, BLOCK) ONTO P
Cet exemple montre la distribution d’un template bi-dimensionnel sur une grille de processeurs bi-dimensionnelle. La première (resp. seconde) dimension est distribuée par
blocs sur la première (resp. seconde) dimension de P . La figure 3.10 illustre graphiquement cette distribution.
Distribution
ρt :
j1
j2
!
7→
j1
j2
!
3.4. EXEMPLES
47
16
12
4
3
distribute
8
2
1
4
0
0
4
8
1
2
3
4
16
12
T
P
F IG . 3.10 – Distribution {BLOCK,BLOCK} : les deux dimensions du tableau sont distribuées par blocs sur la grille de processeurs.
kT :
j1
j2
!
4
4
!
!
1 + ((j1 − 1) ÷ 64)%4
1 + ((j2 − 1) ÷ 4)%4
7→
Forme du motif et espace de répétition :
La première dimension est distribuée par blocs de 64 éléments et le template en compte
256, l’opération doit donc être répétée 4 fois. La seconde dimension est également distribuée par blocs de 64 éléments et me template en compte 256, l’opération doit donc être
répétée 4 fois. Le motif et l’espace de répétition sont donc :
!
!
64
4
Motif :
, Espace de répétition :
.
64
4
Tiler source :
Dans cet exemple, le template T est un tableau bi-dimensionnel. Le tableau source sera
donc T , son origine sera l’origine de T . La première dimension est distribuée par blocs de
64 éléments et la seconde dimension est également distribuée par blocs de 64 éléments, le
pavage vaut donc 64 sur chaque dimension. Les éléments sont contigus, l’ajustage vaut
donc 1 sur chaque dimension.
!
!
!
0
1 0
64 0
Origine :
, Ajustage :
, Pavage :
.
0
0 1
0 64
Tiler destination :
La grille de processeurs P est un tableau bi-dimensionnel. Le tableau destination sera P ,
48 CHAPITRE 3. DES LANGAGES À PARALLÉLISMES DE DONNÉES VERS MARTE
son origine sera celle de P et chaque processeur de P recevra un bloc d’éléments. le pavage vaut donc 1 sur chaque dimension.
!
!
!
0
1 0
0 0
Origine :
, Pavage :
, Ajustage :
.
0
0 1
0 0
3.4.3
Distribution (cyclic, cyclic)
!HPF$ PROCESSORS P(16,16)
!HPF$ TEMPLATE T(256,256)
!HPF$ DISTRIBUTE T(CYCLIC(2), CYCLIC(8)) ONTO P
Cet exemple montre la distribution d’un template bi-dimensionnel sur une grille de processeurs bi-dimensionnel. La première dimension de T est distribuée sur la première dimension de P de manière cyclique en utilisant des blocs de 2 éléments, la seconde dimension de T est distribuée de manière cyclique en utilisant des blocs de 8 éléments. La
figure 3.11 illustre graphiquement cette distribution.
256
16
24
distribute
16
3
2
1
8
0
0
2 4 6
1 2 3
16
256
T
P
F IG . 3.11 – Distribution {CYCLIC(2),CYCLIC(8)} : les deux dimensions du tableau sont
distribuées par blocs de deux et huit éléments et de manière cyclique.
Distribution
ρt :
j1
j2
!
7→
j1
j2
!
!
kT :
j1
j2
!
7→
2
8
1 + ((j1 − 1) ÷ 2)%4
1 + ((j2 − 1) ÷ 8)%4
!
3.4. EXEMPLES
49
Forme du motif et espace de répétition :
La première dimension de T est distribuée cycliquement par blocs de 2 éléments tandis
que le template en contient 256, l’opération doit donc être répétée 128 fois. La seconde
dimension de T est distribuée cycliquement par blocs de 8 éléments tandis que le template en contient 256, l’opération doit donc être répétée 32 fois. Le motif et l’espace de
répétition associés sont donc :
!
!
2
128
Motif :
, Espace de répétition :
.
8
32
Tiler source :
Dans cet exemple, le template T est un tableau bi-dimensionnel, le tableau source sera
donc T , son origine sera l’origine de T . La première dimension est distribuée de manière
cyclique par blocs de 2 éléments, le pavage vaut donc 2 sur cette dimension. La seconde
dimension est distribuée de manière cyclique par blocs de 8 éléments, le pavage vaut
donc 8 sur cette dimension. Les éléments étant contigus, l’ajustage vaut 1 pour chaque
dimension.
!
!
!
0
1 0
2 0
Origine :
, Ajustage :
, Pavage :
.
0
0 1
0 8
Tiler destination :
La grille de processeurs P est un tableau bi-dimensionnel. Le tableau destination sera P ,
son origine sera celle de P et chaque processeur de P recevra un bloc d’éléments. le pavage vaut donc 1 sur chaque dimension.
!
!
!
0
1 0
0 0
Origine :
, Pavage :
, Ajustage :
.
0
0 1
0 0
3.4.4
Distribution (block, *, block)
!HPF$ PROCESSORS P(16,16)
!HPF$ TEMPLATE T(256,256,256)
!HPF$ DISTRIBUTE T(BLOCK,*,BLOCK) ONTO P
Cet exemple montre la distribution d’un template tri-dimensionnel T sur une grille de
processeurs bi-dimensionnelle P . La première dimension de T est distribuée par blocs
sur la première dimension de P , la seconde dimension de T est placée en mémoire et
la troisiéme dimension de T est distribuée par blocs sur la seconde dimension de P . La
figure 3.12 illustre graphiquement cette distribution.
Distribution
 
j1
j1
j3
 
ρt : j2  →
7
j3
!
kT :
16
16
!
50 CHAPITRE 3. DES LANGAGES À PARALLÉLISMES DE DONNÉES VERS MARTE
16
256
distribute
2
1
0
16
1 2
16
0
16
32
48
256
T
P
F IG . 3.12 – Distribution {BLOCK,*,BLOCK} : la première dimension du tableau est distribuée par blocs sur la première dimension de P , la seconde dimension est placée en
mémoire et la troisième dimension est distribuée par blocs sur la seconde dimension de
P.
 
j1
 
j2  7→
j3
!
1 + ((j1 − 1) ÷ 16)%16
1 + ((j3 − 1) ÷ 16)%16
Motif et espace de répétition :
La première dimension de T est distribuée par blocs de 16 éléments tandis que le template
en contient 256, l’opération doit donc être répétée 16 fois. La seconde dimension de T est
placée en mémoire, cela représente donc un bloc de 256 éléments, l’opération ne doit être
faite qu’une fois. La troisième dimension est distribuée par blocs de 16 éléments tandis
que le template en contient 256, l’opération doit donc être répétée 16 fois. Le motif et
l’espace de répétition sont donc :




16
16


 
PatternShape : 256, RepetitionSpace :  1 .
16
16
Source tiler :
Dans cet exemple, le template T est une tableau tri-dimensionnel. Le tableau source sera
le T , son origine sera également l’origine de T . La première dimension est distribuée par
blocs de 16 éléments, le pavage vaut donc 16 pour cette dimension. La seconde est placée
en mémoire, le pavage vaut donc 256 pour cette dimension.La troisième est distribuée par
blocs de 16 éléments, le pavage vaut donc 16 pour cette dimension. Les éléments étant
contigus, l’ajustage vaut 1 pour chaque dimension.
3.5. CONCLUSION
51
 




16 0
0
1 0 0
0




 
Origine : 0, Ajustage : 0 1 0, Pavage :  0 256
.
0
0 64
0 0 1
0
Destination tiler :
La grille de processeurs P est un tableau bi-dimensionnel. Le tableau destination sera P ,
son origine sera celle de P et chaque processeur de P recevra un bloc d’éléments. le pavage vaut donc 1 sur chaque dimension.
!
!
!
0
1 0
0 0
Origine :
, Pavage :
, Ajustage :
.
0
0 1
0 0
3.5
Conclusion
Nous avons donc montré, par l’intermédiaire d’une méthodologie de construction,
que Marte, avec son mécanisme d’allocation et de distribution adapté aux structures répétitives, était capable d’exprimer toutes les distributions offertes par HPF. Les concepts
manipulés par les nouveaux langages à parallélisme de données tels Fortress, Chapel ou
X10 et relatifs aux distributions peuvent se ramener à la manipulation de structure tabulaire. Dans le cas de Chapel, on a montré par l’intermédiaire de HPF, sur lequel il est
en partie basé, que c’était le cas, pour ce qui est de la distribution general tiling distribution permettant de partitionner un ensemble multidimensionnel pour obtenir des sous
domaines rectangulaires que l’on appelle tuiles, le parallèle évident avec les concepts de
MARTE ne laisse pas trop de doute sur la capacité de ce dernier à les gérer.Pour Fortress,
les distributions sequential, par et blocked sont supportées par MARTE., en revanche la
distribution subdivided consistant à découper en deux morceaux et de manière récursive
l’espace d’adressage ne semble pas être exprimable. Enfin, pour X10, les distributions,
concernant des ensembles de points multidimensionnels, peuvent être de type block ou
cyclic, familles de distribution prises en charge par MARTE.
52 CHAPITRE 3. DES LANGAGES À PARALLÉLISMES DE DONNÉES VERS MARTE
Chapitre 4
Validation d’un placement Gaspard2
Sommaire
4.1
4.2
4.3
Allocations . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Allocations répétitives . . . . . . . . . . . .
4.1.2 Allocations hiérarchiques . . . . . . . . . .
4.1.3 Ordonnancement . . . . . . . . . . . . . . .
Critères de validation d’un modèle d’association
4.2.1 Critère de complétude . . . . . . . . . . . .
4.2.2 Critère de cohérence . . . . . . . . . . . . .
Outil de vérification d’un placement . . . . . . .
4.3.1 Approches envisagées . . . . . . . . . . . .
4.3.2 Plugin de validation Gaspard2 . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
54
56
59
60
61
61
62
62
65
avons vu, qu’au travers des différents concepts apportés dans le méta-modèle
Gaspard, nous étions capable d’exprimer un grand nombre de placement de natures différentes. Cependant, parmi tous ces placements, un certain nombre se révèle
incorrect, car étant non complètement spécifiés ou non cohérents.
N
OUS
Dans ce chapitre, nous proposons, d’une part des évolutions afin d’étendre le métamodèle Gaspard permettant de rendre moins ambiguë et plus aisée l’expression d’allocations entre application et plateforme d’exécution et, d’autre part un outil sous la forme
d’une extension de l’outil Gaspard2 permettant de s’assurer du caractère correct d’une
association.
4.1
Allocations
Les performances des systèmes parallèles sont directement liées à l’équilibrage de
charge entre les différentes unités de calcul du système. Pour ce faire, il est nécessaire de
distribuer de manière équitable les différentes répétitions des tâches de l’application sur
les processeurs. Selon la distribution, la localité des données sera plus ou moins différente, imposant davantage de communications et réduisant le gain en performance dans
le cas de faible localité. La distribution optimale d’une tâche est relative à la distribution
des données et à la distribution des différentes tâches. Pour s’en approcher, il est donc
nécessaire de disposer des outils permettant d’exprimer les distributions avec le plus de
précision possible et le moins d’ambiguïté.
53
54
CHAPITRE 4. VALIDATION D’UN PLACEMENT GASPARD2
Le mécanisme d’allocation apporté par le méta-modèle Gaspard permet d’associer
une partie de l’application avec une partie de l’architecture matérielle. Cependant la syntaxe actuelle peut introduire une sémantique ambiguë rendant l’expression d’une association correcte plus difficile. Plusieurs aspects sont concernés et nous allons les développer dans la suite de cette section.
4.1.1
Allocations répétitives
Les concepts apportés permettant de présenter de manière compacte des systèmes
possédant une structure répétitive régulière représentent le point fort du méta-modèle
Gaspard. Une Shape permet, dans un premier temps, de définir une multiplicité sur un
composant, spécifiant le nombre de répétitions de ce dernier. Dans un second temps, un
Tiler permet de construire des liens entre deux composants répétés, spécifiant le partage
d’un ensemble d’éléments d’un tableau. Enfin, un Reshape permet de lier directement et
d’une certaine manière deux composants répétés.
4.1.1.1
Distributions
Les notions de TaskAllocation et de DataAllocation ont été étendues afin de prendre en
charge les composants répétitifs. Cette extension passe par l’utilisation conjointe d’une
Allocation et d’un Reshape pour former ce que l’on appelle une Distribution. Une Distribution désigne le placement d’un composant répété de l’application sur un ensemble de
composants matériels répétés. C’est un concept clé dans l’exploitation du parallélisme
des applications et des architectures matérielles représentées de manière compacte permettant d’exprimer la parallélisation d’une tâche sur un ensemble de processeurs identiques et la répartition des tableaux de données sur un ensemble de bancs mémoire. Plus
précisément, dans le cas d’une TaskAllocation distribuée, cela indique quel processeur exécutera chaque répétition de la tâche et dans le cas d’une DataAllocation distribuée, cela
indique quels éléments d’un tableau d’éléments seront placés sur quelle répétition d’une
mémoire. Les répétitions peuvent être multidimensionnelles sans contrainte d’avoir des
dimensions égales. Il est également possible d’associer une répétition d’un composant de
l’application à plusieurs répétitions d’un composant de l’architecture matérielle, ce qui
présente un intérêt dans un but de réduction des communications par exemple, en répliquant les données sur toutes les mémoires locales des processeurs.
Rappelons qu’une Distribution est composée de deux Tilers, d’un PatternShape et d’un
RepetitionSpace. Chaque élément du tableau de sortie, relatif à l’architecture matérielle,
peut être associé à zéro, un ou plusieurs éléments du tableau d’entrée, relatif à l’application. Toutes les distributions classiques, rencontrées dans les langages du domaine du
calcul haute performance, sont exprimables.
4.1.1.2
Exemples de distribution
Nous allons illustrer cette notion de distribution à l’aide d’une application de calcul
matriciel. La partie application est modélisée sur la figure 4.1. Elle contient une instance
appli de AplusB qui lit deux matrices de 128 x 128 éléments et génère une matrice de sortie de 128 x 128 éléments, résultat de la somme des deux matrices d’entrée. La tâche qui
effectue l’addition est décomposée en une répétition de 16 x 16 instances de Sum. Chaque
répétition de la tâche travaille sur des motifs de 8 x 8 éléments. C’est cette répétition qui
4.1. ALLOCATIONS
55
sera distribuée sur l’architecture matérielle.
F IG . 4.1 – Une application permettant de calculer la somme de deux matrices carrées de
dimension 128x128.
L’architecture matérielle modélisée sur la figure 4.2 représente un système sur puce
multiprocesseur composé d’une grille de 4 x 4 unités de calcul (ProcessingUnit). Chaque
instance de l’unité de calcul est reliée à quatre autres instances par l’intermédiaire des
ports n, s, e et w et de liens InterRepetition pour former une grille torique. Chaque ProcessingUnit est composée d’un processeur, d’une mémoire et d’un crossbar pour la gestion
des communications.
La figure 4.3 présente une distribution par blocs concernant les deux dimensions de
l’instance de l’application sum. Chaque processeur de chaque unité de calcul va traiter un
bloc de 4 x 4 répétitions de la tâche, information donnée par la valeur du PatternShape. Le
pavage fait en sorte que les différents blocs ne se recouvrent pas : un élément d’un bloc
ne se retrouvera pas dans un autre bloc. Enfin le RepetitionSpace assure que l’ensemble
du tableau est recouvert. Chaque unité de calcul [i, j] se chargera d’exécuter les seize instances comprises dans l’interval allant de [i x 4, j x 4] à [i x 4 + 3, j x 4 + 3].
La figure 4.4 présente une distribution cyclique de chaque dimension de l’instance de
l’application sum. Chaque processeur va traiter un bloc de Y x Y répétitions de sum. Le
PatternShape vide indique que chaque motif ne contient qu’un seul élément. Le modulo
permet de revenir sur le premier processeur de la dimension quand la dimension a été
entièrement parcourue. Chaque processeur [i, j] exécutera les 16 instances de [p x 4 + i, q
x 4 + j], p et q étant des entiers compris entre 0 et 15.
La figure 4.5 modélise une distribution de données. Le tableau présent sur m2, de
56
CHAPITRE 4. VALIDATION D’UN PLACEMENT GASPARD2
F IG . 4.2 – Une architecture matérielle, composée d’une grille de 16 unités de calcul, chacune dotée d’un bus d’interconnexion, d’une mémoire et d’un processeur.
dimensions 128 x 128, est distribué sur l’ensemble des unités de calcul présentes sur l’architecture matérielle. Sur chacune d’entre elles est alloué un bloc de données contenant
32 x 32 éléments. La distribution se fait par blocs sur les deux dimensions.
Nous avons, à travers ces quelques exemples, illustré le fait que la notion de distribution permet une grande expressivité de l’association sur l’architecture et ce en adoptant
une syntaxe très compacte et élégante. Cependant, dans le cadre de modèles complexes,
cette liberté d’expression sera la source d’erreurs dans le modèle d’association. Nous allons dans la section suivante présenter quelques situations portant à confusion et proposer une solution permettant de les éviter. Puis nous proposerons un outil permettant de
tester le caractère correct d’une association vis à vis d’une application et d’une architecture matérielle.
4.1.2
Allocations hiérarchiques
Il n’y pas de règle particulière pour effectuer une association entre tâches et données, le développeur est libre de choisir l’allocation des tâches et des données. Il n’y a
pas de restriction entre le placement de données sur des mémoires et le placement sur
des processeurs des tâches qui utilise ces données. De cette grande liberté résultent des
placements qui ne sont pas corrects ne permettant pas d’obtenir un code de simulation
fonctionnel.
4.1. ALLOCATIONS
57
F IG . 4.3 – Placement complet d’un ensemble de tâches sur la grille de processeurs, toutes
les tâches sont associées à un processeur.
F IG . 4.4 – Placement complet d’un ensemble de tâche sur la grille de processeurs, toutes
les tâches sont associées à un processeur.
58
CHAPITRE 4. VALIDATION D’UN PLACEMENT GASPARD2
F IG . 4.5 – Distribution de données, le tableau présent sur le port m2 est alloué par bloc de
32 x 32 éléments sur chaque unité de calcul de la plateforme d’exécution.
La figure 4.6 illustre un exemple d’allocation hiérarchique. L’application est composée de deux tâches t1 et t2, chaque tâche étant elle-même composée de deux d’une tâche
producteur et d’une tâche consommateur. On cherche à placer cette application sur une
architecture composée de deux unités de calcul bp1 et bp2 possédant chacune deux processeurs p1 et p2. On souhaite définir un placement particulier en plaçant les différentes
sous-tâches sur un processeur particulier de la plateforme d’exécution, à savoir : le producteur p de la tâche t1 sur le processeur p1 de l’unité de calcul bp1, le consommateur
c de la tâche t1 sur le processeur p2 de l’unité de calcul bp2, le producteur p de la tâche
t2 sur le processeur p2 de l’unité de calcul bp1 et le consommateur de la tâche t2 sur le
processeur p2 de l’unité de calcul bp2.
On constate, que la spécification de tels placements est rendue difficile et sa mise en
oeuvre est plutôt laborieuse. En effet, si cela reste raisonnable avec notre exemple, imaginer des placements concernant des applications et des architectures plus complexes deviendrait très vite fastidieux. Rappelons que le modèle d’allocation s’inspire du modèle
proposé par SysML, néanmoins dans la mise au point du modèle d’allocation de MARTE,
il a été décidé de ne pas conserver la notion de table d’allocation, concept permettant de
spécifier, à l’intérieur d’un tableau, les différentes allocations et les éléments source et
cible qui sont concernés. Cette notation permet de garder les modèles visuels suffisamment lisibles et permet de lever plus facilement une possible ambiguïté. La figure 4.7
reprend l’application précédente, en ayant remplacé toutes les allocations avec une table
d’allocation. On y gagne donc en lisibilité tout en permettant au développeur de préci-
4.1. ALLOCATIONS
59
F IG . 4.6 – TODO.
ser avec moins de risques d’erreur des allocations hiérarchiques complexes. Nous avons
donc proposé le retour de cette notion dans le modèle, nous nous sommes cependant fait
devancés par les développeurs de MARTE qui ont récemment décidés de la réintroduction de cette notion.
4.1.3
Ordonnancement
Un second point pouvant facilité des ambiguïtés et donc des erreurs concerne la notion d’ordonnancement. La figure 4.8 illustre un exemple d’association faisant intervenir
la notion d’ordonnancement. L’application est constituée de quatre tâches, l’architecture
comporte un processeur et on souhaite distribuer les quatre tâches sur ce processeur en
leur imposant un ordre d’exécution particulier. Pour ce faire, on utilise la notion de orderDependancy, néanmoins si pour cet exemple, cela reste eexploitable, comment sur un
modèle plus complexe, donc faisant intervenir potentiellement plus de tâches, apporter
une syntaxe plus élégante permettant de conserver une certaine lisibilité dans le modèle ?
En lieu et place de la notion d’orderDependancy, nous pourrions introduire un nouveau
stéréotype du même nom, applicable à un processeur afin de préciser un ordre d’exécution des différentes tâches allouées sur ce dernier. Ce stéréotype contiendrait une tagged
value contenant, sous forme d’une chaîne de caractère, la liste ordonnées des tâches à
exécuter. 4.9.
60
CHAPITRE 4. VALIDATION D’UN PLACEMENT GASPARD2
F IG . 4.7 – TODO.
F IG . 4.8 – TODO.
4.2
Critères de validation d’un modèle d’association
Reprenons notre exemple d’addition de matrices. Nous avons d’une part défini le modèle d’application faisant la somme de deux matrices et d’autre part le modèle d’architecture matérielle qui accueillera cette application. Ce qui nous intéresse ici, c’est l’étape
d’association entre les deux modèles. Le but étant d’aboutir à un code de simulation
fonctionnel, il est donc nécessaire de s’assurer du caractère valide de l’association. Cette
vérification peut se dérouler suivant deux étapes : la vérification du caractère complet de
l’association et la vérification du caractère cohérent de l’association.
4.2. CRITÈRES DE VALIDATION D’UN MODÈLE D’ASSOCIATION
61
F IG . 4.9 – TODO.
4.2.1
Critère de complétude
Avec ce critère de complétude de l’association, on cherche à s’assurer de la propriété
suivante : chaque tâche élémentaire du modèle d’association doit être associée à au moins
une unité de calcul du modèle d’architecture avec une TaskAllocation, et chaque donnée
présente dans le modèle d’association doit être allouée sur au moins une mémoire du modèle d’architecture à l’aide d’une DataAllocation. Si ces deux règles sont respectées, cela
signifie, en considérant l’application sous la forme d’un arbre, que pour chaque feuille
correspondant à une tâche, il y aura au moins un processeur qui sera chargé de son exécution et que chaque donnée sera stockée dans au moins une mémoire. À noter qu’en
ce qui concerne les tâches, l’allocation peut être directe ou indirecte : une tâche peut être
allouée indirectement par une tâche de niveau supérieur dans l’arborescence.
La figure 4.10 illustre un exemple de placement incomplet. L’application est toujours
la même : c’est l’addition de matrices modélisée à la figure 4.1 exécutée sur l’architecture
présentée sur la figure 4.2. L’association de l’application et de l’architecture matérielle se
fait à l’aide d’une distribution par bloc sur les deux dimensions de l’instance sum. Il y a
16 x 16 répétitions de l’instance sum qui seront distribuées sur la grille comprenant 4 x 4
unités de calcul par blocs de 4 x 4 tâches.
4.2.2
Critère de cohérence
Si le critère de complétude nous assure que chaque tâche sera placée sur au moins
un processeur et chaque donnée allouée sur au moins une mémoire, il n’est pas suffisant
pour garantir le bon fonctionnement de l’application. C’est pourquoi, avec ce critère de
cohérence de l’association, on cherche à s’assurer du bon fonctionnement de l’application.
Toutes les tâches de l’application doivent pouvoir s’exécuter normalement, l’ordonnancement doit donc être valide. Si les tâches ont besoin d’utiliser des données, ces dernières
doivent être placées sur des mémoires accessibles pour la tâche. Des données différentes
ne doivent pas se recouvrir, le placement des communications doit être en accord avec les
besoins des tâches.
62
CHAPITRE 4. VALIDATION D’UN PLACEMENT GASPARD2
F IG . 4.10 – Placement incomplet d’un ensemble de tâche sur la grille de processeurs, l’espace de répétition ne permettant pas de distribuer l’intégralité des tâches de l’application.
La figure 4.11 illustre un exemple de placement complet mais incohérent. L’application est constituée de deux tâches, comprenant chacune un producteur et un consommateur. L’architecture matérielle est composée de deux unités de calcul, chaque unité étant
composé de deux processeurs.
4.3
4.3.1
Outil de vérification d’un placement
Approches envisagées
La seconde partie de ces travaux concerne la mise en œuvre d’un outil nous permettant, pour une association donnée, de nous assurer que celle-ci est correcte, à savoir que
les critères de complétude et de cohérence que nous avons présentés sont respectés. Pour
ce faire, cet outil utilisera les modèles générés pendant le processus, plus particulièrement
les modèles d’application, d’architecture et surtout d’association. Plusieurs approches se
sont offertes à nous pour réaliser cet outil de vérification.
Parmi les nombreuses approches possibles, nous en avons retenu deux. Nous présenterons d’abord l’approche basée sur OCL puis l’approche reposant sur SynDex.
4.3.1.1
OCL
Présentation OCL [25] (Object Constraint Language) est un langage formel pour l’expression de contraintes standardisé par l’OMG, ces contraintes s’appliquent à des mo-
4.3. OUTIL DE VÉRIFICATION D’UN PLACEMENT
63
F IG . 4.11 – Placement incohérent.
dèles UML qui ne sont pas capables, seuls, de spécifier complètement une application.
OCL apporte les outils pour exprimer des contraintes de deux types : les invariants qui
sont des contraintes devant être respectées en permanence et les pré/post conditions, les
préconditions représentent des contraintes devant être vérifiées avant l’exécution et les
postconditions représentent des contraintes devant être vérifiées après l’exécution. OCL
supporte également les opérations sur les ensembles et la logique des prédicats.
La contrainte suivant illustre un exemple. Cette dernière exprime le fait qu’un composant de type GaspardComponent ne peut contenir que des parts typée par un composant
stéréotypé à l’aide de GaspardComponent.
inv : self.part->exists(p|p.stereotype->exists(name=’GaspardComponent’))
Vérificateur de contraintes OCL de Gaspard2 Il est également intéressant de noter
qu’un outil de vérification de contraintes OCL pour les modèles Gaspard2 est actuellement développé au sein de l’équipe. Dans sa version actuelle, cet outil, appelé GaspardValidation, apporte des contraintes sur la syntaxe et la sémantique des modèles d’architecture et d’application. Une mémoire ne peut pas contenir un processeur par exemple.
L’idée est donc d’étendre ce vérificateur, afin d’y ajouter nos propres contraintes à vérifier
sur le modèle d’association entre un modèle architecture et un modèle d’application.
Limitations Les contraintes OCL ne nous permettront finalement pas de mettre en œuvre
un outil permettant de faire une vérification complète de la spécification d’une association entre application et architecture matérielle. En effet, s’il est possible de vérifier des
64
CHAPITRE 4. VALIDATION D’UN PLACEMENT GASPARD2
contraintes relativement simple comme l’association d’un composant simple sur une partie de l’architecture, OCL ne se révèle pas assez puissant ni expressif pour spécifier des
contraintes plus complexes mettant en œuvre les notions de hiérarchie, de multiplicités
ou les concepts intervenants dans les processus de distribution. Alors que la vérification
syntaxique est complètement prise en charge par OCL, le côté vérification sémantique ne
l’est pas entièrement.
4.3.1.2
SynDEx
Présentation SynDEx [26] est un logiciel de CAO (Conception Assistée par Ordinateur)
niveau système. Il est fondé sur la méthodologie « Adéquation Algorithme Architecture
» [27] (AAA) et a été conçu pour le prototypage rapide et pour l’optimisation d’applications distribuées temps réel embarquées. Il permet de spécifier l’algorithme d’application
et l’architecture basé sur des composants, d’exprimer une adéquation correspondant à
une implantation optimisée de l’algorithme d’application sur l’architecture et le résultat
est une simulation temporelle de l’exécution du premier cité sur le second. SynDEx permet la génération automatique d’un exécutif temps réel dédié pour chaque processeur,
ces exécutifs étant produits à partir de bibliothèques de noyaux d’exécutifs extensibles et
portables dépendant des processeurs de l’architecture.
L’idée est d’utiliser les outils proposés par SynDEx pour tester notre association, il faut
donc effectuer une transformation du modèle Gaspard2 vers le modèle de SynDEx.
Limitations Cependant, cette transformation n’est pas possible en l’état en raison de
certaines limitations du modèle de SynDEx. En effet, plusieurs aspects du modèle Gaspard ne sont pas pris en charge. Au niveau des modèles d’architecture, il n’y a pas de
support de la hiérarchie ni de support des répétitions. En ce qui concerne les modèles
d’application, seules les répétitions monodimensionnelles sont supportées ainsi que les
aspects hiérarchiques, tout en présentant une certaine lacune. Si on prend un exemple
d’application hiérarchique avec un grand nombre de niveaux, SynDEx peut se comporter de deux manières : soit il considère la tâche hiérarchique comme un tout et ne regarde
pas ce qui la compose, soit il déroule les niveaux un par an et dans le cadre d’un placement, il réfléchira pour placer les éléments un par un. Pour être capable de transformer le
modèle Gaspard afin de le rendre utilisable par SynDEx, il est donc nécessaire d’effectuer
une modification au niveau du modèle afin de le rendre compatible.
Mise à plat du modèle Gaspard2 Afin de rendre le modèle de Gaspard2 exploitable
avec SynDEx, la première étape consiste à « supprimer » les notions ne pouvant être
prises en charge. C’est un travail qui a été effectué durant l’été 2007 et qui a consisté à «
mettre à plat » le modèle Gaspard2. Les notions de hiérarchie et de répétition au niveau
du modèle d’architecture ont été supprimées.
Transformation du modèle mis à plat Une fois le modèle « aplati », il ne reste plus qu’à
le transformer vers un modèle SynDEx. Ce travail de transformation vient d’être réalisé
par un étudiant de maîtrise dans le cadre d’un stage filé. Il serait donc intéressant de
creuser davantage dans cette direction afin d’étudier les gains que l’on pourrait retirer de
l’utilisation de SynDEx.
4.3. OUTIL DE VÉRIFICATION D’UN PLACEMENT
4.3.2
65
Plugin de validation Gaspard2
Présentation Nous avons donc décidé de définir notre propre outil de validation à intégrer dans l’environnement Gaspard2. Cet environnement est basé autour d’Eclipse [28]
et fonctionne en tant qu’application autonome. Nous avons donc décidé d’étendre l’environnement en lui greffant un « plug-in » permettant de tester l’association entre une application et une architecture. En tant qu’application Eclipse, notre validateur est donc un
programme Java. La développement d’un « plug-in» est facilité par les outils et la structure même d’Eclipse : Eclipse se révèle en fait être un noyau offrant un grand nombre de
points d’extensions, entité faisant office de point d’ancrage destiné à accueillir des extensions.
Fonctionnement L’environnement Gaspard2 permet, à partir d’un modèle qu’on lui
fournit en entrée, d’effectuer de manière successive un certain nombre de transformation, dans le but d’obtenir au final un code de simulation.
F IG . 4.12 – Un modèle vu avec Gaspard2
Son fonctionnement est le suivant : à partir d’un modèle d’entrée conforme, modélisé
au préalable à l’aide d’un modeleur UML comme Papyrus ou MagicDraw, on effectue
une transformation vers un autre modèle. Dans notre cas ça sera le modèle Gaspard,
cette transformation UML2ToG2 génère à partir du modèle d’entrée, plusieurs modèles
de Gaspard2 (figure 4.13 : Application, Architecture, Association etc. Ces trois modèles sont
justement les modèles qui nous intéressent dans le cadre du plugin :
Toutes les associations sont donc inscrites dans le fichier asso.gaspard2, nous avons
donc fait en sorte d’ajouter un bouton Association Validation nous permettant d’invoquer
l’action de vérification de l’association et de le rendre actif lorsque l’on sélectionne ce modèle d’association. Techniquement parlant, nous avons créé une extension qui se greffe
sur deux points d’extension : l’un pour le démarrage automatique du «plug-in» et l’autre
permettant de spécifier le comportement à adopter lorsque l’on sélectionne un fichier
ayant pour nom asso.gaspard2.
66
CHAPITRE 4. VALIDATION D’UN PLACEMENT GASPARD2
F IG . 4.13 – Résultat de la transformation UML2ToG2
Le programme est organisé par l’intermédiaire de trois paquetages que sont association, complete et consistent. Le paquetage association contient le squelette nécessaire au bon
fonctionnement du programme, le paquetage complete s’occupe des spécificités liées à la
vérification de la complétude et le paquetage consistent s’occupe des notions de cohérence.
F IG . 4.14 – L’organisation en paquetage
Fonctionnalités manquantes Dans sa version actuelle, l’outil supporte la vérification
d’un placement vis à vis de son critère complet : le «plug-in» vérifie que toutes les tâches
concernées par une allocation sont effectivement placées et que les données consommées
par les tâches sont placées sur au moins une mémoire. L’outil est toujours en développement afin de compléter la validation vis à vis du critère de cohérence : données placées à des endroits accessibles, ordonnancement correct des tâches etc. À noter que nous
n’avons pas pris en charge la gestion des communications.
Exemple d’utilisation Nous terminons la présentation de l’outil avec deux exemples
d’utilisation. Nous allons utiliser un modèle correspond à une application et une architecture que nous avons déjà présenté précédemment : l’application effectue une addition
de deux matrices de dimension 128 x 128 à l’aide d’une répétition d’une tâche élémentaire travaillant sur deux matrices de dimension 8 x 8. L’architecture est composée d’une
grille de 4 x 4 unités de calcul. Le placement correspond à une distribution par blocs de 4
x 4 tâches sur l’architecture. Dans cet exemple on vérifie que toutes les tâches sont effectivement placées sur au moins un processeur, notre exemple étant correct, le résultat de
la vérification nous informe de la validité de l’association(figure 4.15.
Pour le second exemple, nous allons conserver la même application et la même architecture, nous allons seulement opérer une modification au niveau de l’association. Nous
4.3. OUTIL DE VÉRIFICATION D’UN PLACEMENT
67
F IG . 4.15 – Validation réussie d’un placement
allons volontairement oublier de prendre en compte un certain nombre de tâche dans la
distribution : la dernier bloc de la première dimension ne trouvera donc pas de processeur
pour s’exécuter. Le résultat de la validation est présent sur la figure 4.16.
F IG . 4.16 – Validation échouée d’un placement
68
CHAPITRE 4. VALIDATION D’UN PLACEMENT GASPARD2
Chapitre 5
Conclusion
ODO
contrib démo
T
contrib méthodo
contrib gaspard
perspective
69
70
CHAPITRE 5. CONCLUSION
Bibliographie
[1] D. D. Gajski and R. Kuhn. Guest editor introduction : New VLSI-tools. 16(12) :11–14,
December 1983.
[2] Hubert Tardieu, Arnold Rochfeld, and René Colletti. La Méthode Merise : Principes et
outils. Editions d’Organisation, 1991.
[3] Malcon Eva. SSADM Version 4 : A User’s Guide. McGraw-Hill Publishing Co, April
1994.
[4] Object Management Group, Inc., editor. UML 2 Infrastructure (Final Adopted Specifcation). http://www.omg.org/cgi-bin/doc?ptc/2003-09-15, September
2003.
[5] Eclipse Consortium. EMF. http://www.eclipse.org/emf, 2007.
[6] Object Management Group, Inc. MOF meta object facility, specification, version 1.3.
http://www.omg.org/cgi-bin/doc?formal/00-04-03, January 2000.
[7] Tom Mens, Krzysztof Czarnecki, and Pieter Van Gorp. A taxonomy of model transformations. In Jean Bezivin and Reiko Heckel, editors, Language Engineering for
Model-Driven Software Development, number 04101 in Dagstuhl Seminar Proceedings.
Internationales Begegnungs- und Forschungszentrum (IBFI), Schloss Dagstuhl, Germany, 2005. http://drops.dagstuhl.de/opus/volltexte/2005/11.
[8] Object Management Group, Inc., editor. SysML v0.9. http://www.omg.org/
cgi-bin/doc?ad/05-01-03, January 2005.
[9] Object Management Group, Inc., editor. UML Profile for Modeling and Analysis of
Real-Time and Embedded systems (MARTE) RFP. http://www.omg.org/cgi-bin/
doc?realtime/2005-02-06, February 2005.
[10] Object Management Group, Inc., editor. (UML) Profile for Schedulability, Performance, and Time Version 1.1. http://www.omg.org/technology/documents/
formal/schedulability.htm, January 2005.
[11] WEST Team LIFL, Lille, France. Graphical Array Specification for Parallel and Distributed Computing (GASPARD-2). http://www.lifl.fr/west/gaspard/, 2005.
[12] A. Benveniste, P. Caspi, S. Edwards, N. Halbwachs, P. L. Guernic, and R. de Simone.
Synchronous Languages Twelve Years Later. Proceedings of the IEEE, January 2003.
[13] P. Caspi, D. Pilaud, N. Halbwachs, and J.A. Plaice. LUSTRE : a declarative language for
real-time programming. ACM Press, 1987.
[14] Paul Le Guernic, Jean-Pierre Talpin, and Jean-Christophe Le Lann. Polychrony for
system design. Journal for Circuits, Systems and Computers, Special Issue on Application
Specific Hardware Design, apr 2003.
[15] Rabie Ben Atitallah, Pierre Boulet, Arnaud Cuccuru, Jean-Luc Dekeyser, Antoine
Honoré, Ouassila Labbani, Sébastien Le Beux, Philippe Marquet, Éric Piel, Julien
71
72
BIBLIOGRAPHIE
Taillard, and Huafeng Yu. Gaspard2 uml profile documentation. Technical Report
0342, September 2007.
[16] Alain Demeure, Anne Lafarge, Emmanuel Boutillon, Didier Rozzonelli, Jean-Claude
Dufourd, and Jean-Louis Marro. Array-OL : Proposition d’un formalisme tableau
pour le traitement de signal multi-dimensionnel. In Gretsi, Juan-Les-Pins, France,
sep 1995. in-french.
[17] Pierre Boulet. Array-OL revisited, multidimensional intensive signal processing specification. Technical Report RR-6113, February 2007.
[18] Allen, Chase, Hallett, Luchangco, Maessen, Ryu, Steele, and Tobin-Hochstadt. The
fortress language specification, version 1.0. Sun Microsystems, Inc., March 2008.
[19] Stéphane Ducasse, Oscar Nierstrasz, Nathanael Schärli, Roel Wuyts, and Andrew
Black. Traits : A mechanism for fine-grained reuse. ACM Transactions on Programming
Languages and Systems, 28(2) :331–388, mar 2006.
[20] Gilad Bracha and William Cook. Mixin-based inheritance. In OOPSLA/ECOOP ’90 :
Proceedings of the European conference on object-oriented programming on Object-oriented
programming systems, languages, and applications, pages 303–311, New York, NY, USA,
1990. ACM Press.
[21] D. Callahan, B.L. Chamberlain, and H.P. Zima. The cascade high productivity language. In High-Level Parallel Programming Models and Supportive Environments, 2004.
Proceedings. Ninth International Workshop on, pages 52–60, 2004.
[22] Philippe Charles, Christopher Donawa, Kemal Ebcioglu, Christian Grothoff, Allan
Kielstra, Vijay Saraswat, Vivek Sarkar, and Christoph Von Praun. X10 : An objectoriented approach to non-uniform cluster computing. In Proceedings of the 20th ACM
SIGPLAN conference on Object-oriented programing, systems, languages, and applications,
pages 519–538. ACM SIGPLAN, 2005.
[23] Pierre Boulet and Xavier Redon. Communication pre-evaluation in HPF. In EUROPAR’98, volume 1470 of LNCS, pages 263–272. Springer Verlag, 1998.
[24] Pierre Boulet, Philippe Marquet, Éric Piel, and Julien Taillard. Repetitive Allocation Modeling with MARTE. In Forum on specification and design languages (FDL’07),
Barcelona, Spain, September 2007. Invited Paper.
[25] Object Management Group, Inc., editor. Object Constraint Language Specification,
version 2.0. http://www.omg.org/cgi-bin/doc?formal/2006-05-01, may
2006.
[26] Yves Sorel and Christophe Lavarenne. Modèle unifié pour la conception conjointe
logiciel-matériel. (numéro spécial Adéquation Algorithme Architecture), 14(6) :569–578,
1997.
[27] Y. Sorel. Massively parallel systems with real time constraints, the algorithm architecture adequation methodology. In Proceedings of Conference on Massively Parallel
Computing Systems, MPCS’94, Ischia, Italy, May 1994.
[28] eclipse.org. Eclipse. http://www.eclipse.org, 2008.