Optimisation des applications de traitement … · RÉSUMÉ Les applications de traitement intensif de signal apparaissent dans de nombreux domaines d’applications tels que multimédia

Numéro d’ordre : 40135

Université des Sciences et Technologies de Lille

thèse

présentée pour obtenir le titre de docteurspécialité Informatique

par

calin glitia

O P T I M I S AT I O N D E S A P P L I C AT I O N S D E T R A I T E M E N TS Y S T É M AT I Q U E I N T E N S I V E S S U R S Y S T E M S - O N - C H I P

Thèse soutenue le 23 novembre 2009, devant la commission d’examen formée de :

Nouredine Melab Professeur Université de Lille 1 Président

François Irigoin Maître de Recherche École des Mines Paris Rapporteur

Patrice Quinton Professeur ENS Cachan Rapporteur

Michel Barreteau Chef de Projet R&D THALES Palaiseau Examinateur

Sven-Bodo Scholz Senior Lecturer University of Hertfordshire UK Examinateur

Pierre Boulet Professeur Université de Lille 1 Directeur

Université des Sciences et Technologies de Lille

LIFL - UMR 8022 - Cité Scientifique, Bât. M3 - 59655 Villeneuve d’Ascq Cedex

O P T I M I S AT I O N D E S A P P L I C AT I O N S D ET R A I T E M E N T S Y S T É M AT I Q U E I N T E N S I V E S

S U R S Y S T E M S - O N - C H I P

calin glitia

Thèse de doctorat

23 Novembre 2009

Calin Glitia : Optimisation des applications de traitement systématique inten-sives sur Systems-on-Chip, Thèse de doctorat, © 23 Novembre 2009

A B S T R A C T

Intensive signal processing applications appear in many applicationdomains such as video processing or detection systems. These applica-tions handle multidimensional data structures (mainly arrays) to dealwith the various dimensions of the data (space, time, frequency). Aspecification language allowing the direct manipulation of these dif-ferent dimensions with a high level of abstraction is a key to handlingthe complexity of these applications and to benefit from their massivepotential parallelism. The Array-OL specification language is designedto do just that.

In this thesis, we introduce an extension of Array-OL to expresscycle dependences by the way of uniform inter-repetition dependences.We show that this specification language is able to express the mainpatterns of computation of the intensive signal processing domain. Wediscuss also the repetitive modeling of parallel applications, repetitivearchitectures and uniform mappings of the former to the latter, usingthe Array-OL concepts integrated into the Modeling and Analysis ofReal-time and Embedded systems (MARTE) UML profile.

High-level data-parallel transformations are available to adapt theapplication to the execution, allowing to choose the granularity ofthe flows and a simple expression of the mapping by tagging eachrepetition by its execution mode : data-parallel or sequential. The wholeset of transformations was reviewed, extended and implemented as apart of the Gaspard2 co-design environment for embedded systems.

With the introduction of the uniform dependences into the specifi-cation, our interest turns also on the interaction between these depen-dences and the high-level transformations. This is essential in order toenable the usage of the refactoring tools on the models with uniformdependences.

Based on the high-level refactoring tools, strategies and heuristics canbe designed to help explore the design space. We propose a strategythat allows to find good trade-offs in the usage of storage and compu-tation resources, and in the parallelism (both task and data parallelism)exploitation, strategy illustrated on an industrial radar application.

v

R É S U M É

Les applications de traitement intensif de signal apparaissent dansde nombreux domaines d’applications tels que multimédia ou systèmesde détection. Ces applications gèrent les structures de données multidi-mensionnelles (principalement des tableaux) pour traiter les différentesdimensions des données (espace, temps, fréquence). Un langage de spé-cification permettant l’utilisation directe de ces différentes dimensionsavec un haut niveau d’abstraction est une des clés de la manipulationde la complexité de ces applications et permet de bénéficier de leurparallélisme potentiel. Le langage de spécification Array-OL est conçupour faire exactement cela.

Dans cette thèse, nous introduisons une extension d’Array-OL pourexprimer des dépendances cycliques par des dépendances interrépéti-tions uniformes. Nous montrons que ce langage de spécification estcapable d’exprimer les principaux motifs de calcul du domaine detraitement de signal intensif. Nous discutons aussi de la modélisationrépétitive des applications parallèles, des architectures répétitives et lesplacements uniformes des premières sur les secondes, en utilisant lesconcepts Array-OL intégrés dans le profil UML MARTE (Modelingand Analysis of Real-time and Embedded systems).

Des transformations de haut niveau data-parallèles sont disponiblespour adapter l’application à l’exécution, ce qui permet de choisir lagranularité des flots et une simple expression du placement en éti-quetant chaque répétition par son mode d’exécution : data parallèleou séquentiel. L’ensemble des transformations a été revu, étendu etimplémenté dans le cadre de l’environnement de comodélisation pourles systèmes embarqués, Gaspard2.

Avec l’introduction des dépendances uniformes, notre intérêt s’esttourné aussi sur l’interaction entre ces dépendances et les transforma-tions de haut niveau. C’est essentiel, afin de permettre l’utilisation desoutils de refactoring sur les modèles avec dépendances uniformes.

En utilisant les outils de refactoring de haut niveau, des stratégieset des heuristiques peuvent être conçues pour aider à l’exploration del’espace de conception. Nous proposons une stratégie qui permet detrouver de bons compromis entre l’usage de stockage et de ressourcesde calcul, et dans l’exploitation de parallélisme (à la fois de tâches etde données), stratégie illustrée sur une application industrielle radar.

vi

P U B L I C AT I O N S

Une partie du matériel présenté dans ce chapitre a également étépublié dans les publications suivantes :

journaux [1]

[1] Calin Glitia, Philippe Dumont et Pierre Boulet :Array-OL with delays, a domain specific specificationlanguage for multidimensional intensive signal processing.Multidimensional Systems and Signal Processing, 2009. URLhttp://springerlink.com/content/w3821760381l4432/

?p=fc0a4428f2f4468a9d630d2a434a6f69&pi=0.

conférences internationales à comité de lecture et actes [2]

[2] Calin Glitia et Pierre Boulet : High level loop transfor-mations for multidimensional signal processing embeddedapplications. In International Symposium on Systems, Ar-chitectures, Modeling, and Simulation (SAMOS VIII), Samos,Greece, juillet 2008. URL http://samos.et.tudelft.nl/

samos_viii/.

[3] Calin Glitia et Pierre Boulet : Interaction between inter-repetition dependences and high-level transformations inarray-ol. In Conference on Design and Architectures for Signaland Image Processing (DASIP 2009), Sophia Antipolis, France,septembre 2009.

workshops internationaux aux comité de lecture [1]

[4] Calin Glitia : Interaction between delays and high-leveltransformations in array-ol. In 2nd Artist Workshop on Modelsof Computation and Communication, Eindhoven, Netherlands,juillet 2008.

rapports de recherche [2]

[5] Calin Glitia et Pierre Boulet : High level loop trans-formations for systematic signal processing embedded ap-plications. Research Report 6469, INRIA, 03 2008. URLhttps://hal.inria.fr/inria-00262023.

[6] Calin Glitia, Pierre Boulet, Éric Lenormand et MichelBarreteau : Repetitive model refactoring strategy for thedesign space exploration of intensive signal processing ap-plications. Rapport technique number not yet available,INRIA, septembre 2009. extended version.

vii

http://springerlink.com/content/w3821760381l4432/?p=fc0a4428f2f4468a9d630d2a434a6f69&pi=0

http://springerlink.com/content/w3821760381l4432/?p=fc0a4428f2f4468a9d630d2a434a6f69&pi=0

http://samos.et.tudelft.nl/samos_viii/

http://samos.et.tudelft.nl/samos_viii/

https://hal.inria.fr/inria-00262023

R E M E R C I E M E N T S

Je tiens à exprimer ma profonde gratitude envers Pierre Boulet pourm’avoir encadré, conseillé et soutenu tout au long de ma thèse et pourm’avoir guidé et aidé lors de l’écriture de ce manuscrit. Je remercieégalement les rapporteurs de cette thèse, François Irigoin et PatriceQuinton, pour avoir lu et commenté ce manuscrit et aussi pour leurremarques, questions et recommandations.

Je tiens à remercier Nouredine Melab d’avoir accepté de présider monjury de thèse et je remercie également Michel Barreteau et Sven-BodoScholz d’avoir fait partie de mon jury.

Les travaux présentés font tous partie du projet Gaspard2 et ilsn’auraient pas pu avoir lieu sans le travail fournit par tous les autrescontributeurs de ce projet. J’en profite pour exprimer toute ma sym-pathie et gratitude à l’ensemble des membres de l’équipe DaRT del’INRIA Lille-Nord Europe et le Laboratoire d’Informatique Fondamen-tale de Lille, pour leur aide, leur collaboration, leur solidarité et leuramitié.

Enfin, je souhaiterais remercier ma famille et mes amis pour m’avoirsoutenu et aidé au cours de ma thèse.

ix

TA B L E D E S M AT I È R E S

i modélisation 5

1 modélisation multidimensionnelle 7

1.1 Traitement intensif du signal sur System-on-Chip 7

1.2 Applications de traitement intensif multidimensionnel 9

1.3 Classification des langages 10

1.4 Approche fonctionnelle 12

1.5 Approche impérative 14

1.6 Approche flot de données 16

1.7 Conclusions 26

2 array-ol 27

2.1 Principes du langage 28

2.2 Parallélisme de tâches 30

2.3 Parallélisme de données 31

2.4 Définition statique 38

2.5 Pouvoir d’expression 40

2.6 Modélisation des dépendances uniformes 48

2.7 Conclusions 61

3 comodélisation dans une vision répétitive en marte 63

3.1 Concepts support 64

3.2 MARTE: Modeling and Analysis of Real-time and Em-bedded systems 65

3.3 Modélisation des structures répétées 66

3.4 Reshapes 67

3.5 Gaspard2: environnement de comodélisation pour l’em-barqué 70

3.6 Modélisation en MARTE pour Gaspard2 71

3.7 Modélisation des architectures 76

3.8 Placement répétitif 81

3.9 Conclusions 83

ii de la spécification vers l’exécution 85

4 optimisations source à source 87

4.1 Étude de l’exécution 87

4.2 Optimisations du code 89

4.3 Conclusions 95

5 refactoring en utilisant des transformations de

haut niveau 97

5.1 Répétitions sous la forme de boucles 98

5.2 Formalisme ODT 100

5.3 Transformations data-parallèles 106

5.4 Extensions 119

5.5 Comparaison avec les transformations de boucles 126

5.6 Conclusions 129

6 impact du refactoring sur les dépendances uniformes 131

6.1 Interaction : analyse formelle 131

6.2 Exemple pratique 138

6.3 Conclusions 139

xi

xii table des matières

iii validation expérimentale 141

7 stratégie de refactoring pour l’exploration de l’es-pace de conception 143

7.1 Application radar STAP 143

7.2 Vers un modèle d’exécution 149

7.3 Analyse des résultats 156

7.4 Conclusions 158

8 refactoring dans le contexte de gaspard2 159

8.1 Contributions 159

8.2 Perspectives 164

8.3 Conclusions 165

iv annexes 171

a application de fenêtres glissantes en array-ol 173

b modélisation d’une architecture noc en marte 177

bibliographie 179

TA B L E D E S F I G U R E S

Fig. 1 Tile64 8

Fig. 2 Une application SDF 17

Fig. 3 Graphe de dépendance d’une application SDF 18

Fig. 4 Une application MDSDF 19

Fig. 5 Une application simple 19

Fig. 6 Une application MDSDF qu’on ne peut transcrireen SDF 20

Fig. 7 Un downsample 20

Fig. 8 Fonctionnement d’une source 22

Fig. 9 Fenêtres glissantes en WSDF 25

Fig. 10 Downscaler - boîte noire 30

Fig. 11 Downscaler - parallélisme de tâches 31

Fig. 12 La répétition du filtre horizontal 32

Fig. 13 Tuile éparse 33

Fig. 14 Tuile rectangulaire 33

Fig. 15 Tuile complexe (éparse sur une dimension et di-agonale sur l’autre) 33

Fig. 16 Une tuile éparse, alignée sur les axes du tableau 34

Fig. 17 L’utilisation du modulo 34

Fig. 18 Tuile au motif élargi 34

Fig. 19 Pavage par ligne 35

Fig. 20 Un motif 2D qui pave exactement un tableau 2D35

Fig. 21 Les tuiles peuvent se chevaucher et le tableau esttoroïdal 35

Fig. 22 L’enchaînement des entrées et des sorties de filtrehorizontal 37

Fig. 23 La répétition totale d’une tâche élémentaire 39

Fig. 24 Multiplication des matrices en MDSDF 44

Fig. 25 Multiplication de matrices en Array-OL 45

Fig. 26 Fenêtres glissantes en Array-OL 46

Fig. 27 Une simple dépendance interrépétition 49

Fig. 28 Les dépendances dans l’espace de répétition del’Intégration 50

Fig. 29 Intégration : répétition mise à plat 51

Fig. 30 Dépendances dans un espace bidimensionnel 53

Fig. 31 Les dépendances dans l’espace de répétition 2D 54

Fig. 32 Multiples liens par défaut 54

Fig. 33 La dépendance interrépétition après une transfor-mation de tiling 57

Fig. 34 Dépendances après le partage en blocs 57

Fig. 35 Dépendances entre les répétitions pour la dépen-dance diagonale 58

Fig. 36 Dépendances diagonales après le tiling en blocs 59

Fig. 37 Dépendance diagonale 60

Fig. 38 Architecture globale du profil MARTE 66

Fig. 39 Shapes multidimensionnelles 67

Fig. 40 TilerSpecification et ShapeSpecification 67

Fig. 41 Liens topologiques répétitives 68

xiii

Fig. 42 Reshape comme une répétition 69

Fig. 43 La méthodologie SoC de Gaspard2 71

Fig. 44 L’environnement Gaspard2 72

Fig. 45 Les types de données vecteur et matrice 74

Fig. 46 Tâche répétitive-composée 75

Fig. 47 Tâche répétitive-composée transformée 75

Fig. 48 Grille de processeurs interconnectée - modélisa-tion MARTE RSM 79

Fig. 49 Grille de processeurs inter-connectées 80

Fig. 50 Dépendance sur le même port 80

Fig. 51 Distribute en MARTE RSM 82

Fig. 52 Distribution d’une répétition de 4× 4 sur 4 pro-cesseurs 82

Fig. 53 Placement des répétitions de la distribution 83

Fig. 54 Filtres répétitifs de l’application de Downscaler 106

Fig. 55 Downscaler après la fusion 107

Fig. 56 Chevauchement du macromotif dans le tableauinitial 110

Fig. 57 Le Downscaler après l’ajout de dimensions maxi-mal sur la première dimension 114

Fig. 58 Réduction des recalculs par agrandissement linéaire 114

Fig. 59 Modèle Downscaler après réduction des recal-culs 116

Fig. 60 Downscaler après l’aplatissement 117

Fig. 61 Filtre vertical après une transformation de tiling 118

Fig. 62 Modèle Downscaler qui respecte les contraintesde flot de données 119

Fig. 63 Enchaînement réel de répétitions 122

Fig. 64 Motif commun pour la consommation multiple. 125

Fig. 65 Hiérarchie sur un niveau 133

Fig. 66 Hiérarchie sur deux niveaux 134

Fig. 67 Dépendances élément-à-élément 136

Fig. 68 STAP 144

Fig. 69 STAP: niveau haut 146

Fig. 70 STAP: le niveau flot de données 146

Fig. 71 Décomposition de STAP 147

Fig. 72 Tiler construction pour les deux premières fil-tres 148

Fig. 73 Partage de la répétition infinie en blocs de {4} 151

Fig. 74 Résultat de la fusion des deux premières répéti-tions 152

Fig. 75 STAP: fusion des quatre premières tâches 153

Fig. 76 Niveau des filtres transformé 157

Fig. 77 Sous-répétitions de StapApplication et IntDoppler 157

Fig. 78 Utilisation d’outils de refactoring 163

Fig. 79 Extension pour gérer les dépendances interrépéti-tion 164

Fig. 80 Fenêtres glissantes en Array-OL en utilisant desReshapes et des Liens par défaut 174

Fig. 81 Fenêtres glissantes en MARTE 175

Fig. 82 Topologie de NoC 177

Fig. 83 Partage hiérarchique du NoC 177

xiv

Liste des tableaux xv

Fig. 84 Partage hiérarchique du NoC 178

L I S T E D E S TA B L E A U X

Tab. 1 Comparaison entre divers modèles de spécifica-tion pour le traitement de signal 11

Tab. 2 Tailles des tableaux pour la fusion complète 154

Tab. 3 Répétitions pour la fusion complète 155

Tab. 4 Fusion deux-par-deux 155

Tab. 5 Tailles des tableaux pour le meilleur choix defusion 156

Tab. 6 Répétitions pour le meilleur choix de fusion 156

I N T R O D U C T I O N

contexte

Notre monde est massivement parallèle. Depuis un moment le mondede l’informatique s’intéresse de nouveau au parallélisme, car celui-ciest la clef de la performance.

Les applications de l’informatique embarquée se sont étendues etsurtout suivent une tendance exigeant de plus en plus de puissance decalcul. La plupart de ces applications correspondent à du traitementde signal : une suite de calculs appliqués sur des flots de donnéesgénéralement multidimensionnels. Ces traitements sont en essenceparallèles et répétitifs. En plus d’être gourmandes en puissance decalcul, ces applications sont souvent soumises à des contraintes detemps réel qu’il convient de respecter.

Dans la conception de systèmes électroniques, la loi de Moore [65]s’applique toujours, tous les trois ans il est possible de placer deuxfois plus de transistors sur une puce électronique. Cette capacité àplacer de plus en plus de composants sur une puce favorise l’évolutioncontinue des systèmes sur puce (SoC, pour System-on-Chip). De parleur forte capacité d’intégration, les SoC offrent de grandes économiesen consommation d’énergie et en espace, ainsi qu’un gain importanten performance. La puce n’est plus dédiée à un type de composantparticulier, mais contient tous les composants qui forment un systèmeinformatique (processeur, mémoire, réseau d’interconnexion, circuitsanalogiques, etc.). Pour une utilisation efficace du grand nombre detransistors disponible pour le calcul, de multiples processeurs sontintégrés sur la même puce (MPSoC, multiprocesseur SoC) et l’usagedu parallélisme de plus en plus massif est essentiel.

Pour exploiter la puissance de calcul des architectures à unités paral-lèles, le code exécuté a un rôle essentiel : un maximum du parallélismede la spécification doit se retrouver à l’exécution. Malheureusement, undécalage peut être observé entre les évolutions technologiques et logi-cielles, marqué par une dégradation de la qualité de la programmation.Comme raison à cela, on peut penser aux complexités architecturalesqui font que les compilateurs ne peuvent plus suivre en fournissantdu code optimisé au maximum. Pour avoir de bons résultats, le coded’entrée devrait être conçu dans la vision parallèle, facilitant la tâchedu compilateur.

Dans le contexte de la conception de SoC, la complexité de concep-tion apporte des contraintes supplémentaires concernant le risque quele produit final ne corresponde pas à la spécification et le délai deproduction qui les rend parfois obsolètes avant même leur mise surle marché. À ces problèmes, il convient d’ajouter, une fois de plus, lademande toujours croissante en puissance de calcul.

Parallèlement aux évolutions technologiques, des méthodologiesde conception de SoC ont évolué et sont le lien entre le SoC et sonconcepteur. Un exemple de méthodologie utilisée depuis quelquesannées déjà est la décomposition en sous-composants interconnectés etla réutilisation d’IPs1 pour les ressources fonctionnelles d’un SoC. 1 pour Intellectual

Property

1

2 Liste des tableaux

Un langage impératif est par construction séquentiel – une suite d’in-structions – et de plus l’habitude de penser séquentiellement la logiqued’un programme ne facilite pas la tâche. Programmer de sorte que leparallélisme soit visible est plus approprié et, dans le domaine desapplications de traitement de signal pour des systèmes embarqués, lamodélisation en utilisant des langages de spécification peut représenterune solution.

Dans cette thèse nous nous intéressons au domaine de traitementintensif de signal pour SoC et notamment aux méthodologies de con-ception pour les SoC multiprocesseurs. La plupart de ces applicationssont par essence parallèles et répétitives et correspondent à une suitede calculs appliqués sur des flots de données généralement multi-dimensionnels. Des langages de spécification sont disponibles pourl’expression à un niveau haut d’abstraction des concepts essentiels : par-allélisme, aspect multidimensionnel, dépendances de données, etc. Desmodèles de calculs associés définissent les règles de fonctionnementde la spécification et facilitent le passage à l’exécution. Dans ce sens,les modèles statiques qui permettent une définition statique et uneexécution déterministe apportent des propriétés très intéressantes pourdes applications avec des contraintes de temps réel.

Un autre aspect intéressant est la modélisation conjointe de l’ap-plication, de la plateforme matérielle et du placement. Cela permetl’exploration de l’espace de conception et favorise des techniques d’op-timisation itératives guidées par les résultats remontés de la simula-tion/exécution au niveau de la spécification.

Dans l’équipe DaRT de l’INRIA Lille-Nord Europe où j’ai préparéma thèse de doctorat, nous nous intéressons à la comodélisation haut-niveau des applications de traitement massivement parallèles placéessur des architectures matérielles embarquées SoC contenant des unitésd’exécution parallèles et, à partir de cela, la génération du code pourdifférentes cibles, travaux intégrés dans l’environnement de conceptionGaspard2.

Dans cette démarche, les travaux présentés dans cette thèse se situentau niveau haut de la spécification multidimensionnelle pour le traite-ment intensif de signal, du modèle de calcul et des optimisations dehaut niveau pour l’adaptation de la spécification à l’exécution. Cesaspects se regroupent autour du langage de spécification et du modèlede calcul Array-OL utilisé dans l’équipe au niveau spécification. Lamodélisation des applications et des architectures parallèles se fait enutilisant la décomposition successive en sous-composants interconnec-tés où un rôle essentiel est occupé par les structures répétitives pourexprimer des traitements parallèles dans l’application et des architec-tures répétitives.

Pour pouvoir arriver à générer du code « performant », le premierpas est un langage de spécification adapté au domaine d’application. Entant que caractéristiques essentielles pour le domaine des applicationsde traitement intensif de signal, on peut citer :

a. l’expressivité pour permettre une spécification facile et complète,qui arrive à saisir les caractéristiques des calculs parallèles ;

b. l’aspect multidimensionnel pour une représentation cohérentedes structures de données ;

c. le formalisme visuel : une spécification visuelle est plus appro-priée à la modélisation du parallélisme qu’une approche textuelle ;

Liste des tableaux 3

d. la définition statique pour simplifier la gestion des ressourcesdans le contexte des systèmes embarqués.

Un modèle de spécification exprime le fonctionnement complet d’uneapplication, en exprimant toutes les dépendances de données, mais unetelle spécification ne dit rien relativement à l’exécution de l’application.Tous les ordres d’exécution respectent les dépendances de données sontcorrects. Mais quel représente l’ordre optimal ? Ce problème, commetoutes les optimisations multicritères, est très complexe et laborieux.

Dans les compilateurs modernes, les techniques d’optimisation s’ap-puient sur l’utilisation de transformations de boucles et d’heuristiquesimplémentant différentes stratégies d’optimisation. Des techniquesd’optimisation similaires aux transformations de boucles sont util-isées dans l’environnement Gaspard2, mais ce sont dans notre cas destransformations data parallèles au niveau haut de la spécification. Desurcroît, des stratégies d’optimisation itérative peuvent être conçuesautour ces transformations, guidées par des paramètres remontants duniveau de la simulation.

contributions

Les contributions principales de cette thèse sont les suivantes :

1. proposition des sémantiques d’expression des dépendances in-terrépétitions dans Array-OL, permettant la construction desboucles dans la modélisation. L’aspect uniforme de ces dépen-dances a un impact réduit sur le parallélisme de la spécificationet, par la composition des dépendances à travers la hiérarchie,des dépendances complexes peuvent être exprimées. En plus, cesdépendances fournissent les constructions nécessaires pour l’ex-pression compacte des architectures répétitives interconnectées ;

2. extension des transformations du haut niveau data parallèleArray-OL. L’ensemble de transformations déjà disponibles asubi des extensions visant soit un ajout de fonctionnalités, soitl’extension pour des cas spéciaux, soit de grouper des transfor-mations élémentaires dans des nouvelles transformations avec denouvelles propriétés dans une vision orientée vers l’utilisation enpratique ;

3. implémentation des transformations de code dans l’environnementGaspard2 et le branchement à l’éditeur Papyrus UML pour desmodèles UML étendus par le profil standard de l’OMG, MARTE ;

4. validation pratique des transformations et étude de stratégies etd’heuristiques d’enchaînement des transformations. Au momentdu passage de la spécification à l’exécution, ces optimisationsvisent adapter la spécification aux contraints de l’exécution etfacilitent l’exploration du placement d’une application sur desarchitectures parallèles distribuées, par l’exploration de l’espacede conception ;

5. étude de l’interaction entre les transformations Array-OL et lesdépendances interrépétition, proposition d’un algorithme pourgérer cette interaction et implémentation de l’algorithme.

4 Liste des tableaux

plan

Dans la première partie de la thèse on s’intéresse aux méthodologiesde conception des SoC.

En premier temps, dans le chapitre 1 – modélisation multidi-mensionnelle –, nous faisons le point sur les langages de spécifica-tion conçus pour le traitement intensif de signal, avec un intérêt spécialpour l’expressivité des fonctions d’accès régulier.

La sémantique du langage Array-OL et son pouvoir d’expressionest exploré dans chapitre 2 – array-ol – en comparaison avec deslangages similaires, suivie par la proposition d’une extension pourpouvoir exprimer des dépendances uniformes entre des répétitionsdata parallèle.

Dans le chapitre 3, comodélisation dans une vision répéti-tive en marte, nous allons voir comment les concepts de la décompo-sition répétitive Array-OL peuvent être utilisés dans la spécification enMARTE des applications de traitement intensif de signal, des architec-tures répétitives et du placement des spécifications data-parallèles surles architectures distribuées contenant des unités de calcul parallèles.

Dans la deuxième partie de la thèse, nous allons enquêter sur destechniques de refactoring utilisant des transformations de haut niveaudata parallèle, travaux développant les résultats des thèses de deuxanciens thésards de l’équipe, Soula et Dumont.

La méthodologie de passage à l’exécution et des techniques d’opti-misation sont étudiés dans le chapitre 4 – optimisations source à

source. Les outils de refactoring basés sur des transformations de hautniveau Array-OL sont approfondis dans le chapitre 5 – refactoring

en utilisant des transformations de haut niveau – et desextensions sont proposées.

Nous focalisons notre attention sur l’interaction des transformationsavec l’extension proposée pour exprimer des dépendances uniformessur des répétitions data-parallèles dans le chapitre 6 – impact du

refactoring sur les dépendances uniformes – et nous pro-posons un algorithme qui gère cette interaction.

La dernière partie de cette thèse est orientée vers la validation destravaux théoriques d’optimisation, par l’étude des stratégies d’optimisa-tion dans le contexte d’une application réelle de traitement intensif designal dans le chapitre 7 – stratégie de refactoring pour l’ex-ploration de l’espace de conception. Les outils de refactoringdans le contexte de l’environnement Gaspard2 et les travaux d’implé-mentation, intégration et interfaçage sont présentés dans le chapitre 8,refactoring dans le contexte de gaspard2 , avant d’en veniraux conclusions.

Première partie

M O D É L I S AT I O N

1M O D É L I S AT I O N M U LT I D I M E N S I O N N E L L E

1.1 Traitement intensif du signal sur System-on-Chip 71.2 Applications de traitement intensif multidimension-

nel 91.3 Classification des langages 101.4 Approche fonctionnelle 12

1.4.1 Alpha 12

1.4.2 Sisal 13

1.5 Approche impérative 141.5.1 StreamIt 14

1.5.2 SaC 14

1.5.3 Fortran 15

1.6 Approche flot de données 161.6.1 SDF: Synchronous DataFlow 16

1.6.2 MDSDF: MultiDimensional SynchronousDataflow 18

1.6.3 GMDSDF: Generalized MultiDimensionalSynchronous Dataflow 20

1.6.4 WSDF: Windowed Synchronous Data Flow 24

1.7 Conclusions 26

Dans ce chapitre nous essayons d’identifier des caractéristiques es-sentielles du domaine de la modélisation des applications de traitementintensif de signal pour l’embarqué. Nous allons examiner différentespropositions de langages de modélisation pour le domaine, qui ontchacune leurs avantages et leurs faiblesses, en insistant sur le pouvoird’expression dans le contexte multidimensionnel.

La section 1.1 introduira tout d’abord le domaine du traitement in-tensif de signal sur System-on-Chic, suivie par une la description descaracteristiques principales des applications multidimensionnelles dansla section 1.2 et une classification des langages dédies au traitement dusignal, dans la section 1.3. Les approches fonctionnelles, impérativeset flot de données sont étudiées respectivement dans les section 1.4,section 1.5 et section 1.6. Les conclusions sont présentées dans la sec-tion 1.7.

1.1 traitement intensif du signal sur system-on-chip

Le traitement de signal consiste à analyser et interpréter des signauxprovenant de capteurs. Nous nous intéressons principalement auxapplications de traitement de signal intensif et régulier.

La complexité de ces applications n’est pas causée par les fonctionsélémentaires qu’elles combinent, mais par leur enchaînement et dela façon par laquelle l’accès aux tableaux intermédiaires est fait. Unemodélisation capable d’exprimer les différentes caractéristiques detelles applications faciliterait l’étape de la spécification et permettraitd’effectuer des nombreuses optimisations.

7

8 modélisation multidimensionnelle

La charge en calcul de ces applications est assez élevée pour claire-ment impliquer des unités matérielles de calcul parallèles. Dans cettedirection, l’exploitation du parallélisme disponible est essentielle, maisil ne faut pas oublier la performance temps réel qui est un besoin cléde la plupart de ces applications.

Depuis le début des années 2000, les System-on-Chips (ou SoC) ontémergé comme un nouveau paradigme pour la conception de systèmesembarqués. Dans une architecture SoC, plusieurs unités fonctionnelles(processeurs programmables, mémoires, périphériques d’entrée/sortie,etc.) sont intégrés sur la même puce. De plus, de multiples processeurspeuvent être intégrés dans un SoC (Multiprocesseur System-on-Chip,MPSoC [46]) et les communications peuvent être réalisées à travers desréseaux embarqués (Networks-on-Chips, NoCs [11]). Les MPSoCs sontparticulièrement avantageuses dans des applications où les contraintesde performances sont cruciales. La Figure 1 illustre un exemple deMPSoC avec des composants interconnectés, l’architecture du Tile64

de Tilera.

XAUI 1PHY/MAC

SerializeDeserialize

XAUI 1PHY/MAC


Flexible I/OPCIe 1PHY/MAC

Flexible I/O

UARTHPI, I2C

JTAG, SPI

PCIe 0PHY/MAC



GbE 0

GbE 1

DDR Controller 0 DDR Controller 1

DDR Controller 3 DDR Controller 2

Fig. 1: Tile64

La conception des SoC couvre des points de vue variés y comprisla modélisation par l’agrégation des composants fonctionnels, l’assem-blage des composants physiques existants, la vérification et la simula-tion du système modélisé et la synthèse d’un produit final intégré dansune seule puce.

Le placement des applications de traitement intensif de signal surdes SoC et surtout des MPSoC est un problème délicat. Le placementdes calculs sur les unités d’exécutions potentiellement parallèles, l’al-location des tableaux dans les mémoires influencent directement lesperformances. L’évaluation des performances se fait très souvent parla simulation et en remontant des résultats du niveau simulation auniveau spécification et l’exploration des différents placements permetl’augmentation des performances.

1.2 applications de traitement intensif multidimensionnel 9

La définition statique de la spécification peut réduire les mécanismesde management des ressources embarqués et aussi garantir des latencesde fonctionnement temps-réel pour des applications exigeantes.

Nous allons maintenant voir quelles sont les caractéristiques desapplications de traitement intensif de signal et comment différentslangages de spécification ont approché la thématique.

1.2 applications de traitement intensif multidimension-nel

Une modélisation dehaut-niveau doitpermettre d’exprimercorrectement etcomplètement lescaractéristiques d’uneapplication.

Des applications de calcul intensif sont prédominantes dans plusieursdomaines d’applications, tels que le traitement d’images et vidéo ou lessystèmes de détection (radar, sonar). Par multidimensionnel on entendque ces applications manipulent principalement des structures de don-nées multidimensionnelles représentées normalement par des tableaux.Comme exemple, une vidéo est un objet 3D avec deux dimensionsspatiales et une temporelle. Dans une application sonar, une dimensionpeut être l’échantillonnage temporel des échos, une autre l’énumérationdes hydrophones et des autres comme les dimensions des fréquencespeut apparaître plus tard dans les calculs.

Traiter ce type d’applications présente un nombre de difficultés :– elles sont d’habitude massivement parallèles et pour bénéficier de

ce parallélisme, on doit l’exprimer complètement ;– seul très peu de modèles de calcul (MoC1) sont multidimensionnels 1 Model of

Computation enanglais.

et aucun n’est largement utilisé ;– les motifs d’accès aux tableaux des données sont divers et com-

plexes et cela représente le problème principal quand on parled’optimisation ;

– l’ordonnancement de ces applications avec des ressources limitéesest un défi, spécialement dans un contexte parallèle et distribué.

On peut retrouver plusieurs essais de conception des langages ou desmodèles de calcul dédiés à ce domaine d’applications. Le défi est deproposer une façon pour exprimer des accès multidimensionnels sanscompromettre l’utilisation et s’il est possible de permettre un ordon-nancement statique de ces applications sur des plateformes matériellesparallèles.

Un bon langage pour des applications de traitement intensif multidi-mensionnel devrait être capable d’exprimer :motifs uniformément espacés :

Le traitement intensif de signal est extrêmement régulieret il présente beaucoup de parallélisme. Pour exprimerla totalité des caractéristiques de ces applications, il estessentiel de décrire complètement et correctement toutecette régularité.

fenêtres glissantes :Les algorithmes en utilisant des fenêtres glissantes sontdes parties fondamentales des systèmes de traitementdes signaux. Les modèles de flots de données ont desdifficultés à exprimer des concepts clefs nécessaires pourexprimer ces algorithmes, tels que la consommationmultiple de données ou le traitement des frontières.


dimensions cycliques :Dans le cas des applications où certaines dimensions spa-tiales peuvent représenter des tori physiques – commedes hydrophones autour d’un sous-marin –, la capacitéde spécifier des dimensions cycliques dans les tableauxest essentielle. Aussi après une transformation Fourierdiscrète, la dimension de la fréquence est cyclique. Pourgérer les bandes de fréquence, la possibilité d’adres-sage cyclique d’une plage d’indices est extrêmementimportante.

sous/sur échantillonnage :

Des contraintes applicatives peuvent causer certainscomposants à consommer des tableaux qui représen-tent des sous/sur échantillons des tableaux disponibles.

spécification hiérarchique : Une spécification hiérarchique est obligatoire pourmodéliser des applications complexes. Elle favorise la modularité et la réutilisationdes composants, tout en permettant la structuration de l’application aux différentsniveaux de granularité.

informations d’état : Dans une spécification orientée flot de données où il y a pasdes variables globales et les cycles ne sont pas permis dans le graphe, pour permettrede garder des informations d’état – nécessaires pour exprimer des filtres récursifs parexemple – ces structures devraient être exprimées explicitement.

1.3 classification des langages

On peut retrouver plusieurs critères de comparaison pour les lan-gages dédiés au traitement de signal :

flot de données, fonctionnel ou impératif ? Le paradigmede flot de données est l’approche largement utilisée dans la de-scription des applications de signal. Une approche fonctionnellea l’avantage de pouvoir exprimer directement des fonctions d’ac-cès par des expressions mathématiques. Les langages impératifsont l’atout du pouvoir d’expression dans l’étape de spécification,mais cela complique énormément l’étape de compilation. Descompromis peuvent être atteints en mettant des restrictions surun tel langage.

visuel ou textuel ? La méthode de saisie des applications influ-ence directement la qualité des modélisations. Certaines caté-gories de langages possèdent des caractéristiques qui font qu’unereprésentation visuelle n’est pas seulement meilleure, mais néces-saire. La sémantique de graphe des langages de flot de donnéesfait d’eux des candidats idéaux pour des représentations et ma-nipulations visuelles. Par contre, pour les langages impératifsune représentation textuelle est normalement plus appropriée.Néanmoins, des éléments visuels peuvent aussi être mélangésaux éléments textuels2.2 Une vue visuelle

pour le niveauglobal et deséléments textuelspour des détails.

statique ou dynamique ? Un langage statiquement ordonnançablefacilite considérablement les mécanismes au moment de l’exécu-tion, en réduisant les temps d’exécution (pas de réallocation demémoire, pas d’ordonnancement à la volée, tout est connu avantl’exécution). Il est évident qu’un langage statique est plus restrictif

1.3 classification des langages 11

MoC

Stru

ctur

esde

donn

ées

Type

d’ac

cès

Gén

éral

ité

d’ac

cès

Stru

ctur

esde

cont

rol

fenê

tres

sous

/sur

non

//dé

lais

glis

sant

esec

hant

iona

geav

ecle

sax

es

SDF

[60,6

1]

1D

sub-

arra

y-

-+

CSD

F[1

3]

1D

sub-

arra

y-

-+

MD

SDF

[62

,18]

mD

sub-

arra

y-

+-

+

GM

DSD

F[7

0,6

9]

mD

sub-

arra

y-

++

+

WSD

F[4

7,5

0]

mD

sub-

arra

y+

+-

+

Ar

ra

y-O

L[2

9,2

8,1

4]

cycl

icm

Dsu

b-ar

ray

++

+ex

t.

Stre

am-I

T[8

7]

1D

sub-

arra

y+

++

Alp

ha[5

9,2

4]

poly

hedr

aaf

fine

++

++

Sisa

l[4

0,6

]m

Dsu

b-ar

ray

++

-+

SaC

[84

]m

Dsu

b-ar

ray

++

++

1.

conc

erna

ntla

colo

nne

dety

pes

dedo

nnée

s,1D

repr

ésen

tede

sflo

tsde

donn

ées

mon

odim

ensi

onne

ls(q

uipe

uven

tco

nten

ird’

autr

esta

blea

uxco

mm

eav

ecSt

ream

IT),

mul

ti-D

veu

td

ire

que

ces

flot

sd

ed

onné

eson

tét

ére

mp

lace

sp

ard

esta

blea

ux

mu

ltid

imen

sion

nels

,cyc

liqu

esm

ult

i-D

rep

rése

nte

des

tabl

eau

xm

ult

idim

ensi

onne

lsav

ecce

rtai

nes

dim

ensi

ons

quip

euve

ntêt

recy

cliq

ueet

poly

èdre

sve

utdi

requ

ele

lang

age

man

ipul

ede

spo

lyèd

res

conv

exes

depo

ints

enti

ers;

2.

un+

dans

une

colo

nne

sign

ifie

que

cett

epa

rtic

ular

ité

est

supp

orté

e,un

-qu

’elle

n’es

tpa

set

ext.

qu’e

llees

tsu

ppor

tée

par

une

exte

nsio

ndu

lang

age

deba

se.

Tab.1

:Com

para

ison

entr

edi

vers

mod

èles

desp

écifi

cati

onpo

urle

trai

tem

ent

desi

gnal


qu’un langage non statique, de par les contraintes pour assurerqu’un ordonnancement statique peut être calculé.

objectifs du langage . Les caractéristiques d’un langage sont con-sidérablement influencées par le but dans lequel il était conçu :la programmation, la simulation fonctionnelle, l’analyse d’ordon-nancement, la synthèse, etc.

Le Tableau 1 présente une comparaison entre plusieurs langages (oumodèles de calculs, MoC) dédiés au traitement de signal. Cette com-paraison met en évidence la pertinence de ces divers langages pour lamodélisation des applications de traitement de signal multidimension-nels. Les structures de données possibles (flots monodimensionnels oudes tableaux multidimensionnels) et le pouvoir d’expression des fonc-tions d’accès à ces structures de données comptent parmi les critèresprincipaux de comparaison. La catégorie des applications que ces lan-gages sont capables de traiter est aussi contrainte par les mécanismesde flot de contrôle permis.

1.4 approche fonctionnelle

La programmation fonctionnelle est un paradigme de programmationqui considère le calcul en tant qu’évaluation de fonctions mathéma-tiques et rejette le changement d’état et la mutation des données. Ellesouligne l’application des fonctions, contrairement au modèle de pro-grammation impérative qui met en avant les changements d’état. L’ap-proche fonctionnelle s’affranchit de façon radicale des effets secondairesen interdisant toute opération d’affectation. Le paradigme fonctionneln’utilise pas de machine d’états pour décrire un programme, maisun emboîtement de fonctions que l’on peut voir comme des « boîtesnoires » que l’on peut imbriquer les unes dans les autres.

1.4.1 Alpha

Le langage Alpha [59, 24], développé au laboratoire Irisa de Rennes,est généralement associé à l’environnement MMAlpha qui est uneinterface basée sur Mathematica pour la manipulation du langage Al-pha. L’intérêt d’Alpha est de fournir un langage de haut niveau poursynthétiser des architectures VLSI3. En effet, Alpha est un langage fonc-3 VLSI : Very Large

Scale Integrationcaractérise lescircuits intégrés detrès hauteintégration.

tionnel basé sur le modèle polyédral, à assignation unique et fortementtypé qui permet de représenter les algorithmes sous forme d’équationsrécurrentes [49].

Alpha ne présente pas de particularismes notables concernant ladéclaration des fonctions, en revanche les variables sont définies à l’aidede fonctions sur le domaine Zn. En effet, les données manipulées parAlpha sont multidimensionnelles : elles correspondent à des unionsde polyèdres convexes. Leurs formes ne sont donc pas restreintesà de simples tableaux rectangulaires. L’exemple suivant montre ladéclaration d’une variable dont le domaine est l’ensemble des pointsdans le triangle : 0 6 i 6 j; j 6 10 :

a : {i,j | 0 6 i 6 j; j 6 10}

Afin d’accéder aux différentes valeurs de ces données, il est possiblede faire des restrictions sur les domaines. On se sert pour cela del’instruction case.

1.4 approche fonctionnelle 13

a =

case

{i,j | j = 0 } : 0.(i,j->);

{i,j | j > 0 } : a.(i,j->i,j-1)+1.(i,j->);

esac;

Dans cet exemple, nous avons a[i, j] = 0 lorsque j = 0 et a[i, j] =

a[i, j− 1] + 1.Alpha se révèle donc être en mesure d’exprimer de façon simple des

formes de données très complexes, mais il s’avère incapable de gérer lesaccès cycliques. En outre, nous n’avons pas besoin de gérer des formesde données aussi complexes et nous pouvons donc nous contenter desimples tableaux à plusieurs dimensions.

1.4.2 Sisal

Sisal (Stream and Iteration in a Single Assignment Language4) est 4 Flot et intéractiondans un langaged’assignationunique.

un langage fonctionnel à assignation unique conçu dans l’objectif defournir une interface utilisateur d’usage générale pour une large plagedes plateformes parallèles. Ces sémantiques précisent la dynamiqued’un graphe de flot de données et les expressions Sisal évaluent etrenvoient des valeurs basées uniquement sur les valeurs limitées à leursarguments formels et identificateurs constitutifs. La définition initialede Sisal (version 1.2 [40]) est basée sur un modèle utilisant des tableauxmonodimensionnels. Dans cette définition, les tableaux peuvent êtreconstruits par la concaténation des tableaux des dimensions intérieurespour construire un seul tableau monodimensionnel, qui favorise cer-taines optimisations comme la vectorisation. Les désavantages de cetteapproche sont le fait que les tableaux doivent être gardés dans unezone de mémoire continue et que les vecteurs inférieurs doivent avoirla même taille.

La définition initiale a été élargie par Attali et al. dans [6] en per-mettant des sémantiques multidimensionnelles. Pour exprimer desséquences potentiellement infinies avec des sémantiques non stricteset pour pouvoir exploiter le parallélisme pipeline, des flots5 ont été 5 définis par la

primitive stream.introduits dans Sisal. Entre autres, dans les sémantiques des tableauxmultidimensionnels, les sous-tableaux peuvent avoir des tailles dif-férentes. Différemment que dans la version précédente, cette deuxièmefavorise des accès aux sous-tableaux dans une manière structurée plutôtqu’élément par élément.

Des spécifications de placement peuvent être utilisées pour placerdes valeurs d’un sous-tableau dans un sous-ensemble géométriquementdéfini du tableau d’origine, d’exprimer des composants diagonaux enutilisant des notations dot ou des placements arbitraires des valeursquand un tableau est utilisé comme vecteur sous-script. Néanmoins, lesplacements prédéfinis des sous-tableaux restent parallèles avec les axesou diagonale et pour pouvoir exprimer des structures plus complexescomme des accès cycliques, le placement des sous-tableaux doit êtredéfini élément par élément.


1.5 approche impérative

1.5.1 StreamIt

StreamIt [87] est une exception dans les langages « textuels » à flots dedonnées. StreamIt, pour stream-MIT, est un langage impératif utilisant laprogrammation orienté objet, développé au Massachusetts Institute

of Technology spécialement pour des systèmes modernes orientésflot de données. Le langage est conçu pour faciliter la programmationdes applications complexes de flot de données et l’infrastructure decompilation disponible pour le langage vise un placement efficace surdes architectures matérielles.Des flots de données

mono-dimensionnelsavec des éléments quisont des tableaux nereprésentent pas desflots de donnéesmulti-dimensionnelsadéquates ; dans lasous-section 2.5.2 ondétaille cetteaffirmation.

La vision du projet StreamIt se concentre sur la programmabilité, desoptimisations spécifiques au domaine et à l’architecture. Le passagesimple et directe de la spécification vers l’implémentation le rend trèsattractif, mais il est assez limité au niveau de l’expressivité ; il saitmanipuler seulement des flot de données mono-dimensionnels.

Un programme StreamIt reprend la syntaxe du langage java, ilest d’ailleurs possible d’utiliser un compilateur java sur un code enStreamIt après une phase de traduction. En StreamIt les filtres con-stituent la classe de base et ces filtres sont constituées principalementde deux méthodes :

la méthode work est la plus importante car elle contient la liste destraitements réalisés par un filtre. Entre outre, c’est dans cetteméthode que le filtre peut communiquer avec les autres filtres del’application. Il utilise pour celà des fifos qui sont traités commedes attributs de la classe filter. L’interaction avec ces fifos se faità l’aide de trois méthodes push, pop et peek qui sont semblablesaux méthodes habituelles de manipulations de fifos ;

la méthode init est utilisée pour initialiser le filtre et les fifos. Ilest ainsi possible de positionner des valeurs initiales dans les fifosavant le début de l’exécution. Mais surtout la méthode permetde positionner le nombre de données qui seront consommées ouproduites par push, pop et peek dans la méthode work.

Il est ensuite possible de relier ces filtres en utilisant trois méthodesdifférentes qui représentent chacune une topologie différente : un liendirect, une boucle et une dissociation suivie d’un regroupement.

L’interaction de StreamIt avec le flot de données est donc relativementbasique. On peut considérer que StreamIt est le pendant « textuel »du langage « graphique » SDF que nous allons étudier dans la sec-tion 1.6 et ceci bien que StreamIt dispose de quelques fonctionnalitéssupplémentaires.

1.5.2 SaC

SaC [84] (Single Assignment C) est un langage qui essaye d’intégrerdes tableaux n-dimensionnels avec un temps d’accès constant dansdes langages impératifs. Il partage des principes de conception avecSisal, présenté dans la sous-section 1.4.2, mais introduit des tableauxn-dimensionnels comme structures de données principales.

Un tableau dans SaC est représenté par l’ensemble d’un tableaumonodimensionnel qui contient les données et un vecteur de formepour définir sa structure, en spécifiant le nombre d’axes (ou nombre de

1.5 approche impérative 15

dimensions) et le nombre d’éléments (les limites des indices) le long dechaque axe. En utilisant la primitive reshape un tableau n-dimensionnelpeut être défini ou redéfini en changeant sa forme.

Similaire aux autres langages, SaC suggère d’utiliser des opérationscomposées sur des tableaux, qui s’appliquent uniformément sur tous leséléments des tableaux ou des sous-tableaux cohérents. La programma-tion en utilisant des opérations sur les tableaux peut se faire décidémentplus concise, compréhensible, et moins susceptible aux erreurs en com-paraison avec en utilisant des nids de boucles qui traversent les élémentsavec des valeurs spécifiques de début, fin et pas. Ces opérations im-pliquent d’habitude des décompositions des tableaux en sous-tableauxet le reassemblage dans une autre forme. Avec SaC, l’approche choisievise à fournir des constructions du langage suffisamment versatile pourpermettre la spécification concise et efficacement exécutable des opéra-tions composés sur les tableaux, basés sur des boucles WITH-loop. Cesconstructions profitent d’être assez-générales et aussi toutes les opti-misations de compilateur concernant la génération du code optimisépeuvent se concentrer sur ces constructions.

1.5.3 Fortran

Même si le langage Fortran [45] n’est pas un langage dédié au calculintensif de signal, nous ne pouvons pas faire de ne le mentionner. Ilest un des langages impératifs les plus populaires dans le domaine ducalcul haute performance, particulièrement adapté au calcul numériqueet scientifique.

Fortran englobe une série de versions, dont chacune a évolué pourajouter des extensions à la langue tout en conservant généralement lacompatibilité avec les versions précédentes. Nous sommes intéresséssurtout des constructions d’accès aux tableaux, qui sont apparus avecla norme Fortran 90, en permettant des opérations unitaires au niveaudes tableaux (ou des sections de tableaux) et son extension pour lecalcul parallèle, High Performance Fortran (HPF) [44], qui ajoute desconstructions parallèles (FORALL).

Les accès uniformes aux sous-tableaux sont définis par des couple(début:fin:pas) pour chaque dimension du tableau et peuvent spécifierdes accès parallèles avec les axes. La construction WHILE permet desaffectations sur des sections non régulières de tableaux. Mais Fortran estessentiellement un langage impératif et permet la spécification des accèscomplexes aux données. La difficulté principale est dans la spécificationdes constructions parallèles : le programmeur doit spécifier lui-mêmeles constructions parallèles, gérer les dépendances de données pourassurer une exécution correcte et spécifier le placement des donnéessur les processeurs.

HPF met la disposition une gamme large de constructions et implé-mente un modèle de calcul data-parallèle qui supporte la distributiondes calculs sur plusieurs processeurs. Ceci permet la mise en œuvreefficace des architectures de type SIMD et MIMD, mais la complexitédes décisions nécessite un programmateur expérimenté pour obtenirun code performant.


1.6 approche flot de données

Un flot de données est un paradigme pour la description des appli-cations du traitement du signal pour l’implémentation sur des archi-tectures matérielles parallèles. Pour l’implémentation concurrente, lestâches sont successivement décomposées en sous-tâches qui ensuitepeuvent être automatiquement, semi-automatiquement ou manuelle-ment ordonnancés sur des processeurs parallèles, soit au moment de lacompilation (statiquement) soit au moment de l’exécution (dynamique-ment). Le concept qui consiste d’automatiquement décomposer unprogramme séquentiel est très intéressant, mais les techniques d’anal-yse et d’extraction sont limités ; des programmes impératifs très souventcachent le parallélisme disponible dans l’application. Si le program-meur fournit cette décomposition comme conséquence naturelle dela méthodologie de programmation, nous devons normalement nousattendre à l’usage plus efficace des ressources concurrentes disponibles.Synchronous précise

que le langage eststatiquementordonnançable.

Dans le passé, plusieurs modèles de spécification orientés flot de don-nées ont été proposés, par exemple Synchronous Data Flow (SDF)[60, 61],Cyclo Static Data Flow (CSDF)[13], Multidimensional Synchronous DataFlow (MDSDF)[62, 18], Generalized Multidimensional Synchronous DataFlow (GMDSDF)[70, 69], Windowed Synchronoud Data Flow (WSDF) [47,50], Parameterized Synchronous Data Flow (PSDF)[12] ou Cyclo DynamicData Flow (CDDF)[91].

La plupart des langages de flot de données sont conçus autour SDFou autour son extension multidimensionnelle, MDSDF. SDF a été créeavec le but de pouvoir directement déduire un ordonnancement sta-tique pour permettre la construction des implémentations efficaces. Lesautres langages développés à partir de SDF ont essayé d’élargir sonexpressivité, mais en restant compatible avec SDF et en gardant lespropriétés statiques si possible. Des applications décrites en SDF ontl’avantage majeur qu’elles sont définies statiquement, mais les restric-tions du langage ainsi que la monodimenisonnalité réduit énormémentl’ensemble d’applications modélisables.

On peut retrouver dans la littérature deux directions d’extension dulangage :

– l’introduction de la multidimensionnalité explorée avec MDSDF etses extensions, GMDSDF et WSDF ;

– jouer avec des restrictions, en permettant des sémantiques paramé-trées (flot de données paramétré) ou l’introduction des modes defonctionnement dans la modélisation ; par exemple les change-ments de fonctionnement cyclique présents avec CSDF.

La deuxième extension va vers une fonctionnalité dynamique. Cer-tains langages, comme CSDF, gardent toujours la propriété de définitionstatique, mais la plupart ont perdu cette propriété et sont passé à unefonctionnalité dynamique, ce qu’on appelle des langages de flot dedonnées dynamiques.

On s’intéresse dans nos travaux plutôt des langages synchronespermettant un ordonnancement statique.

1.6.1 SDF : Synchronous DataFlow

Le modèle SDF (Synchronous DataFlow) a été créé et développé parLee et Messerschmitt à partir de 1986 [60, 61]. Il a été ensuite inté-

1.6 approche flot de données 17

gré à ptolemy, un environnement de modélisation et de simulationd’applications pour l’embarqué.

En SDF, une application est décrite par un graphe orienté dontchaque nœud consomme et produit des données respectivement sur sesarêtes entrantes et sortantes. Dans ptolemy, ces données sont appeléesjetons, tokens, et les nœuds sont appelés acteurs, actors. La Figure 2

montre le graphe d’une application décrite en SDF. En SDF, les noeudsreprésentent lescalculs et les arrêtsles flots des données.A B C D

I1 O1 I2 O2 I3 O3 I4 O4

I : nombre de tokens consommés

O : nombre de tokens produits

A,B,C,D : acteurs

Fig. 2: Une application SDF

Caractéristiques d’une application SDF

Les caractéristiques principales sont :– le nombre de données consommées et produites par un nœud

à chaque exécution est fixé dès la conception de l’application.Ce nombre doit être connu lors de la modélisation. En revancheaucune information n’est nécessaire sur les traitements effectuéspar ces acteurs ;

– la valeur des jetons ne doit en rien modifier le flot de données. Lesdonnées ne doivent servir qu’aux calculs réalisés par les acteurs etne doivent pas changer le comportement de l’application. Le flotde contrôle est donc indépendant des données. La définition statique

implique despropriétés formellestrès intéressantes.

Grâce à ces caractéristiques, l’application est définie statiquement. Ilest donc possible d’utiliser les propriétés formelles qui en découlentafin :

– de détecter les interblocages dès la conception ;– d’ordonnancer l’application dès la modélisation ;– d’avoir une exécution déterministe (résultats identiques pour quel-

conque ordonnancement) ;– d’avoir une exécution dans un temps fini et avec une consommation

de mémoire finie.À l’aide de ces propriétés, SDF permet de tester la validité d’une

application dès sa phase de conception, ce qui est bien entendu unegrande force.

Calcul de l’ordonnancement

Le calcul de l’ordonnancement se base sur la constatation suivante :lorsque l’application est exécutée, le nombre total de jetons produitspar une tâche est égal au nombre de jetons consommés par la tâchesuivante. Soit Ix et Ox le nombre de jetons respectivement consomméet produit par la xe tâche et soit rx le nombre d’exécution de cette tâche(cf la Figure 2), on peut alors écrire l’équation suivante :

rxOx = rx+1Ix+1 (1.1)


On obtient ainsi un système d’équations ; ce système n’a soit aucunesolution, soit une infinité. Dans le premier cas, le graphe est inconsis-tant et il ne peut être ordonnancé. Dans le deuxième cas, toutes lessolutions sont multiples d’une seule et même solution (−→r ). L’ensembledes solutions est donc décrit par k−→r avec k ∈N+.

Lorsque −→r a été calculé, il est possible, grâce aux résultats présentésdans [60], de construire un graphe de dépendance. Le calcul de −→r etla construction du graphe de dépendance étant automatiques, il n’y adonc pas de difficultés pour obtenir l’ordonnancement.

Exemple. Soit l’exemple présenté sur la Figure 3 : la première tâcheproduit deux jetons et la deuxième en consomme trois. La résolutiondu système d’équation donne −→r =

(32

)et le graphe de dépendance

obtenu est présenté sur la droite de la figure.

A B2 3

A1

A2

A3

B1

B2

Fig. 3: Graphe de dépendance d’une application SDF

Utilisation des états et des délais

Une autre opportunité offerte par SDF est l’utilisation des « délais ».Un délai est un ensemble de jetons qu’on peut placer sur une arête.Lors de l’exécution de l’application, la tâche, se trouvant en amont del’arête, produira des jetons, mais ceux-ci ne seront consommés par latâche en aval qu’après les jetons du délai. Les délais permettent doncde prépositionner des valeurs initiales sur les arêtes.

Un « état » est un délai particulier qui autorise une tâche à utiliser lerésultat d’une itération lors de l’itération suivante. Ainsi les n-premiersjetons de l’état sont utilisés par les n-premières itérations de la tâche,puis celle-ci utilise les résultats qu’elle a produits. L’utilisation des étatsest extrêmement utile : un exemple simple est la somme d’un vecteuroù l’état ne comporte qu’un seul jeton de valeur 0.

L’utilisation des états et des délais ne modifie pas la manière decalculer un ordonnancement.

1.6.2 MDSDF : MultiDimensional Synchronous Dataflow

Les flots de donnéesoù les éléments sontdes vecteurs ou destableaux n’exprimentpas unemultidimensionnalitéappropriée ; les accèssont toujoursrestreints sur ladimension du flot dedonnées.

SDF autorise la modélisation de flots de données mono-dimensionne-lles en spécifiant les dépendances entre les tâches. Les jetons transportéspar ces flots de données sont de nature quelconque, il peut notamments’agir de vecteurs ou de tableaux.

Le principe de MDSDF [62, 18] est de transporter des flots de don-nées multi-dimensionnelles appropriée. Bien que certaines applicationsMDSDF peuvent toujours être modélisés en SDF par la linéarisation desdimensions, la description est plus compliquée à comprendre et pourla plupart d’applications multidimensionnelles réelles il est impossiblede spécifier en SDF comment construire le graphe de précédence.


Le fonctionnement de MDSDF est similaire à celui de SDF. Ainsi, ilsuffit juste de préciser pour une tâche le nombre de données consom-mées et produites sur chacune des dimensions du flot. Ce principe estillustré par la Figure 4. Le flot représenté est de forme bidimensionnelle,la première tâche A produit un rectangle de jetons de taille OA,1 surla première dimension et de taille OA,2 sur la deuxième pour chaqueitération.

A B(OA,1,OA,2) (IB,1, IB,2)

Fig. 4: Une application MDSDF

De l’intérêt de MDSDF

L’utilisation de MDSDF permet d’exprimer de manière plus exacteune application. Les figures Subfig. 5a et Subfig. 5b montrent la mêmeapplication décrite respectivement avec MDSDF et avec SDF. En MDSDF(Subfig. 5a), il est évident que la première tâche produit un tableau detaille 40× 48 qui est consommé par morceaux de 8× 8 par la deuxièmetâche. En SDF il apparaît simplement que la première tâche produittrente jetons et que la deuxième les consomme un par un. SDF nepermet donc pas d’exprimer les dépendances de façon optimale lorsquela structure du flot de données est multi-dimensionnelle.

A DCT(40,48) (8,8) (8,8)

(a) en MDSDF

A DCT(30) (1) (1)

(b) en SDF

Fig. 5: Une application simple

Mais surtout MDSDF rend possible la modélisation d’application quine pouvait être décrite en SDF et ceci même avec une linéarisation desdimensions. La raison en est simple, il n’est pas possible en SDF de spé-cifier le mode de construction du graphe de dépendances. La Figure 6

montre que la première tâche produit une colonne de deux jetons etque la deuxième tâche consomme une ligne de 3 jetons. Les deux jetonsde la colonne ne seront donc pas consommés par la même itérationde la deuxième tâche comme le montre le graphe de dépendances. Orla modélisation de cette application en SDF, vue sur la Figure 3 nerespecte pas cette contrainte.

Calcul de l’ordonnancement

Le système d’équation de SDF est remplacé par plusieurs systèmesd’équations. En effet, un système est écrit pour chaque dimension :

rA,1OA,1 = rB,1IB,1

rA,2OA,2 = rB,2IB,2(1.2)

Chaque système est résolu de manière autonome. Les solutions obtenuessont de même forme que celles de SDF, chaque solution s’appliquant


A B(2,1) (1,3)

A1

A2

A3

B1

B2

Fig. 6: Une application MDSDF qu’on ne peut transcrire en SDF

à une dimension. Le nombre total d’itérations d’une tâche est égal auproduit du nombre d’itérations pour chacune des dimensions.

Particularité du modèle MDSDF

Dans les applications qu’on vient de voir en exemple, le nombre dedimensions du flot de données n’évolue jamais et il n’est d’ailleurs paspossible de créer ou de supprimer des dimensions. C’est pourquoi Leepropose des « acteurs clefs ». Ces derniers ne réalisent aucune opération,ils se contentent juste de modifier la structure du flot de données.D’ailleurs, il est important de rappeler que SDF ne manipule que lesflots de données et jamais les données elles-mêmes. La liste des « acteursclefs » n’est pas prédéfinie, Lee se contente d’en présenter quelques-uns. Le downsample sert par exemple à supprimer une dimension. LaFigure 7 représente un downsample qui consomme un tableau de M×Net qui produit un vecteur de taille M ; les éléments de la deuxièmedimension ont été supprimés.

(M,1)(M,N)

Fig. 7: Un downsample

À l’image de SDF, il est possible d’utiliser les « états » et les « délais »en MDSDF. Mais il s’agit désormais de n-uplet qui représente non pasdes jetons initiaux mais des lignes et des colonnes de jetons initiaux.Les différences s’arrêtent là et l’utilisation se fait de manière identiqueà celle de SDF.

Conclusion

MDSDF rend possible l’utilisation de flot de données multidimension-nelles, mais certaines contraintes demeurent. Notamment la consom-mation et la production des données doivent être parallèles aux axes.Pour résoudre ce problème, Murthy et Lee ont proposé une extension àMDSDF appelé GMDSDF.

1.6.3 GMDSDF : Generalized MultiDimensional Synchronous Dataflow

Le but de GMDSDF [70, 69] est de fournir un formalisme capable demodéliser des applications avec une consommation ou une productiondes données non parallèles aux axes. En GMDSDF, les jetons ne sontplus produits en ligne et en colonne comme avec MDSDF, mais ils sont


placés sur des treillis de points. Seuls certains points du treillis sontconsommés ou produits par les tâches de l’application. Trois tâchesspéciales sont introduites : la source, le décimateur et l’expandeur, ellessont les seules à pouvoir manipuler les treillis.

Fonctionnement de GMDSDF

Nous introduisons ici les trois tâches spéciales de GMDSDF, puis lestâches ordinaires. Les principes de bases de GMDSDF restent cependantidentiques à ceux de MDSDF.

la source : elle sert à créer et à définir la forme du treillis. Unesource est toujours associée à une matrice exemple (sampling matrix) V .Cette matrice détermine la forme du treillis en définissant les points duplan6 qui en font partie. La matrice treillis est constituée de l’ensemble 6 Il s’agit bien d’un

plan, car commenous le verronsplus tard, GMDSDFne s’applique paslorsque le nombrede dimensions estsupérieur à deux.

des points−→t = V .−→n , ∀−→n ∈ Nm,m ∈ N Sur la partie gauche de la

Figure 8, nous constatons que les points du treillis sont générés par lamatrice exemple

(1 −11 2

). De même on peut considérer que pour une

application MDSDF bidimensionnelle V =(1 00 1

).

Une autre matrice est associée avec une source, il s’agit de la matricesupport (support matrix) W. Elle est utilisée pour déterminer quelspoints du treillis seront produits. En effet une source ne produit pastous les points du treillis. La matrice exemple ne sert qu’à donner laforme du treillis et la matrice support, elle, indique l’emplacement deséléments produits par la source. Le calcul de ces positions s’effectue dela manière suivante :

– à partir de la matrice support, il est possible de construire le« parallélépipède fondamental » (fundamental parallelepiped) en sebasant à l’origine et en prenant les vecteurs de la matrice supportcomme les deux premiers cotés (cf partie droite de la Figure 8) ;

– tous les points à coordonnées entières se trouvant à l’intérieur de ceparallélépipède sont appelés les « points renumérotés » (renumberedpoints) et sont notés N(W) ; en outre, Lee montre que la cardinalitéde cet ensemble est égale à la valeur absolue du déterminant de lamatrice support |N(W)| = |det W| ;

– la multiplication des coordonnées des « points renumérotés » parla matrice exemple donne les coordonnées des points qui seronteffectivement produits par la source (cf la Figure 8).

Une source est définie par sa matrice exemple et sa matrice support.

le décimateur et l’expandeur : Si la source permet de créer destreillis, le décimateur et l’expandeur permettent eux d’en modifier laforme : le premier en enlevant des points, le deuxième en en rajoutant.Ils sont respectivement définis par leur matrice de « décimation » (M)et d’« expansion » (L).

Murthy et Lee notent respectivement Ve et Vf les matrices exemplesd’entrées et de sorties. De la même facon, il note We etWf les matricessupports. Les liens unissant les treillis d’entrées de sorties sont donnéespar les deux relations suivantes :

décimateur : Vf = Ve.M Wf = M−1.Weexpandeur : Vf = Ve.L−1 Wf = L.We .

(1.3)

Ainsi, un décimateur de matrice M =(3 00 2

), utilisé sur un treillis de

forme(1 00 1

), ne garde qu’un point sur trois sur la dimension horizontale


a b c

d e f

ab

c

d

ef

V =

(1 −1

1 2

)W =

(3 0

0 2

)

Le treillis Les « points renumérotés »

Les points du treillis

Points construits à partir des « points renumérotés »

Parallélogramme dessiné par W

Fig. 8: Fonctionnement d’une source

et un point sur deux sur la verticale. Un expandeur de matrice L =(3 00 2

)permet d’effectuer l’opération inverse.

les autres tâches : Les tâches « ordinaires » consomment etproduisent des points sur des treillis. Cependant elles n’utilisent plusun n-uplet comme en MDSDF mais une matrice support. Ainsi lespoints désignés ne sont plus nécessairement placés consécutivementsur une ligne ou sur une colonne. Mais ils peuvent être choisis demanière non parallèle aux axes et avec un décalage.

les états et les délais : Les « états » et les « délais » sontégalement présents. Comme GMDSDF ignore les notions de lignes etde colonnes, un « état » ou un « délai » sont vus désormais comme undécalage de l’origine lors du calcul du « parallélépipède fondamental ».Le décalage des « points renumérotés » implique également un décalagedes points qu’ils désignent. Les valeurs initiales des « états » et des« délais » servent donc à combler ce décalage.

Calcul de l’ordonnancement :

En MDSDF, il est possible de calculer simplement l’ordonnancementen résolvant le système d’équations. Ce système est simple à écrirecar les dimensions sur lesquelles sont consommées et produites lesdonnées sont parallèles aux axes. Mais en GMDSDF ce n’est pas la caset si une tâche produit des données suivant un vecteur −→x , la tâchesuivante pourra consommer ces mêmes données suivant un vecteur−→y . La désignation du nombre de points est elle aussi différente, toutse fait grâce aux matrices supports qui ne sont pas comparables entreelles. L’établissement du système d’équation est donc beaucoup plusdifficile. En fait, Murthy et Lee proposent de ramener le calcul del’ordonnancement de GMDSDF à celui de MDSDF, ils suggèrent decalculer des boites englobantes pour ranger les points des treillis, maisles calculs sont présentés uniquement pour des applications manipulantdes flots bidimensionnels. Les autres types d’applications ne sont pastraités et sont considérés comme trop complexes.


calcul des boites englobantes : Les données produites ouconsommées par chaque tâche sont « rangées » dans des rectanglesà l’aide d’une fonction de « rectangularisation ». En effet, il suffit dechanger le système de coordonnées d’un treillis en prenant comme baseles vecteurs de la matrice exemple7. 7 Les points du

treillis sont obtenuspar combinaisonlinéaire de lamatrice exemplequi estobligatoirementinversible enGMDSDF ; doncelle est bien unebase des points dutreillis.

Mais pour le décimateur et l’expandeur, le problème est différent. Ilfaut seulement que ces derniers ajoutent ou suppriment des ponts surle treillis ; la quantité de points prise sur un treillis pour une itérationimporte peu. On fixe alors que lexpandeur consomme un rectangle (1, 1)

(d’où We =(1 00 1

)) ce qui donne par application de l’Équation 1.3 Wf =

L. On peut en déduire alors que le décimateur produit un rectangle(L1, L2) avec L1 et L2 deux entiers positifs tels que L1L2 = |det(L)| [68].Par un raisonnement similaire le décimateur produit un rectangle (1, 1)

et consomme un rectangle (M1,M2). Mais on ne peut avoir simplementM1M2 = |det(M)| car il n’y aurait pas toujours de points à produire enraison de la forme des treillis, il faut donc appliquer d’autres conditionssur le calcul de (M1,M2). En fait, Murthy et Lee prouvent qu’il existetoujours une décomposition de |det(L)| qui soit valide. Il suffit de testerdifférentes possibilités jusqu’à ce que l’égalité suivante soit respectéeaprès le calcul de l’ordonnancement :

|N(Wf)| =

∣∣∣∣N(We)

det(L)

∣∣∣∣ (1.4)

calcul de l’ordonnancement : Finalement, il est possible decalculer l’ordonnancement de l’application. Une fois ce calcul effectué,il reste pour chaque tâche à définir la matrice support. En effet, on saitgrâce aux rectangles combien de données ces tâches consomment, maison ignore où ces données sont situées sur les treillis. Murthy et Leeprouvent dans [68] qu’il est possible d’obtenir les matrices supportsautomatiquement à partir du nombre de répétition d’une source. Aprèsce dernier calcul et la vérification de la validité des boîtes englobantesdes décimateurs, la modélisation de l’application et l’ordonnancementsont terminés.

Modélisation d’une application

La modélisation d’une application en GMDSDF s’effectue de lamanière suivante :

– création du graphe ;– choix des matrices exemples, d’« expansion » et de « décimation »

pour les tâches spéciales ;– choix des rectangles pour les tâches « ordinaires » ;– calcul de l’ordonnancement ;– calcul des matrices supports.L’application est donc définie après le calcul de l’ordonnancement,

ce qui est un inconvénient majeur puisque tout le travail est effectuépar le modeleur.

Conclusion

Il est important de signaler que les extensions introduites dansGMDSDF compliquent beaucoup la résolution du système d’équa-tions nécessaire pour l’ordonnancement statique. Pour calculer cetordonnancement, plusieurs simplifications sont nécessaires, décritespar Murthy et Lee pour des applications 2D uniquement. Bien que


GMDSDF soit une extension du MDSDF, il semble que la meilleurefaçon de calculer l’ordonnancement est de considérer les applicationsGMDSDF comme des MDSDF8.8 Les simplifications

proposéesreprésentent deréductions auxrectanglesgénéralisés.

Murthy et Lee affirment dans [69] : « la définition de GMDSDF neserra pas facilement utilisable dans un environnement de développe-ment » et ils n’ont pas implémenté le modèle en ptolemy. Ainsi onpeut regretter que GMDSDF oblige à définir, à un même niveau dedescription, les tâches spéciales de manipulation du treillis et les tâchesordinaires de manipulation des données.

1.6.4 WSDF : Windowed Synchronous Data Flow

WSDF [47, 50] est un modèle de calcul assez récent, consistant en uneévolution de MDSDF et conçu spécialement pour des algorithmes avecdes fonctionnalités de fenêtre glissante, parties importantes de n’importequel système de traitement d’images. Les modèles orientés flot dedonnées de la famille SDF ont des difficultés en exprimant des conceptsimportants des algorithmes de fenêtre glissante ; on peut mentionnerl’impossibilité de spécifier des consommations multiples de donnéesou le traitement des frontières.

Le modèle WSDF a été créé pour surmonter ces restrictions, enajoutant des concepts pour l’abstraction des caractéristiques impor-tantes des algorithmes de fenêtre glissante capables de représentationplus précise, mais tout cela en ajoutant un nombre de concepts nou-veaux comme des jetons virtuels, des jetons effectifs, unions des jetonsvirtuels, translation des fenêtres, traitement des frontières, etc. Tousces concepts additionnels rendent la modélisation plus compliquée etpeuvent mener des ambiguïtés. L’avantage du modèle est qu’il garde lapropriété de définition statique et il peut être utilisé pour résoudre desquestions importantes concernant l’ordonnancement et l’estimation destampons dans des algorithmes statiques de traitement d’images. Toutcela avec le risque de rendre la spécification trop complexe et en limitantl’applicabilité du modèle aux algorithmes de fenêtres glissantes.

La Figure 9 montre un exemple d’un graphe WSDF, emprunté du [50],utilisé pour illustrer les nouveaux concepts introduits en WSDF. L’idéede WSDF est de permettre la spécification des algorithmes de fenêtresglissantes mais en même temps rester compatible avec MDSDF. La con-Une spécification

WSDF avec lesconcepts additionnelsavec des valeurs pardéfaut est équivalenteà une spécificationMDSDF.

sommation des jetons se fait de la même manière qu’en MDSDF, avecla différence qu’on peut spécifier le décalage de la consommation deces jetons. Les jetons produits sont groupés en jetons virtuels et ensuiteen unions des jetons virtuels. Keinert et al. précisent que la motivation deces concepts est d’éviter le non-déterminisme. La taille du bloc danslequel la fenêtre glissante fait ses translations détermine la répétitionde l’acteur. En conséquence, si ce bloc de jetons virtuels n’est pas fixe,mais calculé par l’ordonnanceur, l’exécution n’est pas déterministe etpeut rendre le modèle ambigu. Alors pourquoi des jetons virtuels etaussi des unions de jetons virtuels ? Ce choix est fait pour rendre plusintuitive la spécification des algorithmes de traitement d’images oùplusieurs images sont consommées ensemble, d’après Keinert et al..

Les concepts disponibles en WSDF sont :

jetons effectifs produits, ~p : concept équivalent avec MDSDF,O, ce sont les jetons produits par l’exécution d’un acteur ;


A1

~p1 =

(2

1

)

~v1 =

(2048

1024

)

~p2

= (11 )

~v2

= (64

64 )

A3

~c3

=

( 5 3

) ;~u3

=

( 1 2

)

∆c

3=

( 10

01

)

~c1 =

(5

6

); ~u1 =

(2

2

)

∆c1 =

(1 0

0 2

)~p4 =

(1

1

)

~v4 =

(4092

1022

) A4

~c4 =

(3

3

); ~u4 =

(1

1

)

∆c2 =

(1 0

0 1

)

A2

~c2 =

(8

4

); ~u2 =

(1

1

)

∆c2 =

(8 0

0 4

)~p3 =

(16

2

)

~v3 =

(4096

512

)

~bs4 =

(1

1

)

~bt4 =

(1

1

)

Acteur A1 produit deux images de sortie, les deux avec une taille de 2024× 1024 pixels, avecla différence que la deuxième est coupée en blocs de 64× 64. Acteur A2 prends cette deuxièmeimage et réalise un sous-échantillonnage sur la dimension verticale et un suréchantillonnage surcelle horizontale, en regroupant les blocs dans une image de taille 4096× 512 pixels. ActeurA3 consommes 2× 2 images en provenant de l’acteur A1, avec un sous-échantillonnage sur ladirection verticale, et 1× 2 images de l’acteur A2. Les deux images sont consommées avec unefenêtre glissante de dimension 5× 6 et respectivement 5× 3. Le résultat est passé à l’acteur A4 quiréalise aussi une opération de fenêtre glissante, mais en utilisant l’extension des frontières.

Fig. 9: Fenêtres glissantes en WSDF

jetons virtuels, ~v : les jetons effectifs sont assemblés dans desjetons virtuels, qui représentent des blocs d’éléments qui formentune unité ;

l’union des jetons virtuels, ~u : représente le support pour l’o-pération de fenêtre glissante et est composée d’un ou plusieursjetons virtuels ;

jetons effectifs consommes, ~c : concept équivalent avec MDSDF,I, ce sont les jetons consommés à l’exécution d’un acteur. Dans lecontexte de WSDF, ceci représente la taille multidimensionnellede la fenêtre glissante ;

progression de la fenêtre , ∆c : une matrice diagonale qui pré-cise la translation de la fenêtre ~c à l’intérieur de l’union des jetonsvirtuels, ~u ;

éléments de délai, ~d : ont la même interprétation que dans lemodèle MDSDF ;

extensions des frontières, ~bs et ~bt : sans l’extension des fron-tières, les algorithmes de fenêtre glissante produisent des imagesplus petites que les images d’entrées, indésirable dans la plu-part des cas. ~bs spécifie combien d’hyperplans sont ajoutés audébut de l’union des jetons virtuels, pour chaque dimension, et~bt combien d’hyperplans sont ajoutés à la fin de l’union des je-tons virtuels, pour chaque dimension. Les éléments des frontièresélargis sont censés être des valeurs identiques et constantes.

WSDF modèle est l’extension de MDSDF, donc il englobe toutesles capacités de MDSDF. Des valeurs par défaut pour les conceptsadditionnels de WSDF donnent un modèle équivalent au MDSDF. Cesvaleurs par défaut sont : les jetons produits sont les mêmes que les


jetons virtuels, ~c = ~v, l’union de jetons virtuels contient un seul jetonvirtuel, ~u = ~1, la progression de la fenêtre se fait avec la taille des jetonsconsommes, ∆c = diag(c) et il n’y a pas d’extension des frontières,~bs = ~bt = ~0.

1.7 conclusions

Nous avons vu dans ce chapitre différents modèles de spécificationconçues pour des applications de traitement intensif de signal. Plusieursapproches ont été explorées, résultant de langages variés, chacun avecses avantages et désavantages. Nous avons insisté sur l’expressivité deslangages et sur les caractéristiques statiques.

Avant d’enquêter plus en détail les aspects relatifs à l’expressivitérelativement à Array-OL, le langage de spécification et modèle decalcul que nous utilisons, nous allons faire une présentation du langageet de ses sémantiques.

2A R R AY- O L

2.1 Principes du langage 282.2 Parallélisme de tâches 302.3 Parallélisme de données 31

2.3.1 Représentation visuelle d’une tâche répétée 31

2.3.2 Construire une tuile à partir d’un motif 32

2.3.3 Paver un tableau avec des tuiles 34

2.3.4 Résumé 35

2.3.5 Faire le lien entre les entrées et les sortiesvia l’espace de répétition 36

2.3.6 Exemples d’accès uniformes 36

2.4 Définition statique 382.5 Pouvoir d’expression 40

2.5.1 Positionnement 40

2.5.2 De vrais tableaux multidimensionnels 41

2.5.3 Comparaison entre Array-OL et GMDSDF 42

2.5.4 Désavantages de l’approche flots de donnéssynchrones 43

2.5.5 Array-OL et Alpha 47

2.6 Modélisation des dépendances uniformes 482.6.1 Exemple introductif 49

2.6.2 Définition de la dépendance interrépétition 51

2.6.3 Dépendances dans un espace multidimen-sionnel 53

2.6.4 Dépendances à travers la hiérarchie 55

2.6.5 Dépendances multiples 58

2.6.6 Discussion 60

2.7 Conclusions 61

Nous avons discuté dans le chapitre précèdent de la modélisationmultidimensionnelle pour des applications de traitement intensif designal et des différentes approches existantes qui essayent d’exprimeret exploiter la régularité disponible dans ce type d’application.

Dans ce chapitre nous allons présenter les principes et la sémantiqued’Array-OL, le formalisme que nous utilisons. Suite à une comparaisonavec les langages synchrones statiques dérivés de SDF sur le pouvoird’expression multidimensionnelle, nous identifions une limitation dansle langage en ce qui concerne l’expression des cycles dans l’applica-tion et pour la surpasser nous proposons une extension permettant laspécification de dépendances uniformes.

La section 2.1 résume les principes du langage, suivie par la présenta-tion des sémantiques du langage pour l’expression du parallélisme detâches dans la section 2.2 et de données dans la section 2.3. Les règlesde la définition statique du langage sont décrites dans la section 2.4. Lasection 2.5 s’intéresse au pouvoir d’expression du langage en comparai-son avec les autres langages de spécification. Dans la section 2.6 nousintroduisons le concept de dépendances uniformes dans la spécificationArray-OL, et nous allons finir par des conclusions dans la section 2.7.

27

28 array-ol

2.1 principes du langage

Tout d’abord, il faut faire la remarque qu’Array-OL est seulement unlangage de spécification, il n’y a pas de règles pour l’exécution d’uneapplication décrite avec Array-OL. Néanmoins, un ordonnancementpeut être facilement calculé en utilisant cette description comme il estmontré dans [14], où l’auteur présente en détail la sémantique formelled’Array-OL et la définition d’un noyau d’Array-OL permettant unordonnancement statique.

Le but initial de Array-OL est de fournir un langage mixte graphique-textuel pour modéliser des applications multidimensionnelles de traite-ment intensif de signal. Comme dit précédemment, ces applicationsmanipulent des tableaux multidimensionnels.

La complexité de ces applications n’est pas causée par les fonctionsélémentaires qu’elles combinent, mais par leur enchaînement et dela façon par laquelle l’accès aux tableaux intermédiaires est fait. Ladifficulté et la variété de ces applications de traitement intensif designal est en lien direct avec la façon dont ces fonctions élémentairesaccèdent aux entrées et aux sorties, en tant que parties des tableaux mul-tidimensionnels. Les motifs complexes d’accès mènent aux difficultésd’ordonnancement efficace sur des plateformes d’exécution parallèleset distribuées.

Étant donné que ces applications traitent des quantités énormesde données sous des contraintes de temps-réel extrêmement serrées,l’utilisation efficace du parallélisme potentiel de l’application sur lesstructures matérielles parallèles est obligatoire.Les motifs d’accès

aux tableauxmultidimensionnelsdonnent la complexitédes applications detraitement intensif designal.

De ces exigences, on peut formuler les principes de base qui sous-tendent le langage :

a. tout le parallélisme potentiel de l’application doit être disponibledans la spécification, à la fois le parallélisme de tâches et le paral-lélisme de données ;

b. Array-OL est un langage d’expression des dépendances de données.Seules les vraies dépendances de données sont spécifiées, afind’exprimer le parallélisme complet de l’application, précisant unordre partiel minimal pour les tâches. Ainsi, tout ordonnancementrespectant ces dépendances va produire le même résultat : lelangage est déterministe ;

c. il s’agit d’un formalisme d’assignation unique. Aucune donnéen’est écrite deux fois. Par contre, elle peut être lue plusieurs fois.Array-OL peut être considéré comme un langage fonctionnel dupremier ordre ;

d. les accès aux données sont faits par des sous-tableaux, appelésmotifs ;

e. le langage est hiérarchique afin de permettre des descriptionsaux différents niveaux de granularité et de gérer la complexitédes applications. Les dépendances de données exprimées à uncertain niveau (entre les tableaux) sont des approximations desdépendances précises des sous-niveaux (entre les motifs) ;

f. les dimensions spatiales et temporelles sont traitées de la mêmefaçon dans les tableaux. En particulier, le temps est expansécomme une dimension (ou plusieurs) des tableaux. C’est uneconséquence directe de l’assignation unique ;

2.1 principes du langage 29

g. les tableaux sont vus comme des tores. En effet, certaines dimen-sions spatiales peuvent représenter des tores physiques (pensezaux hydrophores autour un sous-marin). Les domaines des fré-quences obtenues suite aux transformations Fourier discrètes sontaussi toriques.

La sémantiqueArray-OL est celled’un langagefonctionnel depremier ordre quimanipule destableauxmultidimensionnels.

Array-OL n’est pas un langage de flot de données, mais peut êtreprojeté sur ce type de langage. Le langage ne manipule pas des flots,mais des tableaux des données. L’environnement ou la plateformed’exécution peut imposer un ordre et une granularité sur les élémentsdes tableaux et ainsi diriger vers des flots, mais le choix de la granularitédes calculs est laissé pour le compilateur (ou l’ingénieur système) etpas le modeleur.

Exemple. Avec la même spécification Array-OL, une vidéo représentéesous la forme d’un tableau 3D de pixels peut être traitée comme un flotd’images, un flot de lignes ou bien même un flot de pixels).

Comme hypothèse simplificatrice, le domaine d’applications qu’Array-OL couvre est restreint. Un contrôle complexe n’est exprimable et lecontrôle est indépendant des valeurs de données. C’est un choix réalistepour le domaine d’application donné, qui est principalement flot dedonnées. Des efforts de couplage des flots de contrôle et des flots dedonnées, dans le cadre d’Array-OL, ont été réalisés par Labbani et al.dans [56].

Le modèle usuel pour des spécifications basées sur des algorithmesdes dépendances est le graphe de dépendance où les nœuds représen-tent les tâches, et les arcs les dépendances. Différentes variations deces graphes ont été définies. Les graphes étendus représentent le par-allélisme de tâches disponible dans l’application. Afin de gérer desapplications complexes, une extension courante est la hiérarchie. Unnœud peut lui-même être un graphe. Array-OL s’appuie sur telsgraphes de dépendances hiérarchiques et ajoute les nœuds répétitionpour exprimer le parallélisme de données de l’application.

Formellement, une application Array-OL est une série de tâchesconnectées par des ports. Les tâches sont équivalentes à des fonctionsmathématiques qui lisent des données sur leurs ports d’entrées etécrivent des données sur leurs ports de sorties. Les tâches sont de troistypes : élémentaire, composée et répétition :

a. une tâche élémentaire est atomique (une boîte noire) et elle peutfaire partie d’une bibliothèque par exemple ;

b. une tâche composée est un graphe de dépendances dont les sous-tâches sont connectées via leurs ports ;

c. une répétition est une tâche qui exprime comment une seulesous-tâche est répétée.

Toutes les données échangées entre les tâches sont des tableaux. Cestableaux sont multidimensionnels et sont caractérisé par leur forme, lenombre d’éléments sur chacune de leurs dimensions1. Une forme va 1 Un seul point,

considéré commeun tableau0-dimensionnel a laforme (), considérécomme un tableau1-dimensionnel à laforme (1),considéré commeun tableau2-dimensionnel a laforme

(11

), etc.

être notée par un vecteur colonne ou une série de valeurs séparées pardes virgules indifféremment. Chaque port est caractérisé par la formeet le type des éléments du tableau qu’il lit ou écrit.

Comme indiqué précédemment, le modèle Array-OL est à assig-nation unique. Il manipule des valeurs et pas des variables. Le tempsest donc représenté comme une (ou plusieurs) dimension(s) dans lestableaux de données. Par exemple, un tableau qui représente une vidéo

30 array-ol

est tridimensionnel avec une forme (largeur de l’image, hauteur del’image, nombre d’images2.2 Un flot vidéo

haute-définitioninfini a une forme(1920,1080,∞).

Le reste de la présentation d’Array-OL va être illustré par une appli-cation qui met à l’échelle un signal télévision haute définition vers unsignal télévision de définition standard (application appelle « Down-scaler »). L’illustration graphique de cette application est montrée dansla Figure 10. Les deux signaux seront représentés par des tableauxtridimensionnels.

Downscaler

(1920,1080,∞) (720,480,∞)

Les tâches sont représentées par des rectangles nommés, leurs ports pardes carrées sur la frontière des tâches. Pour mieux visualiser les flots dedonnées, les ports d’entrées sont placés sur la côte gauche et les ports desortie sur la côte droite, en exprimant des flots qui vont de la gauche versla droite.

Fig. 10: Downscaler - boîte noire

Dans la spécification d’une application, une stratégie possible demodélisation est la décomposition hiérarchique de haut en bas. On vasuivre cette approche sur l’exemple du Downscaler pour mieux illustrerles concepts Array-OL. À chaque niveau de la hiérarchie, une tâchepeut être vue comme une boite noire où sa fonctionnalité peut êtreexplicitée par la décomposition en sous-tâches.

2.2 parallélisme de tâches

Le parallélisme de tâches est décrit par une tâche composée. Ladescription composée est un graphe orienté acyclique. Chaque nœudreprésente une tâche et chaque lien une dépendance entre deux portsconformes (même type et même forme). Il n’y a pas de relation entreles formes des ports d’entrée et de sortie d’une tâche ; une tâche peutpar exemple lire deux tableaux bidimensionnels et écrire un tableautridimensionnel. La création ou la suppression des dimensions par unetâche est extrêmement utile, un très simple exemple est la FFT qui créeune dimension de fréquence.

Dans l’application Downscaler de la Figure 10, la fonctionnalité peutêtre décomposée en deux filtres successifs, le premier qui réduit ladimension horizontale et le deuxième qui ensuite réduit la dimensionverticale de chaque image. Cette fonctionnalité est exprimée en utilisantla décomposition en tâche composée, illustrée dans la Figure 11. Lesdeux filtres sont des sous-tâches et la dépendance entre les deux estreprésentée par des flèches.Le graphe est un

graphe dedépendances et pasun graphe de flot dedonnées.

Chaque exécution d’une tâche lit un tableau entier sur chaque de cesports d’entrée et écrit les tableaux entiers sur les ports de sortie.

Alors, il est possible d’ordonnancer l’exécution des tâches unique-ment avec la description composée, mais il n’est pas possible d’exprimerle parallélisme de données de nos applications parce que les détails descalculs réalisés par une tâche sont cachés à ce niveau de spécification.

2.3 parallélisme de données 31

Downscaler

(1920,1080,∞)

(720,480,∞)

Filtre Horizontal(1920,1080,∞)

(720,1080,∞)

Filtre Vertical

(720,1080,∞)(720,480,∞)

Fig. 11: Downscaler - parallélisme de tâches

2.3 parallélisme de données

Une répétition data-parallèle d’une tâche est spécifiée dans une tâcherépétée. Deux hypothèses sont à la base de ces répétitions :

les répétitions d’une tâche répétée sont indépendantes .Elles peuvent être ordonnancées dans un ordre arbitraire et, plusimportant, même en parallèle3. 3 C’est pourquoi

nous parlons derépétitions et ne pasd’itérations.

motifs uniformément espacés. Chaque instance de la tâche ré-pétée travaille avec des sous-tableaux des entrées et des sortiesde la répétition. Pour une certaine entrée ou sortie, toutes lesinstances des sous-tableaux ont la même forme, sont composéesd’éléments uniformément espacés et sont uniformément placéesdans le tableau. Cette hypothèse permet une représentation com-pacte de la répétition et elle est cohérente avec le domaine d’ap-plication d’Array-OL qui décrit des algorithmes très réguliers.

Comme tous ces sous-tableaux sont conformes, ils sont appelés motifsquand considérés comme tableaux d’entrées/sorties des répétitions dela tâche répétée et tuiles quand considérés comme une série d’élémentsdes tableaux de la répétition. Pour donner toutes les informationsnécessaires à la création de ces motifs, un « tiler »4 est associé à chaque 4 En anglais, tuile se

traduit par tile ettiler veut dire leconstructeur destuiles ; dans notrecas, la constructionmathématique quipermet despécificationcompacte destuiles.

lien.Un tiler exprime comment construire les motifs à partir d’un tableau

d’entrée, ou comment ranger les motifs dans un tableau de sortie. Ildécrit le lien entre les coordonnées des éléments des tuiles et les coor-données des éléments des motifs. Il contient les informations suivantes :

– F, une matrice d’ajustage5 ;

5 Fitting en anglais.

– o, l’origine vecteur du motif de référence (pour la répétition de référence) ;– P, une matrice de pavage.La répétition de référence est la répétition avec l’indice nul.

2.3.1 Représentation visuelle d’une tâche répétée

Les formes des tableaux et des motifs sont, de la même façon quedans la description composée, notées sur les ports. L’espace de répétition,indiquant le nombre des répétitions est défini lui-même comme untableau multidimensionnel, avec une forme associée. Chaque dimensionde l’espace de répétition peut être regardée comme une boucle parallèleet la forme de cet espace de répétition donne les limites des indices dunid de boucles parallèles.

32 array-ol

Un exemple de la description visuelle d’une répétition est donnéedans la Figure 12 où on retrouve la répétition du filtre horizontal del’application Downscaler. Les tilers sont associés aux dépendances quifont le lien entre les tableaux et les motifs. Le filtre horizontal présenteun comportement idéal pour être représenté avec des tilers : le mêmecalcul élémentaire, le calcul de 3 pixels à partir d’une fenêtre de 13

pixels est répété sur chaque ligne de chaque image, avec un glissementde 8 pixels pour les motifs d’entrée et avec des motifs qui « collent » unaprès l’autre pour les motifs de sortie6. La construction de ces tilers est6 On retrouve un

algorithme defenêtre glissanteusuel pour letraitementd’images. À lasortie, l’assignationunique du langagenous oblige deproduire des motifssanschevauchement.

détaillée par la suite.

Filtre horizontal

(1920,1080,∞) (720,1080,∞)

(240,1080,∞)

HFiltre(13) (3)

F =

100

o =

000

P =

8 0 0

0 1 0

0 0 1

F =

100

o =

000

P =

3 0 0

0 1 0

0 0 1

Fig. 12: La répétition du filtre horizontal

2.3.2 Construire une tuile à partir d’un motif

A partir d’un élément de référence (réf) dans un tableau, on peut ex-traire un motif en énumérant ses autres éléments relativement à l’élé-ment de référence. La matrice d’ajustage est utilisée pour calculer lesautres éléments. Les coordonnées des éléments du motif (ei) sont con-struites comme somme des coordonnées de l’élément de référence etune combinaison linéaire des vecteurs d’ajustage, comme suit :

∀ i,0 6 i < smotif, ei = réf + F · i mod stableau, (2.1)

où smotif est la forme du motif, stableau est la forme du tableau et F lamatrice d’ajustage.

Dans les exemples suivants de matrices d’ajustage et tuiles, Figure 13

à Figure 18, les tuiles sont tirées depuis un élément de référence dansun tableau 2D. Les éléments du tableau sont marqués par leur indicedans le motif, i, en illustrant la formule ∀ i,0 6 i < smotif, ei = réf + F · i.Les vecteurs d’ajustage constituant la base de la tuile sont tirés depuisle point de référence.

Un élément clef qu’on doit retenir quand on utilise Array-OL est quetoutes les dimensions des tableaux sont toroïdales. Cela veut dire queles coordonnées des éléments des tuiles sont calculées modulo la taille


( 0 ) ( 1 ) ( 2 )

F =

(3

0

)spattern =

(3

)

On a 3 éléments dans cette tuile parce que la forme du motif est de (3). Lesindices de ces éléments sont donc (0), (1) and (2). Leur position dans latuile relativement au point de référence sont donc F · (0) =

(00

), F · (1) =(

30

), F · (2) =

(60

).

Fig. 13: Tuile éparse

(10

)(01

) (11

)(02

) (12

)(00

) F =

(1 0

0 1

)spattern =

(2

3

)

Le motif est ici bidimensionnel avec 6 éléments. La matrice d’ajustageconstruit un rectangle tuilé compact dans le tableau.

Fig. 14: Tuile rectangulaire

(10

)(01

) (11

)(02

) (12

)(00

) F =

(2 1

0 1

)spattern =

(2

3

)

Cet exemple illustre comment une tuile peut être éparse, à cause du vecteurd’ajustage

(20

), et non parallèle avec les axes, à cause du vecteur d’ajustage(

11

).

Fig. 15: Tuile complexe (éparse sur une dimension et diagonale sur l’autre)

des dimensions du tableau. Les exemples plus complexes qui suiventsont construits depuis un élément de référence fixe (o comme originedans la figure) dans des tableaux de taille fixe, en illustrant la formule∀ i,0 6 i < smotif, ei = o + F · i mod stableau.

34 array-ol

0 5

0

3

F =

(2 0

0 1

)spattern =

(3

2

)

o =

(0

0

)sarray =

(6

4

)

Cet exemple montre la construction d’un motif qui sous-échantillonnele tableau sur la dimension horizontale. Seuls les éléments des colonnesimpaires sont utilisés.

Fig. 16: Une tuile éparse, alignée sur les axes du tableau

0 5

0

3

F =

(1

1

)spattern =

(6

)o =

(2

0

)sarray =

(6

4

)

Le motif est ici monodimensionnel, la matrice d’ajustage construit une tuilediagonale qui s’enveloppe autour le tableau à cause du modulo.

Fig. 17: L’utilisation du modulo

0 5

0

5

F =

(1 0 1 −1 1

0 1 1 1 −1

)spattern =

2

2

3

2

2

o =

(1

2

)sarray =

(6

6

)

Ceci est un cas extrême d’un motif cinq dimensionnel, ajusté comme unetuile deux dimensionnelle. La plupart des éléments de la tuile sont lusplusieurs fois pour construire le motif de 48 éléments.

Fig. 18: Tuile au motif élargi

2.3.3 Paver un tableau avec des tuiles

Pour chaque répétition, on a besoin de désigner les éléments deréférence des motifs d’entrée et de sortie. Un chemin similaire à celuiqu’on a utilisé pour énumérer les éléments d’un motif est employé.

L’élément de la répétition de référence est donné par le vecteurd’origine, o, pour chaque tiler. Les éléments de référence des autresrépétitions sont construits relativement à celui-ci. Comme auparavant,leurs coordonnées sont construites par une combinaison linéaire desvecteurs de la matrice de pavage, comme suit

∀ r,0 6 r < srépétition, réfr = o + P · r mod stableau, (2.2)


où srépétition est la forme de l’espace de répétition, P la matrice depavage, et stableau la forme du tableau.

Quelques exemples sont présentés par la suite, de la Figure 19 à laFigure 2.3.3.

0 90

3

r = ( 0 ) 0 90

3

r = ( 1 ) 0 90

3

r = ( 2 ) 0 90

3

r = ( 3 )

F =

(1

0

)spattern =

(10

)o =

(0

0

)sarray =

(10

4

)P =

(0

1

)srepetition =

(4

)Cette figure représente les tuiles pour toutes les répétitions de l’espace derépétition indexée par r. Les vecteurs de pavage tracés depuis l’origine oindiquent comment les coordonnées de l’élément de référence réfr de latuile courante est calculée. Ici le tableau est tuilé ligne par ligne.

Fig. 19: Pavage par ligne

0 80

7

r =(

00

) 0 80

7

r =(

10

) 0 80

7

r =(

20

)

0 80

7

r =(

01

) 0 80

7

r =(

11

) 0 80

7

r =(

21

)F =

(1 0

0 1

)spattern =

(3

4

)

o =

(0

0

)sarray =

(9

8

)

P =

(3 0

0 4

)srepetition =

(3

2

)

Fig. 20: Un motif 2D qui pave exactement un tableau 2D

0 90

4

r =(

00

) 0 90

4

r =(

10

) 0 90

4

r =(

20

)

0 90

4

r =(

01

) 0 90

4

r =(

11

) 0 90

4

r =(

21

)

0 90

4

r =(

02

) 0 90

4

r =(

12

) 0 90

4

r =(

22

) F =

(1 0

0 1

)spattern =

(5

3

)

o =

(0

0

)sarray =

(10

5

)

P =

(0 3

1 0

)srepetition =

(3

3

)

Fig. 21: Les tuiles peuvent se chevaucher et le tableau est toroïdal

2.3.4 Résumé

On peut faire le sommaire de ces explications avec une seule formule.Pour un indice de répétition donné r,0 6 r < srépétition et un indice du

36 array-ol

motif i,0 6 i < smotif, l’élément qui correspond dans le tableau a lescoordonnées

o + (P F) ·

(r

i

)mod stableau, (2.3)

où stableau est la forme du tableau, smotif est la forme du motif, srépétitionest la forme de l’espace de répétition, o contient les coordonnées del’élément de référence du motif de référence, appelé aussi origine, Pest la matrice de pavage dont les vecteurs colonne, appelés vecteursde pavage, représentent l’espacement uniforme entre les motifs, F estla matrice d’ajustage dont les vecteurs colonne, appelés vecteurs d’a-justage, représentent l’espacement uniforme entre les éléments d’unmotif dans le tableau.

Des contraintes sur les dimensions des vecteurs et des matricespeuvent être tirés de leur utilisation :

– l’origine, la matrice d’ajustage et celle de pavage ont le mêmenombre de lignes, égal au nombre de dimensions du tableau ;

– la matrice d’ajustage a un nombre de colonnes égal au nombre dedimensions du motif7 ;7 Ainsi, si le motif

est un élément seulvu comme untableau0-dimensionnel, lamatrice d’ajustageest vide et notéepar (). Le seulélément d’une tuileest donc sonélément deréférence. On peutregarder celacomme un casdégénéré del’equationd’ajustage, oùl’index i n’existepas et ainsi pas demultiplication F · i.

– la matrice de pavage a un nombre de colonnes égal au nombre dedimensions de l’espace de répétition.

2.3.5 Faire le lien entre les entrées et les sorties via l’espace de répétition

Les formules précédentes décrivent quels éléments d’un tableaud’entrée ou de sortie sont consommés ou produits par une répétition.Le lien entre les entrées et les sorties est fait par l’indice de répétition,r. Pour une répétition donnée, les motifs de sorties (de l’indice r) sontproduits par la tâche répétée depuis les motifs d’entrées (de l’indice r).Les éléments de ces motifs correspondent aux éléments des tableaux viales tuiles associées à ces motifs. Ainsi, l’ensemble des tilers et les formesdes motifs et de l’espace de répétition définissent les dépendancesentre les éléments des tableaux de sortie et les tableaux d’entrée d’unerépétition. Comme indiqué précédemment, aucun ordre d’exécutionn’est défini implicitement par ces dépendances entre les répétitions.

Pour illustrer ce lien entre les entrées et les sorties, la Figure 22

présente plusieurs répétitions du filtre horizontal de l’application Down-scaler. Pour simplifier la figure et vu que le traitement se fait imagepar image, seules les deux premières dimensions des tableaux sontreprésentées8. Les tailles des tableaux ont été réduites aussi par un8 Effectivement, la

troisièmedimension destableaux d’entrée etde sortie est infinie,la troisièmedimension del’espace derépétition est aussiinfinie, les tuiles necroisent pas cettedimension et le seulvecteur de pavageayant un troisièmeélément non nul est(001

)le long de la

dimension infiniede l’espace derépétition.

facteur de 60 sur chaque dimension pour raisons de lisibilité.

2.3.6 Exemples d’accès uniformes

Le formalisme d’Array-OL permet la spécification d’un éventail vastedes motifs d’accès, qui peut varier de simples motifs tuilés par blocsà des accès complexes où des tuiles non parallèles avec les axes sontassociées avec des pas et du modulo. Pourtant, dans les applicationsde traitement intensif de signal, la grande majorité des accès restentparallèles avec les axes ou utilisant des fenêtres glissantes.

Les constructions les plus usuelles sont :

accès parallèle avec les axes. Avec ce type de construction,les vecteurs des matrices de pavage et d’ajustage sont tous par-


0 310

17

r =(

00

)

F =

(1

0

)spattern =

(13

)o =

(0

0

)sarray =

(32

18

)

P =

(8 0

0 1

)srepetition =

(4

18

)

HFiltre

0 110

17

r =(

00

)

F =

(1

0

)spattern =

(3

)o =

(0

0

)sarray =

(12

18

)

P =

(3 0

0 1

)srepetition =

(4

18

)

0 310

17

r =(

10

)

HFiltre

0 110

17

r =(

10

)

0 310

17

r =(

25

)

HFiltre

0 110

17

r =(

25

)

Fig. 22: L’enchaînement des entrées et des sorties de filtre horizontal

allèles avec les dimensions du tableau. Chaque vecteur contientau plus une valeur non-nulle et l’index de cette valeur fait lacorrespondance entre la dimension du motif ou de la répétitionassociée au vecteur et la dimension du tableau ;

pavage par blocs . Des motifs rectangulaires et tuilés parfaitementsont accédés. Le matrices de pavage et d’ajustage expriment desconstructions parallèles avec les axes où les motifs sont de blocscontinus du tableau, (chaque vecteur d’ajustage contient une seulevaleur égale à 19) et les blocs sont parfaitement tuilés un après 9 Une matrice

pseudo-identité, surchaque ligne oucolonne on peutretrouver au plusune valeur de 1,sans que la matricesoit obligatoirementcarrée.

l’autre dans le tableau (les vecteurs de pavage ont des valeursnon-nulles égales avec la dimension du motif avec laquelle levecteur partage la dimension du tableau) ;Exemple.

Un tableau avec une forme de (80, 50)

peut être tuilé en (10, 5) blocs de taille(10, 8), en utilisant une matrice d’ajustagede

(0 11 0

)et une matrice de pavage de(

8 00 10

), comme illustrée sur la figure à

droite.

38 array-ol

dimensions entièrement pavées . Un cas spécial d’accès par blocoù certaines dimensions des motifs correspondent aux dimensionsentières du tableau.Exemple.

Le même tableau avec une forme de(80, 50), tuilé en (10) blocs de taille (50, 8),en utilisant une matrice d’ajustage de(0 11 0

)et une matrice de pavage de

(80

).

fenêtre glissante. Cela représente des accès par bloc où les blocsne tuilent pas parfaitement certaines dimensions du tableau, avecdes blocs qui se chevauchent et qui provoquent certains élémentsdu tableau de faire partie de multiples motifs. Sur les dimensionsdu glissement, les vecteurs de pavage ont des valeurs non-nullesinférieures aux dimensions correspondantes du motif, des valeursqui représentent les pas de la fenêtre sur cette dimension.Exemple.

En laissant inchangées les matrices dupavage et d’ajustage de l’exemple par bloc,et par l’élargissement du motif à un blocde taille (10, 12), on se retrouve avec unaccès en fenêtre glissante sur la premièredimension du tableau, avec un pas de 8.

2.4 définition statique

Dans les sections précédentes nous avons donné les constructionsdes relations de dépendance entre les éléments des tableaux pour lestrois catégories de tâches : élémentaire, composée ou répétition. Enutilisant la décomposition hiérarchique, par induction, la relation dedépendance peut être dérivée entre tous les appels des tâches élémen-taires. Seules les tâches élémentaires peuvent avoir associées de calcul,donc seules ces tâches seront exécutes. La description Array-OL estutilisé pour exprimer les accès aux données et en même temps lesdépendances de données, donc les dépendances d’exécution entre lestâches élémentaires.

Chaque tâche élémentaire sera exécutée en concordance avec unespace de répétition total donné par la concaténation des espaces derépétition trouvés en parcourant tous les niveaux de hiérarchie à partirdu niveau le plus haut jusqu’au niveau de la tâche élémentaire.

Exemple. La Figure 2.4 montre le calcul de cet espace sur un exemple,toujours l’application Downscaler où la tâche HFiltre peut être encoredécomposée dans une sous-tâche répétée, qui calcule chaque pixel desortie comme une moyenne à partir de plusieurs pixels d’entrée10.10 Sur la figure

seules lesrépétitions sontmontrées.

Les spécifications suivant la définition Array-OL ne sont pas toutes valides.Certaines ne peuvent même pas respecter l’hypothèse de base de l’assig-nation unique. D’autres peuvent définir des cycles dans les relationsde dépendance et ainsi peuvent provoquer des blocages. Des règlesfaciles et vérifiables statiquement pour assurer qu’une application estordonnançable statiquement sont définies dans [14]. Nous rappelleronsces règles par la suite.

2.4 définition statique 39

Downscaler

Filtre Horizontal

Filtre Vertical

(240,1080,∞)

HFiltre(3)

Moyenne

La tâche élémentaire Moyenne a un espace de répétition total de(240,1080,∞, 3) obtenu par la concaténation des tous les espaces derépétition en descendant la hiérarchie jusqu’au niveau de la tâche élé-mentaire. Cet espace de répétition donne un nombre d’exécutions de240× 1080× 3 = 777600 fois de la tâche pour chaque image.

Fig. 23: La répétition totale d’une tâche élémentaire

condition de la définition statique

Une application Array-OL est définie statiquement et ainsi ordon-nançable statiquement si la relation de dépendance entre les appelsdes tâches élémentaires est un ordre partiel strict. Effectivement, unquelconque ordonnancement qui respecte cet ordre partiel calcule lesmêmes valeurs de sortie en utilisant les mêmes entrées.

Les règles proposées sur le langage pour assurer la définition statiquesont :

a. les tailles de tous les tableaux sont des valeurs connues, et pasdes paramètres ;

b. les tableaux de sortie d’une tâche sont toujours produits com-plètement si les tableaux d’entrée sont définis complètement ;

c. les cycles ne sont pas permis dans le graphe d’une tâche com-posée.

Le langage qui respecte ces règles est appelé Array-OL statique. Pourchaque type de tâches, on peut démontrer par induction que ces règlesgarantissent l’existence d’un ordre partiel strict (démontré par Bouletdans [14]) :

tâches élémentaires . Ces tâches produisent entièrement les tab-leaux de sortie à partir des entrées et comme la tâche élémentaireest la seule à s’exécuter dans ce contexte, la relation de dépen-dance est évidemment un ordre partiel strict.

tâches composées . Dans une tâche composée, le graphe des sous-tâches ne permet pas de cycles et ainsi est un graphe acycliqueorienté, donc il définit un ordre partiel strict entre ces nœuds.

tâches répétées . Pour les répétitions, il faut vérifier que tous lestableaux sont produits entièrement. Puisque la répétition est par-allèle, on n’a pas de dépendances entre des appels différentsde la tâche répétée. Une conséquence directe de la règle de laproduction entière des tableaux est qu’une répétition doit obliga-toirement paver exactement les tableaux de sortie. Vérifier cettecondition peut se faire facilement en utilisant des outils de calcul

40 array-ol

polyédrique, tel que SPPoC11 [16]. La méthodologie de vérification11 http://www.lifl.

fr/west/sppoc/ en utilisant le calcul polyédrique est décrite en détail dans [14].Il faut observer que la règle de la production entière et uniquedes éléments est liée directement à l’assignation unique et quela spécification d’une répétition qui ne respecte pas cette règlen’est pas sémantiquement valide et dans ce cas on peut utiliserles méthodes polyédriques pour vérifier que la spécification estcorrecte.Avec Array-OL, la

spécification desrépétitions est la pluscompliquée à faire etdes outils peuventaider le modeleur àvisualiser ou vérifiersa validité.

Les règles pour garantir la définition statique ne sont que des règlespour assurer que la spécification corresponde aux principes d’Array-OL, comme l’assignation unique et la production intégrale des tableauxde sortie. L’interdiction de cycles dans le graphe des tâches pose desrestrictions dans l’ensemble d’applications qu’on peut exprimer avecArray-OL, mais se sont des restrictions qui correspondent au domained’applications envisagé par Array-OL, le traitement intensif de signalavec des sémantiques orientées flot de données.

Nous avons présenté le langage Array-OL dédié à la spécificationdes applications de traitement intensif de signal. Il permet la modéli-sation du parallélisme complet disponible dans l’application par desdécompositions data-parallèles et, à un haut niveau d’abstraction, desmécanismes d’expression des accès uniformes aux sous-tableaux. Lelangage est d’assignation unique et manipule des tableaux multidi-mensionnels, en se concentrant sur l’expression compacte des accèsmultidimensionnels.

2.5 pouvoir d’expression

Essayons maintenant de faire une comparaison entre Array-OL etles autres modèles de calcul présentés. On s’intéresse surtout auxlangages avec lesquels Array-OL partage des caractéristiques. Commeon l’a déjà dit, la sémantique Array-OL est celle d’un langage fonctionnelde premier ordre qui manipule des tableaux multidimensionnels, statiquementordonnançable. On s’intéresse surtout à l’aspect multidimensionnel et aupouvoir d’expression.

2.5.1 Positionnement

Des différentes approches pour la spécification des applications detraitement intensif de signal ont été proposées au fil des années. Nousavons présenté dans les sections précédentes les principes d’une partiedes langages existants, correspondant aux différentes approches.

De dire que certaines propositions de langages sont meilleures quedes autres risque d’être très subjective. Ce qu’on peut affirmer est quechaque approche a ces avantages et désavantages et des langages sontplus expressifs que des autres, mais la simplicité peut être vue aussicomme un avantage.

Une modélisation représente une abstraction de la réalité et essaye decapter certaines caractéristiques essentielles qui peuvent être exploitéespar la suite. Dans le contexte des applications de traitement intensifde signal, une caractéristique que nous considérons essentielle estl’uniformité des accès aux structures de données multidimensionnelles.

Quand on parle d’optimisations de code, l’objectif est d’exécuter plusvite en consommant moins de ressources (taille, mémoire, énergie, etc.).

http://www.lifl.fr/west/sppoc/

http://www.lifl.fr/west/sppoc/

2.5 pouvoir d’expression 41

La plupart des techniques d’optimisation source à-source travaillent au-tour les boucles qui représentent la partie principale des calculs (mêmepour des applications qui ne sont pas nécessairement orientées traite-ment intensif) et où l’aspect répétitif de l’exécution offre des possibilitésd’optimisations complexes, un domaine de recherche considérablementexploré par les techniques d’optimisation basées sur de transformationsde boucles.

Dans le cas des applications de traitement intensif de signal, l’aspectrégulier des calculs est encore plus pertinent et cela facilite davantageles techniques d’optimisation. Ces techniques d’optimisation sont trèscomplexes et elles montrent plus d’efficacité dans le cas du code bienstructuré12. 12 Exemple : de nids

de boucles parfaits.Le langage Array-OL a été conçu pour la modélisation visuelle del’aspect régulier des calculs dans les applications de traitement intensifde signal, par une représentation visuelle de boucles data-parallèles.Array-OL exprime uniquement les vraies dépendances de donnéesdans une vision orientée flot de données.

Array-OL utilise un formalisme visuel13 qui correspond mieux au 13 Array-OL nepermet pas l’accèsdirect aux variables(tableaux), indices,etc.

concept de modélisation de haut niveau. Les valeurs des formes mul-tidimensionnelles et des accès uniformes par des tilers sont spécifiéessous une forme textuelle, mais expriment la représentation formelle desespaces multidimensionnels et de vecteurs dans ces espaces, qui pourplus de trois dimensions rendent délicate une représentation purementvisuelle.

Évidement, une spécification visuelle est moins expressive que l’-expression textuelle qui est beaucoup plus flexible. Le langage Alphapartage beaucoup de caractéristiques avec Array-OL en utilisant unlangage formel textuel et des polyèdres comme structures de don-nées. Nous allons faire une comparaison plus détaillée entre les deuxformalismes dans la sous-section 2.5.5.

Pour Array-OL, l’aspect statique est très important ; une définitionstatique permet le calcul d’un ordonnancement statique et de simplifierles mécanismes d’exécution. Les règles définis sur le langage pourgarantir la définition statique contraint la spécification en Array-OLà un noyau statique où toutes les valeurs des tailles des tableauxsont connues numériquement. Sur ce noyau statique, des extensionsdynamiques peuvent être définies : paramètres, contrôle, etc.

Les caractéristiques du langage Array-OL le reprochent plus auxlangages de flot de données synchrones (Syncronous DataFlow et sesextensions) et par la suite nous allons faire une comparaison plusdétaillée entre les deux approches, en regardant surtout l’aspect multi-dimensionnel et le pouvoir d’expression des accès uniformes.

2.5.2 De vrais tableaux multidimensionnels

Nous avons noté auparavant que, pour exprimer des applicationsmultidimensionnelles, il est impératif de pouvoir manipuler des tableauxmultidimensionnels ou des flots de données multidimensionnels dansle cas d’applications orientées flot de données. Il est important de bien Des constructions de

base, comme l’accèspar blocs, ne sont pasréalisables sur ces« faux » tableauxmultidimensionnels.

faire la différence entre des flots de données monodimensionnels avecdes éléments qui peuvent être des tableaux multidimensionnels et des« vrais » flots de données multidimensionnels. C’est le cas des modèlescomme SDF et StreamIt. Malgré le fait qu’un tableau monodimension-nel avec des tableaux bidimensionnels comme éléments, par exemple,

42 array-ol

peut être vu comme un tableau tridimensionnel, dans le cadre de l’ap-proche flot de données, la multidimensionnalité de ce tableau ne peutpas être utilisée en totalité ; les motifs d’accès doivent contenir deséléments entiers, donc les tableaux qui représentent les éléments sontobligatoirement traités comme des entités indivisibles.

2.5.3 Comparaison entre Array-OL et GMDSDF

Les langages dérivés de SDF et Array-OL sont très similaires et, bienqu’ils soient différents dans leur forme, ils partagent un certain nombrede principes, comme :

– les structures de données devront avoir les dimensions multiplesvisibles ;

– un ordonnancement statique devrait être possible avec des ressourceslimitées ;

– le domaine d’applications est le même : les applications de traite-ment intensif de signal.

Une comparaison détaillant des modélisations avec Array-OL etGMDSDF est disponible dans [33]. Cette comparaison s’intéresse surtoutà l’aspect motifs non-parallèles avec les axes et des conclusions intéres-santes ont été pu tirées :

les informations à donner . Le nombre d’informations à don-ner est plus grand pour Array-OL ; tous les tilers doivent êtrecomplétés, mais la difficulté de calcul des données n’est pastrès élevée. En revanche en GMDSDF, même si le nombre d’in-formations est plus réduit, le concepteur doit être capable decomprendre le calcul de l’ordonnancement et de le vérifier ; lescalculs à faire peuvent être vraiment difficiles.

construction des motifs. La désignation des points à consom-mer ou à produire ne se fait pas de la même façon dans nosdeux modèles. L’utilisation des matrices support pour GMDSDFpermet de désigner des ensembles de points de forme plus ir-régulière qu’en Array-OL, même des motifs qui ne sont pas desparallélépipèdes. Nous ne sommes pas sûr que la désignationde tels ensembles de points représente un avantage quelconquepour GMDSDF. En effet, il est tout à fait possible de prendre uneboîte englobante pour effectuer la modélisation en Array-OL etsurtout il ne nous est jamais arrivé de rencontrer des tâches ayantbesoin d’une manipulation de données semblable. De plus enArray-OL, contrairement à GMDSDF il est possible de désignerdes ensembles disjoints de points.

tableaux toriques. Il s’agit d’une possibilité réellement intéres-sante, par exemple des applications où une des dimensionstoriques représente les sonars se trouvant autour d’un sous-marinet où une autre représente une dimension fréquentielle. L’aspecttorique est une prémisse de base d’Array-OL, différemment detous les langages basés sur SDF.

garder des informations d’état. GMDSDF permet d’utiliser les« états » et les « délais » ce qui n’était pas le cas d’Array-OL14.14 Problème résolu

avec l’extensiond’Array-OL avecdes dépendancesuniformes proposéedans cette thèse etprésentées ensection 2.6.

Pourtant ils sont indispensables à l’établissement de calculs sim-ples comme la somme de vecteurs.

nombre de dimensions. La différence la plus notable entre GMD-SDF et Array-OL est sans doute que certaines des démonstrations


servant de support aux principes de GMDSDF ne sont validesque pour des applications ayant au plus deux dimensions. Array-OL fonctionne avec des applications multidimensionnelles sansaucune restriction sur le nombre maximum de ces dimensions.MDSDF, lui, n’est pas limité du point de vue des dimensions,en revanche il ne permet qu’une manipulation rudimentaire desdonnées.

Nous avons vu que le modèle GMDSDF a certains avantages encomparaison avec Array-OL, mais surtout des désavantages causéspar la complexité des calculs pour des applications avec plus de deuxdimensions.

2.5.4 Désavantages de l’approche flots de donnés synchrones

En regardant les langages de la famille flot de données synchrone, onpeut observer que, en partant de SDF, des fonctionnalités ont été ajoutépour étendre de plus en plus le langage.

En suivant l’évolution SDF, MDSDF, GMDSDF, WSDF, on voit bienl’introduction successive des concepts pour pouvoir exprimer la multi-dimensionnalité, les motifs non-parallèles avec les axes et ensuite lesfenêtres glissantes. Toutes ces extensions sont faites de telle manièrequ’elles restent compatibles avec le modèle antérieur. Rendre toutesces extensions compatibles permet la coexistence des acteurs décritsen différents langages dans la même application. Néanmoins, nousconsidérons que ce choix a aussi des effets négatifs sur le pouvoird’expression, comme on va voir par la suite.

Nous allons nous limiter aux motifs parallèles avec les axes et on vavoir que même MDSDF, qui devrait être capable d’exprimer ces accès,peut avoir des difficultés, causées par le fait d’avoir gardé des principesde SDF qui ne sont parfaitement adaptées aux flots multidimensionnels,à notre avis.

Flot de motifs, et non pas des motifs tuilés dans des tableaux

Dans l’approche flots monodimensionnels de SDF, l’utilisation desfifos pour les motifs d’entrées et de sortie est évidente. Le flot dedonnées a la forme d’un flot infini de motifs. En passant à un modèlemultidimensionnel, dans MDSDF, ces principes ont été gardés, enutilisant des structures fifos multidimensionnelles infinies sur chaquedimension. Pour rester fidèles aux principes SDF et pour simplifier lecalcul de l’ordonnancement statique, chaque dimension est vue commeun flot monodimensionnel équivalent à la représentation SDF.

Plusieurs inconvénients viennent de ces choix, visibles sur un exem-ple d’une multiplication des deux matrices, repris de [69] et montré surla Figure 24 :

dimensions bornées. Les flots de données n’ont pas de dimensionsbornées, donc toutes les dimensions des tableaux peuvent êtreinfinies. La définition des tableaux bornés peut être simulée parl’introduction des acteurs qui produisent ces tableaux entièrement,comme dans l’exemple de la Figure 24. Cela peut contraindreà garder les deux matrices en mémoire, contrairement à unefonctionnalité de type pipeline, où seules des motifs des matricessont placés dans la mémoire.

44 array-ol

B

(M,N

)

T(3,1, 2)

(M,N,1)

(1,M,N

)

(1,1,1)

(L,1, 1)

A

(L,M

)

(1,1,1)

(1,1,N

)

Downsample

(1,M,1)

(1,1,1)

T(1,3, 2)

(L,1,N

)

(L,N,1)

(0,1, 0)

T Transposition

Répétition

Sous-échantillonage

Multiplication

Addition

Délai

Les deux matrices opérandes sont projetés dans l’espace 3D des indices, enutilisant des acteurs clés de transposition, répétition ou sous-échantillonnage.Les opérations de multiplication et d’addition se font élément par élément.L’ensemble addition et délai représente une construction d’état, nécessairepour décrire l’opération de somme d’un tableau.

Fig. 24: Multiplication des matrices en MDSDF

mixer la dimensionnalité. Le changement du nombre des di-mensions dans une application se fait difficilement et seulementà l’aide des acteurs clés ; sur la Figure 24, l’acteur Répétition varépéter des éléments sur une dimension ou l’acteur Transpositionqui va interchanger des dimensions entre elles, etc. D’après nosconnaissances, des constructions habituelles comme la linéarisa-tion des dimensions ne sont pas exprimables en MDSDF.

consommation multiple. En préférant l’approche flots des motifsaux motifs pavés dans des tableaux, les langages flot de donnéessynchrone interdisent les consommations multiples de données.Ce n’est pas la consommation d’un flot par plusieurs acteurs, quiest possible en utilisant des nœuds de branchement, fork, mais desconsommations des mêmes éléments par plusieurs invocationsd’un acteur, le cas des fenêtres glissantes discutées dans la sectionsuivante.

La Figure 25 illustre la modélisation de la même application de mul-tiplication des matrices en Array-OL. En regardant cette modélisation,on peut retrouver facilement les tailles des tableaux et des motifs, ainsique les espaces de répétitions. C’est la première étape dans la modéli-sation Array-OL, avec la construction des graphes de dépendances.Des outils visuels

pour aider dans lamodélisation sontdisponibles à http:

//www.lifl.fr/

west/aoltools/.

L’étape de la spécification des répétitions, qui implique la saisie destilers, est la plus compliquée pour le concepteur, mais a l’avantagequ’avec les concepts de tiler on peut modéliser la plupart des con-structions des motifs uniformément espacés : pavage par bloc, fenêtresglissantes, accès cyclique, motifs non-parallèles avec les axes, etc. Une

http://www.lifl.fr/west/aoltools/




Multiplication matrices

B(M,N)

A(L,M)

C(L,N)

(L,N)

Mult Ligne/Colonne

(M)

(M)

(1)

F =

(1

0

)

o =

(0

0

)

P =

(0 0

0 1

)

F =

(0

1

)

o =

(0

0

)

P =

(1 0

0 0

)

F =()

o =

(0

0

)

P =

(1 0

0 1

)

Ligne * Colonne

(M)

(M)

(M)

(M)

*

(1)

(1)

(1)

F =()

o =(0

)P =

(1

)

F =()

o =(0

)P =

(1

)

F =()

o =(0

)P =

(1

)

Somme

(M) (1)

Fig. 25: Multiplication de matrices en Array-OL

fois le concept de tiler maîtrisé, la modélisation en Array-OL devientfacile.

La multiplication des matrices en Array-OL, la Figure 25, montreaussi les limites du modèle Array-OL : on ne peut pas exprimer desconstructions d’état nécessaires pour modéliser sous la forme répétitivele calcul de la somme d’un tableau. En modélisant cette opérationcomme une tâche élémentaire on perd le parallélisme disponible et celapeut influencer la qualité de la modélisation.

Accès en fenêtre glissante

Nous avons vu dans l’étude des langages orientés flot de donnéesque l’approche prédominante est évolutive ; à partir d’un langage ex-istant, des fonctionnalités additionnelles sont ajoutées en utilisant desnouveaux concepts, en restant toujours compatible avec le langage d’o-rigine. Le modèle WSDF est l’illustration parfaite de cette approche.Dans la Figure 9, sous-section 1.6.4, nous avons montré une applica-tion contenant des accès de type fenêtre glissante modélisés avec WSDF.Plusieurs concept nouveaux ont été ajouté dans le but de modéliserspécialement ces algorithmes. On voit bien que ces concepts alourdis-sent beaucoup la modélisation et en plus ils servent uniquement à lamodélisation des fenêtres glissantes. La Figure 26 montre la mêmeapplication modélisée avec Array-OL.

Le modèle Array-OL est capable d’exprimer facilement des algo-rithmes de fenêtre glissantes ; ces algorithmes sont traités comme toutautre accès multidimensionnel. Il faut remarquer que la Figure 26 ex-prime exactement les mêmes accès que celles de la Figure 9, même si la

46 array-ol

A1

(2048,1024,∞)

(2048,1024,∞)

A2

(2048,1024,∞)

(4096,512,∞)

(128,256,∞)

a2

(8,4)(16,2)

F =

1 0

0 1

0 0

o =

000

P =

8 0 0

0 4 0

0 0 1

F =

1 0

0 1

0 0

o =

000

P =

16 0 0

0 2 0

0 0 1

A3

(2048,1024,∞)

(4096,512,∞)(4088,1016,∞)

(2044,2, 508,2,∞)

a3(5,6)

(5,3) (1)

F =

1 0

0 1

0 0

o =

000

P =

1 0 0 0 0

0 0 2 0 0

0 1 0 2 4

F =

1 0

0 1

0 0

o =

000

P =

2 1 0 0 0

0 0 1 0 0

0 0 0 1 2

F =()

o =

000

P =

2 1 0 0 0

0 0 2 1 0

0 0 0 0 1

A4

(4088,1016,∞)

(4088,1016,∞)

a4(3,3)

F =

1 0

0 1

0 0

o =

−1

−1

0

P =

1 0 0

0 1 0

0 0 1

Le tableau de sortie de la tâche A3 a une taille plus petite que dans la modélisation en WSDF ;en Array-OL on ne dispose pas d’un concept pour exprimer que plusieurs images sont traité encontinue par l’accès en fenêtre glissante. La vision Array-OL est que si plusieurs images sont traité encontinue, la modélisation doit la refléter. En mettant l’origine a (−1,−1,0), le dépassement desfrontières se fait aussi sur la première ligne et la première colonne, pour avoir une modélisationconforme au modèle en WSDF.

Fig. 26: Fenêtres glissantes en Array-OL

nécessité d’avoir des jetons virtuels et des unions des jetons virtuels noussemble inadéquate15.15 C’est pourquoi

sur la Figure 26 onarrive à avoir unerépétition à 5

dimensions pourdes tableaux3-dimensionnels.

Observation. Pour exprimer que, dans un flot d’images, quatre imagessuccessives sont traitées comme une seule image, en Array-OL, ontransforme la forme du flot dans un autre flot ou l’image est quatre foisplus grande et contient les quatre images successives.

La motivation pour ce choix est de pouvoir exprimer des accèscontinus entre des images successives. En Array-OL, pour exprimerdes accès similaires, la solution est de transformer la forme des tableaux,


en utilisant la construction de Reshape, présenté ultérieurement dans lasection 3.4.

le traitement des frontières . L’expression du traitement desfrontières a été ajouté en WSDF. La question qui se posé est la suivante :que se passe-t-il quand les fenêtres d’accès sont à la frontière destableaux ? Il y a plusieurs possibilités :

1. l’accès ne doit pas dépasser les frontières, cas où l’image de sortieaura une taille réduite en comparaison avec celle d’entrée ;

2. l’accès dépasse les frontières, en utilisant une approche cyclique ;

3. les frontières peuvent être entendues avec des éléments par défaut.

Le premier cas est l’approche habituelle, le désavantage étant laréduction des taille des tableaux. Le troisième cas a été choisi commesolution en WSDF, l’accès cyclique n’étant pas conforme à l’approcheflot de données. En Array-OL, l’accès cyclique est une prémisse de basedu langage et donc cette approche est naturelle. Pour pouvoir exprimerdes extensions des frontières on peux faire appel a un concept nouveau,le lien par default, utilisé pour exprimer des dépendances uniformes enArray-OL, présenté par la suite dans le section 2.6.

Dans la modélisation des algorithmes avec des accès en fenêtre glis-sante, Array-OL est capable d’exprimer ces constructions sans grandsefforts. Le modèle WSDF est conçu exclusivement pour la spécificationsde ces algorithmes et dispose de concepts spécialisés pour chaque car-actéristique nécessaire. Même avec tous les nouveaux concepts ajoutées, Une modélisation

plus fidèle àl’application décriteen WSDF, enutilisant certainsconcepts additionnelsintroduits par la suiteen Array-OL, estdisponible dansAppendice A.

WSDF ne peut toujours pas modéliser des accès cycliques. Array-OLne peut pas exprimer des accès en continu sur des éléments qui nesont pas sur la même dimension, mais dispose de mécanismes de « re-structuration » des tableaux, par le changement de leurs formes enutilisant le concept de Reshape, présenté dans la section 3.4. L’extensiondes frontières est aussi possible en utilisant le concept de lien par défaut.

2.5.5 Array-OL et Alpha

Le langage Alpha, présenté dans la sous-section 1.4.1, partage depropriétés importantes avec Array-OL : les deux sont des langagesfonctionnels orientés flot de données et les deux langages exprimentles dépendances de données dans une application en utilisant un for-malisme d’assignation unique.

Mais, en utilisant un formalisme textuel et une représentation des al-gorithmes sous forme d’équations récurrentes, le langage Alpha permetla spécification des applications plus complexes, là où le formalisme vi-suel d’Array-OL permet l’expression des accès uniformes qui peuventêtre décrits avec le concept de tiler : les coordonnées des éléments desmotifs dans le tableau sont des combinaisons linéaires des indices desrépétitions et des coordonnées des éléments dans les motifs.

Les structures de données manipulées sont différentes, des tableauxmultidimensionnels cycliques pour Array-OL et des polyèdres pourAlpha. Une structure polyédrique est plus générale que des tableauxmultidimensionnels où des espaces avec des formes plus complexesne sont pas exprimables16. La restriction est toujours causée par le 16 Exemple : Un

espace triangulaire.formalisme visuel qui ne permet pas l’utilisation des variables oul’identification directe des dimensions des tableaux.

48 array-ol

Observation. Le noyau statique Array-OL ne permet pas de définir desstructures de données qui ne sont pas rectangulaires. Cela n’exclut pasl’introduction des extensions : une possibilité que nous avons enquêtéest le paramétrage des dimensions des tableaux et la spécification descontraintes entre ces dimensions. Pratiquement, cela se traduit par unereprésentation polyédrique composée d’un espace multidimensionnelcontraint par d’hyperplans.

Néanmoins, nous considérons que l’utilisation des tableaux multidi-mensionnels correspond largement au domaine d’applications qu’Array-OL cible :

– la plupart des structures de données sont des tableaux multidi-mensionnels ou ils peuvent être englobés dans une forme multidi-mensionnelle ;

– en Array-OL, même si les tableaux et les motifs ont une formerectangulaire, les placements des motifs dans les tableaux (ce quenous appelons tuiles) peuvent prendre des formes complexes nonrectangulaires ;

– les structures de données multidimensionnelles qu’Array-OL utiliseau niveau spécification peuvent être traduites directement dansdes structures de données équivalentes dans le code généré ;

– l’aspect cyclique natif en Array-OL n’est pas géré par Alpha.Même si les deux langages (Array-OL et Alpha) partagent des

principes en commun, le choix visuel/textuel de la spécification apportedes différences importantes dans l’expressivité et la forme. Un langagetextuel est plus flexible en termes d’expressivité de ses constructions,mais n’apporte pas l’aspect visuel lié au concept de modélisation dehaut niveau.

Nous avons vu dans la comparaison avec les langages de spécifica-tion synchrones que la décomposition répétitive d’Array-OL permetl’expression des accès par motifs uniformes usuels, mais pose des prob-lèmes dans l’expression des cycles dans la spécification, nécessairespour exprimer de structures d’état. Pour surmonter cette limitation,nous proposons une extension du langage qui permet l’expression desdépendances uniformes entre les répétitions data-parallèles.

2.6 modélisation des dépendances uniformes

Afin d’exprimer les informations nécessaires pour une spécificationcomplète des algorithmes orientés flot de données, les langages commeArray-OL se basent sur des formalismes spéciaux. Un des aspectsrencontrés couramment dans ces langages est l’approche orientée com-posants dans laquelle une application est successivement décomposéeen tâches qui sont connectées et communiquent à travers des tableaux.Pour maintenir les sémantiques de flot de données, les cycles sont in-terdits dans les graphes des connexions entre les tâches. Combiné avecla contrainte d’assignation unique, cela interdit aux tâches de conserverles informations d’état.

Dans ce contexte, le concept de délai disponible dans SDF et ensuitedans la plupart de ses extensions revêt une grande importance pour unlangage de flot de données, en permettant la construction des cycleset des tâches avec des boucles sur elles-mêmes, ce qu’on appelle desconstructions d’état. Une telle construction permet un acteur d’utiliserdes données qu’il a produit mais dans une exécution antérieure.

2.6 modélisation des dépendances uniformes 49

Un langage « complet » orienté flot de données doit impérativementêtre capable d’exprimer ce genre de constructions. Array-OL étantun langage plus expressif que les langages de la famille flot de donnéessynchrone, les concepts capables d’exprimer des cycles dans le graphedoivent être par conséquent plus complexes.

Dans SDF, un délai est représenté par des jetons initiaux disponiblessur un lien. Avec l’extension multidimensionnelle de MDSDF, les délaissont devenus aussi des jetons multidimensionnels, représentés par deslignes et des colonnes initiales dans le cas bidimensionnel, ou deshyperplans pour plus de dimensions. Ces valeurs initiales disponiblessur un lien impliquent que la production de jetons sur le lien estdéplacée avec les valeurs correspondantes, alors que la consommationne l’est pas. Des données déjà disponibles sur le lien permettent à unacteur d’avoir une boucle sur lui-même et de consommer des jetonsproduits par lui-même dans une itération antérieure, sans bloquerl’exécution, constructions appelées états. En Array-OL, il n’y

a pas d’ordreprédéfini d’exécutionet ainsi le concept dejetons initiaux n’estpas adéquate.

Plutôt que d’exprimer des jetons initiaux disponibles sur une connex-ion, nous avons choisi d’exprimer des dépendances uniformes entreles répétitions de la même tâche répétée, ce que nous appelons desdépendances interrépétition.

2.6.1 Exemple introductif

Pour être en mesure de représenter des boucles contenant des dépen-dances interrépétition, nous avons ajouté la possibilité de modéliser desdépendances uniformes entre les tuiles produites et celles consomméespar une composante répétée. La Figure 27 contient une représentationgraphique de cette construction.

Intégration

(∞)

(∞)0 ()

(∞)

+()

()

()

F =(1

)o =

(0

)P =

(1

)F =

(1

)o =

(0

)P =

(1

)

pentrée

psortie

d =(1

)

La dépendance est représentée par la boucle autour la tâche répétée +. Leconnecteur en pointillé représente le lien par défaut.

Fig. 27: Une simple dépendance interrépétition

Formellement, une dépendance interrépétition connecte un port desortie, psortie sur la Figure 27, d’une tâche répétée avec un de ces portsd’entrée, pentrée sur la même figure. La forme des deux ports connectés doitimpérativement être identique. Le connecteur de dépendance a associé un

50 array-ol

vecteur de dépendance d qui définie la distance de dépendance entre lesrépétitions dépendantes,

rdép = r − d. (2.4)

Cette dépendance est uniforme, ce qui signifie identique pour toutesles répétitions. Quand la source de la dépendance est en dehors del’espace de répétition, une valeur par défaut est utilisée, définie par lelien par défaut connecté au même port d’entrée, pentrée :

a. Quand on affirme qu’une répétition r dépend d’une autre rdép,cela signifie qu’au moment de l’exécution la répétition r prendracomme valeurs d’entrées sur le port pentrée des valeurs produitespar la répétition rdép sur son port de sortie psortie.

b. Quand une répétition prend des valeurs d’un lien par défaut, celasignifie que les valeurs consommées sur le port pentrée provientd’un port connecté avec un lien par défaut à ce port pentrée (letableau entier associé à ce port si les deux ont la même forme ouune tuile de ce tableau, cas où le connecteur par défaut doit avoirun tiler associé, comme nous allons voir en plus de détails par lasuite).

Dans l’exemple d’une simple intégration discrète de la Figure 27,les motifs (et aussi les tuiles) sont des points singuliers. Le vecteurde dépendance d = (1) précise que chaque répétition r dépend dela répétition rdép = r − d = r − (1). La représentation graphique desdépendances dans l’espace de répétition est illustrée sur la Figure 28

Dans ce cas, la dépendance interrépétition est utilisée pour exprimerque la valeur de sortie d’une répétition est utilisée comme entrée par laprochaine répétition.La dépendance

interrépétitionintroduit un ordredans l’espace d’unerépétition et c’estpourquoi on peutparler de répétitionprécédente/suivante.

0. . .

def

Dans l’espace de répétition monodimensionnel, la dépendance interrépéti-tion d = (1) exprime que chaque répétition dépend de celle qui la précède.La première répétition dépend d’une qui est en dehors de l’espace derépétition et ainsi elle va prendre la valeur par défaut comme entrée.

Fig. 28: Les dépendances dans l’espace de répétition de l’Intégration

À l’exécution, chaque répétition prendra comme entrées deux valeurssur ses deux ports d’entrée, une valeur d’entrée d’une tuile et le résultatde la répétition précédente. Ces valeurs sont additionnées et le résultatest fourni sur le port de sortie, qui va en même temps servir commeentrée pour la répétition suivante et être rangée dans le tableau desortie. Pour commencer le calcul, une valeur par défaut de 0 est pris parla répétition r = 0, comme indiqué par le lien par défaut. Les calculssont séquentiellisés par la dépendance interrépétition. La répétitionmise à plat est montré sur la Figure 29.

La dépendance interrépétition présentée est un exemple relativementsimple utilisé pour illustrer les concepts de dépendances uniformeset de lien par défaut. Le langage Array-OL étendu par ces conceptspermet la construction des structures plus complexes, comme desdépendances interrépétition multiples ou des dépendances non con-tiguës. Ces dépendances peuvent être également connectées à traversla hiérarchie pour exprimer des dépendances entre des répétitions auxdifférents niveaux de la hiérarchie.


Intégration

...

...

0

+[0] +[1] +[2]...

Fig. 29: Intégration : répétition mise à plat

2.6.2 Définition de la dépendance interrépétition

Une dépendance interrépétition complète, dans le contexte d’Array-OL, qui permet la construction des dépendances complexes connectéesà travers les niveaux de la hiérarchie, contient les deux éléments quenous avons vu sur l’exemple précédent :

– la dépendance uniforme étiquetée avec un vecteur de dépendance ;– le lien par défaut ;

auxquels on ajoute deux observations :– premièrement, le lien par défaut peut avoir comme source un port

du composant qui contient la dépendance interrépétition et la tâcherépétée. De cette façon, on peut établir des connexions entre desniveaux successifs de la hiérarchie ;

– deuxièmement, le lien par défaut peut connecter des ports avecdes formes différentes, cas où un tiler associé au lien est nécessairepour exprimer les relations exactes élément à élément.

Le tiler sur le lien par défaut permet d’avoir de multiples liens pardéfaut connectés à une dépendance interrépétition – un seul lien doitêtre valide pour chaque répétition qui a besoin d’une valeur par défaut.

Exemple. Un exemple montrant l’intérêt de cette construction est unespace de répétition bidimensionnel avec des valeurs différentes pardéfaut en fonction de la direction dans laquelle on sort de l’espace derépétition (nord, sud, est ou ouest).

Définition 1 (dépendance interrépétition). La spécification formelled’une dépendance interrépétition complète consiste en :

– un composant répété c avec un espace de répétition srépétition ;– une dépendance interrépétition dép avec un vecteur de dépen-

dance d ; dép connecte un port de sortie psortie à un port d’entréepentrée (psortie et pentrée doivent avoir la même forme s et les deuxappartient à c) ;

– un ensemble de n liens par défaut défi (0 6 i < n), connectant desports de sortie pi (0 6 i < n) d’autres composants au port pentrée ;

– chaque lien par défaut défi a associé un tiler θi, avec l’exception dudernier qui peut manquer le tiler (cas où pn-1 doit avoir la mêmeforme que pentrée) ; t représente le nombre des liens par défautayant des tilers associés (n− 1 6 t 6 n).

En calculant les dépendances, nous retrouvons :

∀ r,0 6 r < srépétition, rdép = r − d (2.5)

52 array-ol

et si la répétition de dépendance est à l’intérieur de l’espace de répéti-tion (0 6 rdép < srépétition) la répétition r dépend de rdép (les valeursproduites par la répétition rdép sur le port psortie sont consommées parla répétition r sur le port pentrée) ; autrement la répétition r prend lesvaleurs d’entrées d’un des liens par défaut connectés au pentrée.

Dans le cas où plusieurs liens par défaut sont connectés au portpentrée, une sélection entre ces liens disponibles doit être faite. La sélec-tion se fait en fonction de l’indice de répétition r et les tilers associés auxliens par défaut. En prenant chaque tiler θi, un élément de référence estcalculé à l’intérieur du tableau qui corresponde au port pi dans la mêmemanière que pour un tiler normal (sous-section 2.3.3, Équation 2.2),mais sans l’usage du modulo :

∀ i, 0 6 i < t, réfi = oi + Pi · r, (2.6)

où oi et Pi sont l’origine et la matrice de pavage du tiler θi.

propriété de validité. La spécification des tilers associés auxliens par défaut doit respecter la contrainte que, pour toutes les répéti-tions qui ont besoin des valeurs d’entrée des liens par défaut, maximumune des références calculées avec l’Équation 2.6, réfi (0 6 i < t), està l’intérieur du tableau qui corresponde au port pi. Cette référencevalide, réfv, vérifie donc que 0 6 réfv < sv, où sv est la forme du portpv. Cette référence ainsi que le tiler correspondant Tv sera utilisée pourcalculer la tuile à passer au port pentrée de la répétition r comme unensemble d’indices ei vérifiant

∀ i,0 6 i < s, ei = réfv + Fv · i mod sv (2.7)

où s est la forme du port pentrée et sv est la forme du port pv.Si aucune des références calculées n’est valide, le connecteur par

défaut sans tiler associé va être choisi. L’exclusion des tilers peut êtrefacilement vérifiée en utilisant l’algèbre polyédrique.

exclusion des tilers. L’exclusion des tilers peut se faire parla construction de l’ensemble de points de l’espace de répétition, r,qui prennent des valeurs par défaut et qui donnent deux (au moins)références valides, par la vérification du système d’(in)équations :

0 6 r < srépétition

rdép = r − d

rdép < 0 ou rdép > srépétition

0 6 i < t

réfi = oi + Pi · r0 6 réfi < si0 6 j < t

réfj = oj + Pj · r0 6 réfj < sji 6= j

. (2.8)

Si cet ensemble est vide alors les tilers des liens par défaut s’excluententre eux. La vérification peut se faire en construisant l’ensemble depoints par l’utilisation de Polylib17 (qui est inclus dans SPPoC) et tester17 http:

//icps.u-strasbg.

fr/polylib/

http://icps.u-strasbg.fr/polylib/




si l’ensemble est vide par la recherche d’un élément dans l’ensemble depoints avec un appel vers le solveur PIP18 [35], aussi inclus dans SPPoC.

18 http:

//www.piplib.org/Ces opérations sont possibles parce que, comme les dimensions destableaux sont des valeurs numériques connues, le système d’inéquationsest équivalent à un système d’équations affines définissant des unionsde treillis linéaires bornées que SPPoC, Polylib et PIP manipulent.

La construction des tilers associés aux liens par défaut pour respecterla propriété de validité (une seule référence valide pour chaque répéti-tion) pourrait paraître complexe, mais, dans des applications réelles,des constructions avec plusieurs liens par défaut sont très rares. Laplupart des exclusions entre les liens par défaut sont faites en utilisantdes tilers très similaires, avec les mêmes matrices de pavage et d’a-justage et des origines déplacées. Des exemple et plus de détails sur cesconstructions sont disponibles dans les sections suivantes.

Par la suite on va argumenter sur la nécessité de pouvoir exprimerdes dépendances à travers les niveaux de la hiérarchie et commentla définition des dépendances interrépétition sont capables de les ex-primer.

2.6.3 Dépendances dans un espace multidimensionnel

On commence par montrer un exemple d’une dépendance inter-répétition sur un espace bidimensionnel, illustré sur la Figure 30 et quispécifie les dépendances explicitées de la Figure 31.

(240,1080) (240,480)

def (4)

(240,120)

(14) (4)

(4)

F =

(0

1

)

o =

(0

0

)

P =

(1 0

0 9

)

F =

(0

1

)

o =

(0

0

)

P =

(1 0

0 4

)

d =(2,0

)

Un sous-ensemble de l’application Downscaler, le filtre vertical sur uneseule image. Une dépendance interrépétition a été ajoutée sur la premièredimension de la répétition avec un pas de 2. Le lien par défaut fournit lavaleur par défaut ; pour chaque répétition qui a une dépendance qui sortde l’espace de répétition, une « valeur » par défaut est en vérité un tableaudes valeurs par défaut qui a la même forme que le port d’entrée, dans cecas un tableau de (4) éléments.

Fig. 30: Dépendances dans un espace bidimensionnel

Dans l’espace de répétition de la Figure 31, les répétitions d’unecolonne dépendent des répétitions correspondantes (sur la même ligne)de la colonne à deux pas avant dans l’ordre des indices. Les deuxpremières colonnes dépendent des répétitions en dehors de l’espace

http://www.piplib.org/

http://www.piplib.org/

54 array-ol

0 . . . 239

0

. . . 119

def

Fig. 31: Les dépendances dans l’espace de répétition 2D

de répétition et donc ces répétitions prennent des valeurs par défautcomme entrées, dans ce cas la même valeur fournie par la tâche def.

multiples valeurs par défaut. En utilisant des liens par défaut,différentes valeurs par défaut peuvent être passées aux différentesrépétitions avec des dépendances en dehors de l’espace de répétition.La Figure 32 montre l’exemple précédent avec des valeurs par défautdifférentes pour chaque colonne.

(240,1080)

(240,480)

def1 (4)

def2 (4)

(240,120)

(14)

(4)

(4)

F =

(0

1

)

o =

(0

0

)

P =

(1 0

0 9

)

F =

(0

1

)

o =

(0

0

)

P =

(1 0

0 4

)

d =(2,0

)

F =(1

)o =

(0

)P =

(4 0

)

F =(1

)o =

(−4

)P =

(4 0

)

Des entrées par défaut différentes sont utilisées pour les deux premièrescolonnes qui ont des dépendances qui sortent de l’espace de répétition. Lesdeux entrées sont produites par les deux tâches, def1 et def2, et les tilersassociés aux liens par défaut expriment les deux sous-espaces disjonctesd’application des deux entrées. La matrice de pavage de ( 4 0 ) pour lesdeux tilers fait qu’un seul indice de la dimension horizontale de l’espacede répétition donne une référence dans le tableau de taille (4) et donc uneseule colonne. Le choix de la colonne et fait par la valeur de l’origine, (0)pour la première colonne et (−4) pour la deuxième (réf = o + P · r =( −4 ) + ( 4 0 ) ·

(1?

)= ( 0 ), pour tous éléments de la deuxième colonne).

Fig. 32: Multiples liens par défaut


impact sur le parallélisme de données . En Array-OL, unetâche répétée est considérée parallèle par construction, donc ces répéti-tions peuvent être ordonnancées dans un ordre arbitraire par le com-pilateur. Une exécution parallèle des toutes les répétitions peut êtreconsidérée comme l’idéal en temps de latence, mais le choix dépendde beaucoup plus de paramètres19. Dans la vision Array-OL, ces choix 19 Ressources,

localité desdonnées, etc.

d’exécution doivent rester à la charge du compilateur/ordonnanceur etla spécification doit seulement exprimer le maximum de parallélisme.

Sur la Figure 28, la dépendance interrépétition élimine complètementle parallélisme disponible sur la répétition, causée par la dépendanceentre toutes les instances de la tâche répétée. Dans ce cas, une exécutionséquentielle dans l’ordre des indices est imposée, mais le compilateurpeut exploiter la structure de pipeline native dans la construction desdépendances interrépétition (cf Figure 29).

Dans une application, les dépendances entre les éléments d’unerépétition se propagent à travers la hiérarchie et l’enchaînement destâches et peuvent avoir un impact très négatif sur le parallélisme con-tenu dans l’application.

Sur l’exemple multidimensionnel de la Figure 31, la dépendancen’élimine pas tout le parallélisme. Sur un espace de répétition multidimen-sionnel, une seule dépendance interrépétition ne peut pas éliminer complète-ment le parallélisme de la répétition. En parcourant cet espace avec deshyperplans perpendiculaires sur le vecteur de dépendance, toutes lesrépétitions sur un de ces hyperplans sont des répétitions parallèlesentre elles.

Même si le problème se complique quand sur un espace de répétitionon a plusieurs dépendances, la solution peut être toujours représen-tée comme des hyperplans et des algorithmes pour les calculer sontdisponibles. En utilisant ce type d’algorithmes, le compilateur peut ex- L’aspect uniforme des

dépendancesinterrépétition vise àlimiter l’impact sur leparallélisme.

ploiter les hyperplans contenant des répétitions parallèles et les aspectspipeline pour générer des ordonnancements optimisés.

Sur l’exemple de la Figure 31, la dépendance avec un pas de 2 sur ladimension horizontale fait que sur l’espace de répétition 2D, des blocssuccessifs de deux colonnes contiennent des répétitions indépendantes,et donc parallèles. Le compilateur pourrait ordonnancer, en fonction descontraintes, les colonnes en blocs de deux colonnes parallèles, colonnepar colonne ou même en séquentiel les éléments de chaque colonne,une colonne après l’autre.

2.6.4 Dépendances à travers la hiérarchie

Motivation

Dans la section précédente, nous avons vu comment exprimer desdépendances uniformes sur des espaces de répétition multidimension-nels. Comme discuté dans la section 2.4 et montré sur la Figure 2.4,pour déterminer l’espace de répétition d’une tâche il faut concaténertoutes les répétitions en descendant du niveau le plus haut jusqu’auniveau de la tâche. Une dépendance sur l’espace de répétition d’unniveau donne des dépendances entre des blocs de l’espace de répétitiontotal. Afin de pouvoir exprimer des dépendances sur l’espace total derépétition, ou sur des parties de cet espace étalées sur plusieurs niveauxde la hiérarchie, la définition des dépendances interrépétition permetde les connecter à travers la hiérarchie.

56 array-ol

Une raison encore plus forte est amenée par les transformations deboucles Array-OL qu’on va discuter dans la section 5.3. Ces transfor-mations sont des outils de refactoring de l’application, pour l’adapterau passage à un modèle d’exécution. Pour résumer, ces transformationsont un fonctionnement qui ressemble aux transformations de bouclesusuelles appliquées sur des nids de boucles, avec la différence que dansle cas d’Array-OL les transformations s’appliquent au niveau de laspécification sur des structures hiérarchiques de répétitions20. L’effet20 Contrairement

aux nids de bouclesau niveau de lacompilation.

des transformations Array-OL est la redistribution des répétitions àtravers la hiérarchie, avec la création ou la suppression des niveauxde hiérarchie si besoin, et les transformations Array-OL ont commeprémisse fondamentale l’invariance de la fonctionnalité.

Définition 2 (fonctionnalités équivalentes). Deux spécifications ontdes fonctionnalités équivalentes si, pour toutes les valeurs d’entréespossibles, les valeurs de sortie sont les mêmes. Array-OL est un langaged’expression des dépendances et donc pour que deux spécificationssoient équivalentes il faut qu’elles expriment les mêmes dépendances.

Imaginons une transformation qui a comme effet la partition d’unespace de répétition en blocs, avec la génération d’un niveau de hiérar-chie21. Pour que les spécifications restent équivalentes, une éventuelle21 La transformation

de tiling a cettefonctionnalité.

dépendance interrépétition sur l’espace de répétition initial doit setraduire dans une structure qui exprime exactement les mêmes dépen-dances, mais maintenant sur l’ensemble des deux espaces de répétitionsliées par le niveau de la hiérarchie.

Connecter des dépendances des deux niveaux successives de la hiérarchie

La Figure 33 illustre la modélisation de l’exemple précédent avec unedépendance sur la première dimension après une transformation detiling pour partager l’espace de répétition en blocs de 5× 4 éléments22.22 Les deux

modélisations ontdes fonctionnalitéséquivalentes.

Sur la modélisation cela se traduit par l’introduction d’un niveau dehiérarchie et le partage de l’espace de répétition entre ces deux niveaux ;l’espace de répétition total doit rester le même.

Après la transformation, la dépendance interrépétition initiale doits’adapter à la nouvelle structure : la Figure 34 montre les dépendancesdans l’espace de répétition partagé en blocs ; les nouvelles dépendancesse trouvent davantage à l’intérieur des blocs et entre les élémentsappartenant aux blocs voisins, mais en restant uniformes.

Ces dépendances se traduisent par une dépendance à l’intérieur desblocs et donc sur le niveau inférieur de la hiérarchie et une autre auniveau des blocs. En addition, pour exprimer la dépendance exacteentre des éléments dépendants des blocs différents, un lien par défautayant associé un tiler fait le lien entre les deux espaces de répétition. Letiler est similaire au tiler de sortie du niveau inférieur de la hiérarchieavec une origine déplacée comme une différence entre la référencedu bloc de dépendance et la référence de la fenêtre de dépendance –cette fenêtre est un bloc avec la même forme qui contient toutes lesrépétitions dépendantes pour ce bloc, comme montré sur la Figure 34.

Détails sur la construction du tiler

Les similarités entre les tilers (le tiler de sortie et le tiler du lien pardéfaut) sont évidentes quand on analyse plus en détail la structure :les deux doivent avoir les mêmes formes pour les tableaux associés


(240,1080) (240,480)

0 (4)

(48,30)

(5,4, 14) (5,4, 4)

(5,4, 4)

F =

(1 0 0

0 9 1

)

o =

(0

0

)

P =

(5 0

0 36

)

F =

(1 0 0

0 4 1

)

o =

(0

0

)

P =

(5 0

0 16

)

F =(0 0 1

)o =

(0

)P =

(0 0

)

d =(1,0

)

(5,4)

Vfilter

(14) (4)

(4)

F =

001

o =

000

P =

1 0

0 1

0 0

F =

001

o =

000

P =

1 0

0 1

0 0

F =

001

o =

300

P =

1 0

0 1

0 0

d =(2,0

)

L’espace de répétition a été partagé en (48,30) blocs de (5,4).

Fig. 33: La dépendance interrépétition après une transformation de tiling

0 . . . 239

0

. . . 119 fenêtre de dépendance du bloc (1,1)

dist (3,0)

(0,0) (1,0)

(0,1) (1,1)

def 0 . . . 47

0

. . . 29

(0,0) (1,0)

(0,1) (1,1)

def

(-1,0)

(-1,1)

Des parties de l’espace de répétition sont montrées sur la gauche de la figure : pour le bloc (1,0)toutes les répétitions qui dépendent des répétitions à l’intérieur du même bloc, pour le bloc (1,1)les répétitions qui dépendent des répétitions d’un bloc voisin et pour le bloc (0,0) les répétitionsqui vont utiliser des valeurs par défaut. Sur la partie droite, les dépendances entre les blocs sontmontrées.

Fig. 34: Dépendances après le partage en blocs

(les deux ports sont connectés par la dépendance du niveau haut), lesmêmes formes pour les motifs associés (les deux ports sont connectéspar la dépendance du niveau bas), et aussi le même espace de répétition.

58 array-ol

Les blocs avec des valeurs par défaut

Pour les dépendances entre les blocs, le bloc (0, 1) et (0, 0) dépendentdes blocs en dehors de l’espace de répétition et ainsi vont utiliser commeentrées des blocs remplis avec des valeurs par défaut représentées pardes copies des valeurs par défaut fournies par le lien par défaut initial23.23 Des copies

virtuelles dansl’étape de laspécification ; afinde réduire lesbesoins en taillemémoire, aumoment del’exécution il n’y apas besoin descopies mémoire.

Le choix d’utiliser des blocs remplis avec des valeurs par défaut vient dela définition des dépendances interrépétition (Définition 1) qui contraintles deux ports de l’extrémité d’une telle dépendance à avoir la mêmeforme. Les copies de la valeur par défaut initiale sont exprimées parle tiler associé qui construit un motif plus grand que le tableau parréplication. Les zéros des matrices du pavage et d’ajustage du tiler, enexceptant la dernière colonne d’ajustage, expriment que le tableau avecune dimension de (4) correspond à la dernière dimension du motif,alors que sur les autres dimensions d’ajustage et de pavage, le tableauest répliqué.

2.6.5 Dépendances multiples

Une dépendance interrépétition spécifie la dépendance de donnéesentre des couples de répétitions qui se trouvent à une distance égaleau vecteur de dépendance dans l’espace de répétition. Et si on voulaitexprimer qu’une répétition dépend de deux ou plusieurs autres ? Enutilisant plusieurs dépendances interrépétitions sur le même espacede répétition, on peut exprimer des dépendances multiples, toujoursuniformément espacées.

Prenant toujours le sous-ensemble du Downscaler (Figure 30) eten remplacent le vecteur de dépendance avec un vecteur de (1,1)

pour exprimer des dépendances en diagonale on se retrouve avec desdépendances comme montrées sur la Figure 35.

0 . . . 239

0

. . . 119

def

Des répétitions choisies aléatoirement sont montrées sur la figure.

Fig. 35: Dépendances entre les répétitions pour la dépendance diagonale

En partageant l’espace de répétition en blocs en utilisant la mêmetransformation de tiling, les dépendances à l’intérieur d’un bloc et entreles blocs sont montrées sur la Figure 36.

La fenêtre de dépendance du bloc (1, 1) se croise avec trois autresblocs voisins et donc il y a trois dépendances entre les blocs associésaux trois liens par défaut au niveau bas de la hiérarchie.


0 . . . 239

0

. . . 119

(0,0) (1,0)

(0,1) (1,1)

fenêtre de dépendance du bloc (1,1)

def

0 . . . 47

0

. . . 29

(0,0) (1,0)

(0,1) (1,1)

def

(-1,0)

(-1,1)

(-1,-1) (0,-1) (1,-1)

Les dépendances diagonales après le partage en blocs sur la gauche. Des dépendances triples entreles blocs sur la droite.

Fig. 36: Dépendances diagonales après le tiling en blocs

La Figure 37 montre la représentation graphique de l’application entraitement par bloc, avec trois dépendances interrépétition au niveaudu bloc.

La sélection du bloc approprié se fait en fonction des tilers associésaux trois liens par défaut ; les tilers sont toujours similaires l’un à l’autreet au tiler de sortie, avec l’exception de l’origine qui est déplacée. Desorigines différentes assurent l’exclusivité de la sélection du lien pardéfaut : l’origine représente la différence entre la référence du blocde dépendance et la référence de la fenêtre de dépendance. Avoir (1)la différence en valeur absolue entre quelconques deux origines quidépasse, sur au moins une dimension, la taille du tableau (la mêmeforme de tableau pour tous les tilers) et (2) la même matrice de pavagepour tous les trois tilers, garantissent que pour une répétition, un seultiler va donner une référence valide.

démonstration de l’exclusivité des tiler .En présumant que pour une répétition r qui dépend d’une répétition

en dehors de l’espace de répétition il y a un tiler (θv) des liens pardéfaut qui fournit un élément de référence à l’intérieur des dimensionsdu tableau,

réfv = ov + Pv · r (2.9)

et

0 6 réfv < s. (2.10)

Pour tous les autres tilers, θi, on a

∀ i, 0 6 i < t, i 6= v, réfi = oi + Pi · r, (2.11)

des matrices identiques et les mêmes dimensions des tableaux, pendantque la différence entre les deux origines est δi :

Pi = Pv, oi = ov + δi. (2.12)

En remplaçant dans Équation 2.11, on se retrouve avec

réfi = ov + δi + Pv · r = δi + réfv. (2.13)

60 array-ol

(240,1080) (240,480)

(48,30)

(5,4, 14) (5,4, 4)

(5,4, 4)

(5,4, 4) (5,4, 4)

d =(1,0

)d =

(0,1

)d =

(1,1

)

(5,4)

Vfilter

(14) (4)

(4)

F =

001

o =

4−10

P =

1 0

0 1

0 0

F =

001

o =

−1

3

0

P =

1 0

0 1

0 0

F =

001

o =

430

P =

1 0

0 1

0 0

d =(1,1

)

La même application, la même transformation, la seule différence est que le vecteur de dépendanceinitial est un vecteur diagonal, (1,1). On a choisi de ne pas surcharger la figure avec des informationsredondantes qui restent identiques avec la Figure 33 (tilers, lien par défaut) ; des modificationsinterviennent seulement au niveau des dépendances interrépétition.

Fig. 37: Dépendance diagonale

De l’hypothèse |δi| 6< s, soit réfi 6> 0 soit réfi 6< s, qui signifie qu’aucundes tilers θi, i 6= v, ne donne une référence valide et donc seulement lelien par défaut v est valide pour la répétition r.

2.6.6 Discussion

La spécification Array-OL autorise des constructions plus complexesque SDF et ses extensions multidimensionnelles, avec l’exception desboucles de dépendance, exprimées en utilisant le concept de délai enSDF. Avec l’extension des dépendances interrépétition, on peut affirmerqu’Array-OL est devenu un langage qui peut exprimer non seulementdes délais et des états, mais des dépendances plus complexes dans lesespaces de répétition et à travers la hiérarchie. Tout cela fait d’Array-OL, dans notre opinion, un langage « complet » pour la spécificationmultidimensionnelle des applications de traitement intensif du signal.

De plus, les dépendances interrépétition sont capables d’exprimerdes dépendances complexes connectées à travers les niveaux de lahiérarchie, extrêmement importantes pour Array-OL dans le contextedes transformations Array-OL, des outils clefs quand on parle derefactoring, optimisations et ordonnancement avec Array-OL [3]. Cestransformations seront discutées en détail dans la section 5.3 et l’inter-

2.7 conclusions 61

action avec les dépendances interrépétition est analysée et formaliséedans la chapitre 6.

Par l’enchaînement des dépendances interrépétition avec la structurehiérarchique d’Array-OL, on peut même construire des dépendancesnon uniformes, comme une répétition bidimensionnelle avec une dépen-dance linéaire sur toutes les lignes (chaque répétition dépend de laprétendante sur la même ligne), en temps que la première répétitionde chaque ligne dépend de la dernière de la ligne précédente, pourexprimer une chaîne de dépendance en forme de Z.

Les dépendances interrépétition sont modélisées avec Array-OL enutilisant les mêmes concepts déjà disponibles – l’espace de répétition,les tilers (origine, ajustage, pavage) – et, dans cette démarche, très peude nouveaux concepts ont du être ajoutés.

Une autre propriété très intéressante de SDF et de ses extensionsest la possibilité d’ordonnancement statique des applications décrites.Comme déjà discuté en section 2.4, une spécification Array-OL quirespecte les règles de la définition statique est aussi ordonnancablestatiquement. L’ordonnancement des nids de boucles avec des dépen-dances uniformes est un problème connu depuis les travaux de Darte etRobert [22]. En utilisant ces résultats, on peut ordonnancer statiquementdes applications Array-OL avec des dépendances interrépétition.

Il s’agit de l’utilisation des techniques de recherche d’un ordonnance-ment linéaire qui respecte les dépendances uniformes par l’utilisationpar exemple de la méthode de l’hyperplan proposée par Lamport [57].La présence d’une seule dépendance interrépétition sur un espace derépétition détermine un ordonnancement sur des hyperplans perpen-diculaires sur le vecteur de dépendance. Plusieurs dépendances sur lemême espace de répétition compliquent l’algorithme de recherche, maisle problème peut toujours être projeté sur un problème d’optimisationlinéaire.

2.7 conclusions

Nous avons présenté dans ce chapitre le langage de spécificationet modèle de calcul Array-OL, conçu pour la spécification des appli-cations de traitement intensif de signal. Le langage vise l’expressioncomplète de la régularité du calcul de ce type d’applications, qui setraduit par des décompositions en répétitions data-parallèles où maxi-mum de parallélisme est exprimé et peut être exploité dans le contextede l’exécution sur des plateformes embarquées multiprocesseurs.

Les contraintes dans le formalisme d’Array-OL pour le rendre or-donnancable statiquement (qui interdisaient de cycles dans le graphe dedépendances) nous ont conduit à proposer une extension pour l’expres-sion des dépendances uniformes dans la spécification. Les dépendancesinterrépétition permettent l’expression de dépendances uniformes entreles répétitions à un niveau de hiérarchie et peuvent être connectées àtravers la hiérarchie pour exprimer des dépendances entre les répéti-tions totales de la décomposition hiérarchique. En plus, le caractèreuniforme de ces dépendances à un impact réduit sur le parallélismedans la spécification.

Dans le chapitre suivant nous allons voir comment le formalismed’Array-OL est utilisé dans le contexte de la comodélisation pourl’embarque en utilisant le standard MARTE d’OMG.

3C O M O D É L I S AT I O N D A N S U N E V I S I O N R É P É T I T I V EE N M A RT E

3.1 Concepts support 643.2 MARTE: Modeling and Analysis of Real-time and

Embedded systems 653.3 Modélisation des structures répétées 663.4 Reshapes 67

3.4.1 Spécification formelle 68

3.4.2 Impact sur l’ordre partiel de la tâche com-posée 69

3.5 Gaspard2: environnement de comodélisation pourl’embarqué 70

3.6 Modélisation en MARTE pour Gaspard2 713.6.1 Équivalence des concepts 72

3.6.2 Règles de réduction vers une définition valide 74

3.7 Modélisation des architectures 763.7.1 État de l’art 77

3.7.2 Modéliser des architectures répétées 78

3.7.3 Concepts répétitifs dans des structures nonapplicatives 78

3.8 Placement répétitif 813.8.1 Allocation 81

3.8.2 Distribution 81

3.9 Conclusions 83

Dans ce chapitre nous allons nous intéresser à la comodélisation dessystèmes en utilisant le standard OMG MARTE dans le contexte del’environnement Gaspard2.

Tous les concepts définis pour le langage Array-OL sont disponiblesdans le standard et nous allons voir comment une spécification enMARTE peut être réduite à une spécification Array-OL et donc toutesles propriétés dérivées du modèle de calcul Array-OL s’appliquentà une spécification MARTE. Dans cette direction, on peut profiterdes outils de conception autour UML, de l’ingénierie dirigée par lesmodèles, d’avoir une ouverture facile vers la communauté apportée parle standard OMG et en même temps tous les avantages du modèle decalcul, tel que la définition statique du langage.

En plus de la modélisation des applications, la décomposition répéti-tive permet la modélisation compacte des architectures avec des topolo-gies régulières et facilite l’exploration du placement des applicationsrépétitives sur telles architectures.

Nous commençons, dans la section 3.1, par la définition des conceptsde l’IDM que nous allons utiliser par la suite pour présenter le standardMARTE (dans la section 3.2), en insistant sur les concepts qui permet-tent modéliser des structures répétées, section 3.3. La section 3.4 décritune construction répétitive appelée reshape permettant l’expression derelations uniformes entre deux formes multidimensionnelles.

L’environnement Gaspard2 est présenté dans la section 3.5 et nousallons voir comment les concepts répétitifs de MARTE peuvent être

63

64 comodélisation dans une vision répétitive en marte

utilisés pour la modélisation des applications, des architectures et duplacement répétitif, respectivement dans les section 3.6, section 3.7 etsection 3.8.

3.1 concepts support

Avant de continuer, nous devrons introduire un ensemble de conceptsclés dans le contexte de l’ingénierie dirigé par des modèles (IDM) quenous allons utiliser dans ce chapitre :

les modèles sont la base de la récente méthodologie d’ingénieriedirigée par les modèles, mais le concept de modèle en lui-mêmeest très ancien comme le dit Favre dans [34]. Ainsi, toute représen-tation peut être considérée comme un modèle. Un modèle estune vue abstraite d’un système informatique réalisée selon un(ou plusieurs) point(s) de vue. Pour réaliser un modèle, il estimportant d’identifier les caractéristiques pertinentes et intéres-santes du système afin de les modéliser et ainsi de permettrel’étude du système selon ces caractéristiques. L’IDM repose surune utilisation intensive des modèles tout au long du processusde développement.

les métamodèles ont le rôle d’ajouter une sémantique et une syn-taxe aux modèles afin qu’ils soient compréhensibles par les ma-chines. Un modèle fait dans un métamodèle est dit conforme àce métamodèle. Il est possible de faire une analogie entre lesmétamodèles et les grammaires des langages de programmation.Un métamodèle doit rendre possible la modélisation de tou tesles caractéristiques pertinentes du type de systèmes à modéliser.

unified modeling language (uml) est un langage de modéli-sation graphique standardisé par l’OMG [72]. Ce langage estbasé sur un métamodèle auquel est associée une représentationgraphique. Le principal inconvénient de ce langage est qu’il nepropose une sémantique faible, une des raisons pour laquelle lanotion de profil a été introduite afin d’ajouter une sémantique à unmodèle UML par l’intermède des stéréotypes. Un stéréotype ajouteune sémantique à l’élément UML sur lequel il est placé, et peutégalement ajouter des attributs à cet élément à l’aide des taggedvalues(balises). Ce mécanisme d’extension d’UML est à la basede son succès. Une autre clé de son succès est que de nombreuxoutils proposent une implémentation de ce standard. Il s’agitaussi bien d’outils propriétaires (MagicDraw UML1, Enterprise1 http:

//www.nomagic.com Architect2) que d’outils libres tels que Papyrus UML3.2 http://www.

sparxsystems.com.

au/3 http://www.

papyrusuml.org/

transformations de modèles. Rendre un modèle productif en-traîne qu’il faut, comme son nom l’indique, produire. Les trans-formations de modèles [63] permettent cette production. Unetransformation prend un ou plusieurs modèles d’entrée (con-formes à leurs métamodèles respectifs) et produit un ou plusieursmodèles de sortie (également conformes à leurs métamodèles re-spectifs). Le passage des modèles sources vers les modèles ciblesest décrit à l’aide de règles de transformations qui sont exécutéespar un moteur de transformation. Il existe de nombreux outils per-mettant la description et l’exécution de transformation de modèles(Kermeta [88, 67], ATL [48], ModelMorf [30],etc.). Ces outils nesont pas standard et sont donc très spécifiques. Le seul standard

http://www.nomagic.com

http://www.nomagic.com

http://www.sparxsystems.com.au/



http://www.papyrusuml.org/

http://www.papyrusuml.org/

3.2 marte : modeling and analysis of real-time and embedded systems 65

de transformation de modèle est Query/View/Transformation(QVT) [75] standardisé par l’OMG.

3.2 marte : modeling and analysis of real-time and embedded

systems

La conception système basé sur une approche orientée modélisationhaut-niveau devient de plus en plus attractive. Les concepteurs peuventatteindre des niveaux plus hauts d’abstraction en se concentrant sur undomaine particulier, en profitant d’une forme d’expression visuelle quifacilite la compréhensibilité du système et améliore la communicationentre concepteurs. Les concepts et les relations à travers lesquels lemodèle d’un système est décrit sont spécifiés précisément dans lemétamodèle auquel le modèle est conforme. Afin de disposer d’uneinterface graphique pour la représentation et la manipulation de cesmodèles, deux alternatives sont possibles :

a. définir une vue graphique pour chaque concept du métamodèle ;

b. élargir UML avec un profil pour supporter ces concepts.

Même si des outils comme Eclipse, EMF, GMF facilitent énormémentla tâche, la première solution reste relativement fastidieuse due à lanécessité d’avoir un outil dédié. La deuxième solution vise à ajouter dessémantiques et des nouveaux concepts à UML, dans le but de l’adapterà un domaine spécifique et d’utiliser des outils de conception tels queMagicDraw UML, Enterprise Architect ou Papyrus UML.

MARTE (Modeling and Analysis of Real-time and Embedded sys-tems) [71, 83, 79, 80] est un profil standard d’UML proposé par l’OMG(Object Management Group), visant principalement à ajouter à UMLdes capacités pour le développement dirigé par des modèles des sys-tèmes embarqués temps réel. UML fournit le cadre pour brancher lesconcepts nécessaires. Le profil MARTE étend les possibilités pour lamodélisation applicative, architecturale et des relations entre elles. Ilpermet aussi des extensions pour faire l’analyse des performances etd’ordonnancement, de même que prendre en considération des servicesplateforme (telles que les services fournis par un système d’exploita-tion).

La Figure 38 présente l’architecture globale et la décomposition enpaquetages du profil MARTE. Le profil est structuré suivant deuxdirections, la modélisation des concepts des systèmes embarqués temps-réel et l’annotation des modèles d’applications pour supporter l’analysedes propriétés système. L’organisation du profil reflète cette structure,par la séparation des deux paquetages, MARTE design model et MARTEanalysis model, respectivement.

Ces deux parties majeures partagent des concepts communs, groupésdans MARTE foundations : pour exprimer des propriétés non fonc-tionnelles (NFPs), des notions de temps (Time), la modélisation desressources (GRM), des composants (GCM) et des éléments d’alloca-tion (Alloc). Un paquetage additionnel contient les annexes du profildéfinies en MARTE, ainsi bien que des librairies prédéfinies.

L’annexe Repetitive Structure Modeling (RSM) de MARTE est inspiréedu modèle de calcul Array-OL. Tous les concepts utilisés en Array-OL,décrits dans chapitre 2 sont présents et leur sémantique est équivalenteà celle d’Array-OL.


NFPs = Non-Functional Properties, GRM = Generic Resource Modeling, GCM = Generic ComponentModel, Alloc = Allocation modeling, RTEMoCC = RTE Model of Computation & Communication,SRM = Software Resource Modeling, HRM = Hardware Resource Modeling, GQAM = GenericQuantitative Analysis Modeling, SAM = Schedulability Analysis Modeling, PAM = PerformanceAnalysis Modeling, VSL = Value Specification Language, RSM = Repetitive Structure Modeling.

Fig. 38: Architecture globale du profil MARTE

3.3 modélisation des structures répétées

L’extension RSM de MARTE est destinée à proposer des modalitéspour l’expression compacte des systèmes ayant une structure ou unetopologie répétitive. Ces structures considérées sont décomposées enrépétitions de sous-composants, interconnectés via des motifs réguliers.

Les mécanismes disponibles sont orientés vers deux aspects :

a. la possibilité de spécifier la forme (shape) d’une répétition parune forme multidimensionnelle, et ainsi permet la représentationd’une collection de liens potentiels comme un tableau multidi-mensionnel. Le gain est double : facilite l’expression des liens detopologie et augmente le pouvoir d’expression du mécanisme dedescription de la topologie ;

b. une modalité de spécification des informations topologiques surdes relations entre des entités, pour exprimer des liens topologiquesentre des entités au moment de l’exécution.

Ces mécanismes peuvent être utilisés pour spécifier :

1. des architectures matérielles d’exécution : pour exprimer tout leparallélisme disponible, précisément et sous une forme compacte ;

2. modélisation d’applications : pour exprimer le maximum de par-allélisme disponible de l’application (parallélisme de tâches et dedonnées) ;

3. un placement régulier, temporel et spatial, de l’application surdes plateformes d’exécution matérielles.

Concernant les concepts additionnels, il s’agit de :

3.4 reshapes 67

a. l’extension du concept de multiplicité d’UML pour le cas mul-tidimensionnel, représenté par le stéréotype Shaped (Figure 39) ;

Le diagramme UML définit lestéréotype « Shaped » commel’extension de la métaclasseUML::MultiplicityElement avec labalise shape définissant une formemultidimensionnelle représentéepar le datatype ShapeSpecification.

Fig. 39: Shapes multidimensionnelles

b. Les types de données ShapeSpecification et TilerSpecfication (Fig-ure 40 :

Le diagramme UML définit les typesde données :– TilerSpecfication comme une collec-

tion d’un vecteur d’origine et deuxmatrices, d’ajustage et de pavage,qui définissent le concept de tiler ;

– ShapeSpecification comme une liste or-donnée de valeurs naturelles définis-sant la taille de chaque dimension dela forme multidimensionnelle.

Fig. 40: TilerSpecification et ShapeSpecification

c. l’extension des liens de connexion UML (Connector) pour exprimerdes liens de topologie répétitifs. La Figure 41 montre ces liens ; lesconcepts de Tiler, InterRepetition et DefaultLink sont équivalentsà la spécification Array-OL et le lien de Reshape permet l’ex-pression de liens de dépendance par motif entre deux tableauxmultidimensionnels.

Nous allons présenter par la suite le concept de Reshape permettantl’expression de relations entre des motifs uniformes entre deux tableauxmultidimensionnels.

3.4 reshapes

L’expression de dépendances régulières entre les éléments de deuxtableaux multidimensionnels est une construction essentielle en MARTE.Le concept de Reshape permet la spécification d’un réarrangement desmotifs tuilés différemment dans les tableaux source et destination :création/suppression des dimensions, linéarisation/scission des dimen-sions, duplication des éléments.


Fig. 41: Liens topologiques répétitives

Cette construction peut être vue comme une représentation compacted’un cas spécial de répétition et elle est essentielle pour la comodélisa-tion en MARTE, permettant l’expression des :

– restructurations des tableaux multidimensionnels dans l’applica-tion ;

– liens « moins » réguliers dans la modélisation de l’architecture ;– distributions uniformes de l’application sur l’architecture.Le concept de Reshape exprime le réarrangement des éléments entre

deux tableaux multidimensionnels. Dans le contexte de la spécificationapplicative, ces constructions peuvent être utilisées pour exprimer unlien d’égalité entre les éléments d’un tableau source, caractérisé parsa forme ss, et un tableau cible, avec sa forme sc, par la scission leséléments du tableau source dans une série de sR motifs identiques avecla forme sM, en utilisant en tiler source θs, et par le réarrangement desces motifs dans le tableau destination, eu utilisant un tiler cible θc.

Le concept peut être vu comme une représentation compacte d’unerépétition d’une tâche Égalité, comme le montre Figure 42. Une représen-tation compacte est plus appropriée pour l’expression du réarrangementdes données, en montrant qu’il n’y a pas de calculs.

3.4.1 Spécification formelle

Définition 3 (connecteur de reshape). Un connecteur reshape peutêtre utilisé pour remplacer un connecteur d’assemblage4 d’une tâche4 entre deux ports

appartenant à deuxappels de tâche.

composée, avec la différence que les deux ports connectés peuventavoir des formes différentes ss et sc

5 et la présence des informations de5 Différemment auconnecteur normaloù les deux portsdoiventobligatoirementavoir la mêmeforme.

reshape, ρ = (sR, sM, θs, θc) :– la répétition des motifs, caractérisé par une forme sR ;– la forme des motifs, sM ;– le tiler source θs = (Fs, os, Ps) ∈ Zdim(ss)×dim(sM) ×Zdim(ss) ×

Zdim(ss)×dim(sR) ;

3.4 reshapes 69

(ss)

Reshape

(ss) (sc)

(sR)

(sM)

(sc)

θs = (Fs,os, Ps) θc = (Fc,oc, Pc)

m

(ss) (sc)

ρ = (sR, sM,

θs = (Fs, os, Ps),

θc = (Fc,oc, Pc))

Fig. 42: Reshape comme une répétition

– le tiler cible θc = (Fc, oc, Pc) ∈ Zdim(sc)×dim(sM) × Zdim(sc) ×Zdim(sc)×dim(sR).

Définition 4 (relation d’égalité entre les éléments des ports connectéspar un reshape). Un connecteur de reshape ((s, ds, τs, ss), (c, dc, τc, sc), ρ)

défini par la Définition 3, spécifie les relations suivantes entre les élé-ments de s et c

∀r ∈Ndim(sR),0 6 r < sR

∀i ∈Ndim(sM),0 6 i < sM

js = os + (Ps Fs)

(r

i

)mod ss

jc = oc + (Pc Fc)

(r

i

)mod sc

s[js]↔ c[jc]

, (3.1)

où↔ représente la relation de connexion entre les éléments et peut êtreinterprétée selon le contexte :

– dans l’application, la relation exprime une dépendance de don-nées ;

– dans l’architecture, un lien physique ;– dans l’allocation, une association.

3.4.2 Impact sur l’ordre partiel de la tâche composée

Un connecteur simple d’une tâche composée spécifie une dépendanceun à un entre les éléments des deux tableaux (ports) connectés, quidétermine une dépendance de données entre les appels qui contientles deux ports. Une construction de reshape spécifie des dépendancespar motifs entre les éléments des deux ports connectés, et donc ladépendance entre les appels persiste. La présence d’un reshape sur lelien du graphe d’une tâche composée ne change rien en matière dedépendances de données entre les appels et, en conséquence, d’ordrepartiel strict au niveau de la tâche composée.

Observation. Dans la description d’une application, des contraintes surla spécification du reshape sont héritées de sa forme répétitive. Pareil


que pour une tâche répétée, le tiler cible doit produire entièrement letableau destination et les tuiles doivent ne pas se chevaucher.

Par la suite nous allons présenter l’environnement de conceptionGaspard2 et comment le profil MARTE est utilisé dans l’étape despécification.

3.5 gaspard2 : environnement de comodélisation pour l’embar-qué

Gaspard2 (Graphical Array Specification for Parallel and DistributedComputing) [20, 79] est un environnement de développement intégré(IDE6) dédié à la comodélisation visuelle des systèmes embarqués,6 De l’anglais

IntegratedDevelopmentEnvironment.

développé au sein de l’équipe DaRT de l’INRIA LILLE-NORD EU-ROPE et du Laboratoire d’Informatique Fondamentale de Lille (LIFL).En utilisant une méthodologie IDM, il vise la modélisation, la sim-ulation, l’analyse et la génération du code pour des applications etdes architectures matérielles SoC. Il permet la représentation conjointedes parties applicatives et architecturales d’un système. Un mécanismed’association est disponible pour le placement des applications sur desarchitectures.

À partir cette modélisation, une série de transformations de modèlespermet, en passant par différents niveaux d’abstraction, la spécialisationde ce système pour différentes cibles :

– validation avec des langages synchrones [93] ;– exécution en OpenMP (C ou Fortran) [86] ;– simulation au niveau TLM (Transaction Level Modeling) [17] en

SystemC [9, 78] ;– synthèse FPGA en passant par du code VHDL [58].L’architecture de Gaspard2 est schématisé sur le diagramme de la

Figure 43.En commençant avec la spécification conjointe en MARTE de l’ap-

plication, de l’architecture, du placement et le déploiement des com-posants élémentaires sur des fonctions de bibliothèque, le modèle dusystème est traduit successivement entre plusieurs niveaux d’abstrac-tion, chacun correspondant à un métamodèle qui ajoute des propriétésspécifiques, jusqu’à la génération du code.

Exemple. Pour la branche SystemC, le modèle UML est traduit dansune représentation équivalente conforme au métamodèle MARTE,en allégeant le modèle des concepts non utilisés et de la représen-tation graphique. Ensuite, les répétitions distribuées sont traduites dansdes polyèdres et un outil externe est appelé pour la génération desboucles qui vont parcourir correctement les polyèdres (il s’agit de l’outilCLooG [1] – Chunky Loop Generator). Les modules SystemC qui re-spectent la spécification (dépendances de données, placement, etc.) sontgénérés à partir ce dernier métamodèle et peuvent être utilisés pour lasimulation du système.

Gaspard2 a fortement contribué au développement du profil UMLstandard OMG de MARTE. Le paquetage RSM – Repetitive StructureModeling – de MARTE est inspiré de Gaspard2 et son modèle decalcul, Array-OL. Le paquetage HRM – Hardware Resource Modeling– utilise aussi des concepts architecturaux pris de Gaspard2.

Dans le but de rendre l’environnement Gaspard2 plus « standard »,pour faciliter l’interfaçage avec d’autres outils et de profiter des outils

3.6 modélisation en marte pour gaspard2 71

Fig. 43: La méthodologie SoC de Gaspard2

et technologies disponibles autour, des efforts ont été faits pour rendreGaspard2 complètement compatible avec le MARTE ; au moment del’écriture de ce document seuls les concepts de déploiement ne sontpas intégrés en MARTE.

3.6 modélisation en marte pour gaspard2

Au début de ces travaux de thèse, le concepteur disposait d’un profilGaspard2 [10] pour la spécification et la manipulation des modèles, enprofitant des outils de modélisation UML, notamment MagicDraw UML.Le profil Gaspard2 a pour origine les travaux de Cuccuru lors de sathèse [19] et est basé sur le langage Array-OL présenté précédemment.

Une transformation de modèle permettait l’import des modèles(application, architecture, association et déploiement) dans l’environ-nement Gaspard2 basé sur Eclipse7, sous la forme des modèles Gas- 7 http://www.

eclipse.org/pard2 conformes à un métamodèle Gaspard2. Les concepts du profilet de métamodèle Gaspard2 sont équivalentes avec la différence queles concepts UML non utilisés ont été enlevés pour simplifier la modéli-sation. En dehors des

concepts dedéploiement, toutesles autres concepts del’ancien profilGaspard2 seretrouvent dans leprofil MARTE.

Avec l’apparition du standard MARTE, des efforts ont été faits dansl’équipe pour rendre l’environnement complètement compatible avecle standard et supprimer le passage par le métamodèle Gaspard2, uneétape redondante vue que MARTE a été influencé par Gaspard2 et quepresque tous les concepts se retrouvent dans le standard.

http://www.eclipse.org/

http://www.eclipse.org/


Le nouvel environnement Gaspard2 profite aussi du développementde l’éditeur graphique Papyrus UML8, intégré à Eclipse et open source.8 http://www.

papyrusuml.com/ Dans cette démarche, tout le développement Gaspard2 actuel, de laspécification à la génération du code, est structuré autour la plate-forme Eclipse et des extensions peuvent être facilement développées etbranchées au noyau Gaspard2. Figure 44 montre une capture d’écrande l’environnement, la modélisation en Papyrus au niveau de la spécifi-cation. Pour décrire la de-composition hiérarchique tâches/sous-tâches,en Papyrus nous utilisons le diagramme composite d’UML.

Fig. 44: L’environnement Gaspard2

3.6.1 Équivalence des concepts

Le modèle de calcul utilisé par l’environnement est Array-OL etnous avons vu dans le chapitre 2 les bases de la sémantique du langage,et aussi les extensions pour exprimer des dépendances uniformes dansle section 2.6.

Pour faciliter la conception en utilisant des outils de modélisationvisuels, en Gaspard2 on utilise des modèles UML étendus par le profilMARTE, où on retrouve tous les concepts d’Array-OL.

Par la suite nous allons voir comment on modélise avec MARTEdes systèmes qui correspondent au modèle de calcul d’Array-OL etquels sont les concepts équivalents, mais avant il faut pointer quelquesobservations très importantes :validité de la modélisation. Une modélisation en MARTE pour

Gaspard2 est considérée valide si elle correspond à une définitionArray-OL, et qu’en plus cette définition respecte les règles dela définition statique Array-OL. De plus, pour réduire la com-plexité de la modélisation, une spécification en MARTE est aussi

http://www.papyrusuml.com/

http://www.papyrusuml.com/


valide si elle peut être réduite à une définition Array-OL valide, pardes transformations structurales que nous allons discuter dans lasous-section 3.6.2 ;

modélisations non-applicatives. Les concepts du modèle decalcul Array-OL sont définis dans la vision d’une modélisationapplicative. Gaspard2 permet la modélisation conjointe de l’ap-plication, l’architecture et le placement de l’application sur desstructures architecturales. Dans ce sens, certains concepts Array-OL, même si la syntaxe reste la même, changent légèrement designification, discuté par la suite dans la sous-section 3.7.3.

Les conceptsArray-OL ont desconcepts équivalents(homonymes) enUML plus le profilMARTE.

Le métamodèle UML convient parfaitement à une spécification équiv-alente à Array-OL par les concepts autour sa vue Composite : unedécomposition hiérarchique en sous-composantes interconnectées parleurs ports :

1. les composantes Array-OL correspondent aux classes UML –Class ;

2. les ports Array-OL correspondent aux ports d’UML – Port –étendus par le stéréotype FlowPort pour spécifier la direction et lestéréotype ShapeSpecification pour la forme multidimensionnelledu tableau ;

3. les types des ports, représentant le type des données des tableauxassociés aux ports, peuvent être des types primitifs d’UML, MARTEou des types composés ou primitifs définis en UML ;

4. les sous-tâches correspondent au propriétés – Property – avecle type de la sous-composante et le stéréotype ShapeSpecificationpour exprimer l’espace de répétition, si besoin9 ; 9 Pour des

sous-tâchesrépétées.5. les connecteurs Array-OL correspondent aux connecteurs UML –

Connector – étendus par les stéréotypes du paquetage RSM pourdésigner les tilers (stéréotype Tiler), les dépendances interrépéti-tions (stéréotype InterRepetition), les liens par défaut (stéréotypeDefaultLink) ou les reshapes (stéréotype Reshape).

Observation. Les stéréotypes MARTE ajoutent des concepts aux élé-ments UML, des balises (tagged values en anglais), permettant la spécifi-cation complète des modèles ; par exemple, le stéréotype Tiler ajouteles concepts d’origine, ajustage et pavage aux connecteurs UML.

La modélisation multidimensionnelle nécessite la spécification desvecteurs et des matrices pour les liens de la structure répétitive et desshapes pour la multidimensionnalité des tableaux et des répétitions :

shapespecification. La multiplicité d’UML, définie comme un in-tervalle inclusif d’entiers non négatifs commençant avec une borneinférieure et finissant avec une borne supérieure potentiellementinfinie, est associé au concept abstrait de MultiplicityElement, com-mun à de nombreux d’éléments UML, incluant Property et Port.Le concept est étendu par MARTE à une multiplicité multidimen-sionnelle via une ShapeSpecification. Une shape est définie par uneliste ordonnée d’entiers non nuls, où au plus une dimension estinfinie. Les éléments de la liste sont entourés par des accolades etséparés par des virgules, pendant que l’infini est représenté parle caractère étoile ;Exemple. Un tableau de données tridimensionnel représentant unflot infini d’images de taille 1920× 1080 est défini par la shape de{1920, 1080, ∗}.


integervector. Le type de vecteur de valeurs entiers est défini dansla bibliothèque MARTE (cf la Figure 45) comme une liste ordonnéedes valeurs entiers (possiblement zéro) et est défini par la listed’entiers entourés par des accolades et séparés par des virgules ;

integermatrix. Une matrice des valeurs entiers (cf la Figure 45) estreprésentée par une liste des vecteurs entiers, qui respectent ladéfinition précédente et qui ont la même taille.Observation. Dans la spécification MARTE, les matrices sont écrites

colonne par colonne. Par exemple, une matrice de(1 23 45 6

)est

représentée par {{1, 3, 5}, {2, 4, 6}}.

Fig. 45: Les types de données vecteur et matrice

Observation. La spécification des shapes ne peut pas contenir desvaleurs nulles, pendant que les vecteurs et les matrices ne peuventpas contenir des valeurs infinies.

Exemple. Dans l’Appendice A on peut retrouver la modélisation enMARTE de l’application de fenêtres glissantes modélisée avant enArray-OL. Sur les deux figures on peut clairement identifier les simili-tudes entre une modélisation en MARTE et la spécification Array-OL.

Nous allons nous intéresser par la suite à la validité d’une spécifica-tion en MARTE pour Gaspard2.

3.6.2 Règles de réduction vers une définition valide

Une modélisation Gaspard2 en utilisant UML et le profil MARTEest valide dans la sémantique de Gaspard2 si elle correspond à unedescription Array-OL correcte. Une description Array-OL peut êtredérivée à partir de la modélisation en MARTE par des transformationsun à un entre les concepts équivalents.

Néanmoins, ce choix fait que toutes restrictions du modèle de calculArray-OL doivent être respectées dans la modélisation en MARTEet détermine une complexité non nécessaire de point de vue de l’u-tilisateur. Le cas le plus souvent rencontré en pratique est causé parl’exclusion entre les structures composées et répétitives d’une tâche,qui fait que chacune des répétitions Array-OL doit contenir une seuletâche répétée. Pour faciliter la tâche de l’utilisateur et réduire la com-plexité de la description hiérarchique, nous avons choisi de permettredes modélisations simplifiées qui sont correctes même si elles ne re-spectent exactement la définition Array-OL, mais des règles précisesde transformation peuvent transformer une telle modélisation vers unedescription Array-OL correcte.


tâche répétitive-composée

Une tâche Array-OL peut être soit élémentaire, soit répétitive (uneseule sous-tâche répétée), soit composée (potentiellement plusieurssous-tâches, toutes non répétées). Dans la modélisation MARTE, lacoexistence des sous-tâches répétées et non répétées dans une décom-position est permise, si la spécification permet la transformation versune description Array-OL suite à une règle de transformation qui ditque, si la décomposition est de type répétitive-composé10, toutes les 10 Une tâche est

répétitive-composéesi elle contient aumoins deuxsous-tâches et aumoins une dessous-tâches estrépétée.

sous-tâches répétées sont transformées par l’introduction d’une tâcherépétée intermédiaire par sous-tâche répétée dans la hiérarchie et latransformation de tous les liens connectés à cette sous-tâche.

Tâche répétée-composée

(pd)

(pin) (sR,po)

(pr)

(sR)

rép

(pd) (pd)

(pi) (po)

d

θi = (Fi, oi, Pi)

ρ = (sR, sM, θs, θc)

Les ports qui n’appartient à aucune tâche expriment qu’ils peuvent ap-partenir à une tâche quelconque dans la description composée (des sous-tâches ou même de la tâche répétée-composée).

Fig. 46: Tâche répétitive-composée

Tâche composée

Tâche répétée générée

(pd)

(pin) (sR,po)

(pd)

(pin) (sR,po)

(pr)

(sR)

rép

(pd) (pd)

(pi) (po)

d

θi = (Fi, oi, Pi)

θid = (Fid,oid, Pid)

ρ = (sR, sM, θs, θc)

Fig. 47: Tâche répétitive-composée transformée

Un exemple est illustré sur la Figure 47, montrant la transformationde la tâche répétée composée de la Figure 46 dans une tâche composéecontenant une sous-tâche répétée, selon les règles suivantes :

déplacement des connecteurs. Les connecteurs connectés à larépétition, selon leur type, vont se retrouver soit à l’extérieur dela tâche générée (les connecteurs normaux et les reshapes), soit à


l’intérieur (les tilers, les dépendances interrépétition et les lienspar défaut).

changement des tailles des ports . Suite au déplacement desconnecteurs, les tailles des ports sur les bords de la tâche généréeauront des tailles différentes :– pour un tiler, la taille du tableau ((pin) sur les figures) ;– pour un lien par défaut, la taille n’est pas changée ((pd) sur les

figures) ;– pour les connecteurs normaux et les reshapes, la taille du l’es-

pace de répétition multipliée par la taille du port de la tâcherépétée ((sR,po) sur les figures) ;

tailles réelles des tableaux. Le changement des tailles selonla règle précédente nous indique que, dans une décompositionrépétitive-composée, la taille réelle des tableaux des sous-tâchesrépétées dépend du type de connecteur qui est connecté au port ;pour les connecteurs normaux et reshapes, la taille réelle desports est donnée par la concaténation des shapes de l’espace derépétition et du port. La spécification doit être fait en respectant lataille réelle des ports. Sur la Figure 46, la reshape ρ est entre un portde taille (sR,po) et un port de taille (pr) et donc le tiler sourceθs contient des matrices d’ajustage et de pavage et le vecteurd’origine avec des dimensions qui correspondent à la taille duport réel.

génération des connecteurs Le déplacement des tilers et desliens par défaut se fait avec la génération des connecteurs dans latâche composée ;

génération du tiler identité . Les connecteurs normaux et lesreshapes restent au niveau de la tâche composée, avec la généra-tion d’un tiler « identité »11 dans la répétition générée – un tiler11 Les matrices

d’ajustage et depavage ont uneformepseudo-identité.

qui place (sR) motifs de taille (po) dans un tableau de taille(sR,po),

θid =

oid = 0

Fid =

(0dim(sR)×dim(po)

Idim(po)

)

Pid =

(Idim(sR)

0dim(po)×dim(sR)

) , (3.2)

où In est une matrice carrée identité de taille n et 0n×m est unematrice nulle de taille n×m.Exemple. Le tiler identité qui place des motifs deux dimensionnelsdans un tableau avec cinq dimensions :

oid =

0

0

0

0

0

, Fid =

0 0

0 0

0 0

1 0

0 1

, Pid =

1 0 0

0 1 0

0 0 1

0 0 0

0 0 0

.

3.7 modélisation des architectures

La modélisation conjointe de l’application et de l’architecture d’unsystème permet d’avoir une vison d’ensemble du système et facilite

3.7 modélisation des architectures 77

l’exploration de l’espace de modélisation et des optimisations au niveaude la spécification.

3.7.1 État de l’art

L’architecture d’un système est l’étape initiale dans la conception quiaide à déterminer les paramètres globaux du système et des contraintesliées à la fonctionnalité, la maintenabilité, la gestion des ressources,performances, etc. Usuellement, dans des langages tels que les ADLs,Architecture Description Langages – Langages de description des architec-tures –, des systèmes complexes d’architectures sont modélisés suivantun modèle orienté composants, où l’interaction entre les modules sefait par une infrastructure [54] contenant normalement des composants,des ports, des connecteurs, etc.

UML propose une infrastructure orientée composants et une manièrefacile de faire des extensions et des spécialisations, à travers les profilsUML. Plusieurs profils UML ont été développés pour la conceptiondes systèmes embarqués temps réels et plusieurs d’entre eux ont étéstandardisés. Deux catégories majeurs peuvent être identifiées :

a. les profils orientés vers des implémentations de nivaux bas quis’intéressent à la réalisation des circuits, telles que UML forSoC [77] ou UML for SystemC [82] ;

b. les profils qui visent la modélisation des systèmes dans une per-spective fonctionnelle. Dans cette catégorie on peut citer SPT(Schedulability, Performance and Time) [76], ¨et le premier stan-dard proposé par OMG pour l’ingénierie système, SysML (SystemModeling Language) [74].

SysML est un standard OMG qui fournit des mécanismes génériquespour la description de systèmes complexes. SysML n’apporte cepen-dant pas une attention particulière aux systèmes embarqués, comme lefait le profil pour la modélisation et l’analyse des systèmes embarquéset temps réel MARTE. Même si SysML est utilisé par la communautépour la conception des SoC, le standard n’était pas créé spécialementpour le domaine des systèmes embarqués et un nombre de propriétésnon fonctionnelles telles que des contraintes de temps, de latence etde débit qui sont cruciales pour le design de systèmes temps réelssont absentes du profil. Ce n’est pas le cas du profil UML MARTE,qui fournit entre autres des concepts précis pour la description desdétails d’architectures matérielles dans les SoCs. Dans le cas de simili-tudes entre des concepts du profil SysML avec des concepts du profilMARTE, MARTE réutilise les stéréotypes définis par SysML ou définitdes éléments qui sont conceptuellement et terminologiquement alignéssur SysML. MARTE raffine les concepts de temps proposés dans leprofil SPT (Scheduling, Performance and Time) [73] ce qui permet lamodélisation de temps logique, discret et continu. Les modèles con-formes au profil MARTE peuvent être annotés par des propriétés nonfonctionnelles dans le but d’exprimer des contraintes auxquelles lesystème est soumis (contraintes de temps, de consommation d’énergie,etc.)

Plusieurs projets s’intéressent à la comodélisation Software/Hard-ware pour MPSoC mais seulement une partie d’entre eux intègre uneméthodologie IDM ou utilisent des spécifications propres non stan-


dards. On peut mentionner ROSES [90], MILAN [64], MOPCOM [2] ouMARTES [42].

Dans cette thèse nous nous intéressons plutôt aux aspects de lamodélisation répétitive dans le contexte de la co-modélisation MPSoC.Par l’utilisation conjointe des paquetages HRM et RSM de MARTE,nous pouvons modéliser des architectures répétitives sous une formecompacte et cela facilite le placement uniforme de l’application sur cesarchitectures.

3.7.2 Modéliser des architectures répétées

Gaspard2 est un environnement de comodélisation qui permet aussila modélisation des architectures matérielles et du placement des appli-cations sur ces architectures. En utilisant les mêmes concepts de RSM(répétitions, tilers, shapes, etc.), des architectures répétitives peuventêtre modélisées sous une forme compacte.

L’environnement MMAlpha qui implémente le langage fonction-nel Alpha, discuté dans la sous-section 1.4.1 permet la synthèse desarchitectures régulières (et parallèles) à partir la description par deséquations récurrentes. Mozipo et al. présentent dans [66] la générationdes circuits VLSI (des tableaux systoliques) pour le filtrage Kalman.En utilisant l’environnement MMAlpha pour résoudre le problèmede programmation linéaire entre les variables, les auteurs arrivent àgénérer une architecture systolique où le parallélisme est maximal. Bed-nara et Teich dans [8] visent le placement automatique des programmescontenant des nids de boucles sur des architectures hardware recon-figurables en utilisant l’outil de design PARO. Les deux propositionsvisent la génération automatique du code VHDL synthétisable pourl’implémentation en FPGA des tableaux de processeurs systoliques.

L’environnement Gaspard2 est aussi capable de générer du codeVHDL pour la synthèse de FPGA, mais on ne peut pas prétendred’attendre les performances de MMAlpha, même si les modules VHDLgénérés reflètent la spécification de haut niveau et des transformationsde haut niveau peuvent être utilisées pour améliorer les performances.

La modélisation répétitive en MARTE des architecture vise plutôtl’expression compacte des architectures répétitives qui facilite énormé-ment la spécification et permet une exploration des distributions descalculs sur les unités de calculs parallèles. Une modélisation compactepeut être expansée par une transformation de mise à plat qui replaceles répétitions avec des copies réelles et les liens de topologie avec desliens de connexion élémentaires.

3.7.3 Concepts répétitifs dans des structures non applicatives

La définition statique Array-OL introduit des contraintes dans la spé-cification des applications en MARTE pour Gaspard2. Ces contraintesconcernent surtout les liens topologiques et sont là pour garantir la déf-inition statique de la modélisation. Les règles de spécification assurentl’assignation unique et la production entière de tous les éléments destableaux.

Dans les modélisations non applicatives, les concepts répétitifs ontune signification légèrement différente. Les liens topologiques n’expri-ment plus des dépendances de données, mais des liens physiques entredes unités matérielles et les règles de la définition statique Array-OL

3.7 modélisation des architectures 79

ne s’appliquent plus. Par la suite nous allons voir quels sont les change-ments le plus importants dans la modélisation et leur signification.

Ports « InOut »

MARTE permet la spécification des ports de flot bidirectionnels –entrée-sortie – pour exprimer dans l’architecture des canaux de com-munication avec double sens. L’étiquette de direction du stéréotypeFlowPort permet la spécification de la direction d’un port dans un mod-èle MARTE, DirectionKind::in, DirectionKind::out, ou DirectionKind::inout.

Tilers non tuilés parfaitement

Dans la spécification des applications Array-OL, les tilers de sor-tie (ceux qui réarrangent les motifs produits par la répétition dansles tableaux de sortie) doivent tuiler parfaitement les tableaux de sor-tie ; tous les éléments des tableaux sont produits et les tuiles ne sechevauchent pas. Dans la modélisation des architectures, cette con-trainte ne s’applique plus et les structures répétitives sont plus flexibles.La même remarque s’applique aussi aux tilers des reshapes.

Dépendances interrépétitions cycliques

Les dépendances interrépétitions dans la spécification de l’appli-cation sont obligatoirement non cycliques. Une éventuelle présenced’une dépendance cyclique introduirait des dépendances de donnéescycliques et donc des points de blocage dans l’exécution. Néanmoins,dans la modélisation de l’architecture, ce type de dépendance est per-mis et est très utile pour exprimer des constructions telles que desanneaux de processeurs interconnectés. Un exemple d’une telle con-struction est montré sur la Figure 48, qui spécifie des structures de laFigure 49, où les répétitions sont mises à plat.

(a) Dépendances non-cycliques (b) Dépendances cycliques

Fig. 48: Grille de processeurs interconnectée - modélisation MARTE RSM

Interrépétition sur le même port

Les ports de la modélisation de l’architecture peuvent être bidirection-nels (inout) et ainsi une dépendance inter-répétition, qui par définitionest entre un port de sortie et un port d’entrée, peut être définie sur lemême port bidirectionnel. Figure 50 montre une telle construction.


(a) Dépendances non-cycliques (b) Dépendances cycliques

Fig. 49: Grille de processeurs inter-connectées

(a) Modèle UML (b) Topologie mise-à-plat

Fig. 50: Dépendance sur le même port

Reshape sur le même port

La décomposition répétitive permet la spécification compacte desarchitectures régulières. Des constructions plus complexes peuvent êtremodélisées en faisant usage de la hiérarchie. Pour spécifier des liensmoins réguliers, la construction de reshape peut être employée. Elle estcapable d’exprimer des liens :

– entre seules parties des éléments des deux ensembles de portsconnectés ;

– de plusieurs éléments vers un ou de un vers plusieurs ;– réarrangeant des éléments dans des tableaux multidimensionnels ;– etc.Le reshape peut être utilisé sur le même port, cas où il exprime

des liens entre les éléments du même tableau. Cela permettrait parexemple la spécification des inter-connexions moins réguliers que lesdépendances interrépétition.

Exemple. Dans l’Appendice B, la modélisation d’une architecture NoCest montrée. La décomposition hiérarchique et les concepts répétitifsde MARTE RSM sont utilisés pour exprimer sur une forme compacteune architecture où la régularité n’est pas directement exprimable parles concepts répétitifs de base.

Après avoir discuté des aspects de la modélisation répétitive desapplications et des architectures en MARTE, nous allons nous penchersur le placement des applications sur les architectures.

3.8 placement répétitif 81

3.8 placement répétitif

Le profil MARTE permet la comodélisation de l’application et de laplateforme d’exécution. Les deux sont spécifiés séparément au début,suivi par le placement de l’application sur l’architecture matérielle pourexprimer le système complet.

Le placement efficace des calculs sur les unités d’exécution est unaspect essentiel de la comodélisation pour des systèmes embarqués.Celui a une influence forte sur les performances et un rôle importantsur le plan de la consomption en énergie. Pour permettre un placementoptimal, plusieurs possibilités devront être testées et comparées.

Le concept de placement est présent en MARTE (paquetage Alloc) etdans RSM une extension répétitive est proposée.

3.8.1 Allocation

Une allocation MARTE est une association entre un applicationMARTE et une plateforme d’exécution MARTE. L’ensemble de toutesles allocations du modèle définit le placement complet.

Le concept principal est représenté par le stéréotype « Allocate »,utilisé pour spécifies des associations entre les éléments du modèle del’application et des éléments du modèle de l’architecture.

L’allocation peut représenter soit un placement spatial soit un place-ment temporel. Le placement spatial est le placement des calculs sur desressources de calcul, des données sur des mémoires à des plages spéci-fiques d’adresses et des dépendances entre des ressources logicielles etdes ressources de communication. Le placement temporel représentel’ordonnancement d’une série d’éléments placés sur la même ressourcematérielle. Par exemple, plusieurs tâches peuvent être placées sur lemême processeur ou une plage d’adresses peut être utilisée aux in-stances différentes de temps pour contenir des données différentes. Uneallocation est valide si les deux types d’allocation, spatiale et temporelle,sont consistants.

3.8.2 Distribution

Nous avons vu comment les constructions de MARTE RSM per-mettent en même temps la spécification répétitive du parallélismedisponible dans l’application et la spécification compacte des architec-tures répétées. Dans les deux cas, les répétitions sont exprimées avecl’aide des espaces multidimensionnels. Le placement de telles applica-tions sur de telles architectures peut se faire d’une manière distribuée,en utilisant un concept qui englobe le reshape et l’allocation, la distri-bution entre des éléments répétés dans un modèle d’application et deséléments répétés dans un modèle d’architecture. Le sujet est abordé parBoulet et al. dans [15].

La Figure 51 montre le concept de distribution dans le profil MARTE.Ce concept peut être employé pour exprimer des distributions uni-

formes :

a. des répétitions sur des unités de calculs parallèles ;

b. des tableaux sur des mémoires distribués.

Quelques observations sur telles constructions sont nécessaires :– chaque répétition doit être placée sur une unique unité de calcul ;


Fig. 51: Distribute en MARTE RSM

– chaque élément du tableau doit être placé sur une unique mémoire.Ces observations se traduisent sur la contrainte que le tiler source doitpaver exactement l’espace multidimensionnel source.

Exemple. La Figure 52 montre la distribution par colonne d’une répéti-tion bidimensionnelle sur 4 processeurs.

Fig. 52: Distribution d’une répétition de 4× 4 sur 4 processeurs

Les deux répétitions et le placement sont montrés sur la Figure 53.

3.9 conclusions 83

Répétition tâche Répétition processeurs

Fig. 53: Placement des répétitions de la distribution

3.9 conclusions

Dans ce chapitre nous avons vu comment le profil UML de MARTEpeut être utilisé pour la comodélisation des applications de traitementintensif de signal sur SoC. Nous nous sommes intéressés surtout àl’aspect répétitif de la modélisation en MARTE RSM, qui permet la mod-élisation du parallélisme dans l’application, des architectures répétéessous une forme compacte et une allocation distribuée de l’applicationsur l’architecture.

Toutes les concepts de topologie répétitive d’Array-OL se retrouventdans la modélisation MARTE et une modélisation en MARTE est équiv-alente ou peut être réduite au modèle de calcul Array-OL et donc lamodélisation d’une application conserve la propriété de la définitionstatique qui offre la possibilité de calcul statique d’un ordonnancement.

Nous avons vu aussi comment les concepts de topologie répétitiveont une sémantique et une signification légèrement différente dansla modélisation de l’architecture. La représentation compacte d’unearchitecture répétée facilite la modélisation – surtout quand il s’agit desarchitectures complexes avec un nombre important d’unités intercon-nectées – et permet l’exploration pour un placement performant.

Dans les chapitres suivants, nous allons nous intéresser aux aspectsliés à l’exécution et aux optimisations de haut niveau pour adapter laspécification à l’exécution.

Deuxième partie

D E L A S P É C I F I C AT I O N V E R S L’ E X É C U T I O N

4O P T I M I S AT I O N S S O U R C E À S O U R C E

4.1 Étude de l’exécution 874.1.1 Modèle d’exécution immédiat 88

4.1.2 Refactoring pour l’adaptation de la spécifi-cation vers l’exécution 89

4.2 Optimisations du code 894.2.1 Transformations de boucles 90

4.2.2 Techniques d’optimisation des boucles 92

4.2.3 Fonctionnement de l’optimisation des boucles 93

4.3 Conclusions 95

Dans les chapitres précédents, nous avons discuté de la comodélisa-tion répétitive pour des applications de traitement intensif de signaldans le contexte des systèmes embarqués. La qualité de la spécificationest essentielle pour arriver à générer du code performant. Un modèle despécification exprime la fonctionnalité d’une application, en exprimanttoutes les dépendances de données, mais une telle spécification ne ditrien sur la façon dont exécuter l’application.

Tous les ordonnancements d’exécution qui respectent les dépen-dances de données sont corrects. Mais lequel est l’ordonnancementoptimal ? Ce problème est complexe et dans l’équipe nous avons choisid’utiliser des optimisations à plusieurs niveaux d’abstraction. Des op-timisations de haut niveau visent l’adaptation de la spécification àl’exécution, en réduisant les tableaux intermédiaires et changeant lagranularité de l’application. Un passage direct à un modèle d’exécutionest fait, ayant comme avantages que la structure de l’application seretrouve à l’exécution et que le concepteur a un degré de contrôle surle code généré et exécuté, mais on peut perdre en performances.

Avant de s’intéresser aux optimisations de haut niveau dans le con-texte de la spécification en MARTE, nous allons discuter du passageà l’exécution et des techniques d’optimisation basées sur des transfor-mations de boucles, qui partagent des éléments en commun avec lestransformations Array-OL, mais à un autre niveau d’abstraction.

La section 4.1 analyse l’exécution d’une spécification Array-OL etdans section 4.2 nous faisons état des techniques d’optimisations decode par des transformations de boucles.

4.1 étude de l’exécution

Une spécification MARTE RSM exprime le maximum de parallélisme,en utilisant une décomposition hiérarchique et répétitive. Elle décritles dépendances de données entre les éléments des tableaux et, commeconséquence directe, un ordre partiel strict entre les appels des tâches.Une spécification valide dans le sens de Gaspard2 doit être définiestatiquement et ainsi admettre un ordre partiel strict. Effectivement,quelconque ordonnancement qui respecte cet ordre calculera les mêmesvaleurs de sortie à partir des mêmes entrées.

87

88 optimisations source à source

Les règles de construction qui assurent la validité d’une spécificationsont rappelées dans la section 2.4.

Un modèle d’exécution représente l’abstraction de l’exécution et il doitrespecter l’ordre partiel strict défini par la spécification statique. En ex-primant l’ordre minimal d’exécution, de nombreuses décisions peuventet doivent êtres prises au moment du placement d’une spécificationMARTE sur une plateforme d’exécution :

a. comment associer les différentes répétitions en temps ou espace ?

b. comment placer les tableaux dans la mémoire ?

c. comment ordonnancer les tâches parallèles sur la même unité decalcul ?

d. comment ordonnancer les communications entre les unités decalculs ?

La séparation entre l’association espace-temps et la spécificationfonctionnelle est un des points forts de la modélisation en MARTE.Cela permet la construction des bibliothèques fonctionnelles pour laréutilisation et d’effectuer des explorations architecturales avec lesmoins de restrictions possibles.

Les premiers travaux sur l’exécution d’une application conforme aumodèle de calcul Array-OL sans hiérarchie ont été réalisés par Ancourtet al. dans le cadre d’une collaboration avec TUS1 [4] en 1997. Ces1 TUS = Thales

UnderwaterSystems.

travaux étudient l’ordonnancement et le placement automatique d’uneapplication sur une architecture SPMD.

Ils proposent pour cela d’utiliser un modèle concurrent de program-mation logique par contrainte (CCLP) [31, 43]. Les contraintes sontétablies à partir d’une formalisation de l’architecture, de l’application etdu placement. Il est ainsi possible de tenir compte d’un grand nombrede paramètres au cours de la formalisation : le nombre de processeurs,la taille de la mémoire, la latence maximale entre les entrées et lessorties, etc. Les contraintes sont passées à un outil de résolution quiutilise un ensemble d’heuristiques pour obtenir : un ordonnancementdes calculs, un placement de ces calculs sur les processeurs et unegestion optimisée de la mémoire.

Au final, cette méthode est capable de générer automatiquement unordonnancement séquentiel, pipeline ou data-parallèle, mais sans toute-fois garantir que cet ordonnancement soit optimum. Afin d’améliorer laqualité des résultats, Ancourt et al. proposent de restructurer l’applica-tion pour obtenir un plus haut degré de parallélisme et pour améliorerla localité des données. Les outils de refactoring décrits dans cette thèsepourraient donc être utilisés en aval de ces calculs d’ordonnancement.

4.1.1 Modèle d’exécution immédiat

Nous avons choisi pour le passage d’une spécification MARTE versun modèle d’exécution de le faire le plus directement possible : lemodèle d’exécution devrait refléter la spécification. Ce choix a l’avantage degarder des similitudes avec la structure de la spécification (parallélisme,granularité) dans l’exécution, au moins jusqu’à la génération de codequand des optimisations de bas-niveau entrent en jeu.

Exemple. Un exemple représentatif est la génération de code VHDLutilisé par la suite pour la synthèse des circuits FPGA2, où la structure2 Disponible dans

l’environnementGaspard2.

de la spécification se retrouve au niveau des modules VHDL et de ladisposition FPGA.

4.2 optimisations du code 89

Le choix de ce modèle d’exécution a ses désavantages naturelle-ment. Un autre choix pourrait être un modèle d’exécution dérivé desdépendances exactes de la spécification, suite aux règles formellesqui définissent les dépendances globales au niveau des éléments destableaux. Une telle direction risque de réduire le contrôle du mod-eleur sur l’exécution, mais les gaines en performances pourront êtreimportantes.

Ce passage direct se traduit par la contrainte qui dit qu’une tâchene peut commencer son exécution que quand les tableaux d’entréessont entièrement disponibles. Cette contrainte introduit un problèmemajeur, ce que nous appelons des « barrières de synchronisation » entreles composants. Une telle barrière est créée par les dépendances de Exemple de blocage :

une tâche attendqu’une autre finît deproduire un tableauinfini.

données et une illustration représentative est la présence d’un tableauintermédiaire avec une dimension infinie qui va causer un blocage dansl’exécution dans ce point. Comme solution, certaines répétitions peu-vent être transformées en flots, l’exécution des répétitions est séquen-tialisée (ou pipelinée) et les motifs sont consommés et produits commeun flot de jetons (chaque jeton transportant un motif).

4.1.2 Refactoring pour l’adaptation de la spécification vers l’exécution

Le refactoring de l’application pour l’adaptation de la spécification aupassage à l’exécution joue un rôle important dans le but d’augmenterles performances du code généré.

En utilisant des transformations de haut niveau data-parallèles, lerefactoring permet le changement de la granularité des répétitionsdans la description répétitive, la réduction des tableau intermédiaireset l’augmentation de la localité des données. Il facilite l’explorationde l’espace de conception pour prendre en compte les contraintes deressources et de l’environnement.

Ce sont des outils d’optimisation au niveau haut de la spécification etils se traduisent par des changements dans la spécification ; l’utilisationd’autres optimisations à un niveau bas est toujours possible. Par l’util-isation d’un modèle d’exécution immédiat, les optimisations de hautniveau peuvent être guidées par la simulation du système au niveau del’implémentation3. 3 Dans

l’environnementGaspard2, lasimulation peut sefaire en SystemC auniveau TLM.

Les transformations data-parallèles ressemblent aux transformationsde boucles usuelles, mais au niveau de la spécification. Les techniquesd’optimisation basées sur les transformations de boucles sont résuméesbrièvement par la suite pour identifier des connexions avec les transfor-mations Array-OL.

4.2 optimisations du code

Le décalage entre les performances de pointe clamées des construc-teurs et celles achevées avec le code réel a radicalement augmentédernièrement, principalement à cause de l’augmentation brutale de lacomplexité des processeurs qui a entraîné une dégradation importantede l’efficacité du code généré par les compilateurs.

Les trois directions principales pour améliorer les performances sont :1. accroître le parallélisme au niveau des instructions en même

temps que de multiplier les mécanismes permettant l’exécutionsimultanément des instructions et réduisant le plus possible leurlatence ;


2. faire évoluer les mécanismes spéculatifs permettant la prédictiondu comportement local des programmes ;

3. implémenter des hiérarchies mémoires complexes pour exploiterle mieux la localité des données, spatiale ou temporale.

Pour toutes ces directions, les techniques de transformations decode « source à source » ont un rôle déterminant. La plupart de cestechniques sont représentées par des transformations appliquées auxnids de boucles « for » qui peuvent être utilisés dans deux sens :

a. augmenter le parallélisme des instructions ;

b. améliorer la régularité et la localité des accès aux données et, enplus, l’élimination des tampons au niveau système dans le code.

Ces transformations peuvent être utilisées surtout dans le cas ducode extrêmement régulier qui contient du code de traitement desdonnées fortement uniforme. Cela favorise le domaine d’applicationdu traitement de signal intensif orienté flot de données.

La plupart des transformations qui visent l’optimisation des pro-grammes pour des monoprocesseurs réduisent le nombre d’instruc-tions exécutées par l’analyse des quantités scalaires et des techniquesorientées flot de données. En revanche, les optimisations pour des pro-cesseurs haute-performance, vectoriels ou parallèles visent à maximiserle parallélisme et la localité mémoire, avec des transformations qui sebasent sur le repérage des caractéristiques des tableaux en utilisant desanalyses des dépendances de boucles.

4.2.1 Transformations de boucles

Une technique importante au niveau système, la technique des trans-formations des boucles « for » vise l’augmentation de la régularité etde la localité des accès aux données en permettant la suppression (oula réduction) des tampons dans le code. Ainsi, elle permet la réductiondes besoins en taille mémoire globale et les latences des accès mémoire.Il est vital pour la taille, la consommation d’énergie et les performancesdes systèmes embarqués. Une régularité et une localité améliorée aug-mentent le ratio de réutilisation des emplacements mémoire, puisquedes zones mémoire peuvent être utilisées pour des éléments de donnéesavec des durées de vie non chevauchantes. Cela, à son tour, réduit lesbesoins en taille mémoire globale. L’amélioration de la régularité desaccès aux données peut aussi augmenter le degré de parallélisme d’uneapplication.

Nous n’avons pas l’intention de faire une liste complète des transfor-mations de code existantes, le sujet et extrêmement complexe et a été aucœur de nombreuses études, tels que Zima et Chapman en [94], Darteet al. en [23], Kennedy et Allen en [51] ou Wolfe en [92]. Bacon et al. don-nent dans [7] un vue d’ensemble sur les techniques de restructurationautour des boucles dans un langage impératif.

Les méthodes de transformation de boucles peuvent être classéesselon différents critères et leur rôle peut changer en fonction de l’archi-tecture ciblée et des objectifs ; augmenter le parallélisme et la réductionde la taille mémoire peuvent être des objectifs divergents dans certainscas.

Dans le cadre du projet Ter@ops4 du pôle de compétitivité Sys-4 http:

//teraops-emb.

ief.u-psud.fr/tem@tic, un glossaire des transformations de code a été établi, relative-ment aux différents outils participants au projet et leurs techniques

http://teraops-emb.ief.u-psud.fr/




d’optimisations5. Plusieurs types de transformations de code ont été 5 http:

//www.ief.u-psud.

fr/~tadonki/

projects/teraops/

glossaire/

identifiés :

modification de l’allocation mémoire : renommage de sca-laires, expansion de scalaires/tableaux, remplacement d’un tableauglobal par un scalaire privé, etc. ;

transformations de boucles : découpage de l’espace d’itéra-tions, déroulage (partiel ou complet) de boucle, fusion de boucles,fission de boucles, découpage de l’espace d’itérations et beaucoupd’autres ;

transformations inter-procédurales : déplacement desboucles entre l’extérieur et l’intérieur d’une procédure (ou l’in-verse), le remplacement d’un appel de procédure par son corps,etc. ;

élimination du code inutile.

Ces transformations de code, même si elles sont la plupart de tempsutilisées autour les boucles, sont liées aussi aux concepts du codeimpératif : scalaires, procédures, itérations de boucles. Dans le contextede la spécification répétitive en MARTE, les répétitions peuvent êtrevus comme des nids de boucles avec une structure à part, sans desvariables locales, scalaires, conflits de données et appels aux procédures.Dans ce sens, nous allons restreindre notre intérêt aux transformationsde nids boucles parfaits.

Nous allons montrer une sélection des transformations importantesdans le contexte de cette thèse :

déplacement du code qui change l’ordre d’exécution entre deuxboucles dans le code, sans changer les boucles elles-mêmes. Latransformation peut être utilisée pour augmenter la localité desdonnées ou comme support pour des autres transformations.

fusion de boucles qui groupe plusieurs boucles successives dansune seule. Elle peut être utilisée pour réduire les tableaux inter-médiaires et ainsi les besoins en taille mémoire.

scission de boucles qui effectue l’opération inverse de la fusion etqui essaye de simplifier une boucle ou d’éliminer des dépendancesen cassant la boucle en multiples boucles avec le même corpsde boucle, mais itère sur des portions continues différentes del’espace initial d’itération. Elle peut être utilisée aussi pour séparerles instructions parallèles du reste.

tiling (ou partage) de boucles augmente le niveau de nidifica-tion d’une boucle. L’effet est que l’espace d’itération est diviséen blocs qui sont traités en séquentiel. Le partage de l’espaced’itération entraîne le découpage des grands tableaux en blocsplus petits et ainsi on peut rentrer les éléments accédés dans lecache, améliorer la réutilisation du cache et réduire les besoins entaille de cache.

déroulage de boucles réduit le nombre d’itérations en dédou-blant les mêmes instructions dans le corps de la boucle, dansle but de limiter l’évaluation de la condition de la boucle et dessauts, qui pénalisent la performance en affectant le pipeline desinstructions.

pipeline de boucles (alignement ou pliage) décale certainesinstructions d’une ou plusieurs itérations dans la boucle. Cette

http://www.ief.u-psud.fr/~tadonki/projects/teraops/glossaire/






transformation est utilisée pour améliorer la localité des donnéeset peut être aussi utilisée comme transformation support.

effondrement de boucles est l’inverse du tiling. Les deux peu-vent être utilisées comme outils de manipulation du concept deblocs de données dans l’application, essentiel pour la localité desdonnées et le parallélisme.

Toutes ces transformations et encore beaucoup plus6 sont utilisées6 Lestransformationslistées sont qu’unsous-ensemble destransformations deboucles existantes.

ensemble pour attendre les meilleures performances. Le choix destransformations à appliquer et l’ordre sont essentiels et peut dépendredu but final de l’optimisation.

4.2.2 Techniques d’optimisation des boucles

Typiquement, une optimisation du code au niveau du compilateurconsiste en trois pas :

1. choisir une partie de code à optimiser et l’enchaînement de trans-formations à appliquer ;

2. vérifier la conformité de l’optimisation ;

3. et en dernier, appliquer les transformations.

La première étape est la plus laborieuse et parce que l’analyse estcoûteuse, des obstacles d’ingénierie très souvent mettent des contraintessur les stratégies d’optimisation disponible au compilateur. Commel’architecture du processeur est de plus en plus complexe, le nombrede dimensions dans lequel l’optimisation est possible augmente, ce quirend le processus de décision extrêmement complexe.

La conformité d’une transformation et un aspect extrêmement im-portant dans le contexte des optimisations de code. Nous devrons nousassurer que l’application d’une transformation (ou d’une série de trans-formations) ne modifie pas le fonctionnement du code. Les restrictionssont usuellement exprimées sous la forme de dépendances (de donnéesou de contrôle). La partie complexe des optimisations est l’identificationdes transformations correctes (qui ne changent pas les dépendancesdans l’application) et le choix de la chaîne optimale de transformationspour atteindre nos objectifs.

Un algorithme parfait d’optimisation celui que l’un proposé parKennedy et McKinley pour la réutilisation maximale par des fusionsdes boucles est prouvé extrêmement coûteux en termes de complexité,temps et ressources [52] – problème NP-complet – et cela a conduit àl’utilisation extensive des heuristiques. La plupart des compilateursintègrent une série de décisions heuristiques relatives aux ordonnance-ments des transformations susceptibles de fonctionner avec des bonsrésultats sur la/les machine(s) cible. Les optimisations peuvent prendreplace à des phases distinctes de la compilation, il n’y a pas d’organi-sation définitive. Des architectures dissemblables dictent des designsdifférents et les opinions sur le meilleur ordre font polémique. Ba-con et al. présentent un tel design dans [7] pour donner une idée surcomment les transformations s’assemblent.

La complexité des algorithmes d’optimisation est une raison pourlaquelle beaucoup de compilateurs (pour ne pas dire la plupart) utilisentencore des heuristiques. Cela implique l’utilisation de la même chaînede transformations, celle qui statiquement démontre les meilleurs résul-tats dans la plupart des cas. Des compilateurs plus complexes disposent


de plusieurs chaînes de transformations d’où choisir, selon les carac-téristiques de l’application.

La compilation itérative [39, 53] est une approche répandue pourl’optimisation des programmes pour des objectifs variés sur des archi-tectures d’une complexité sans cesse croissante, lorsque les compilateurstraditionnels ne parviennent pas à offrir la meilleure performance pos-sible. Car construire des modèles détaillés de coût statique pour lesarchitectures modernes et dynamiques n’est pas plus possible, la com-pilation itérative s’appuyer sur le mécanisme où des transformationssuccessives ont été appliquées à un programme et leur une valeur déter-minée par l’exécution effective du code qui en résulte. Un grand nombrede différentes versions du programme sont générées et exécutées, avecla plus rapide version sélectionnée. Une telle approche est décidableet, étant donné suffisamment de temps, sera trouvé le meilleur pro-gramme. L’inconvénient évident est que le temps de compilation defaçon spectaculaire augmentations.

La complexité du sujet a suscité la nécessité de concevoir des moyensde représentation du problème (contraintes, transformations, fonctionde coût) utilisant un formalisme plus efficace qui pourrait faciliter lamanipulation des concepts tels que la conformité, les dépendancesde données et de contrôle, les objectifs d’optimisation. Certains ontapproché le thème en utilisant l’algèbre linéaire (Feautrier en [36]), ab-straction polyédrale (Girbal en [41]), algorithmes de la théorie des graphesou la programmation linéaire entière (Fraboulet en [38]). Toutes les ap-proches ont en commun, à part du fait d’obtenir une solution presqueoptimale, la forte complexité.

L’introduction du formalisme est une prémisse importante pourla partie décisionnelle de l’optimisation. Des algorithmes corrects etefficaces ont besoins d’être conçus autour de tels formalismes.

4.2.3 Fonctionnement de l’optimisation des boucles

Pour mieux comprendre l’utilisation des transformations de boucles,un exemple pourrait être plus approprié. L’exemple classique qui suitprésente la fonctionnalité de la transformation de fusion de boucles.

Exemple. Ici, un tableau est écrit dans une boucle et lu dans une autre.Entre les deux boucles, les tableaux doivent être gardés en mémoire.

1: for i = 1 to n do2: A[i] = expr13: end for4: for i = 1 to n do5: expr2 = f(A[i])

6: end for

La technique de fusion des boucles permet le groupement de plusieursboucles dans une seule. Le résultat peut être observé ci-dessous :

1: for i = 1 to n do2: A[i] = expr13: expr2 = f(A[i])

4: end for

La fusion n’a pas d’impact sur la consomption en taille mémoire.C’est parce que la fusion des boucles ne travaille pas toute seule. Elle estutilisée en collaboration avec des autres transformations, le replacement


scalaire dans ce cas. Cette technique peut supprimer des tableaux entiersde la mémoire, en les remplaçant avec des scalaires, comme montréci-dessous.

Exemple. Ce remplacement et correct seulement si les valeurs de tableauA produites par la première boucle ne sont pas utilisées ailleurs.

1: for i = 1 to n do2: a = expr13: expr2 = f(a)

4: end for

Observation. Le remplacement du tableau A avec un scalaire réduit lesbesoins en taille mémoire, mais élimine le parallélisme de la boucle :avant le remplacement scalaire, la boucle était complètement parallèlealors qu’après elle est séquentialisée par le conflit d’écriture sur lamême variable.

Les dépendances peuvent être compliquées et ne pas permettre lasuppression des tableaux entiers. Dans ce cas, d’autres techniquespeuvent être employées, telles que l’optimisation de l’ordre de stockageintratableau7, qui sert à calculer une fenêtre de référence pour le tableau7 Intra-array storage

order optimization enanglais.

et à plier le tableau. Le fonctionnement est illustré sur l’exemple quisuit.

Exemple. Le code

1: for i = 1 to n do2: A[i] = expr13: end for4: for i = 1 to n do5: expr2 = f(A[i− 1], A[i])

6: end for

est transformé en

1: for i = 1 to n do2: a[i%2] = expr13: expr2 = f(a[i%2− 1], a[i%2])4: end for

par la fusion des boucles en collaboration avec l’optimisation de l’ordrede stockage intratableau.

Comme montrée sur les exemples précédents, la fusion des bouclespeut être un outil puissant si utilisé en association avec d’autres trans-formations, permettant la réduction des tableaux intermédiaires et lesbesoins en taille mémoire. Les exemples en haut sont très simples ; pourdes applications réelles, les décisions sont considérablement plus com-plexes, mais la manipulation d’une manière très régulière qu’on peutretrouver dans les applications orientées flots de données telles quedes traitements multimédias font que ces techniques sont extrêmementefficaces.

Le problème d’optimisation basé sur des transformations de bouclespour une partie du code source peut être réduit à :

Trouver l’enchaînement optimal des transformations de bouclesqui, appliqués sur le code d’entrée, maximiseraient la fonction decoût associé et en même temps garantirait la conformité du codede sortie.

4.3 conclusions 95

4.3 conclusions

Les techniques d’optimisation de code par des transformations deboucles sont largement utilisées dans les compilateurs et leurs per-formances sont directement influencées par la structure du code : lesnids de boucles parfaits facilitent la tâche du compilateur, pend que laprésence des pointeurs rendre l’analyse des dépendances extrêmementcomplexe.

Une description répétitive en MARTE peut être vue comme unestructure spéciale de nids de boucles avec des caractéristiques quifavorisent l’utilisation de techniques similaires aux transformations deboucles usuelles, mais à un niveau haut de la spécification.

Nous allons voir par la suite comment les structures répétées deMARTE peuvent être représentés comme nids de boucles parfaits etdata-parallèles et comment des transformations data-parallèles ont étéconçues autour, en utilisant un formalisme basé sur l’algèbre linéairepour exprimer les concepts de dépendances, conformité et objectif.

5R E FA C T O R I N G E N U T I L I S A N T D E ST R A N S F O R M AT I O N S D E H A U T N I V E A U

5.1 Répétitions sous la forme de boucles 985.2 Formalisme ODT 100

5.2.1 Opérateurs ODT 101

5.2.2 Propriétés des ODT 102

5.2.3 Représentation d’une répétition en ODT 102

5.2.4 Utilisation des ODT 105

5.3 Transformations data-parallèles 1065.3.1 Fusion 106

5.3.2 Changement du pavage 111

5.3.3 Aplatissement 115

5.3.4 Tiling 117

5.3.5 Conclusions sur l’utilisation des transfor-mations 118

5.4 Extensions 1195.4.1 Agrandissement linéaire sans recalculs 121

5.4.2 Fusions multiples 121

5.4.3 Tableau intermédiaire consommé plusieursfois 124

5.4.4 Résumé 126

5.5 Comparaison avec les transformations de boucles 1265.6 Conclusions 129

Dans ce chapitre nous nous intéressons aux transformations de haut-niveau data-parallèles conçus autour la description répétitive. Ces trans-formations partagent des caractéristiques avec les transformations deboucles que nous avons vues mais qui agissent au niveau haut de laspécification multidimensionnelle.

Nous commençons dans la section 5.1 par montrer comment unedescription répétitive peut être traduite en un nid de boucles spécial,avant de présenter dans la section 5.2 le formalisme utilisé derrière lestransformations pour la manipulation des concepts de dépendancesmultidimensionnelles, conformité, objectifs.

Les transformations de haut-niveau disponibles déjà existantes sontprésentées brièvement dans la section 5.3.

Dans la section 5.4 nous proposons des extensions aux transfor-mations existantes visant soit le regroupement des transformationsélémentaires dans des transformation rassemblant plusieurs transfor-mations élémentaire avec des propriétés nouvelles, soit d’étendre ledomaine d’applicabilité.

La section 5.5 présente une comparaison entre les transformationde haut niveau Array-OL avec les transformations de boucles, pouridentifier des relation permettant l’utilisation des résultats du domained’optimisations basées sur des transformations de boucles dans lecontexte d’optimisations en utilisant le refactoring Array-OL.

97

98 refactoring en utilisant des transformations de haut niveau

5.1 répétitions sous la forme de boucles

Une spécification MARTE RSM est conçue autour du concept derépétition, qui peut être vue comme l’abstraction d’un nid de bouclesspécial, sous une forme visuelle data-parallèle. Les caractéristiquesprincipales d’un tel nid de boucles sont :

– les boucles sont parfaitement imbriquées ;– toutes les boucles varient entre zéro et une constante, avec un pas

de 1 ;– toutes les instructions se retrouvent au niveau le plus profond du

nid de boucles ;– les écritures des éléments sont en assignation unique, donc il n’y a

pas de dépendances d’écriture de données, ce qui rend les bouclescomplètement parallèles.

L’accès au éléments des tableaux d’entrées et de sortie se fait par laconstruction de tiler, cf Équation 2.3, page 36. Pour rappeler,

∀ r,0 6 r < srépétition,

∀ i,0 6 i < smotif,

eri = o + (P F) ·

(r

i

)mod stableau,

(5.1)

oùeri la référence dans le tableau qui corresponde a l’élément

avec l’indice i dans le motif de la répétition r

stableau la forme du tableau

smotif la forme du motif

srépétition la forme de l’espace de répétition

o l’origine du tiler

P la matrice de pavage

F la matrice d’ajustage.Une répétition caractérisée par un espace de répétition srépétition qui

consume n tableaux d’entrées et produit m tableau de sortie, accèsexprimés par les tilers associés qui définissent des relations de type del’Équation 5.1 :

consomption des entrées : ∀ k, 0 6 k < n, le tiler d’entrée θek =

(Fek , oek , Pek) exprime le placement de Motif_Opérandek avecune forme de smotif_opérandek dans le Tableau_entréek avec uneforme de stableau_entréek ;

production des sorties : ∀h, 0 6 h < m, le tiler de sortie θsh =

(Fsh , osh , Psh) exprime le placement de Motif_Résultath avec uneforme de smotif_résultath dans le Tableau_sortieh avec une formede stableau_sortieh .

L’algorithme qui montre la traduction d’une répétition vers des nidsdes boucles est montré sur l’Algorithme 1.

Chaque boucle multidimensionnelle représente un nid de bouclesparallèles avec la profondeur de la dimension du vecteur où chaqueboucle itère une dimension du vecteur. L’Algorithme 2 montre uneboucle multidimensionnelle mise à plat (ligne no 1 de l’Algorithme 1,

avec d = dim(r) = dim(srépétition), r =( r0...rd−1

)et srépétition =

( s0...sd−1

).

5.1 répétitions sous la forme de boucles 99

Algorithme 1 Traduction d’une répétition vers des boucles multidimen-sionnelles.

1: for r = 0 to srépétition do /* pour toutes les répétitions */2: for k = 0 to n do /* pour touts les tilers d’entrée */3: for i = 0 to smotif_opérandek do /* pour tous les indices du

motif */4: /* calcule l’indice dans le tableau d’entrée */

5: eri = oek + (Pek Fek) ·

(r

i

)mod stableau_entréek

6: /* copie l’élément du tableau dans le motif opérande */7: Motif_Opérandek[i] = Tableau_entréek[eri ]

8: end for9: end for

10: /* exécute le calcul de la tâche répétée */11: Motif_Résultath(06h<m) = Traitement(Motif_Opérandek(06k<n))

12: for h = 0 to m do /* pour touts les tilers de sortie */13: for i = 0 to smotifh do /* pour tous les indices du motif */14: /* calcule l’indice dans le tableau de sortie */

15: eri = osh + (Psh Fsh) ·

(r

i

)mod stableau_sortieh

16: /* copie l’élément du motif résultat dans le tableau */17: Tableau_sortieh[eri ] = Motif_Résultath[i]18: end for19: end for20: end for

Algorithme 2 Mis-à-plat d’une boucle multidimensionnelle.1: for r0 = 0 to s0 do2: for r1 = 0 to s1 do3: ... /* boucles de 2 à d− 2 */4: for rd−1 = 0 to sd−1 do5: ... /* le corps de la boucle */6: end for7: end for8: end for

description composée

Cette description se traduit sous la forme de boucles comme unesuccession de nids de boucles représentant la traduction de chaqueappel aux sous-tâches.

Observation. La succession doit correspondre à l’ordre partiel strict desappels.

description hiérarchique

Une description hiérarchique se traduit par la hiérarchisation desboucles : le traitement des motifs (la ligne no 11 de l’Algorithme 1 estremplacée par la traduction par des boucles du niveau inférieur de lahiérarchie.

analyse


Nous avons vu comment une description MARTE RSM peut setraduire naturellement sous la forme des nid de boucles. En plus,ces nids de boucles ont des caractéristiques qui les rendent parfaitspour des techniques d’optimisation basées sur des transformations deboucles. Néanmoins, les transformations de boucles sont des optimisa-tions source à source, et une éventuelle stratégie d’optimisation de laspécification MARTE RSM par la traduction sous la forme de nids deboucles et l’utilisation des transformations de boucles n’est pas le bonchoix :

– premièrement, les boucles résultat après telles transformationsne peuvent pas être retraduites directement sous la forme d’unespécification MARTE RSM ;

– deuxièmement, des informations structurelles issues du formal-isme répétitive sont perdues (parallélisme, assignation unique,etc.).

C’est une raison pour laquelle l’utilisation des transformations deplus haut niveau qui ressemblent aux transformations de boucles, maiss’appliquent au niveau de la spécification multidimensionnelle (sur desrépétitions data-parallèles), a été choisie.Observation. L’utilisation de telles transformations de haut niveau n’in-terdit pas l’utilisation des transformations de boucles au niveau d’ab-straction plus proche à l’exécution, tout comme au niveau de la généra-tion du code ou de la compilation.

Pour appliquer les optimisations, il nous faut donc connaître lesdépendances de données présentes dans l’application. En effet, la co-hésion des dépendances est nécessaire pour qu’une transformation nemodifie pas les résultats d’une application. Il existe plusieurs modèlespour représenter et manipuler les dépendances de données, mais l’utili-sation de tableaux toriques dans Array-OL complexifie grandement lamanipulation des dépendances, car elle les rend non linéaires. Nous nedétaillerons donc pas ici les techniques habituelles, toutefois le lecteurtrouvera des études très détaillées dans [37, 21].

La manipulation des dépendances est le réel défi de la transformationd’applications Array-OL. Il est pour cette raison que tus a proposéson propre formalisme de manipulations de dépendances : les ODT.

5.2 formalisme odt

Le formalisme ODT (Opérateurs de Description de Tableau) a étéproposé par Demeure [27] afin d’exprimer les dépendances entre lesparties opérandes et résultats d’une tâche Array-OL. Il est basé sur l’al-gèbre linéaire avec contraintes et est constitué de plusieurs opérateursdéfinissant les liens entre deux espaces Kn. On peut relier ces opéra-teurs donc ces espaces à l’aide d’une loi de composition. Pour transcrireen ODT les dépendances d’une tâche Array-OL, il faut identifier lespoints des tableaux à leurs coordonnées. Puis c’est sur ces coordonnéesque sont appliqués les opérateurs. On obtient ainsi une suite d’opéra-teurs exprimant les dépendances. Il est alors possible d’effectuer uncertain nombre de calculs découlant des propriétés intrinsèques à ladescription répétitive.

Le formalisme ODT et ses opérateurs sont étudiés en détail par Soulaen [85] et Dumont en [32]. Par la suite nous allons faire un court résumédu formalisme et, plus important, de la représentation d’une répétitionsous cette forme.

5.2 formalisme odt 101

5.2.1 Opérateurs ODT

Chaque opérateur est en fait une relation binaire de Kn dans Km

et se comprend par une lecture de la droite vers la gauche. Dans lecontexte particulier d’Array-OL, nous utiliserons le plus souvent Z

comme espace, car les opérateurs sont appliqués aux coordonnées depoints d’un tableau.

Au total, il existe neuf opérateurs :modulo : Une valeur infinie dans le modulo indique que seules les

valeurs positives sont gardées. Le modulo se note(−→m)

M.

∀−→m ∈ (Z∗)n, ∀ (−→x ,−→y ) ∈ Kn ×Kn,−→yM−→x ⇔ −→y = −→x mod −→m

shift : Il s’agit simplement d’une opération de translation. Elle se

note(−−−→shift

)S.

∀−−−→shift ∈ Kn, ∀ (−→x ,−→y ) ∈ Kn ×Kn,

−→y S−→x ⇔ −→y = −→x +−−−→shift

gabarit : Le gabarit agit comme un filtre laissant passer certains

points et en bloquant d’autres. Il se note(−−→min,−−→max

)G

ou simple-

ment(−−→max

)G

si−−→min est nul. En outre une valeur infinie indique

une absence de contrainte.

∀ (−−→min,−−→max) ∈ Zn ×Zn, ∀ (−→x ,−→y ) ∈ Kn ×Kn,

−→yG−→x ⇔−−→min 6 −→x < −−→max et −→x = −→y

projection : La projection est une multiplication matricielle et per-met donc d’effectuer des changements de repères ou de calculer

le résultat d’applications linéaires. Elle se note∣∣∣M∣∣∣. La taille de

l’espace de départ est égale aux nombre de colonnes de M alorsque le nombre de lignes est égale à la taille de l’espace d’arrivée.

∀M ∈Mmn(K), ∀ (−→x ,−→y ) ∈ Kn ×Km,−→y Pro−→x ⇔ −→y = M.−→x

segmentation : La matrice M d’une projection n’étant pas forcé-ment inversible la segmentation sert de notation pour exprimerune « inversion théorique ». Elle se note M . La concordance entrele nombre de lignes et de colonnes avec la dimension des espacesest inversée par rapport à la projection.

∀M ∈Mmn(K), ∀ (−→x ,−→y ) ∈ Kn ×Km,−→y Seg−→x ⇔ −→x = M.−→y

éclatement : Une valeur infinie dans l’éclatement indique queseules les valeurs positives sont gardées. L’éclatement se note(−→m)

?.

∀−→m ∈ (Z∗)n, ∀ (−→x ,−→y ) ∈ Kn ×Kn,−→0 6 −→x < −→m,

−→y E−→x ⇔ ∀−→k ∈ Kn,−→y = −→x +

−→k ×−→m


arrondi : L’arrondi se note b.

∀ (−→x ,−→y ) ∈ Qn ×Zn,

−→yA−→x ⇔ −→y = b−→x c

fractionneur : Le fractionneur se note c.

∀ (−→x ,−→y ) ∈ Zn ×Qn, ∃−→r ∈ Qn,−→0 6 −→r <

−→1 ,

−→y F−→x ⇔ −→y = −→x +−→r

5.2.2 Propriétés des ODT

Il existe une loi de composition sur les ODT et elle est identique à celledes relations. Elle ne permet donc de composer que des ODT qui ontdes espaces d’arrivée et de départ communs. Elle se lit de droite àgauche et se note « . ».

Par symétrie, nous désignons le fait de construire un ODT ayantexactement les mêmes liens entre les points des deux espaces extrêmes,mais en échangeant les espaces source et destination. Nous appelleronsindifféremment miroir ou symétrique, l’ODT résultat de la symétrie et ledésignerons à l’aide de l’exposant −1.

Le miroir d’une composition d’ODT s’effectue de la même manièreque l’inverse d’une composition de fonction : en composant les miroirsdes ODT dans l’ordre opposé

(ODT1.ODT2)−1 = ODT−12 .ODT−1

1 (5.2)

Il nous suffit donc de décrire les miroirs des opérateurs élémentaires :

gabarit

(−−→min,−−→max

)G

−1 =(−−→min,−−→max

)G

décalage

(−−−→shift

)S

−1 =(−−−−→shift

)S

modulo

(−→m)

M−1 =

(−→m)

?

éclatement

(−→m)

?

−1 =(−→m)

M

projection

∣∣∣M∣∣∣−1 = M

segmentation M−1 =

∣∣∣M∣∣∣arrondi b−1 = cfractionneur c−1 = b

5.2.3 Représentation d’une répétition en ODT

Le formalisme ODT est conçu pour exprimer les dépendances dedonnées entre les éléments des tableaux résultats et ceux opérandesd’une description Array-OL. Dans une décomposition répétitive, lesdépendances sont identifiables au niveau des motifs d’entrée/sortie :

a. l’ensemble d’éléments d’un motif de sortie dépend de tous leséléments des motifs d’entrée de la même instance de la répétition ;


b. le lien entre les éléments des tableaux d’entrée et de sortie d’unerépétition se fait en passant par l’espace de répétition.

Dans le cas de la décomposition composée ou hiérarchique, le lien sefait par les éléments des tableaux connectés par des liens.

Nous sommes surtout intéressées de la modélisation des dépendancesd’une répétition et cela est possible en utilisant les opérateurs ODTentre les espaces multidimensionnels qui définissent les formes destableaux d’entrée, de sortie et l’espace de répétition.

Représentation des accès par motifs uniformes

Pour modéliser en ODT les correspondances entre les éléments d’untableau et l’ensemble des motifs qui correspondent à l’espace de répéti-tions, nous allons passer par la description du tiler associé, pour fairele lien entre l’espace de points du tableau, M, caractérisé par sa formemultidimensionnelle et l’ensemble espace d’itération Q et l’espace D dumotif, ce qu’on note comme espace QD. L’Équation 5.3 contient la rela-tion ODT qui exprime cette correspondance et est dérivée directementde la définition des tilers (cf l’Équation 5.1).

(M

)M

.(O

)S

.∣∣∣P F

∣∣∣ .(QD

)G

(5.3)

Représentation dès dépendances entrées-sorties

Les dépendances entre un tableau opérande et un tableau résultatdans une répétition se fait en passant par l’espace de répétition commun,

(Mop

)M

.(Oop

)S

.∣∣∣Pop Fop

∣∣∣ .( Q

Dop

)G(

Mres

)M

.(Ores

)S

.∣∣∣Pres Fres

∣∣∣ .( Q

Dres

)G

,

(5.4)

en inversant la relation résultat (cf l’Équation 5.2 et les règles d’inver-

sion) et les ajustant vers un espace commun

Q

Dop

Dres

:

(Mop

)M

.(Oop

)S

.∣∣∣Pop Fop 0

∣∣∣ . Q

Dop

Dres

G Q

Dop

Dres

G

.Pres 0 Fres .(−Ores

)S

.(Mres

)?

.

(5.5)

Par la composition des deux relations, la relation qui exprime lesdépendances entre les éléments d’un tableau opérande et un tableaurésultat devient :


(Mop

)M

.(Oop

)S

.∣∣∣Pop Fop 0

∣∣∣ . Q

Dop

Dres

G

.Pres 0 Fres .(Ores

)S

.(Mres

)?

(5.6)

Représentation d’une répétition complète

Une répétition complète peut consommer plusieurs tableaux opéran-des et en produire plusieurs. En gardant la même logique que pourl’expression des dépendances entre un tableau d’entrée et un de sortie,la relation qui décrit une répétition complète devient :

Mop1

Mop2...

M

.

Oop1

Oop2...

S

.

∣∣∣∣∣∣∣∣Pop1 Fop1 0 0 0 0 0

Pop2 0 Fop2 0 0 0 0... 0 0

. . . 0 0 0

∣∣∣∣∣∣∣∣ .

Q

Dop1

Dop2...

Dres1

Dres2...

G

.

Pres1 0 0 0 Fres1 0 0

Pres2 0 0 0 0 Fres2 0... 0 0 0 0 0

. . .

.

Ores1

Ores2...

S

.

Mres1

Mres2...

?

(5.7)

Le formalisme ODTn’est qu’un outild’expression desdépendancespermettant d’effectuerun certain nombred’opérations qui setraduisent sous laforme destransformationsODT.

Observation. Il n’y a pas une équivalence totale entre la représenta-tion répétitive et ODT. Dans l’Équation 5.7, les tableaux ne sont plusdifférentiables par la présence des zéros et ainsi cette expression nepermet pas de revenir à sa description répétitive sans des informationssupplémentaires.

« Court-circuit »

Une construction intéressante est celle qu’on appelle le « court-circuit », qui permet dans une hiérarchie d’exprimer les coordonnéesdes éléments d’un motif d’une sous-tâche selon les coordonnées des élé-ments du tableau de la tâche supérieure. On note de la façon suivanteles représentations ODT des tâches supérieure et inférieure :

(Mup

)M

.(Oup

)S

.∣∣∣Pup Fup

∣∣∣ .(QupDup

)G

(5.8)

(Msub

)M

.(Osub

)S

.∣∣∣Psub Fsub

∣∣∣ .(QsubDsub

)G

(5.9)

On peut alors écrire que les coordonnées, pour des itérations de pavageet d’ajustage fixés, sont de la forme :

(Oup

)S

.∣∣∣Pup Fup

∣∣∣ . Xq,up

Osub +∣∣∣Psub Fsub

∣∣∣ .(XqXd

)G

G

(5.10)


On obtient donc des coordonnées égales à :

Oup+PupXq,up+ FupOsub+∣∣∣FupPsub FupFsub

∣∣∣(XqXd

)G

(5.11)

Il est alors possible de modifier la forme de nos deux tâches, enpassant directement à la sous-tâche, un tableau qui corresponde auxmotifs qu’elle consomme.

(Oup + FupOsub

)S

.∣∣∣Pup FupPsub FupFsub

∣∣∣ .QupQsub

Dsub

G

(5.12)

Par l’enchaînement des constructions de court-circuit on peut ex-primer les coordonnées des éléments d’un tableau à un niveau quel-conque en fonction des éléments d’un tableau à un niveau supérieur.

5.2.4 Utilisation des ODT

Le formalisme ODT à été conçu pour exprimer les relations entre lesespaces multidimensionnels dans une décomposition répétitive qui estau cœur de la représentation Array-OL et MARTE RSM. En plus, enappliquant des opérations définies sur le formalisme, la représentationen ODT des répétitions peuvent être transformées sous une formeéquivalente (les mêmes dépendances exactes sont exprimées) mais quicorrespond à une représentation répétitive différente.

Une succession d’opérations ODT qui, appliquée sur la représentationen ODT d’une structure répétitive, arrive à la convertir dans une autrereprésentation qui correspond (et peut être traduite) à une représenta-tion répétitive correcte représente une transformation ODT. Une telletransformation, par la propagation des opérateurs ODT, garanti laconformité de la transformation.

Une transformation de haut niveau a associée une transformationODT qui formalise son fonctionnement, garanti sa conformité et amènedes informations de gain, telles que la minimisation des tableau inter-médiaires.

L’exécution d’une transformation Array-OL peut être décomposéenormalement dans les étapes suivantes :

1. identification des éléments structurels qui participent dans latransformation : normalement des répétitions successives ouhiérarchiques ;

2. transformation de ces éléments sous la forme ODT ;

3. application des successions d’opérateurs ODT qui représentent latransformation ODT ;

4. convertir la représentation ODT résultat sous la forme répétitive ;

5. réinsertion des éléments transformés dans la spécification com-plète.

Nous n’allons pas montrer le fonctionnement complet des transfor-mations ODT. Elles sont décrites en détail et prouvées dans les thèsesde Soula [85] et Dumont [32]. Par la suite nous allons faire une listedes transformations Array-OL disponibles, montrant très sommaire lacorrespondance en termes d’ODT.


5.3 transformations data-parallèles

Les transformations de haut niveau data-parallèles permettent larestructuration d’une spécification répétitive, par la redistribution desrépétitions entre les niveaux de la hiérarchie. Dans cette section nousallons étudier les différentes transformations qui sont disponibles. Cestransformations ont un fonctionnement similaire aux transformationsde boucles homonymes, sur lesquelles elles sont basées.

Nous allons illustrer le fonctionnement de chaque transformationsur l’application de Downscaler que nous avons utilisée pour montrerla modélisation répétitive d’Array-OL dans la section 2.1. La décompo-sition complète de l’application en deux filtres successifs est montréesur la Figure 54.

Filtre horizontal

(1920,1080,∞)

(720,1080,∞)

(240,1080,∞)

Hfiltre

(13) (3)

F =

100

o =

000

P =

8 0 0

0 1 0

0 0 1

F =

100

o =

000

P =

3 0 0

0 1 0

0 0 1

Filtre vertical

(720,1080,∞) (720,480,∞)

(720,120,∞)

Vfiltre

(14) (4)

F =

010

o =

000

P =

1 0 0

0 9 0

0 0 1

F =

010

o =

000

P =

1 0 0

0 4 0

0 0 1

L’application est décomposée en deux filtres successifs, un qui réduit chaque image sur la dimensionhorizontale, Filtre horizontal, et l’autre qui réduit ensuite l’images sur la dimension verticale, Filtrevertical. Chaque filtre a une fonctionnalité répétitive, décrite par l’espace de répétition de chaquerépétition et avec des accès uniformes définis par les tilers :– la tâche répétée du filtre horizontal prend une fenêtre de 13 éléments successifs qui glisse sur

chaque ligne avec un pas de 8 et produit 3 éléments qui sont rangés dans le tableau de sortie unaprès l’autre, pour toutes les lignes et toutes les images ;

– la tâche répétée du filtre vertical a un fonctionnement similaire, mais cette fois une fenêtre deglissement de 14 avec un pas de 9 qui produit 4 éléments, pour chaque colonne de chaqueimage.

Fig. 54: Filtres répétitifs de l’application de Downscaler

5.3.1 Fusion

Définition 5 (Fusion élémentaire). La transformation de fusion prenddeux répétitions successives et calcule une répétition commune pourles deux, pendant que les sous-répétitions qui restent sont placées auniveau inférieur de la hiérarchie, en minimisant le tableau intermé-diaire entre ces deux sous-répétitions. Un des effets de la fusion estl’introduction d’un niveau de répétition dans la hiérarchie.

5.3 transformations data-parallèles 107

Définition 6 (Tâches successives). Deux tâches sont considérées succes-sives si elles se trouvent au même niveau hiérarchique et la premièreproduit un tableau consommé par la seconde. La propriété de succes-sion est en lien direct avec l’ordre partiel strict des tâches.

Définition 7 (Tableau intermédiaire minimal). Entre deux répétitionssuccessives, un tableau intermédiaire minimal est désigné par ungroupe minimal de motifs produit par la première tâche qui permet àla deuxième répétition de s’exécuter au moins une fois, donc produiredes éléments et en conséquence permettant une exécution sans blocage.

Exemple. La Figure 55 montre le résultat de la fusion sur les deuxrépétitions successives de la modélisation du Downscaler de la Fig-ure 54. Nous pouvons observer la création de la répétition communeet le déplacement des deux tâches répétées à un niveau inférieur dela hiérarchie, avec des espaces de répétition réduits et en consommantdes tableaux avec des dimensions réduites.

(1920,1080,∞) (720,480,∞)

(240,120,∞)

(14,13) (3,4)

F =

0 1

1 0

0 0

o =

000

P =

8 0 0

0 9 0

0 0 1

F =

1 0

0 1

0 0

o =

000

P =

3 0 0

0 4 0

0 0 1

Filtre horizontal

(14,13) (3,14)

(14)

Hfiltre

(13) (3)

F =

(0

1

)

o =

(0

0

)

P =

(1

0

)

F =

(1

0

)

o =

(0

0

)

P =

(0

1

)

Filtre vertical

(3,14) (3,4)

(3)

Vfiltre

(14) (4)

F =

(0

1

)

o =

(0

0

)

P =

(1

0

)

F =

(0

1

)

o =

(0

0

)

P =

(1

0

)

Fig. 55: Downscaler après la fusion

calcul de la fusion

Le but de la fusion est la minimisation du tableau intermédiaire etdonc de trouver des macromotifs produits par la première répétition quipermettent à la deuxième tâche de s’exécuter : le macromotif produitpar la première tâche contient des motifs entiers consommés par laseconde.

Définition 8 (Macromotif). L’agglomération de plusieurs motifs, tou-jours sous une forme uniforme.

Dans ce but, le formalisme d’ODT et sa capacité à exprimer lesdépendances sont utilisées. Nous n’allons pas montrer toutes les étapes


de calcul de la fusion en ODT, qui sont présentées en détail dans lathèse de Dumont. Nous allons nous contenter de montrer le principe etles résultats.

En commençant avec les représentations ODT des deux répétitionssuccessives,

T1 7→(M1

)M

.(S1

)S

.∣∣∣Pop1 Fop1 0

∣∣∣ . Q1

Dop1

Dres1

G

.Pres1 0 Fres1 (5.13)

T2 7→(M2

)M

.(S2

)S


∣∣∣ . Q2

Dop2

Dres2

G

.Pres2 0 Fres2 (5.14)

et suivant la loi de composition entre les deux relations (opérationpermise par la présence du du tableau commun, tableau résultat dela première et opérande de la seconde), nous nous retrouvons avec larelation(

M1

)M

.(S1

)S


∣∣∣ . Q1

Dop1

Dres1

G

.Pres1 0 Fres1 .(M2

)M

.(S2

)S


∣∣∣ . Q2

Dop2

Dres2

G︸︷︷︸

relation Q1D1→Q2D2 passant parA2

.Pres2 0 Fres2 . (5.15)

À partir la partie centrale de l’Équation 5.15 qui exprime le passage

entre l’espace

(Q1

D1

)et

(Q2

D2

)en passant par le tableau intermédiaire

M2, une succession d’opérateurs ODT est appliquée pour calculerl’espace de répétition commun et les macromotifs opérandes et résultats,ce que se traduit par trois relations équivalentes à des expressions enODT des trois répétitions :

– pour la tâche supérieure :

(M1

)M

.(Sup

)S

.∣∣∣Popup Fopup Fop1 0 0

∣∣∣ .

Q

DMop

Dop1

DMres

Dres2

G

.Presup 0 0 Fresup Fres2 ;

– pour la première sous-tâche :

(DMop

Dop1

)M

.

(0

0

)S

.

∣∣∣∣∣1 0 0

0 1 0

∣∣∣∣∣ .DMop

Dop1

Dres1

G

.Pressub1 0 Fres1 .(Sressub1

)S

.(M2

)?

;

– pour la deuxième sous-tâche :

(M2

)M

.(Sopsub2

)S

.∣∣∣Pressub2 Fop2 0

∣∣∣ .DMres

Dop2

Dres2

G

.1 0 0

0 0 1.


DMop représente le groupe minimal de motifs initiaux qui formentles macromotifs du M2. Le même macromotif est consommé par ladeuxième sous-répétition sous la forme d’un groupe de motifs DMres .

plusieurs tableaux intermédiaires

La transformation de fusion élémentaire présentée est formaliséepour le cas de répétitions avec un seul tableau d’entrée et de sor-tie et un tableau intermédiaire unique entre les deux répétitions :

T1 T2

.Dumont propose en [32] des solutions pour d’autres cas possible. Il

distingue cinq cas différents :

1. plusieurs tableaux extérieures ;T1 T2

2. plusieurs tableaux intérieures ;

T1 T2

3. plusieurs tableaux intermédiaires ;T1 T2

4. double consomption du tableau intermédiaire ;

T1 T2

5. double production du tableau intermédiaire.T1 T2

Le 5e cas est interdit par la propriété d’assignation unique d’Array-

OL et à part le 3e cas, avec plusieurs tableaux intermédiaires, les autres

sont traités dans une manière similaire. On peut observer que danstous ces cas il y a un seul tableau intermédiaire et indifféremment denombre de tableaux extérieurs ou intérieurs des deux tâches, le calculdu macromotif dépend exclusivement des motifs de production/con-somption du ce tableau. Dans sa thèse, Soula préfère la descriptioncomplète des tâches (cf l’Équation 5.7) mais Dumont argumente quece choix complexifie beaucoup l’implémentation, en rendent plus com-plexe la distinction des différentes tâches dans la forme ODT. Dumontopte pour l’application du calcul du macromotif individuellement pourchacun des tableaux, sachant que le macromotif restera le même. Celafacilite surtout la séparation et l’identification des parties ODT quicorrespondent à chacun des tableaux après le calcul de la fusion.

Quant au 3e cas, la présence de plusieurs tableaux intermédiaires,

une solution idéale pour la fusion n’existe pas encore. La représentationODT complète de plusieurs tableaux intermédiaires n’est pas possiblepuisqu’elle rendrait non exacte la partie droite de la première répétition,ce qui bloquerait l’inversion du ODT exact.

Dumont propose d’effectuer la fusion en plusieurs étapes, en différen-ciant la production des tableaux intermédiaires par plusieurs copies de


la première tâche et effectuant plusieurs fusions, pour chaque tableauintermédiaire à la fois. Un tel choix aura comme résultat la générationd’un nombre de niveaux de hiérarchie égal au nombre de tableauxintermédiaires. À part l’explosion en niveaux hiérarchiques, cela impli-querait aussi l’exécution multiple de la première répétition, ce qu’onappelle apparition des recalculs.

recalculs

Définition 9 (Recalcul). Les recalculs sont représentés par l’augmenta-tion de la répétition complète pour la première tâche impliquée dansune fusion, causée par les motifs de production/consomption entre lesdeux répétitions.

Observation. La répétition complète d’une tâche (cf la section 2.4, Défi-nition statique) est donnée par la concaténation de toutes les formesmultidimensionnelles en descendant les niveaux de la hiérarchie duhaut jusqu’au niveau de la tâche concernée. Recalculs sont représentéspar l’augmentation de la répétition complète pour une tâche, suite àune transformation de fusion.

Le recalcul intervient lorsque deux macromotifs partagent des mo-tifs originaux (ou des parties de motifs) en commun, ce que fait quedeux exécutions de la première sous-répétition produit plusieurs foisles mêmes éléments et donc augmente la quantité de calculs de laspécification, même si la fonctionnalité décrite reste la même.

Exemple. Le cas le plus souvent de recalculs rencontré en pratique estcausé par des accès en fenêtre glissante, dans la deuxième répétition. Ilest le cas de l’application de Downscaler où la deuxième répétition aun tel motif d’accès, comment on peut voir sur la Figure 56.

0 . . . 7200

. . . 1080 Le placement des macro-motifs dans le tableau in-termédiaire initial montrele chevauchement entre lesmacromotifs successifs surla dimension du glisse-ment. Tous les élémentsqui sont partagés entredes macromotifs (en grisfoncé sur la figure) serontcalculés deux fois par lapremière sous-répétitionaprès la fusion.

Fig. 56: Chevauchement du macromotif dans le tableau initial

Avant la fusion, cf la Figure 54, nous avons pour la première répéti-tion un espace de répétition avec une forme de (240, 1080,∞), ce quereprésente 240× 1080 = 259200 exécutions de la tâche répétée pourchaque image. Après la fusion, cf la Figure 55, l’espace de répétitiontotal pour la première sous-répétition, en concaténant les répétitions


des deux niveaux de la hiérarchie, devient (240, 120,∞, 14), et donc240× 120× 14 = 403200 exécutions pour chaque image. Le facteur derecalcul introduit par la fusion1 est de u 1.56 pour la première répéti- 1 En divisant les

deux quantitésd’exécutions.

tion. Ce facteur s’explique par le partage de 6 lignes entre chaque deuxmacromotifs successifs contenant 14 lignes, qui seront calculées deuxfois par la première sous-répétition.

réduction des tableaux intermédiaires

La réduction des tableaux intermédiaires par le calcul d’un macro-motif minimal est une opération de base dans le cadre du refactoringArray-OL.

Des techniques d’optimisation de stockage intra-tableau [25, 89, 81]dans le contexte des transformations de boucles permettent le calcul dela « fenêtre de référence » d’un tableau multidimensionnel, qui permetla réutilisation des emplacements mémoires pour les éléments du mêmetableau. Par une analyse des domaines de définition et opérandes etde l’ordre d’exécution et de stockage [25], les tailles mémoires destableaux multidimensionnels peuvent être réduites aux ces fenêtres deréférences.

D’une manière similaire, la fusion Array-OL calcule du macromotifminimal entre deux répétitions qui permet une exécution sans blocage.Le macromotif intermédiaire et les macromotifs d’entrées et de sortiepour les deux sous-répétitions sont les tailles minimales qui doivent êtrestockées en mémoires si nous considérons une exécution séquentiellepour le niveau de la répétition commune. Si une exécution parallèle estchoisie, chaque unité d’exécution doit avoir ses propres macromotifsstockés en mémoire.

Des optimisations pour réduire encore plus la taille globale de lamémoire (ou des mémoires si le système contient plusieurs mémoiresdistribuées) peuvent être employées avant la compilation par la tech-nique d’optimisation de l’ordre de stockage inter-tableaux : plusieurstableaux qui ont des durées de vie sans chevauchement partagent desadresses mémoires.

La fusion de deux répétitions successives réduit le tableau intermé-diaire entre les deux répétitions. Le problème se complique quandplusieurs répétitions se succèdent et l’objectif devient la réduction detous les tableaux intermédiaires. La fusion de multiples répétitions seraabordée dans la sous-section 5.4.2.

5.3.2 Changement du pavage

Une transformation de changement de pavage agit sur la redistribu-tion de répétitions entre des niveaux successifs de la hiérarchie, de hauten bas. Des répétitions d’un niveau haut de hiérarchie sont descenduesau niveau suivant de la hiérarchie, en les ajoutant à chaque répétitionde ce niveau.

Tout d’abord, une telle transformation peut être utilisée pour changerla granularité de la spécification répétitive. Deuxièmement, elle permetla réduction des recalculs introduits dans une spécification par la fusion.

Définition 10 (Granularité). La notion de degré de granularité a étéintroduite par Labbani et al. en [56] dans le contexte du contrôle, quipermet de délimiter les différents cycles d’exécution ou les instantsdans lesquels la prise en compte des événements de contrôle devient


possible. Il permet également d’introduire une sémantique de flot dansla description des applications Array-OL pour faciliter l’étude deleur comportement réactif en synchronisant les valeurs des donnéesen entrée avec celles du contrôle. Dans notre contexte, la granularitéreprésente plutôt des sous-ensembles des espaces de répétitions traitéscomme des blocs à l’exécution.

Exemple. La résultat de la fusion de la Figure 55 détermine le partagede l’application en blocs indépendants, chacun consommant un tableaude (14, 13) éléments et produisant (3, 4). Le degré de granularité dela répétition globale est donné par ces blocs et à l’exécution ils aurontassocié un ordre d’exécution dicté par les contraintes d’exécution.

Observation. Plusieurs niveaux de répétitions hiérarchiques spécifientplusieurs niveaux de granularité.

Deux transformations de changement de pavage sont disponibles :

par ajout de dimensions. Cette transformation permet de grouperplusieurs motifs du niveau supérieur par le passage de blocs del’espace de répétition dans le niveau inférieur de la hiérarchie.L’inconvénient est que cela ne réduit pas les recalculs.

par agrandissement linéaire . La transformation est conçue spé-cialement pour réduire les recalculs introduits dans une applica-tion par le calcul des boîtes englobantes qui couvrent plusieursmotifs qui se chevauchent. Elle peut être utilisée uniquement dansle cas des motifs d’accès avec des chevauchements.

Changement de pavage par ajout de dimensions

L’idée pour cette transformation est de descendre des répétitionsd’un niveau haut de répétition au niveau qui suit dans la hiérarchie, àtoutes les répétitions de ce niveau. L’opération est assez simple, pourpasser plusieurs macromotifs au niveau inférieur de la hiérarchie ilsuffit d’ajouter une dimension dans la forme du motif et de placerplusieurs motifs un après l’autre dans cette dimension.

Définition 11 (Ajout de dimension). Une transformation de change-ment de pavage par ajout de dimension élémentaire s’applique surune seule dimension de l’espace de répétition, avec un facteur dechangement de pavage défini par une valeur naturelle n. Soit Q =(Qi,06i<m

)l’espace de répétition du niveau haut avec m dimensions

et k, 0 6 k < m, l’indice du cet espace sur lequel l’opération de change-ment de pavage aura lieu. Pour que la transformation soit correcte, ndoit diviser exactement la taille de la dimension sur laquelle le change-ment de pavage s’effectue, Qk mod n = 0.

Définition 12 (Changement de pavage maximal). Dans le cas où lefacteur de changement de pavage coïncide avec la taille de la dimensionde la répétition, Qk = n, toute cette dimension de la répétition estpassée au niveau inférieur.

Les effets d’une telle transformation, sur les deux niveaux de répéti-tions hiérarchiques impliquées dans la transformation, sont :

au niveau supérieur :– la dimension k de l’espace de répétition est divisée par la valeurn,


– tous les motifs de la répétition haute auront une dimension deplus, d’une taille de n2, 2 Nous avons choisi

d’ajouter ladimension audébut de la formemultidimension-nelle, observationvalable pour lereste de la section.

– pour tous les tilers d’accès, le vecteur de pavage qui corre-sponde à la dimension k de la répétition est ajoutée dans lamatrice d’ajustage,

Observation. S’il s’agit d’un changement de pavage maximal, ladimension k de l’espace de répétition peut être supprimée, enmême temps que tous les vecteurs du pavage correspondants ;

au niveau inférieur :Pour chacune des répétition du ce niveau,– tous les tableaux auront une dimension de plus avec une taille

de n,– pour tous les tilers, une valeur de 0 sera ajoutée dans tous les

vecteurs du pavage et d’ajustage, pour s’aligner à l’augmenta-tion des dimensions des tableaux,

– la répétition aura une dimension de plus, toujours avec unetaille de n,

– pour tous les tilers d’accès, un vecteur de pavage de forme

1

0

...

est ajouté à la matrice de pavage.

Définition 13 (Changement de pavage multidimensionnel). Une trans-formation de changement de pavage par ajout de dimension sur plusieursdimensions de l’espace de répétition est définie comme la transforma-tion unitaire de plusieurs transformations élémentaires, pour chaquedimension.

Exemple. La Figure 57 montre le résultat de la transformation de change-ment de pavage (maximal) par ajout de dimensions sur la premièredimension du Downscaler après la fusion. La granularité de la répéti-tion du niveau haut n’est plus représentée par des blocs de (13, 14),mais par de 13 lignes de pixels.

Le changement de pavage par ajout de dimension permet l’ajustagede la granularité de la spécification répétitive, mais a aussi deux désa-vantages majeurs :

a. ne réduit pas les recalculs ; Plus de dimensionsdans la spécificationmultidimensionnellecompliquent lamanipulation desaccès et rendent letravail de conceptionplus laborieux pourl’utilisateur.

b. la segmentation des dimensions : chaque transformation de change-ment de pavage ajoute des dimensions dans les formes destableaux et des répétitions du niveau inférieur. Des dimensionsinitiales peuvent se retrouver partagées en plusieurs morceaux,avec une augmentation de la complexité de la spécification multi-dimensionnelle.

Changement de pavage par agrandissement linéaire

Une transformation conçue dans le but de réduire les recalculs in-troduits par une fusion est disponible. Cette transformation ressembleau changement de pavage par ajout de dimension, avec la différenceque les motifs du niveau supérieur ne sont pas mis un à côté de l’autredans une dimension additionnelle, mais dans une boîte englobante.

Sur la Figure 58, nous pouvons observer la réduction des recalculsdes macromotifs après l’élargissement par la boîte englobante sur ladimension des recouvrements.


(1920,1080,∞) (720,480,∞)

(120,∞)

(240,14, 13) (240,3, 4)

F =

8 0 1

0 1 0

0 0 0

o =

000

P =

0 0

9 0

0 1

F =

3 1 0

0 0 1

0 0 0

o =

000

P =

0 0

4 0

0 1

Filtre horizontal

(240,14, 13) (240,3, 14)

(240,14)

Hfiltre

(13) (3)

F =

001

o =

000

P =

1 0

0 1

0 0

F =

010

o =

000

P =

1 0

0 0

0 1

Filtre vertical

(240,3, 14) (240,3, 4)

(240,3)

Vfiltre

(14) (4)

F =

001

o =

000

P =

1 0

0 1

0 0

F =

001

o =

000

P =

1 0

0 1

0 0

La première dimension de l’espace de répétition a descendu un niveau de hiérarchie. Le facteur dechangement de pavage, avec une valeur de 240 se retrouve dans les formes des motifs au niveausupérieur de la hiérarchie et dans les formes des tableaux et des répétitions dans le niveau inférieur.

Fig. 57: Le Downscaler après l’ajout de dimensions maximal sur la première dimension

0 . . . 7200

. . . 1080

(a) Facteur de 2

0 . . . 7200

. . . 1080

(b) Agrandissement maximal

L’agrandissement linéaire avec un facteur de 2 réduit les recalculs, en comparaison avec les chevauche-ments de la Figure 56 et l’agrandissement maximal sur toute la dimension du glissement réduitcomplètement les recalculs. Les réductions ont comme effet secondaire une augmentation de la tailledu macromotif.

Fig. 58: Réduction des recalculs par agrandissement linéaire

calcul de la boîte englobante. Toutes les étapes du calculde l’agrandissement linéaire sont décrites et prouvés dans la thèse deDumont. Nous n’allons pas rentrer trop dans les détails de calcul, nouslimitant aux principes et résultats.


Une transformation d’agrandissement linéaire consiste en plusieursétapes :

identification du recouvrement et donc des recalculs. Pourqu’il y ait recouvrement, il faut que chaque itération du pavagepartage un motif de la sous-tâche avec une autre itération depavage. Cette condition de traduit dans une équation

−−→Popi −

−−−−→MFopk ×∆ ≡ 0 mod

−→M (5.16)

qui dit simplement qu’une origine de motif originel soit at-teignable par une dimension de macroajustage dans un premiermacromotif

−−−−→MFopk × dk et que cette même origine soit également

atteignable par la même dimension de macroajustage−−−−→MFopk × d ′k

après une itération de pavage sur le vecteur−−→Popi . Dans la pratique,

la condition se traduit dans un algorithme3 capable à fournir tous 3 Disponible dans lathèse de Dumont.les couples (i, k, ∆) avec les dimensions où il y a de recouvrement ;

choix de la transformation entre les alternatives disponibles.Pour chaque couple (i, k, ∆) et un facteur de changement depavage de n on peut calculer un taux de recouvrement égal à

MDopk + (n− 1)|∆|

n|∆|(5.17)

qui peut guider le choix de la transformation ;

application de la transformation Une fois la transformationet le facteur d’agrandissement choisi, une succession d’opérateursODT sont appliquées, permettant le calcul des nouvelles valeurspour les répétitions (tailles de tableaux, motifs, tilers d’accès) desdeux niveaux de la hiérarchie.

Exemple. La Figure 59 montre le résultat de la transformation de change-ment de pavage par agrandissement linéaire sur la dimension du glisse-ment avec un facteur de 20 qui réduit les recalcule à un facteur de185× 6/1080 = 1.02(6). Pour les calculs, identifier une transformationd’agrandissement linéaire se résume à identifier les indices i, k et le

déplacement ∆ de l’Équation 5.16, pour Pop =(8 0 00 9 00 0 1

), MFop =

(0 11 00 0

)et |∆| < MDopk =

(14, 13

)k

. La solution est représentée par le couple(i, k, ∆) = (1, 0, 9) : la première dimension du macroajustage4 est at- 4 Les indices des

dimensionscommencent à 0.

teignable par une itération du pavage sur la deuxième dimension. Unetransformation d’agrandissement linéaire pour cette solution avec unfacteur de n = 20 réduit les recalculs, en utilisant l’Équation 5.17, àune valeur de 14+(20−1)×9

20×9 = 185180 = 1.02(6), la même valeur que celle

calculée par la division des répétitions sur la figure.

5.3.3 Aplatissement

Définition 14 (Aplatissement). Nous avons vu comment l’utilisationd’un changement de pavage maximal sur une dimension de l’espacede répétition fait que cette dimension descend un niveau de la hiérar-chie. Un changement de pavage maximal sur toutes les dimensionsde la répétition du niveau supérieur aura comme effet l’éliminationde la répétition entière au niveau supérieur. Le niveau supérieur de lahiérarchie est donc inutile et sera supprimé de la spécification, en le


(1920,1080,∞) (720,480,∞)

(240,6,∞)

(185,13) (20,3, 4)

F =

0 1

1 0

0 0

o =

000

P =

8 0 0

0 180 0

0 0 1

F =

0 1 0

4 0 1

0 0 0

o =

000

P =

3 0 0

0 80 0

0 0 1

Filtre horizontal

(185,13) (3,185)

(185)

Hfiltre

(13) (3)

F =

(0

1

)

o =

(0

0

)

P =

(1

0

)

F =

(1

0

)

o =

(0

0

)

P =

(0

1

)

Filtre vertical

(3,185) (20,3, 4)

(20,3)

Vfiltre

(14) (4)

F =

(0

1

)

o =

(0

0

)

P =

(0 1

9 0

)

F =

001

o =

000

P =

1 0

0 1

0 0

Un agrandissement linéaire avec un facteur de 20 sur la dimension du recalcul réduits les répétitionsde la première tâche d’un facteur de u 1.56 à un facteur de u 1.03, mais avec une augmentationde la taille du macromotif avec un facteur de u 13.21, soit 513 éléments mémoire de plus.

Fig. 59: Modèle Downscaler après réduction des recalculs

remplaçant par le niveau inférieur de répétitions. C’est ce qu’on appelleaplatissement5.5 Collapse en

anglais.Observation. Au moment de la suppression du niveau supérieur dela hiérarchie, même s’il n’y a pas de répétition, les tilers doivent êtrecomposés avec les tilers correspondants du niveau inférieur par le court-circuit (cf l’Équation 5.2.3) pour faire le lien direct entre les tableaux duniveau supérieur et les motifs du niveau inférieur.

Exemple. La Figure 60 montre le résultat de l’aplatissement sur le mod-èle du Downscaler après la fusion. Cette nouvelle spécification estéquivalente au celle d’avant la fusion, mais avec de motifs d’accèsdifférents. La taille du tableau intermédiaire est aussi modifiée et l’u-tilisation du changement de pavage par ajout de dimension fait queles recalculs n’ont pas disparu. La construction de court-circuit permetl’expression directe des accès aux motifs du deuxième niveau de lahiérarchie dans les tableaux du niveau haut. Prenant par exemple le tilerd’entrée, sur la Figure 55, l’accès aux tableaux (1920, 1080,∞) par desmotifs de taille (13) sans passer par les macromotifs de taille (13, 14) sefait par le tiler calculé avec les relations de court-circuit, comme dans lecalcul suivant :

O = Oup + Fup.Osub =

000

+

0 1

1 0

0 0

.(0

0

)=

000


Filtre horizontal

(1920,1080,∞)

(240,120,∞, 3, 14)(240,120,∞, 14)

Hfiltre

(13) (3)

F =

100

o =

000

P =

8 0 0 0

0 9 0 1

0 0 1 0

F =

0

0

0

1

0

o =

0

0

0

0

0

P =

1 0 0 0

0 1 0 0

0 0 1 0

0 0 0 0

0 0 0 1

Filtre vertical

(240,120,∞, 3, 14) (720,480,∞)

(240,120,∞, 3)Vfiltre

(14) (4)

F =

0

0

0

0

1

o =

0

0

0

0

0

P =

1 0 0 0

0 1 0 0

0 0 1 0

0 0 0 1

0 0 0 0

F =

010

o =

000

P =

3 0 0 1

0 4 0 0

0 0 1 0

Sans l’utilisation du court-circuit pour les deux tilers du niveau supérieur, on se serait retrouvéavec des tilers similaires aux tilers d’accès au tableau intermédiaire aussi pour les tilers extérieurs.Même s’il n’y a pas de répétition, un tiler exprime le placement d’un motif dans le tableau, maisqui occupe toute la taille du tableau. Dans le cas du tiler d’entrée, le placement d’un motif de(240,120,∞, 13, 14) dans le tableau de taille (1920,1080,∞).

Fig. 60: Downscaler après l’aplatissement

P =(Pup Fup.Psub

)=

8 0 0

0 9 0

0 0 1

0 1

1 0

0 0

.(1

0

) =

8 0 0 0

0 9 0 1

0 0 1 0

F = Fup.Fsub =

0 1

1 0

0 0

.(0

1

)=

100

.

Ce tiler est exactement le tiler d’entrée après l’aplatissement.

5.3.4 Tiling

La transformation d’aplatissement, comme nous venons de voir, per-met la suppression d’un niveau de hiérarchie. Une transformationcapable de faire l’opération inverse est disponible : la création d’un


niveau de hiérarchie. Dumont dans sa thèse présente la transformationde tiling qui seulement ajoute un niveau de la hiérarchie sans répétitionau niveau inférieur. Même si une transformation de changement depavage ultérieure pourrait déplacer des répétitions du niveau supérieurà celui inférieur, nous préférons faire les deux opérations en mêmetemps : au moment de la création de la hiérarchie, l’espace de répéti-tion est partagé en blocs et les répétitions des blocs seront au niveauinférieur, pendant que les répétitions des blocs resteront au niveausupérieur.

Exemple. Dans la description des dépendances interrépétition connec-tées à travers la hiérarchie (sous-section 2.6.4) nous avons vu le résultatd’une transformation de tiling sur un sous-ensemble du filtre verticalavec des dépendances interrépétition. La Figure 61 montre le partageen blocs de (5, 4) sur le filtre vertical de la Figure 54. Le résultat de latransformation est similaire avec la transformation de changement depavage par ajout de dimension si on considérait un niveau inférieur dehiérarchie avec une répétition vide, ().

Filtre vertical

(720,1080,∞) (720,480,∞)

(144,30,∞)

Bloc-répétition(5,4, 14) (5,4, 4)

F =

1 0 0

0 9 1

0 0 0

o =

000

P =

5 0 0

0 36 0

0 0 1

F =

1 0 0

0 4 1

0 0 0

o =

000

P =

5 0 0

0 16 0

0 0 1

(5,4)

Vfilter(14) (4)

F =

001

o =

000

P =

1 0

0 1

0 0

F =

001

o =

000

P =

1 0

0 1

0 0

L’espace de répétition a été partagé en (144,30,∞) blocs de (5,4).

Fig. 61: Filtre vertical après une transformation de tiling

Cette transformation peut être utilisée pour changer la granularitéd’une répétition, la création de la hiérarchie quand une fusion n’est pasapplicable et permet d’augmenter la localité des données au niveauinférieur de la hiérarchie.

5.3.5 Conclusions sur l’utilisation des transformations

Pour résumer, les transformations de haut niveau Array-OL sontdes transformations data-parallèles au niveau de la spécification baséessur le formalisme ODT pour exprimer les dépendances et garantir lavalidité des opérations.

Les transformations permettent le refactoring de la spécificationpour l’adapter au passage à un modèle d’exécution, en distribuant lesrépétitions data-parallèles à travers la hiérarchie et ainsi permettant lechoix d’un passage direct à l’exécution.

5.4 extensions 119

Les différentes transformations peuvent être utilisées pour optimiserla spécification, par :

– la réduction des tableaux intermédiaires ;– le changement du degré du parallélisme ;– la réduction des recalculs ;– augmenter la localité des données ;– adapter la spécification aux contraintes d’exécution.

adapter la spécification aux contraintes d’exécution.Nous avons vu comment utiliser les transformationsArray-OL pour

prendre en compte les contraintes internes : comment enchaîner lescalculs. Des contraintes d’exécution peuvent aussi influencer le choixdu refactoring. Sur l’application du Downscaler, une telle contraintepeut spécifier par exemple que les images arrivent pixel par pixel surla dimension horizontale. L’extension des macromotifs au niveau hautpour inclure de lignes entières de données, en utilisant une transforma-tion d’agrandissement linéaire maximale sur la dimension horizontale,permet de mieux prendre en compte cette contrainte et une meilleuregestion des tampons de données. Le résultat est montré sur la Figure 62.

(1920,1080,∞) (720,480,∞)

(120,∞)

(14,1920) (720,4)

F =

0 1

1 0

0 0

o =

000

P =

0 0

9 0

0 1

F =

1 0

0 1

0 0

o =

000

P =

0 0

4 0

0 1

Filtre horizontal

(14,1920) (720,14)

(240,14)

Hfiltre

(13) (3)

F =

(0

1

)

o =

(0

0

)

P =

(0 1

9 0

)

F =

(1

0

)

o =

(0

0

)

P =

(3 0

0 1

)

Filtre vertical

(720,14) (720,4)

(240,3)

Vfiltre

(14) (4)

F =

(0

1

)

o =

(0

0

)

P =

(3 1

0 0

)

F =

(0

1

)

o =

(0

0

)

P =

(3 1

0 0

)

Le niveau supérieur de la hiérarchie prend des tuiles contenant des lignes entières des images.Moins de parallélisme est exprimé à ce niveau, mais vu que les images arrivent ligne par ligne, lemécanisme de tampons est simplifié.

Fig. 62: Modèle Downscaler qui respecte les contraintes de flot de données

5.4 extensions

Les transformations de haut niveau Array-OL, leur définition etformalisation utilisant les ODT ont été au cœur des thèses de Soula


et Dumont. Des besoins pratiques nous ont conduits à étendre cestransformations. Deux directions d’extension peuvent être notées :

a. le regroupement de plusieurs transformations élémentaires dansune seule transformation unitaire ; cela facilite l’utilisation destransformations et permet de remonter des propriétés assez in-téressantes ;

b. l’extension des transformations pour des cas non traités où traitésdans une manière non appropriée.

Nous avons déjà fait référence dans la présentation des transforma-tions aux extensions possibles. Pour récapituler, les groupements deplusieurs transformations unitaires mentionnées sont :

changement de pavage multidimensionnel. Une transforma-tion unitaire constituée de plusieurs changements de pavages surdes dimensions différentes de l’espace de répétition ;

changement de pavage maximal. Une transformation de change-ment de pavage avec un facteur de changement de pavage égal àla taille de la dimension de l’espace de répétition concernée ; ladimension entière descend un niveau de la hiérarchie ;

partage d’un espace de répétition en blocs . C’est ce qu’onappelle tiling, mais en fait représente deux opérations distinctes,une opération de tiling comme celle décrite par Dumont pourcréer un niveau de hiérarchie et une transformation de change-ment de pavage par ajout de dimensions ;

fusions multiples. La fusion de plusieurs répétitions qui se succè-dent, en utilisant plusieurs fusions élémentaires suivies par destransformations d’aplatissement pour limiter à deux le nombredes niveaux de hiérarchie résultat.

Comme extension des transformations, le plus de restrictions sontdéfinies sur la fusion élémentaire, dans le cas de plusieurs tableauxintermédiaires. Comme extension on mentionne :

agrandissement linéaire sans recalculs. La transformationd’agrandissement linéaire est conçue pour réduire les recalculs etla première étape est exactement la détection des recalculs. Unetelle transformation est intéressante même dans les cas où il n’ya pas de recalculs. Nous proposons d’étendre la transformationpour des motifs qui ne se chevauchent pas, mais qui sont « collés »un après l’autre ;

tableau intermédiaire consommé plusieurs fois. C’est lecas d’un tableau intermédiaire qui est consommé par la deuxièmetâche en deux motifs d’accès différents :

T1 T2

élimination de la multiplicité inutile . Des transformationsde refactoring peuvent amener à des structures multidimension-nelles contenant des dimensions de taille unitaire. Pour simplifierla description multidimensionnelle, ces dimensions peuvent etdevraient être éliminés. Cette simplification implique aussi :– dans le cas de la forme d’une répétition, la suppression des

vecteurs de pavage qui correspondent à la dimension éliminé,– dans le cas de la forme d’un tableau, la suppression récursive

des dimensions dans les tableaux connectés à celui-ci, la sup-pression des lignes dans les matrices d’ajustage et de pavage

5.4 extensions 121

dans les tilers qui accèdent le tableau et des vecteurs d’ajustagesi le tableau exprime la forme du motif dans une descriptionrépétitive.

Nous allons nous arrêter seulement sur les extensions plus complexesdont nous n’avons pas discuté dans la présentation des transformations.

5.4.1 Agrandissement linéaire sans recalculs

L’agrandissement linéaire identifie les dimensions où des recouvre-ments de motifs se produisent et donc des recalculs. En augmentant lataille du motif sur cette dimension en prenant la boîte englobante pourcontenir plusieurs motifs initiaux, la quantité de recalculs est diminuée.

L’utilisation de la même transformation (même quand il n’y a pasdes recalculs) au détriment du changement de pavage par ajout dedimension, a ces avantages :

– on peut éviter la segmentation des dimensions et l’apparition destableaux multidimensionnels avec excessivement de dimensions ;

– gérer les tampons de données pour des dimensions linéarités estplus simple et plus directe.Exemple. Le modèle du Downscaler qui respecte les contraintes duflot de données sur la Figure 62 est le résultat d’une telle transfor-mation. Sur la dimension horizontale, il n’y a pas de recalculs etdonc la transformation d’agrandissement linéaire n’est pas permisesans cette extension.

Au niveau de la formalisation de la transformation, la modification seretrouve au niveau de l’algorithme qui cherche les dimensions du recal-cul. La condition de recalcul est modifiée pour retourner les dimensionsoù les motifs sont collés un après l’autre.

5.4.2 Fusions multiples

Une fusion élémentaire calcule la répétition commune des deuxrépétitions qui se succèdent, en minimisant les tableaux intermédiairesproduits par la première et consommés par la seconde. Dans des ap-plications réelles, plusieurs répétitions peuvent se succéder et l’objectifest de réduire si possible tous les tableaux intermédiaires entre cesrépétitions. Comme nous allons voir, cet objectif dépend de plusieursparamètres et n’est pas facilement atteignable.

Si on considérait une répétition

Répétition

(ss) (sc)

(sR)

tâche

(ms) (mc)

θs = (Fs,os, Ps) θc = (Fc, oc, Pc)

représentéecomme

Répétition

(sR)

sous une forme simplifiée, en négligeant les tilers et la forme des motifs,une succession de répétitions à un niveau de hiérarchie ressemblait à laFigure 63

6. 6 Nous nousintéressons toujoursaux fusions avec unseul tableauintermédiaire entrechaque deuxrépétitions.

Dans une telle configuration, le but est de réduire toutes les tailles destableaux intermédiaires. Cette opération est possible par l’enchaînementde plusieurs fusions élémentaires pour calculer une répétition communepour chaque couple répétition productrice ⊕7 répétition consommatrice.

7⊕ = opération defusion.

L’algorithme de fusion doit suivre les règles suivantes :


Répétition1

(sR1 )

Répétition2

(sR2 )

Répétition2(sR3 )

Répétition4(sR4 )

Fig. 63: Enchaînement réel de répétitions

– on commence avec la fusion de deux répétitions ;– à chaque étape, le résultat de la fusion antérieure est fusionné avec

une nouvelle répétition ;– l’enchaînement des répétitions est imposé par les tableaux intermé-

diaires entre les répétitions ; dans une fusion, la première répétitiondoit produire un tableau consommé par la deuxième. Á la fin l’en-chaînement est dicté par l’ordre partiel entre les répétitions.Exemple. Sur la structure de la Figure 63, le seul ordre de fusionpossible est : Répétition1 ⊕Répétition2 ⊕Répétition3 ⊕Répétition4 ;

– pour limiter à deux les niveaux de hiérarchie résultat, chaque fu-sion (exceptant la première) est suivie par une opération d’aplatisse-ment pour éliminer le niveau supplémentaire de hiérarchie.

Observation. L’ordre partiel entre les répétitions détermine l’ordre desfusions, mais la fusion est une opération non-associative et la façon defaire cette association influence les résultats. L’ordre de la structure surla Figure 63 peur être interprété comme :

– (Répétition1 ⊕ (Répétition2 ⊕ (Répétition3 ⊕Répétition4))) ;– (((Répétition1 ⊕Répétition2)⊕Répétition3)⊕Répétition4) ;– (Répétition1 ⊕ ((Répétition2 ⊕Répétition3)⊕Répétition4)) ;– etc.

Exemple. Pour la structure de la Figure 63, les étapes de la fusion multi-ple, si on choisi l’association (Répétition1 ⊕ (Répétition2 ⊕ (Répétition3 ⊕Répétition4))), sont :

1. Fusion Répétition3 ⊕Répétition4 :

Répétition1

(s1)

Répétition2

(s2)

Répétition3,4

(s34)

sub_rép3(sb3)

sub_rép4(sb4)

5.4 extensions 123

2. Fusion Répétition2 ⊕Répétition3,4 :

Répétition1

(s1)

Répétition2,3,4

(s234)

sub_rép2

(sb2)

sub_rép3,4(sb34)

sub_rép3(sb3)

sub_rép4(sb4)

3. Aplatissement Répétition3,4 :

Répétition1

(s1)

Répétition2,3,4

(s234)

sub_rép2

(sb2)

sub_rép3(sb34, sb3)


4. Fusion Répétition1 ⊕Répétition2,3,4 :

Répétition1,2,3,4

(s1234)

sub_rép1

(sb1)

sub_rép2,3,4(sb234)

sub_rép2

(sb2)



5. Aplatissement Répétition2,3,4 :

Répétition1,2,3,4

(s1234)

sub_rép1

(sb1)


sub_rép3(sb234, sb34, sb3)

sub_rép4(sb234, sb34, sb4)

Observation. Par une fusion multiple, seulement le dernier8 tableau in- 8 Selon l’ordre de lafusion.termédiaire est minimisé. Les autres tableaux intermédiaires représen-

tent des groupes minimaux de motifs nécessaires pour l’exécutionau moins une fois de la dernière sous-répétition, et non de la sousrépétition qui consomme le tableau respectif.


Le choix de l’ordre de fusion influence les résultats d’une fusionmultiple. Dans le contexte des optimisations en taille mémoire enutilisant des fusions, cet ordre est essentiel. Dans le chapitre 7, nousallons étudier ce problème plus en détail sur une application réelle detraitement de signal.

5.4.3 Tableau intermédiaire consommé plusieurs fois

Dans la présentation de la transformation de fusion de la sous-section 5.3.1, nous avons vu comment les cas avec plus de tableauxproduits ou consommés sont traités. La plupart de cas peuvent êtreréduits aux calculs successifs de la même fusion avec différentes partiesopérandes de la première tâche ou parties résultat de la seconde.

Le vrai problème se pose dans le cas de plusieurs tableaux intermédi-aires. La représentation sous la forme ODT complète ne fonctionne pas ;cette représentation bloque le calcul de la fusion à cause d’une inversioninterdite de matrice. La solution proposée par Dumont consiste à copierla première répétition autant de fois qu’il y a de tableaux intermédiaireset à calculer la fusion avec la deuxième en considérant un tableau à lafois. Ce choix a des inconvénients assez importantes :

– la création d’un nombre de niveaux de hiérarchie égal au nombrede tableaux intermédiaires, qui peuvent amener aux hiérarchiesabyssales ;

– les tableaux intermédiaires ne sont pas réduits en même temps ;– les recalculs introduits par la duplication de la première répétition.Tous ces motifs nous ont conduit à chercher des alternatives pour

ce type de transformation, au moins pour des cas spéciaux. C’est lecas de la consommation multiple d’un tableau intermédiaire par ladeuxième répétition. Cela peut sembler improbable, mais dans desapplications de traitement intensif de signal ce type de consommationest assez fréquente, même si elle est cachée. C’est le cas de l’exempleprésenté sur la Figure 63, où même si sur la figure on ne retrouve pasdirectement une telle consommation, on peut voir qu’entre la Répétition1et Répétition4 il y a deux chemins de données. Dans le cas d’une fusionmultiple de toutes ces répétitions on va de retrouver à un moment oul’autre avec une consommation multiple entre deux répétitions.

Exemple. Dans le cas de la fusion multiple présentée précédemment,la 5

e étape (fusion Répétition1 ⊕ Répétition2,3,4) représente une fusionavec un tableau intermédiaire consommé plusieurs fois.

proposition. Une consommation multiple d’un tableau intermédi-aire par la deuxième répétition à une structure de type :

Répétition1

(ss1 ) (sc1 )

(sR1 )

tâche1

(ms1 ) (mc1 )

θs1θc1

Répétition2

(ss2 )

(ss3 )

(sc2 )

(sR2 )

tâche2

(ms2 )

(ms3 )

(mc2 )

θs2

θs3

θc2 .La fusion des deux répétitions devrait réduire les tableaux intermé-

diaires en calculant une répétition commune. Dans ce cas nous avonsun seul tableau intermédiaire, mais consommé plusieurs fois avec desmotifs d’accès différents. Pour réduire le tableau intermédiaire, il faut

5.4 extensions 125

calculer un macromotif qui englobe les deux macromotifs correspon-dant à chaque consommation.

Pour trouver ce macromotif global, nous proposons de calculer unmotif commun opérant pour la deuxième répétition et d’appliquer latransformation de fusion considérant un seul tableau intermédiairequi est consommé par ce motif commun par la deuxième répétition.C’est comme si on ajoutait un niveau de hiérarchie pour la deuxièmerépétition, illustré sur la Figure 64.

Répétition1

(ss1 ) (sc1 )

(sR1 )

tâche1

(ms1 ) (mc1 )

θs1θc1

Rép_commun2

(scs2 ) (scc2 )

(scR2 )

Sub_rép2

(scs23 )

(scc2 )

(sbR2 )

tâche2

(ms2 )

(ms3 )

(mc2 )

θsb2

θsb3

θcb2θcc2

θsc23

Fig. 64: Motif commun pour la consommation multiple.

Le calcul du motif commun opérande peut se faire en se servantd’une construction support et l’application d’une transformation defusion élémentaire pour calculer le motif commun minimal. La con-struction support est réalisée par la séparation d’un tiler d’accès dansune autre répétition qui sera la première répétition de la fusion :

Rép_support

(ss2 ) (ss2 )

(sR2 )

tâcheid

(ms2 ) (ms2 )

θs2θs2

Répétition2

(ss3 )

(sc2 )

(sR2 )

tâche2

(ms3 ) (mc2 )

θs3θc2 .

Suite à la fusion de la répétition support avec la deuxième répétitionsans la consommation du tableau intermédiaire utilisé pour la créationde la répétition support,

Rép_commun2

(ss2 ) (sc2 )

(scR2 )

Sub_rép2

(scs2 ) (scc2 )

Rép_support

(scs23 ) (scs23 )

(sbR2 )

tâcheid

(ms2 ) (ms2 )

θsb2θsb2

Répétition2

(scs23 ) (scc2 )

(sbR2 )

tâche2

(mbs3 ) (mbc2 )

θsb3θcb2

θsc23θcc2

,on se retrouve avec le motif commun minimal pour les deux consom-mations et les tilers d’accès de la Figure 64. Toutes les étapes de la

fusion doivent êtretransparentes pourl’utilisateur.

Après le calcul du motif commun pour les consommations de la deux-ième répétition, une transformation de fusion élémentaire est utiliséepour réduire le tableau intermédiaire entre les deux répétitions. Une


transformation d’aplatissement est utilisée par la suite pour éliminerle niveau de hiérarchie introduit par la fusion pour le calcul du motifcommun consommé.

Observation. Nous avons présenté le rationnement de la fusion pourle cas de deux consommations dans la deuxième répétition. Dans lecas de plus de deux consommations l’algorithme reste le même, maisil faut plusieurs étapes pour le calcul du motif consommé commun :pour chaque consommation nous avons besoin d’une fusion avec unerépétition support, suivi par des opérations d’aplatissement derrièrepour limiter le nombre de niveaux de hiérarchie.

5.4.4 Résumé

Nous avons présenté les transformation data-parallèles disponiblespour le refactoring de haut-niveau et nous avons proposé une séried’extensions, intéressantes surtout dans une perspective plus pratique.

Par la suite nous allons essayer de tirer quelques associations entreces transformation de haut niveau et les transformations de boucles.

5.5 comparaison avec les transformations de boucles

Comme nous avons discuté dans le chapitre 4, les techniques d’opti-misation employant les transformations de boucles visent l’améliorationde la régularité et la localité d’accès aux données et la suppression/ré-duction des tampons du niveau système du code d’une application.

Nous avons vu que ces transformations de code sont plus efficacessur un code de traitement de données extrêmement régulier : des nidsde boucles parfaits. Cela est précisément le domaine d’applicationsvisé par Array-OL et, comme nous avons vu, la traduction vers unedescription basée sur boucles est directe.

Les ressemblances évidentes entre les deux types de transformationnous ont amenés à essayer d’identifier les connexions entre les deuxdomaines et d’enquêter sur les optimisations techniques basées sur destransformations de boucles et si des correspondances possibles avec lesoptimisations en Array-OL.

Nous commençons avec quelques observations importantes sur lesdeux types de transformations :

– contrairement aux transformations de boucles qui sont des usuelle-ment des optimisations locales, les transformations Array-OL sontdes transformations qui peuvent être utilisées à n’importe quelniveau de la hiérarchie grâce à l’accès aux données basé sur desmotifs uniformes ;

– les structures d’accès Array-OL sont rendues plus visibles et plusfacilement utilisables par les accès uniformes, contrairement auxreprésentations complexes des indices de boucles.

Il y a bien évidemment de désavantages dans l’utilisation d’Array-OL :

– la régularité restreint le domaine d’application à un ensemblerelativement limité ;

– les outils d’optimisation sont, pour le moment, semi-automatiques,des transformations de refactoring dans les mains du concepteur.

La complexité des algorithmes d’optimisation force l’introduction desmodalités pour représenter le problème (contraintes, transformation,

5.5 comparaison avec les transformations de boucles 127

fonctions de coût) par l’utilisation de formalismes plus efficaces quipourront faciliter la manipulation des concepts tels que : conformité,dépendances de donnés, objectifs. L’introduction d’un formalisme estextrêmement importante pour la partie décision de l’optimisation. Desalgorithmes corrects et complexes ont besoin d’être conçus autour detels formalismes. La spécification Array-OL est conçue autour d’untel formalisme et aussi les transformations sont spécifiées et leursconformités est prouvée par l’utilisation du formalisme ODT basé surl’algèbre linéaire. Les noms des

transformationsArray-OL ont étéchoisis pour montrerles similarités avec lestransformations deboucles homonymes.

Nous n’allons pas faire une comparaison séparée pour chaque pairede transformations, chaque transformation Array-OL a une fonction-nalité similaire à son homonyme, mais plutôt essayer d’identifier le rôlede chaque transformation et son usage potentiel.

Au moment du passage à un modèle d’exécution à partir une spécifi-cation Array-OL, un ensemble d’éléments clefs doit être attentivementanalysé. Tout d’abord, nous devons isoler les dimensions infinies, re-specter les contraintes internes introduites par les dépendances dedonnées et en même temps éviter les points de blocage dans l’exécu-tion.

Pour tout cela on peut utiliser la transformation de fusion qui acomme effets : l’isolation des dimensions infinies au niveau haut de lahiérarchie, la minimisation des tableaux intermédiaires et la garantied’une exécution sans blocage.

Comme pour la fusion des boucles, les deux ont le rôle d’unifier deuxentités dépendantes (des répétitions dans le cas d’Array-OL et des nidsde boucles dans l’autre cas). La fusion de boucles est une transformationde programme qui combine plusieurs boucles en une seule et elleest utilisée dans les compilateurs-paralléliseurs principalement pouraugmenter la granularité des boucles et pour améliorer la réutilisationdes données.

Néanmoins, la fusion de boucles englobe d’optimisations beaucoupplus complexes et peut être utilisée pour attendre diffèrent objectifs encollaboration avec d’autres transformations de boucles : réduire le coûtde l’évaluation des limites des boucles, améliorer la localité temporelledes données, réduction des synchronisations quand les boucles sontdistribuées sur plusieurs unités d’exécution. La fusion de boucles peutavoir un impact indirect sur les performances en autorisant d’autresoptimisations très utiles qui sont limitées à de blocs de base ou deboucles parfaites.

La fusion Array-OL est conçue dans le but de réduire la taille mé-moire nécessaire pour le stockage des données intermédiaires. Dans cesens, elle a des similitudes avec la technique d’optimisation de bouclesqui utilise la fusion et des autres transformations pour réduire lestailles des tableaux intermédiaires telles que le remplacement scalaireou l’optimisation de l’ordre de stockage intra/inter-tableau.

De Greef et al. présentent en [25] une stratégie qui permet la réductiondes tailles mémoires nécessaires pour des applications multimédia data-intensives visant la réutilisation efficiente des emplacements mémoirespar d’optimisations de l’ordre de stockage. Premièrement, chaquetableau est optimisé indépendamment par la réduction à sa fenêtrede référence (optimisations intra-tableau) pour augmenter la réutilisa-tion des emplacements mémoires pour les éléments du même tableau.Après une deuxième phase, différents tableaux peuvent partager desplacements en mémoire si leur durée de vie ne se chevauche pas (opti-


misations inter-tableau). La fusion des répétitions Array-OL permetdans la même façon de calculer la fenêtre de référence minimale entrela production/consomption des tableaux intermédiaires.

La transformation de fusion peut être utilisée pour restructurer l’ap-plication vers une spécification hiérarchique spéciale où toutes lesdimensions infinies sont isolées à un niveau haut de la hiérarchie quiva représenter le niveau du flot-données.

Une différence entre la fusion Array-OL et les transformations deboucles est l’introduction de recalculs dans la spécification. Sans l’in-troduction des recalculs pour des accès chevauchants, la réductiondes tableaux intermédiaires en gardant une répétition commune data-parallèle n’est pas possible en Array-OL. Les recalculs sont des com-promis entre le parallélisme et la réduction des tailles mémoires.

La transformation d’aplatissement a un rôle important en connexionavec la fusion, en évitant l’apparition des « hiérarchies abyssales », créespar le chaînage de fusions élémentaires.

Le changement de pavage ressemble au déroulement de boucles.Les deux transformations agissent sur la redistribution des itérationsentre les niveaux (de la hiérarchie ou des nids de boucles). Dans lecontexte d’Array-OL, cette transformation peut aussi être utilisée pourrestructurer la spécification pour respecter les contraintes d’exécutionou d’environnement.

La transformation Array-OL de tiling corresponde au partage deboucles ; la première introduit un niveau de hiérarchie pendant que ladeuxième un niveau de nidification dans le nid de boucles. Les deuxont le rôle de partager l’espace d’itération en blocs fonctionnels pouraugmenter la localité des données.

Nous devrons noter que dans le contexte des optimisations Array-OL nous ne sommes pas intéressés d’augmenter le parallélisme dansl’application. Tout le parallélisme est disponible par construction ; lebut d’Array-OL est de fournir un langage de modélisation de hautniveau où le maximum de parallélisme est entièrement disponible auniveau de la spécification.

Nous sommes plus intéressés dans des optimisations mémoires (sta-tique et dynamique), en respectant les contraintes de la spécification.Néanmoins, les transformations changent la structure de la spécifica-tion et cela provoque des changements dans le parallélisme (ou sonorganisation).

Considérant les similitudes entre les deux types de transformations,nous pouvons essayer de prendre des résultats des techniques d’opti-misation des boucles, dont on peut dire qu’elles ont atteint le niveaude maturité dû aux études extensives du sujet, et utiliser ces résultatsdans le contexte d’Array-OL.

Des problèmes de complexité font que les algorithmes capables dedonner une solution optimale pour des optimisations mémoires nesont pas pratiques. On utilise le plus souvent des heuristiques dontl’efficacité est prouvée. C’est dans cette direction que nous avons orienténos études sur des optimisations basées sur les transformations de hautniveau Array-OL.

Dans cette section nous avons essayé de tracer des parallèles entreles transformationsArray-OL et les transformations de boucles. Lecœur du langage Array-OL est la représentation visuelle de bouclesdata-parallèles (ce que nous appelons répétitions) et les transformationsArray-OL sont conçus pour manipuler ces répétitions, de la même

5.6 conclusions 129

manière que les transformations de boucles manipulent les boucles.Même si les transformations Array-OL peuvent être considérés commedes transformations de boucles de haut niveau et les deux types detransformations partagent des similitudes, les deux contextes différentsoù elles sont utilisées changent radicalement leur rôle.

Les transformations de boucles sont utilisées au niveau de la compi-lation du code et leur utilisation dépend des stratégies d’optimisationimplémentées dans le compilateur et en grande partie par la plate-forme d’exécution ciblée. Au contraire, les transformationsArray-OLsont au niveau haut de la spécification et sont indépendantes du codefinal généré, même si elles peuvent aussi être dirigées par certainescaractéristiques de la plateforme cible.

Les transformations Array-OL ont été conçus pour permettre lerefactoring d’une spécification Array-OL à un niveau haut de spéci-fication visuelle, en manipulant les concepts de répétition, hiérarchie,granularité. La contrainte que le résultat d’une telle transformationreste au même niveau d’abstraction de la spécification Array-OL (dé-composition hiérarchique en répétitions data-parallèles avec des accèsuniformes) limite l’éventail de transformations permises.

Les deux types de transformations restent aux deux niveaux dif-férents d’abstraction et elles peuvent être complémentaires, les transfor-mations de haut niveau pour la manipulation de la structure globalede l’application et des transformations de boucles au niveau de compi-lation du code généré, pour des optimisations de bas niveau.

5.6 conclusions

Dans le chapitre 7 nous allons présenter une stratégie d’optimisa-tion par l’utilisation des transformations de boucle, illustrée sur uneapplication réelle de traitement intensif de signal.

Avant de passer à la validation pratique des résultats théorétiques au-tour les transformations de boucle, nous devrons analyser l’interactionde ces transformation avec les dépendances uniformes.

Les dépendances interrépétition n’existaient pas au moment de laconception du formalisme ODT et des transformations de haut-niveaudata-parallèles et ainsi une représentation en ODT d’une répétition n’ex-prime pas les éventuelles dépendances uniformes entre les répétitions.Pour pouvoir en même temps exprimer ce type de dépendances etpouvoir profiter des transformations de refactoring, l’interaction entreles deux doit être gérée.

Une possibilité sur laquelle nous avons enquêté a été le choix d’éten-dre la représentation en ODT d’une répétition pour l’expression desdépendances uniformes (avec l’extension des opérateurs ODT si néces-saire) et de modifier l’ensemble de transformations de haut-niveau.Comme ODT permet pas l’expression des relations entre les élémentsdu même espace multidimensionnel, ce choix aurait impliqué des mod-ifications considérables dans tous les niveaux du formalisme ODT.

Nous avons choisi de prendre une autre direction, en se basantsur quelques observations sur les effets des transformations de haut-niveau sur la structure répétitive. Cela permet une séparation entreles transformations et les dépendances uniformes et nous ont amené àproposer un algorithme pour gérer l’interaction entre les deux concepts.Nous allons présenter en détail cette interaction dans le chapitre suivant.

6I M PA C T D U R E FA C T O R I N G S U R L E SD É P E N D A N C E S U N I F O R M E S

6.1 Interaction : analyse formelle 1316.1.1 Un niveau de hiérarchie 133

6.1.2 Deux niveaux de hiérarchie 134

6.1.3 Dépendances uniformes entre les répéti-tions 135

6.1.4 Analyse 135

6.1.5 Calculer le déplacement de l’origine 137

6.2 Exemple pratique 1386.3 Conclusions 139

Nous avons présenté dans le chapitre précédent les transformationsde haut niveau conçus autour le formalisme Array-OL qui permettentd’adapter à un haut niveau d’abstraction la spécification à l’exécution.

Dans ce chapitre nous analysons l’interaction entre les transforma-tions Array-OL et l’extension que nous avons proposée pour l’expres-sion des dépendances uniformes. L’intérêt de cette analyse est d’au-toriser l’utilisation des techniques de refactoring sur des spécificationqui contient des dépendances interrépétitions.

La section 6.1 analyse formellement cette interaction, propose etprouve un algorithme permettant de calculer les dépendances uni-formes après une transformation Array-OL sans toucher au formalismeODT. Un exemple pratique montrant le fonctionnement de l’algorithmeest présenté par la suite dans la section 6.2 et nous finissons le chapitrepar des conclusions sur l’interaction transformations/dépendancesuniformes dans la section 6.3.

6.1 interaction : analyse formelle

Les dépendances interrépétitions proposées dans la section 2.6, Mod-élisation des dépendances uniformes, ont été conçues dans le con-texte d’Array-OL pour exprimer des dépendances uniformes entre desrépétitions data-parallèles. Une telle construction exprime des dépen-dances de données entre toutes les répétitions qui se trouvent à unedistance donnée par le vecteur de dépendance dans l’espace de répéti-tion. Mais l’espace de répétition total pour une tâche est donné parla concaténation de toutes les répétitions hiérarchiques en partant duniveau le niveau le plus haut de la spécification vers le niveau de latâche.

En connectant les dépendances à travers la hiérarchie, on peut ex-primer des dépendances complexes entre des répétitions aux niveauxdifférents de la hiérarchie, très importants spécialement quand les trans-formations de haut niveau entrent en jeu. Le sujet à été déjà abordé danssous-section 2.6.4 et sous-section 2.6.5 où nous avons vu comment unetransformation de tiling qui partage l’espace de répétition en blocs nousa obligé à fissionner une dépendance initiale dans des dépendances in-

131

132 impact du refactoring sur les dépendances uniformes

terconnectées entre différents niveaux de la hiérarchie et même d’avoirmultiples dépendances sur le même niveau de la hiérarchie.

Dans la sous-section 2.6.5, nous avons vu comment en prenant lamême spécification et en modifiant seulement le vecteur de dépendanceinitial qui exprimait des dépendances horizontales avec un pas de 2,d =(2, 0), vers un vecteur diagonal, d =(1, 1), après une transforma-tion de tiling, les dépendances interrépétitions dans les deux cas sontsignificativement différentes, mais sans impact sur le reste du modèle(répétitions, motifs, tilers, etc.). Cette observation suggère une netteséparation entre les transformations Array-OL et les dépendances inter-répétition et nous a conduit à une analyse formelle de l’interaction quia confirmé nos observations et nous a permis de proposer et prouverun algorithme qui gère cette interaction.

En prenant comme entrées les structures de l’application avant etaprès une transformation, ainsi que les dépendances initiales, l’algo-rithme est capable de calculer les dépendances exactes sur la nouvelleapplication qui respectent la contrainte de la fonctionnalité équivalente(la Définition 2, page 56).

Indépendamment de leur rôle, toutes les transformations de hautniveau Array-OL ont un impact similaire sur la structure de l’applica-tion, concernant les répétitions et la hiérarchie. En généralisant :

a. elles agissent sur la redistribution des répétitions à travers lesniveaux hiérarchiques, avec la création ou la suppression desniveaux de la hiérarchie, si le cas ;

b. en plus, une transformation affecte au maximum deux niveauxsuccessifs de répétitions hiérarchiques.

Définition 15 (niveaux des répétitions hiérarchiques). Un niveau derépétition est représenté par la hiérarchie introduite par une tâcherépétée. Plusieurs niveaux successifs de répétitions sont représentéspar les décompositions successives en tâches répétées, ignorant lesdécompositions en tâches composées.

Observation. Deux niveaux successifs de répétitions peuvent être représen-tés soit par une décomposition tâche répétée–tâche répétée, soit tâcherépétée–tâche composée–tâche répétée.

En prenant chaque transformation une par une, nous avons :

fusion prend deux répétitions successives, crée un niveau supérieurde hiérarchie pour la répétition commune et les sous-répétitionsqui restent sont placées sur le niveau inférieur de la hiérarchie, enminimisant la taille du tableau intermédiaire ;

tiling partage une répétition en blocs, en créant un niveau de hiérar-chie ; le niveau supérieur pour la répétition des blocs et le niveauinférieur pour les répétitions du bloc ;

changement du pavage (soit par la création des dimensions, soitpar agrandissement linéaire) agit en redistribuant des répétitionsentre des niveaux successifs de la hiérarchie en en modifiant lagranularité de l’application ;

aplatissement en étant l’opposé de la fusion et du tiling, supprimele niveau supérieur d’une hiérarchie et ajoute la répétition de ceniveau à toutes les répétions du niveau inférieur.

Pour résumer, une transformation prend comme entrées une structured’un ou deux niveaux de répétitions et génère une autre structure d’un

6.1 interaction : analyse formelle 133

ou deux niveaux de répétitions. En plus, une transformation garantitque les sémantiques de la spécification ne sont pas modifiés.

Après une transformation, les répétitions sont réarrangées dans lesniveaux hiérarchiques et cela force un réarrangement des éventuellesdépendances inter-répétitions, pour qu’elles expriment les exactesmêmes dépendances entre répétitions qu’avant.

Le problème peut être formulé comme suit :

Ayant la structure avant et après la transformation (représentéeles deux fois par une structure d’un ou deux niveaux successifs derépétitions), ainsi que la(les) dépendance(s) interrépétition avantla transformation, la(les) dépendance(s) interrépétition qui expri-ment les exactes mêmes dépendances sur les nouvelles répétitionstransformées doivent être calculées.

Dans cette démarche, des connexions entre les répétitions initiales etfinales impliquées dans une transformation doivent être identifiées onmanipulant le formalisme derrière Array-OL et des contraintes qui as-surent que les sémantiques de la spécification ne changent pas. Commenous avons dit, une transformation effectue des modifications seule-ment dans les répétitions impliquées dans la transformation. L’interfaceavec le reste de l’application doit obligatoirement rester la même ; lestableaux qui communiquent avec le reste de l’application et les motifsde production/consommation doivent rester inchangés. Il est à traversces tableaux qu’on peut identifier des connexions entre les répétitionsavant et après une transformation.

Tout d’abord, nous allons commencer par la description des connex-ions entre les répétitions et les tableaux de l’interface dans les deux casque nous intéressent : un ou deux niveaux hiérarchiques de répétitions.

6.1.1 Un niveau de hiérarchie

Répétition sur un niveau

(stableau)

(srépétition)

(smotif)

θ = {o, P, F}

Fig. 65: Hiérarchie sur un niveau

Les connexions entre la répétition srépétition et le tableau stableau sur laFigure 65 se fait à travers le tiler θ. En utilisant la définition de la con-struction pour les références des tuiles dans le tableau, cf l’Équation 2.2sur la page 34, nous avons :

∀ r,0 6 r < srépétition, réfr = o + P · r mod stableau (6.1)


Répétition sur deux niveaux

(stableausup)

(srépétitioninf)

(smotifinf)

(srépétitionsup)

(smotifsup)

(stableauinf)

θinf = {oinf, Pinf, Finf}

θsup ={

osup, Psup, Fsup}

Fig. 66: Hiérarchie sur deux niveaux

6.1.2 Deux niveaux de hiérarchie

La connexion entre les deux espaces de répétition, srépétitionsupet

srépétitioninf, et le tableau stableau (Figure 66) se fait à travers les tilers θsup

et θinf, et le tableau qu’ils partagent (smotifsup = stableauinf).

∀ rsup, 0 6 rsup < srépétitionsup,

réfrsup = osup + Psup · rsup mod stableausup

(6.2)

∀ rinf, 0 6 rinf < srépétitioninf,

réfrinf = oinf + Pinf · rinf mod stableauinf

(6.3)

Avec les deux tilers connectés à travers un tableau commun, en utilisantla construction de « court-circuit », qui permet l’expression directe desrelations entre des éléments des tableaux connectés par plusieurs tilerssuccessives, nous avons

∀ rsup, 0 6 rsup < srépétitionsup,

∀ rinf, 0 6 rinf < srépétitioninf,

réfrsuprinf = osup + Fsup · oinf + Psup · rsup

+ Fsup · Pinf · rinf mod stableausup

. (6.4)

En considérant les deux répétitions comme une seule, par la concaténa-tion des deux espaces de répétition, la relation devient :

∀

(rsup

rinf

), 0 6

(rsup

rinf

)<

srépétitionsup

srépétitioninf

,réfrsuprinf = osup + Fsup · oinf + (Psup Fsup · Pinf)

·

(rsup

rinf

)mod stableausup

(6.5)

Dans les deux cas, cf l’Équation 6.1 et l’Équation 6.5, les relationsde construction des motifs peuvent s’écrire sous la forme donne parl’Équation 6.1.

∀ r,0 6 r < srep, réfr = o + P · r mod sarray (6.6)


6.1.3 Dépendances uniformes entre les répétitions

La définition d’une dépendance inter-répétition (l’Équation 2.5, page 51)nous donne pour Équation 6.1 avec une dépendance uniforme, d, larelation :

∀ r, 0 6 r < srépétition, rdép = r − d

réfrdép = o + P · rdép mod stableau

⇒réfr − réfrdép = P · (r − rdép)

⇒dréfr = réfr − réfrdép = P · d

(6.7)

D’après l’Équation 6.7, une dépendance uniforme entre les répétitionsd’une tâche est équivalente avec une dépendance uniforme entre lesréférences de ces répétitions dans un tableau (dréfr ).

6.1.4 Analyse

Nous avons montré comment dans les deux cas (un ou deux niveauxde hiérarchie), les relations entre les répétitions et leurs références dansun tableau peuvent être exprimées sous la même forme et une dépen-dance uniforme entre des répétitions est équivalente à une dépendanceentre les références de ces répétitions dans un tableau.

De plus, la contrainte qui dit que la sémantique de l’applicationdoit rester inchangée après une transformation laisse entendre que lestableaux à la frontière de l’action de la transformation doivent êtreproduits de la même façon, et ainsi toutes les références des accèsà un tel tableau avant la transformation doivent se retrouver aprèsla transformation. Une éventuelle dépendance uniforme entre les référencesdes accès réguliers à un tableau doit rester inchangée. C’est le lien qu’oncherchait pour connecter les dépendances sur les répétitions avant etaprès une transformation.

Maintenant, nous avons une structure initiale exprimée par unerelation entre les répétitions et un tableau extérieur1 ainsi que les 1 À la frontière de

l’action de latransformation.

dépendances initiales entre les références, introduites par la dépendanceentre les répétitions

∀ ravant, 0 6 ravant < srépétitionavant,

réfravant = oavant + Pavant · ravant mod stableau(6.8)

dréfavant = Pavant · davant (6.9)

et une structure finale exprimée par une relation similaire,

∀ raprès, 0 6 raprès < srépétitionaprès,

réfraprès = oaprès + Paprès · raprès mod stableau(6.10)

dréfaprès = Paprès · daprès, (6.11)

en mettant la contrainte d’égalité entre les références avant et après, onse retrouve avec :

dréfavant = dréfaprès ⇒ Pavant · davant = Paprès · daprès. (6.12)

Résoudre l’Équation 6.12 suffit à trouver les dépendances sur lesnouvelles répétitions :


a. s’il n’y a pas de solution, cela signifie qu’aucune dépendance uni-forme n’existe qui exprime l’exacte même dépendance que celleavant la transformation et donc la sémantique de l’application nepeut pas être gardée, ce qui rendre la transformation incorrecte ;

b. une solution correspond a une dépendance sur le nouvel espacede répétitions ;

c. si plusieurs solutions existent, chaque solution correspond à unedépendance sur l’espace de répétition.

Si après la transformation la structure de l’application est représentéepar un seul niveau de hiérarchie, chaque solution sera traduite dansune dépendance. Si par contre, la structure est représentée par deuxniveaux de hiérarchie, chaque solution sera utilisée pour calculer lesdépendances sur les deux espaces de répétition de chaque niveau dehiérarchie2 :2 La séparation

entre les deuxdépendances se faiten conséquenceavec les dimensionsdes espaces derépétition.

dafter =

(dsup

dinf

)(6.13)

Pour une solution :

a. si la dépendance du niveau supérieur, dsup, est le vecteur nul,pour cette solution il n’y a pas une dépendance sur le niveauhaut et la dépendance au niveau inférieur sera représentée par levecteur correspondant dinf ;

b. si le vecteur dsup n’est pas nul, nous avons des dépendancesentre des éléments des blocs différents, représentées par unedépendance au niveau supérieur avec le vecteur de distance dsupet les dépendances exactes élément à élément exprimées parun tiler au niveau inférieur de la hiérarchie, selon les règles deconstruction détaillée dans la sous-section 6.1.5.

La sémantique d’Array-OL pour les dépendances interrépétitionforce le passage des blocs entiers contenant des éléments en dépendanceau niveau inférieur de la hiérarchie. Les dépendances exactes élémentà élément seront représentées par un tiler similaire au tiler de sortiecorrespondant du niveau inférieur de la hiérarchie, avec une originedéplacée.

0 . . . 239

0

. . . 119

(0,0) (1,0)

(0,1) (1,1)

fenêtre de dépendance pour le bloc (1,1)

dépendance entre bloc (1,1) et (0,1)

distance entre bloc (0,1) etfenêtre de dépendance pour le bloc (1,1)

dépendance élément-à-élément

La dépendance élément-à-élément entre des répétitions placées dans desblocs différents se calcule comme somme des dépendance des deux niveauxde la hiérarchie.

Fig. 67: Dépendances élément-à-élément


6.1.5 Calculer le déplacement de l’origine

La dépendance élément à élément pour des répétitions des blocsdifférents sera exprimée comme somme des deux dépendances desdeux niveaux de hiérarchie. Ayant les répétitions dépendantes en blocsdifférents, exprimer la dépendance au niveau inférieur avec une dépen-dance inter-répétition n’est plus nécessaire3. Utiliser une copie du tiler 3 et impossible à

exprimer.de sortie avec une origine déplacée suffit :

∀ rinf,0 6 rinf < srépétitioninf, réfrdéfaut = odéfaut + Pinf · rinf (6.14)

La formule pour calculer le déplacement de l’origine peut êtreobtenue en imposant la contrainte d’identité des dépendances avant etaprès la transformation, même pour des répétitions des blocs différents,avec la dépendance exprimée par une relation de la forme donnée parl’Équation 6.14.

Pour une répétition(

rsuprinf

)qui dépend d’une autre répétition en

dehors du son bloc, nous avons la référence dans le tableau d’origine

réfrsuprinf = osup + Fsup · oinf + (Psup Fsup · Pinf)

·

(rsup

rinf

)mod stableausup (6.15)

et la référence de la répétition dépendante

réfrdép = osup + Fsup · odef + (Psup Fsup · Pinf)

·

(rsup − dsup

rinf

)mod stableausup (6.16)

et ainsi la distance entre les deux est de

dréfr = réfrsuprinf − réfrdép

= Fsup · (oinf − odef) + (Psup Fsup · Pinf) ·

(dsup

0

).

(6.17)

Utilisant l’Équation 6.11 dans le cas d’une hiérarchie sur deux niveaux,on se retrouve avec

dréfaprès = Paprès · daprès = (Psup Fsup · Pinf) ·

(dsup

dinf

)(6.18)

et donc

dréfr = dréfaprès

⇒(Psup Fsup · Pinf) ·

(dsup

dinf

)

= Fsup · (oinf − odéfaut) + (Psup Fsup · Pinf) ·

(dsup

0

)⇒Psup · dsup + Fsup · Pinf · dinf

= Fsup · (oinf − odéfaut) + Psup · dsup

⇒Pinf · dinf = oinf − odéfaut

(6.19)


En conséquence, le déplacement de l’origine sera calculé utilisantdinf, selon la relation :

odéfaut = oinf − Pinf · dinf, (6.20)

où odéfaut représente l’origine du tiler du lien par défaut, oinf et Pinf levecteur d’origine et la matrice de pavage du tiler de sortie correspondentau niveau inférieur de la hiérarchie.

6.2 exemple pratique

Par la suite nous allons appliquer les résultats de l’analyse sur l’exem-ple de la dépendance diagonale (Figure 37, page 60) et la transformationde tiling en blocs de 5× 4.

Nous avons une répétition initiale avec un espace de répétition deravant =

(240120

), et une dépendance initiale de davant =

(11

), pendant

que l’espace de répétition après la transformation de tiling en (48, 30)

blocs de (5, 4) est(

rsuprinf

)=

(483054

), avec une dépendance inter-répétition

inconnue de(

dsupdinf

). Ayant Paprès =

(Psup Fsup · Pinf

)(cf l’Équation 6.5)

et en remplaçant dans l’Équation 6.12 en utilisant le tableau de sortiecomme connexion, nous avons le système d’inéquations :

(1 0

0 4

)·(1

1

)=

(5 0 1 0

0 16 0 4

)·

(dsup

dinf

)(

−rsup

−rinf

)=

−48

−30

−5

−4

<

(dsup

dinf

)<

(rsup

rinf

)=

48

30

5

4

(

dsup

dinf

)∈ Z4

. (6.21)

Les solutions du système d’inéquations sont :

(dsup

dinf

)∈

0

0

1

1

,1

0

−4

1

,0

1

1

−3

,1

1

−4

−3

. (6.22)

Les quatre solutions représentent les quatre dépendances sur laFigure 37. La première a dsup =

(00

), et ainsi la dépendance est sur le

deuxième niveau de la hiérarchie avec un vecteur de dinf =(11

). Les

trois autres solutions représentent des dépendances entre les blocs auniveau supérieur, avec un vecteur de dépendance égal à dsup, pendantque dinf est utilisé pour calculer l’origine déplacée du lien par défautsur le niveau inférieur de la hiérarchie, cf l’Équation 6.20. Pour ces troisdernières solutions, nous avons :

odéfaut ∈

4

−1

0

,−1

3

0

,430

. (6.23)

Les solutions obtenues correspondent aux tilers d’accès qu’on retrouvesur l’exemple avec des triples dépendances entre les blocs de la Fig-ure 37, sur la page 60.

6.3 conclusions 139

6.3 conclusions

Dans ce chapitre, nous avons analysé l’interaction entre les trans-formations de haut-niveau conçus autour le modèle de spécificationArray-OL et les dépendances interrépétition.

Comme une transformation affecte maximum deux niveau succes-sives de répétitions hiérarchiques, nous avons montré comment, ayantla structure de l’application avant et après une transformation, nouspouvons calculer les dépendances uniformes qui expriment, sur la nou-velle structure, les mêmes dépendances élément-à-élément qu’avantla transformation. Cela garanti que la sémantique de l’application nechange pas et rend possible l’utilisation du refactoring sur des spécifi-cation contenant des dépendances uniformes.

L’algorithme proposé pour gérer l’interaction fonctionne indépen-damment des transformation Array-OL et cela facilite l’implémentationpratique : l’adaptation des dépendances est une étape ultérieure à latransformation ODT et n’influence pas les calculs d’ODT.

Dans cette partie de la thèse nous nous sommes intéressés aux tech-niques d’optimisations au niveau haut de la spécification répétitive.Nous avons vu l’ensemble d’outils de refactoring dans une perspectiveorientée plus théorique. Les extensions proposées sont aussi le résultatdes travaux de validation dans le contexte de la comodélisation enMARTE pour Gaspard2.

Dans les chapitre suivantes nous allons présenter les outils de refac-toring dans une perspective pratique, commençant avec l’étude destratégies d’optimisation sur une application réelle de traitement in-tensif de signal. Les travaux d’implémentation dans le contexte deGaspard2 seront présentés brièvement après.

Troisième partie

VA L I D AT I O N E X P É R I M E N TA L E

7S T R AT É G I E D E R E FA C T O R I N G P O U RL’ E X P L O R AT I O N D E L’ E S PA C E D E C O N C E P T I O N

7.1 Application radar STAP 1437.1.1 Contraintes d’implémentation 145

7.1.2 Modélisation de STAP 145

7.2 Vers un modèle d’exécution 1497.2.1 Utilisation des transformations de haut-niveau

data-parallèles 149

7.2.2 Refactoring utilisant des transformations dehaut-niveau 150

7.2.3 Réduction des tableaux intermédiaires deSTAP 154

7.3 Analyse des résultats 1567.4 Conclusions 158

Dans les chapitres précédents, nous nous sommes intéressés à destechniques d’optimisation de haut niveau dans une perspective théorique.Nous allons essayer de voir comment les outils de refactoring peuventêtre utilisés dans la pratique.

Des outils de refactoring sont disponibles pour adapter une spécifi-cation à l’exécution, en réduisant les tailles des tableaux et changeantla granularité du parallélisme pour permettre une expression directed’un modèle d’exécution. Ces outils sont représentés par des transfor-mations de haut-niveau data-parallèles dont nous avons discuté dans lechapitre 5, refactoring en utilisant des transformations

de haut niveau.Dans ce chapitre nous allons voir comment les outils de refactoring

peuvent être utilisés pour adapter une spécification à l’exécution surune application réelle de traitement intensif de signal, par l’explorationde l’espace de conception. L’application que nous allons utiliser estune application de traitement radar qui est le candidat idéal pourune modélisation en MARTE et pour l’exécution sur une architecturemultiprocesseur. Dans ce sens, nous proposons une stratégie pour lerefactoring de haut-niveau qui permet l’exploration de l’espace deconception des modèles répétitives MARTE, visant l’adaptation de laspécification aux contraintes d’exécution.

Dans la section 7.1, Nous commençons par la description de l’ap-plication de traitement radar. La stratégie d’optimisation basée sur lestransformation de refactoring est approfondie dans la section 7.2 et uneanalyse des résultats est faite dans la section 7.3. Des conclusions sontprésentés dans la section 7.4.

7.1 application radar stap

L’application que nous allons utiliser pour la modélisation et l’optimi-sation par du refactoring est une application industrielle de traitementradar MTI (de l’anglais Moving Target Indication), dont l’objectif est dedétecter à partir d’un aéronef les objets en mouvement sur le sol, et spé-cialement en mouvement lent entre toutes les autres surfaces immobiles

143

144 stratégie de refactoring pour l’exploration de l’espace de conception

reflétant l’onde du radar (échos de sol). Cela se fait par la réception del’écho de sol d’une séquence périodique d’impulsions radar (rafales).Le traitement radar permet l’estimation en même temps de la positionde la cible, par le délai entre la transmission du signal (pulse) et laréception de son écho, et de sa vitesse par l’effet Doppler qui affecte leséchos d’une séquence de pulses identiques envoyés périodiquement : lavitesse de la cible se traduit par une (faible) variation de sa distance duradar, qui est visible uniquement comme un déplacement de phase dusignal radar (e. g. environ 10GHz). Dans cette approche, le traitementDoppler consiste en un banc de filtres (e. g. Transformation de Fourierrapide), chacun réglé vers un déplacement particulier entre des échossuccessifs.

Ce type de traitement Doppler est dans certaines situations suffisantpour séparer les objets réfléchissants sur la base de leurs vitesses.Quand l’onde est orientée vers le sol, la partie principale de l’énergiede l’écho est censée provenir des objets qui composent le sol (appelésentassements), pendant que les objets d’intérêt envoient des échosfaibles, mais avec un déplacement de phase. Cependant, l’onde radarn’est pas parfaitement nette et elle a une épaisseur de quelques degrés,qui aboutit à donner à certains objets immobiles sur le sol à la frontièrede l’onde une vitesse relative à l’aéronef (causé par la vitesse proprede l’aéronef) et ainsi créant des interférences non désirées sur les échosdes cibles en mouvement : cela crée une ambiguïté entre les vitessesintrinsèques et azimuts des cibles.

Fig. 68: STAP

Des techniques de filtrage adaptatif, où des filtres fixes sont rem-placés par de filtres calculés au moment de l’exécution à partir dusignal reçu lui-même, aident minimisant les influences de ce signald’entassement indésirable : dans le cas de MTI, le traitement adaptatifespace-temps1 est utilisé. Dans cette méthode, un ensemble de filtres1 Space Time

AdaptiveProcessing enanglais.

est calculé à chaque rafale, par la résolution des systèmes linéaires avecla partie droite constituée des vecteurs de référence des motifs de phasethéorétiques attendus sur les sous-tableaux de l’antenne pour plusieurspulses consécutifs, chacun correspondant à une hypothèse particulière(vitesse, angle) de la cible relativement à l’aéronef. Cela est montré

7.1 application radar stap 145

sur la Figure 68, où 2D motifs sur les dimensions de l’antenne et dupulse (rec) sont considérés pour calculer les filtres qui éliminent lesambiguïtés naturelles entre la vitesse et l’azimut.

7.1.1 Contraintes d’implémentation

Ces caractéristiques sont principalement :

1. une large partie de l’application est représentée sous la forme deflot de données, manipulant des tableaux multidimensionnels dedonnées ;

2. la chaîne de traitement utilise différents opérateurs, chacun avecses besoins particuliers en termes de précision et de plage dy-namique ;

3. la chaîne de traitement est dynamique et peut varier pendantl’exécution par la variation fréquente des paramètres de l’algo-rithme (tailles des tableaux, bornes des boucles, . . .), en préservantgrosso modo le même graphe de traitement. Cela est générale-ment appelé multimodes dans la communauté radar ;

4. la charge en calcul est assez élevée pour clairement impliquer desunités matérielles de calcul parallèles ;

5. la performance temps réel est le besoin clé, à la fois en termesde débit de calcul et de latence. Cela peut résulter de certainsbesoins opérationnels et/ou des contraintes matérielles telles quedes limitations en taille mémoire.

7.1.2 Modélisation de STAP

L’application STAP a été modélisée en Papyrus UML en utilisant leprofile UML MARTE2. 2 Les figures de ce

chapitrereprésentent desmodèles UMLutilisables.

Commençant au niveau le plus haut, l’application est successivementdécrite en utilisant une décomposition composée ou répétitive, jusqu’auniveau de détails désiré, représenté par des tâches élémentaires quipeuvent être déployés sur des fonctions de bibliothèque.

Le niveau le plus haut de la spécification, illustré sur la Figure 69,décrit le fonctionnement global et l’interaction avec l’environnement.

Les dimensions infinies des tableaux traités par GlobalSTAP représen-tent l’abstraction du temps et la Figure 70 décrit le niveau du flot dedonnées de l’application, la répétition infinie (le temps) d’un traitementSTAP.

La Figure 71 illustre la décomposition de la tâche répétée en tempsdans une succession de filtres répétitifs, avec les dimensions des tableauxet les espaces de répétition montrées sur la figure. Les tilers qui expri-ment les constructions des motifs/tuiles pour chaque répétition ne sontpas visibles3. 3 Un modèle

complet estdisponible àl’adresse http://

gforge.inria.fr/

frs/download.php/

5755/examples_

papyrus.zip.

Chaque filtre répétitif a une fonctionnalité élémentaire différente etaccède distinctement à ses motifs :

pulsecompression prend des fenêtres glissantes monodimension-nelles de taille {16} avec un pas de {1} sur la troisième dimensiondu tableau d’entrée et calcule une valeur moyenne pour chaquede ces motifs ;

covmatrixestim prend {119, 96} blocs de taille {10, 8}, en fenêtreglissante avec un pas de {1} sur la deuxième dimension du tableau

http://gforge.inria.fr/frs/download.php/5755/examples_papyrus.zip






La tâche principale, GlobalSTAP, prend comme entrées un tableau infini dedonnées provenant des capteurs (InputSignalET) et, en utilisant les vecteursde guidage fournis par SteerVectCompIET et les coefficients Doppler fournispar Gen_Coef_DopplerET, traite les données et fournit les résultats de ladétection radar sous la forme d’un tableau infini, consommé par OutputSig-nalET pour l’affichage, la sauvegarde ou un traitement ultérieur.

Fig. 69: STAP : niveau haut

Seulement un tiler est montré, exprimant comment l’infinité des échosradar , représentés sous la forme d’un tableau avec une taille multidi-mensionnelle de {8,128,111,∗} est décomposé dans une infinité, {∗},de motifs avec une forme de {8,128,111}. La matrice de pavage de{{0,0, 0, 1}} désigne la correspondance entre la répétition infinie etla dernière dimension du tableau, pendant que la matrice d’ajustage{{1,0, 0, 0}, {0,1, 0, 0}, {0,0, 1, 0}} désigne les correspondances entreles dimensions du motif et les trois premières dimensions du tableau.

Fig. 70: STAP : le niveau flot de données

d’entrée et étend chaque motif vers un bloc de {80, 80} qui serarangé dans un tableau de taille {80, 80, 119, 96} ;

averagecovar élimine la troisième dimension du tableau d’entrée,en la remplaçant par la moyenne des {119} valeurs de cette dimen-sion ;

matinv exécute l’inversion de {96} matrices carrées de taille {80, 80} ;

7.1 application radar stap 147

Fig

.71

:Déc

ompo

siti

onde

STA

P


stap_filter applique {128} vecteurs de guidage, chacun avec une di-mension de {80}, sur chaque ligne des matrices inversées, enproduisant un tableau de taille {128, 96, 80} ;

stap_application compare les valeurs filtrées avec les pulses initiaux,par blocs de {8, 10}, pour identifier les mouvements ;

int_doppler applique les {128} vecteurs Doppler de taille {119} pouridentifier les vitesses des cibles en mouvement.

Chaque répétition est caractérisée par des répétitions et des accès auxmotifs uniformes différents, consommation ou production des données,exprimées par les informations de tiler sur chaque connecteur à l’in-térieur d’une répétition, en concordance avec la relation spécifiée parl’Équation 2.3, sur la page 36. La Figure 72 illustre la construction destilers pour deux des filtres STAP, PulseCompression et CovMatrixEstim.

– pour la répétition du PulseCompression, commençant avec chaque élément du tableau d’entrée(matrice de pavage identité), un motif de {16} éléments sur la troisième dimension est utilisépour calculer une seule valeur, {}, valeurs réarrangées dans un tableau tridimensionnel avec uneforme de {8,128,96} ;

– la différence de taille entre le tableau d’entrée et de sortie sur la troisième dimension (111−96 =15) est due aux accès en fenêtre glissante, pour les 15 derniers éléments la fenêtre d’accès sortdes dimensions du tableau et l’utilisation du modulo n’est pas souhaitée ;

– la répétition du CovMatrixEstim a aussi une fonctionnalité en fenêtre glissante, cette fois de blocs2D avec une forme de {10,8} glissant sur la deuxième dimension avec un pas de 1. Ces blocssont étendus en {119,96} blocs de taille {80,80}.

Fig. 72: Tiler construction pour les deux premières filtres

Au niveau des filtres, chaque tâche répétée a un fonctionnementélémentaire et peut être déployée sur des fonctions de bibliothèque :inversion des matrices, des calculs des valeurs moyennes, etc.

Nos modèles sont statiques et ainsi nous avons choisi d’implémenterun seul mode de la fonctionnalité multimodes mentionnée en la descrip-

7.2 vers un modèle d’exécution 149

tion de l’application STAP de la sous-section 7.1.1. Des modes multiplespeuvent êtres modélisés en utilisant les structures de contrôle baséessur les automates de mode proposées par Labbani et al. dans [55, 56]ou la prochaine version beta3 ou 1.0 de MARTE4, mais sont en dehors 4 Des références

publique ne sontpas encoredisponibles aumoment de larédaction.

l’objet de ce chapitre.

7.2 vers un modèle d’exécution

Dans la section 4.1, Étude de l’exécution, nous avons discuté autourl’exécution d’une spécification répétitive. Pour rappeler, une spécifica-tion répétitive exprime le maximum de parallélisme, en utilisant unedécomposition hiérarchique et répétitive. Elle décrit les dépendancesde données entre les éléments des tableaux et, comme conséquencedirecte, un ordre partiel strict entre les appels des tâches. Un modèled’exécution représente l’abstraction de l’exécution et il doit respecterl’ordre partiel strict défini par la spécification statique. Il est l’intentionde la conception que, en exprimant l’ordre minimal d’exécution, denombreuses décisions peuvent et doivent êtres prises au moment del’association d’une spécification sur une plateforme d’exécution.

Nous avons choisi pour le passage d’une spécification MARTE RSMvers un modèle d’exécution de le faire le plus directement possible :le modèle d’exécution devrait refléter la spécification. Ce passage direct setraduit par la contrainte qui dit qu’une tâche peut commencer sonexécution quand les tableaux d’entrées sont entièrement disponibles.

Des outils de refactoring basés sur des transformation de haut-niveauont été conçus autour le formalisme pour permettre l’adaptation de laspécification aux contraintes d’exécution. Nous avons présenté ces trans-formation dans le chapitre 5. Ici, nous approchons le problème dansune perspective plus pratique et nous allons voir comment ces outilspermettent l’exploration de l’espace de conception sur la modélisationde l’application STAP.

7.2.1 Utilisation des transformations de haut-niveau data-parallèles

Les transformations de code data-parallèles peuvent êtres utiliséesdans l’adaptation de la spécification vers l’exécution, en permettant dechoisir la granularité des flots comme une expression directe de l’associ-ation par l’étiquetage de chaque répétition avec son mode d’exécution :data-parallèle ou séquentiel.

Nos transformations de haut-niveau sont conçues comme outils derefactoring au niveau de la spécification pour optimiser l’applicationpour l’exécution sur des plateformes matérielles parallèles et pourl’exploration de l’espace de conception, qui mènent à quelques carac-téristiques très intéressantes :

a. les transformations agissent comme des outils de refactoring, lerésultat se traduit en changements du modèle au même niveaud’abstraction. Cela permet le chaînage des différentes transforma-tions et facilite l’exploration de l’application, de l’architecture etdu placement d’une sur l’autre ;

b. les transformations garantissent que l’application ne change pasde fonctionnalité, les mêmes valeurs de sortie seront calculées àpartir des mêmes entrées ;


c. comme cibles pour l’optimisation, la réduction des tailles destableaux et le management du parallélisme sont des priorités.Une spécification MARTE RSM exprime déjà le maximum deparallélisme et les transformations peuvent êtres utilisées pourchanger la granularité de l’application pour une meilleure associ-ation sur une plateforme d’exécution parallèle ;

d. la spécification, le refactoring et le passage vers un modèle d’exé-cution sont des étapes séparées. La même spécification peut êtretraduite différemment vers l’exécution, en respectant les con-traintes matérielles, fonctionnelles ou d’environnement.

7.2.2 Refactoring utilisant des transformations de haut-niveau

Par la suite, nous allons voir comment la spécification de STAP peutêtre adaptée à l’exécution en utilisant le refactoring et comment desstratégies de chaînage des transformations peuvent être déduites. Lesconcepts utilisés ont été discutés dans la présentation des transforma-tions haut-niveau Array-OL (section 5.3) et les plus importantes serontrappelés.

isolation des dimensions infinies

La présence des dimensions infinies (dans les tailles des tableaux oudes répétitions) à travers l’application est la première préoccupationquand on fait le passage vers l’exécution. Une valeur infinie pour unerépétition cause le blocage de l’exécution dans ce point et un tableauavec une dimension infinie ne peut pas être placé dans une mémoireavec une capacité bornée. Comme la dimension infinie est utilisée pourexprimer le temps (ou le flot de données), une solution est d’isoler lesvaleurs infinies à un niveau haut de la hiérarchie et de considérer ceniveau comme le niveau du flot de données à l’exécution : les tableauxne seront pas placés entièrement en mémoire (seulement un motif à lafois) et une exécution séquentielle sera choisie pour la répétition.

En utilisant la transformation de fusion sur des répétitions successivesinfinies, une répétition commune peut être calculée et elle va représenterle niveau du flot de données à l’exécution5.5 Une fusion des

deux répétitionsinfinies qui échoued’isoler ladimension infinieau niveau hautindique unespécificationinvalide.

L’application STAP a été déjà modélisée ayant toutes les valeursinfinies à un niveau de la hiérarchie (Figure 70) et donc cette étapepeut être ignorée. La spécification de la même application, mais oùles valeurs infinies auraient été au niveau de la décomposition enfiltres aurait exprimé l’exacte même fonctionnalité, mais aurait nécessitél’isolation des valeurs infinies à un niveau flot de données avant lepassage à l’exécution.

changement de la granularité

Des contraintes d’exécution pourraient imposer des changementsdans la granularité de la spécification répétitive. Prenons, par exemple, sinous disposons de 4 processeurs et nous voulons exécuter la répétitionsur la Figure 70 en parallèle, une transformation de tiling peut êtreutilisée pour partager l’espace de répétition en blocs de 4 répétitionsqui peuvent êtres placées sur les 4 processeurs et exécutées en parallèle,pendant que la séquence de blocs du niveau haut représentera le niveaudu flot de données. Cela représente ce que nous appelons changer lagranularité d’une répétition et le résultat est illustré sur la Figure 73.


Fig. 73: Partage de la répétition infinie en blocs de {4}

réduction des tableaux intermédiaires

La réduction des tableaux intermédiaires peut être réalisée par l’u-tilisation de la transformation de fusion et représente un des rôlesprincipaux du refactoring. Une fusion élémentaire calcule un tableauintermédiaire minimal entre deux répétitions successives.

Définition 16 (Taille d’un tableau multidimensionnel). La taille destableaux est calculée en unités mémoires du type des éléments dutableau, par la multiplication des dimensions de sa forme multidimen-sionnelle.

Entre deux répétitions successives6, un tableau intermédiaire minimal 6 La premièreproduit un tableauconsommé par laseconde.

est désigné par un groupe minimal de motifs produit par la premièretâche qui permet la deuxième répétition de s’exécuter au moins unefois, donc produire des éléments et en conséquence permettre uneexécution sans blocage.

Observation. La fusion calcule un groupe minimum de motifs intermé-diaires et transforme l’application en créant une répétition communeavec deux sous-répétitions et un tableau intermédiaire réduit au groupeminimal de motifs.

Exemple. La Figure 74 montre le résultat de la fusion des deux répéti-tions de la Figure 72, PulseCompression et CovMatrixEstim. Une répéti-tion commune avec une forme de {119, 96} est calculée est deux sous-répétitions de {10, 8} et respectivement {} sur le deuxième niveau dela hiérarchie. Le groupe minimal de motifs produit par la premièresous-répétition qui permet l’exécution au moins une fois7 de la deux- 7 Dans ce cas

exactement unefois, {}.

ième sous-répétition est de {10, 8, 1}, et ainsi le tableau intermédiaire estréduit de la taille initiale de {8, 128, 96} (une demande en taille mémoireréduite de 8× 128× 96 = 98304 éléments à 10× 8× 1 = 80, avec unfacteur de 98304/80 = 1228.8 fois).

La fusion de plusieurs répétitions connectées peut être réalisée par lechaînage de transformations élémentaires de fusion et d’aplatissement.


Fig. 74: Résultat de la fusion des deux premières répétitions

Suivant l’ordre de dépendance entre les tâches, chaque répétition est fu-sionnée avec le résultat de la précédente, pendant que la transformationd’aplatissement limite l’explosion des niveaux de hiérarchie.

Observation. Par une fusion multiple, seulement le dernier8 tableau in-8 Selon l’ordre de lafusion. termédiaire est minimisé. Les autres tableaux intermédiaires représen-

tent des groupes minimaux de motifs nécessaires pour l’exécutionau moins une fois de la dernière sous-répétition, et non de la sousrépétition qui consomme le tableau respectif.

Exemple. La Figure 75 montre la fusion des répétitions PulseCompres-sion, CovMatrixEstim, AverageCovar et MatInv. Les premières trois sous-répétitions représentent des exécutions minimales qui permettent ladernière sous-répétition de s’exécuter au moins une fois et ainsi min-imiser le dernier tableau intermédiaire, mais pas les deux d’avant. Suiteà une telle fusion multiple, le premier tableau intermédiaire est réduità une taille de {10, 8, 1, 119}, 119 fois plus grande que le minimumtableau atteint par la fusion élémentaire des deux premières répétitionsmontrées sur la Figure 74.

Un autre facteur qui rentre en jeu est la quantité de recalculs intro-duits dans la spécification par la fusion. Les recalculs sont représentéspar l’augmentation de la répétition complète pour la première tâche


Fig. 75: STAP : fusion des quatre premières tâches

impliquée dans une fusion, causée par les motifs de production/con-somption entre les deux répétitions.

Observation. La répétition complète d’une tâche est donnée par la con-caténation de toutes les formes multidimensionnelles en descendant lesniveaux de la hiérarchie du haut jusqu’au niveau de la tâche concernée9. 9 La répétition

infinie du niveauflot de données estnégligée dans cechapitre.

Les recalculs sont représentés par l’augmentation de la répétition com-plète pour une tâche, suite à une transformation de fusion.

Définition 17 (Calcul associé à un espace de répétition). Un espacede répétition multidimensionnel exprime une boucle d’exécution dela tâche répétée égale à la multiplication des dimensions de la formemultidimensionnelle de son espace.

Les accès en fenêtre glissante par la deuxième tâche impliquentdans une fusion, où des éléments initiaux se retrouvent dans plusieursgroupes de motifs minimaux après la fusion, détermine la premièretâche de les calculer plusieurs fois, ce qu’explique le recalcul. Dans lecas des recalculs, la réduction de la taille du tableau intermédiaire acomme effet secondaire une augmentation des calculs.

Exemple. Sur la Figure 74, la répétition complète de la première tâcheest, suite à la concaténation des espaces de répétition des deux niveauxde la hiérarchie, de {119, 96, 10, 8}, pendant que la répétition initialeétait de {8, 128, 96} et nous pouvons observer une augmentation desrépétions avec un facteur de 119× 96× 10× 8/(8× 128× 96) = 9.29.

Ainsi, dans le cas de valeurs intermédiaires qui sont utilisés plusieursfois, le concepteur doit faire un compromis entre le stockage en mémoireou des calculs multiples de ces valeurs.


7.2.3 Réduction des tableaux intermédiaires de STAP

La réduction des tableaux intermédiaires est l’utilisation principalede la transformation de fusion. Ayant plusieurs répétitions successives,nous cherchons une stratégie pour réduire au maximum l’ensembledes tableaux intermédiaires et en même temps d’éviter des pointsde blocage dans l’exécution et limitant le plus possible les recalculsintroduits par les fusions. Des placements sur différentes architecturespourraient imposer légèrement différentes stratégies de refactoring,comme l’interdiction de recalculs ou la priorité vers la réduction destailles des tableaux au détriment des recalculs. Sur l’application STAPde la Figure 71, nous avons choisi comme objectif de réduire les tableauxintermédiaires tout en limitant les recalculs.

fusion complète. Une fusion complète (la fusion de toutes lesrépétitions successives d’un niveau de hiérarchie) n’est pas appropriéedans le cas de STAP, comme le montre le Tableau 3, contenant lesvaleurs des répétitions avant, après et les recalculs introduits par unetelle fusion. Comme le montre le tableau, nous nous retrouvons avecune importante quantité de recalculs. La fusion multiple des répétitionsgaranti la minimisation seulement du dernier tableau intermédiaire. LeTableau 2 montre comment seulement deux des tableaux intermédiairesont une taille réduite, quant aux autres tableaux, nous pouvons observermême une augmentation en taille, causée par le re-arrangement desmotifs suite à la succession des transformations fusion/aplatissement10.10 Des accès initiaux

chevauchants sontétendus surplusieursdimensions, avecduplication deséléments.

tableau taille avant taille après réduction (/)

pc→cme 8× 128× 96 8× 128× 119 0,807

cme→ac 80× 80× 119× 96 80× 80× 119× 119 0,807

ac→mi 80× 80× 96 80× 80× 119 0,807

mi→sf 80× 80× 96 80× 80× 119 0,807

sf→sa 80× 128× 96 80× 119 103,26

pc→sa 8× 128× 96 8× 128× 119 0,807

sa→id 119× 128× 96 119 12288

Les tableaux sont identifiés par les tâches qui produisent/consomment letableau (Producteur→Consommateur) et la réduction de la taille est donnéepar la division des tailles des tableaux avant et après le refactoring.

Tab. 2: Tailles des tableaux pour la fusion complète

Néanmoins, une telle transformation apporte des informations utilesqui peuvent être utilisées pour trouver la meilleure séquence de fusionspour atteindre notre objectif déclaré. Tout d’abord, elle fournit l’ordrede fusion qui représente l’ordre partiel strict entre les tâches répétées,dans ce cas : PulseCompression ⊕ CovMatrixEstim ⊕ AverageCovar ⊕MatInv ⊕ StapFilter ⊕ StapApplication ⊕ IntDoppler. Deuxièmement, surle Tableau 3 nous pouvons identifier où des changements dans lesrecalculs apparaissent et ainsi les fusions qui introduisent des recalculs,dans nos cas : MatInv ⊕ StapFilter et StapFilter ⊕ StapApplication. Dansnotre but de limiter les recalculs, cela peut suggérer que la fusiondes quatre premières répétitions et des deux dernières, tout en isolantStapFilter, n’introduirait pas des recalculs.


tâche répétition avant répétition après recalcul (×)

pulsecompression (pc) 8× 128× 96

128× 96×

8× 128× 119119× 119

80× 80× 119119

80× 119119

1

119× 128

covmatrixestim (cme) 119× 96 119× 128

averagecovar (ac) 80× 80× 96 119× 128

matinv (mi) 96 119× 128

stapfilter (sf) 128× 96× 80 119

stapapplication (sa) 119× 128× 96 1

intdoppler (id) 128× 96 1

La hiérarchie de répétitions est représentée par des parenthèses dans le tableau. Après la fusioncomplète des filtres, une répétition commune de {128,96} est calculée et la répétition totale pourchaque des sous-répétitions est donnée par la concaténation avec celle commune. Le recalcul estcalculé comme division entre la quantité des répétitions après et avant le refactoring.

Tab. 3: Répétitions pour la fusion complète

fusions deux-par-deux . D’autres fusions qui apportent des infor-mations utiles sont les fusions de chaque deux répétitions successives.Le résultat contient les valeurs des tableaux minimaux réalisables entredeux répétitions et sur le recalcul introduit par une telle opération,comme montré sur le Tableau 4.

fusion réduction (/) recalcul (×)

pulsecompression ⊕ covmatrixestim 128× 96/10 = 1228.8 9.29

covmatrixestim ⊕ averagecovar 96 1

averagecovar ⊕ matinv 96 1

matinv ⊕ stapfilter 96 128

stapfilter ⊕ stapapplication 128× 96 = 112288 119

pulsecompression ⊕ stapapplication 128× 96/10 = 1228.8 119× 10 = 1190

stapapplication ⊕ intdoppler 128× 96 = 12288 1

La réduction maximale pour les tableaux intermédiaires ainsi que le recalcul introduit sur la premièresous-répétition, après la fusion de chaque deux répétitions successives.

Tab. 4: Fusion deux-par-deux

meilleur choix de fusion. Les informations apportées par lafusion complète et deux-par-deux peuvent guider le choix pour uneséquence de transformations qui achèvera les meilleurs résultats pournotre objectif choisi de réduire au maximum les tableaux intermédiairestout en limitant les recalculs. La fusion complète suggère de grouperles quatre premières répétitions et les deux dernières, mais les fusionsdeux-par-deux montrent que la fusion des deux premières répétitionsintroduit des recalculs avec un facteur de presque 10 pour la réductiondu tableau intermédiaire avec un facteur de 1228.8.

Nous avons deux choix pour le premier groupe de répétitions :a. si le facteur de 10 pour le recalcul de la première sous-répétition

est acceptable, nous pouvons grouper les quatre premières répéti-tions pour la fusion ;

b. sinon, seulement les répétitions deux à quatre seront fusionnées,sans recalcul cette fois.

Pour illustration, nous avons choisi la première alternative, de grouperles premières quatre répétitions et les deux dernières. Le résultat mon-


tre une réduction au maximum (selon les tailles minimales réalisablesdu Tableau 4) des tableaux : CovMatEst→AvCov, AvCov→MatInv andStapApp→IntDopp mais une réduction non-maximale pour PulCompr→CovMatEst. Sur le deuxième niveau de la hiérarchie, par la fusion desdeux sous-répétitions, PulseCompresion⊕CovMatrixEstim, nous pouvonsréduire encore plus ce tableau (au maximum cette fois), avec commerésultat la présence de trois niveaux de hiérarchie pour ces deux sous-répétitions. Les réductions en taille des tableaux sont montrés sur leTableau 5, pendant que les répétitions et les recalculs sont montrés surle Tableau 6.

tableau taille avant taille après réduction (/)

pc→cme 8× 128× 96 8× 10 1228.8

cme→ac 80× 80× 119× 96 80× 80× 119 96

ac→mi 80× 80× 96 80× 80 96

mi→sf 80× 80× 96 80× 80× 96 1

sf→sa 80× 128× 96 80× 128× 96 1

pc→sa 8× 128× 96 8× 128× 96 1

sa→id 119× 128× 96 119 12288

Tab. 5: Tailles des tableaux pour le meilleur choix de fusion

tâche répétition avant répétition après recalcul (×)

pulsecompression 8× 128× 96

96×

119×

(10× 81

)80× 801

9.29

covmatrixestim 119× 96 1

averagecovar 80× 80× 96 1

matinv 96 1

stapfilter 128× 96× 80 128× 96× 80 1

stapapplication 119× 128× 96128× 96×

(119

1

)1

intdoppler 128× 96 1

Tab. 6: Répétitions pour le meilleur choix de fusion

Une partie de l’application transformée selon la stratégie précédenteest illustré sur la Figure 76, le niveau des filtres et, sur la Figure 77, lesdeux dernières sous-répétitions.

7.3 analyse des résultats

Dans la section précédente, nous avons vu comment les transforma-tions de haut niveau peuvent être utilisées pour adapter une spécifi-cation à l’exécution. Les optimisations sont de deux types, plateformedépendante ou d’usage général. La réduction des tableaux intermé-diaires peut être vue comme une optimisation d’usage général, maiscomme montré, des contraintes peuvent guider le choix des fusionsqui dirigent la réduction des tableaux intermédiaires. Des changementsde la granularité, en utilisant des transformations de changement depavage, tiling ou aplatissement, sont des transformations plus orientéesoptimisations plateforme-dépendante, visant l’adaptation de la spécifi-cation vers l’architecture matérielle et l’optimisation du placement desrépétitions sur les unités parallèles.

7.3 analyse des résultats 157

Les premières quatre répétitions groupées dans une seule répétition com-mune de {96} et les deux dernières dans une répétition de {128,96} d’unetâche composée contenant les deux sous-répétitions des tâches initiales,montrées sur la Figure 77.

Fig. 76: Niveau des filtres transformé

La réduction du tableau intermédiaire StapApp→IntDopp vers une taille de119 peut être observée.

Fig. 77: Sous-répétitions de StapApplication et IntDoppler

Les applications de traitement intensif de signal sont souvent représen-tées sous la forme de filtres successifs, comme le cas de l’applicationradar STAP. Les accès complexes aux motifs rendent impossible latâche de réduire au maximum tous les tableaux intermédiaires et par-fois seulement avec l’introduction des calculs supplémentaires.

Nous avons montré comment, en explorant des scénarios variés derefactoring, nous pouvons extraire des informations qui nous amènentvers le meilleur choix d’enchaînement de transformations. La fusion


complète apporte des informations sur l’ordre partiel strict et sur lesjonctions où des recalculs sont introduits, pendant que les fusionsdeux-par-deux fournissent les valeurs pour les réductions maximalesréalisables et sur les recalculs introduits par une telle réduction. Cesinformations ont été utilisées pour séparer les répétitions en groupesen interdisant des fusions qui introduisent beaucoup de recalculs. Desobjectifs et des applications différentes pourront déterminer l’usagealternatif des fusions, prenant par exemple la présence d’un tableau àdimension infinie, l’élimination de cette dimension infinie est prioritaireà l’introduction des recalculs.

7.4 conclusions

Nous avons montré dans ce chapitre comment les transformations dehaut-niveau data-parallèles peuvent être utilisées dans l’exploration del’espace de conception pour des applications multidimensionnelles detraitement intensif de signal, modélisées en MARTE RSM. Le but estde restructurer la modélisation à un niveau haut de spécification pourpermettre un passage direct à l’exécution. La direction principale d’util-isation est la réduction des tailles des tableaux et le changement dansla granularité des répétitions en fonction des contraintes matérielles,du placement, de l’environnement, de l’exécution, etc.

Nous avons présenté une stratégie qui permet la réduction des taillesdes tableaux intermédiaires guidée par les accès aux motifs. Des autresstratégies peuvent être utilisées et, ensemble avec des placements variéssur la plateforme d’exécution, elles peuvent être explorées et guidéesavec des résultats remontés des niveaux de la génération de code, de lasimulation ou de l’exécution dans l’environnement Gaspard2.

Comme travaux d’avenir, ces différentes stratégies pourront être im-plémentées dans l’environnement, ainsi que des outils semi-automatiquesde refactoring : proposition pour le concepteur de différentes stratégiesavec des gains calculés en matière de réduction des tableaux et derecalculs.

Dans le chapitre suivant, nous allons présenter brièvement les travauxd’implémentation et intégration dans l’environnement Gaspard2.

8R E FA C T O R I N G D A N S L E C O N T E X T E D E GASPARD2

8.1 Contributions 1598.1.1 Niveau transformations 160

8.1.2 Niveau interface 161

8.1.3 Implémentation de l’interaction avec lesdépendances interrépétitions 162

8.1.4 Interfaçage avec l’atelier Ter@ops 164

8.2 Perspectives 1648.3 Conclusions 165

Nous avons vu dans les chapitres précédents la base théorique der-rière le refactoring de haut-niveau basé sur des transformations data-parallèles et comment ces outils peuvent être utilisés pour l’explorationde l’espace de conception pour adapter une spécification aux contraintesd’exécution. Des stratégies de refactoring peuvent être explores, commecelle présentée dans le chapitre précédent, stratégie de refactor-ing pour l’exploration de l’espace de conception, pour laréduction des tailles des tableaux intermédiaires.

Pour pouvoir bénéficier des outils de refactoring et aussi pour pou-voir les utiliser en collaboration avec les autres outils autour l’environ-nement de comodélisation Gaspard2, ils doivent être intégrés dansl’environnement.

Pendant cette thèse, une large partie des travaux a visé l’intégrationdes outils de refactoring dans Gaspard2 et l’interfaçage avec l’ensembledes outils développés au sein de l’équipe. L’intégration permet en mêmetemps la validation des travaux théoriques, mais aussi nous a permisd’avoir un retour et d’étendre les outils de transformations dans unevision orientée plus vers l’utilisation pratique.

Dans ce chapitre nous allons présenter brièvement les travaux d’im-plémentation réalisés pendant la thèse. Il s’agit principalement del’implémentation des transformations de haut-niveau et de l’interfaçageavec l’environnement, mais aussi des travaux dans le contexte IDM deGaspard2, notamment autour les transformations de modèles entre lesdifférents niveaux d’abstraction de Gaspard2.

La section 8.1 résume mes contributions relativement à l’implémen-tation et l’intégration dans l’environnement Gaspard2. La section 8.2identifie quelques perspectives d’évolution et la section 8.3 présente lesconclusions.

8.1 contributions

Les optimisations de haut-niveau data-parallèles ont été conçues dansle contexte du modèle de calcul Array-OL et sont utilisées dans l’envi-ronnement de comodélisation Gaspard2. La technique d’optimisations’appuie principalement sur l’exploration de l’espace de conceptionen suivant plusieurs directions, selon l’objectif, les contraintes et lescaractéristiques de la spécification.

159

160 refactoring dans le contexte de gaspard2

Dumont a commencé les travaux d’implémentation des transfor-mations Array-OL par l’implémentation d’un cadre permettant lamanipulation du formalisme ODT dans le contexte des transformationsArray-OL. L’interfaçage avec le niveau des opérations ODT se faisaitpar l’intermède d’une interface de programmation (API1) qui permet la1 De l’anglais

ApplicationProgrammingInterface.

spécification des structures de répétitions hiérarchiques interconnectées,la transformation de ces structures dans un format qui corresponde auformalisme ODT et l’appel à la transformation ODT. Le résultat de latransformation ODT est traduit sous la forme de la spécification internede l’API.

Malgré cette interface avec les transformations ODT, il n’y avait pasun vrai branchement dans l’environnement Gaspard2 et l’utilisationdes transformations était assez laborieuse.

Pendant ma thèse, une large partie de mes activités ont été orien-tées vers le branchement de ces transformations de haut-niveau auGaspard2. Cela a impliqué :

– extension des transformations ODT : seule la transformation defusion était implémentée auparavant ;

– implémentation des extensions proposées dans la section 5.4 ;– branchement au niveau du métamodèle Gaspard2 ;– avec le passage au profil UML standard de MARTE, le branchement

sur l’éditeur visuel Papyrus UML ;– implémentation de l’interaction avec les dépendances interrépéti-

tions ;– validation des travaux sur de modélisations d’applications réelles ;– dans le cadre de la méthodologie IDM de Gaspard2, participation

aux différentes étapes du développement : définition des méta-modèles intermédiaires, implémentation de transformations demodèles, . . . ;

– dans le cadre du projet Ter@ops, l’interfaçage avec le reste del’atelier par l’import/export entre nos modèles (UML + profileMARTE) et le format XML proposé par PIPS2.2 http://www.cri.

ensmp.fr/pips/

8.1.1 Niveau transformations

Le passage entre une spécification de haut-niveau en Gaspard2 etle formalisme ODT pour les opérations nécessaires aux calculs destransformations se fait à travers trois niveaux :

niveau spécification : la spécification basée sur la décomposi-tion en composants répétitifs hiérarchiques ;

niveau api : à ce niveau les répétitions et les dépendances de don-nées sont identifiées et la traduction vers le formalisme ODT et àl’envers est gérée ;

niveau odt : les répétitions sont exprimées sous la forme ODT, desmatrices et des vecteurs de valeurs rationnels ensemble avec tousles opérateurs ODT et les opérations du formalisme.

Au niveau de l’API les répétitions sont représentées comme desobjets OdtApiTask et chaque tiler est transformé dans une OdtApiDepen-dance, d’entrée ou de sortie, selon le cas. Une telle dépendance contienttoutes les informations de l’accès par motifs uniformes (origine, ma-trices de pavage et d’ajustage). Une OdtApiTask peut être hiérarchique,cas ou les sous-répétitions sont référencées sous la forme d’une listed’OdtApiTasks. Les dépendances de données entre les répétitions s’-

http://www.cri.ensmp.fr/pips/

http://www.cri.ensmp.fr/pips/

8.1 contributions 161

expriment par des points de connexion, OdtApiConnectionPoint : deuxdépendances qui consomment/produisent le même tableau partagentle même OdtApiConnectionPoint.

Chaque transformation a sa propre interface d’appel. OdtApiFusiongère la transformation de fusion entre deux répétitions connectées :deux OdtApiTask qui partagent un point de connexion entre deux dépen-dances, de sortie pour la première et d’entrée pour la deuxième.

À ce niveau j’ai ajouté les transformations ODT qui n’étaient pasencore implémentées :

– OdtApiChangementPavage pour les transformations de changementde pavage par ajout de dimensions et par agrandissement linéaire ;

– OdtApiCollapse pour l’aplatissement ;– OdtApiTiling pour l’opération de tiling.

8.1.2 Niveau interface

Pour pouvoir utiliser les transformations Array-OL dans le contextede la spécification en Gaspard2, le branchement de la boîte à outilsde refactoring à l’environnement de comodélisation était impératif.Avec l’aide des outils de développement autour Eclipse, une interfaceutilisateur branchée à l’éditeur de modèles a été développée.

Au début, le branchement se faisait au niveau des modèles ecore

conformes au métamodèle Gaspard2, la première étape disponiblesous Eclipse au niveau spécification3. 3 La modélisation

visuelle se faisait enMagicDraw UML.

Avec l’apparition du profile UML standard OMG MARTE, des ef-forts ont été faits dans l’équipe pour s’aligner au standard par l’adop-tion du standard comme norme de spécification. Dans cette directionnous avons profité aussi de l’éditeur Papyrus UML, basé aussi sur laplateforme Eclipse. Maintenant nous pouvons vraiment dire que nousdisposons d’un environnement intégré de comodélisation : toutes lesétapes, de la spécification visuelle jusqu’à la génération du code enpassant par les différents niveaux d’abstraction, sont intégrées autourla plateforme Eclipse.

Pouvoir profiter de l’interface visuelle disponible dans Papyrus UMLpour les transformations de haut niveau nous semblait indispensable.Une autre interface avec la boîte de refactoring a été développée, cettefois branchée au éditeur visuel de Papyrus. Les principes de l’interfacerestent les mêmes pour les deux interfaces :

– en fonction d’/des élément(s) sélectionné(s), des transformationsde haut niveau sont mises à disposition ;

– l’utilisateur choisit la transformation voulue, en spécifiant desparamètres si le cas : sur quelle(s) dimension(s) de faire le change-ment de pavage, le facteur de pavage, etc. ;

– la partie de la spécification qui est impliquée dans la transformationest transformée sous la forme de l’API.Observation. Maximum deux niveaux de répétitions hiérarchiquescommençant avec la/les tâche(s) sélectionnée(s) sont nécessaires ;

– l’API s’occupe du calcul de la transformation au niveau ODT et demettre à disposition le résultat de la transformation ;

– le résultat, toujours sous la forme d’une hiérarchie de maximumdeux niveaux de répétitions, est rétransformé dans des objets quicorrespondent au modèle initial.


Observation. Dans le cas de l’interface avec l’éditeur visuel de Pa-pyrus UML, les représentations visuelles des éléments transformésdoivent être transformées aussi.

– les objets résultat sont branchés au bon endroit dans le modèleUML.

La traduction des éléments du modèle sélectionné est une opérationassez simple, en faisant la traduction un-à-un de tous les élémentséquivalents. L’équivalence des concepts à été discutée dans la sous-section 3.6.1, Équivalence des concepts.

Le problème plus complexe est de retrouver les bons endroits oùréinsérer les éléments transformés. Cela se fait en gardant un lien entreles éléments avant et après la transformation, par des relations entrecertains concepts de la forme interne de l’API et les concepts du modèleinitial :

– les OdtApiDependences correspondent aux tilers ;– les OdtApiConnectionPoints correspondent aux ports de connexion.Pour faciliter la tâche

de l’utilisateur, lespositions relatives deséléments UML dansles diagrammes(composants,propriétés, ports, . . .)sont conservées.

De plus, pour la transformation de la représentation visuelle, en fonc-tion des positions initiales dans les diagrammes composites du modèleavant la transformation, des nouvelles positions pour les éléments trans-formés sont calculées, avec la création de nouveaux diagrammes et ledéplacement des éléments initiaux si nécessaire.

Exemple. La Figure 78 montre l’utilisation d’outil de refactoring dansl’éditeur Papyrus UML.

En fonction des éléments UML sélectionnés4, le menu contextuel4 Des propriétésUML quicorrespondent auxappels desous-tâches.

du diagramme composite (Subfig. 78a) propose les transformationsdisponibles. Des boites de dialogue seront utilisées pour la saisie desparamètres de la transformation (facteur de changement de pavage,dimensions, etc.).

La Subfig. 78b montre le résultat de la fusion de trois répétitionssuccessives :

– les répétitions sont remplacées sur le diagramme par la répétitionglobale ;

– les sous-répétitions et le niveau inférieur de la composition sontplacées sur des nouveaux diagrammes composites.

Observation. Les diagrammes composites (Figure 78) montrent unique-ment des vues graphiques du modèle UML. Les vrais changementseffectués par l’outil de refactoring sont au niveau UML et les dia-grammes montrent ces changements pour apporter une vue visuelledu refactoring. Les transformations de haut-niveau peuvent être util-isées directement sur les objets UML de la vue Outline, avec les mêmesrésultats exceptant les modifications de la représentation visuelle5.5 Cette

fonctionnalité peutêtre employée dansle cas où on nedispose pas d’unevue graphique dumodèle UML.

8.1.3 Implémentation de l’interaction avec les dépendances interrépétitions

Pour gérer l’interaction des transformations de haut-niveau avec lesdépendances interrépétitions, l’algorithme présenté dans le chapitre 6 aété ajouté à la boite d’outils de refactoring.

Au niveau de l’API, certains concepts ont été ajoutés pour exprimerles dépendances interrépétitions. Ces concepts sont illustrés sur laFigure 79.

Une étape de recalcul des dépendances a été ajoutée au calcul destransformations. Au niveau de l’API, après la traduction du résul-tat de la transformation ODT, la distribution des répétitions avant et

8.1 contributions 163

(a) Appel de la fusion

(b) Modèle résultat

Fig. 78: Utilisation d’outils de refactoring

après la transformation est identifiée et pour chaque dépendance inter-répétition avant la transformation, le/les dépendance(s) équivalente(s)sont calculée(s) par la résolution du système d’inéquations donné parl’Équation 6.12, sur la page 135.


Fig. 79: Extension pour gérer les dépendances interrépétition

8.1.4 Interfaçage avec l’atelier Ter@ops

Le projet Ter@ops6 vise de proposer une solution apportant à la6 Ce travail à étéeffectué dans lecadre du projetTer@ops, http://www.teraopsemb.

ief.u-psud.fr/.

fois efficacité de traitement et souplesse d’emploi par une facilité deprogrammation pour de nombreuses applications de traitement intensif(imagerie, multimédia, etc.) dans le contexte des systèmes complexes« embarqués » requièrent de plus en plus de traitements intensifs etdes performances temps réel garanties. L’approche Ter@ops est renduepossible par la mise en coopération des compétences systèmes associésaux compétences en plates-formes SoC, en compilation et architecturesde traitement parallèles.

La première phase du projet Ter@ops inclut la mise en place d’unechaîne développement logiciel fondée sur l’approche Array-OL, sur lelangage C et sur un ensemble d’outils existants. Les outils participantau projet (APOTRES, Gaspard2, PIPS, SPEARDE, XLR8, GRAPHITE)doivent être fédérés autour de modèles communs de tâche, d’applica-tion, de machine cible et d’application placée.

L’interfaçage entre ces outils dans le cadre de l’atelier se fait parl’intermède de schémas XML correspondants aux modèles fournis parPIPS suite à l’analyse de code.

Pour l’intégration de Gaspard2 dans l’atelier, un outil d’import/ex-port entre ce format et les modèles manipulés par Gaspard2 (UML + leprofil MARTE) à été développé. Cela permet l’interfaçage avec les autresoutils dans le projet et bénéficier du refactoring Array-OL. La deuxièmepossibilité est l’exportation des modèles conçus en MARTE dans le for-mat XML qui peuvent être utilisés par le reste de l’atelier. L’outil d’im-port/export est disponible à l’adresse http://gforge.inria.fr/frs/

download.php/20222/fr.lifl.west.gaspard2.tools.convertor.pipsxml_

0.2.2.jar.

8.2 perspectives

Les transformations de haut-niveau data-parallèles permettent lerefactoring de la spécification répétitive et facilitent l’exploration del’espace de conception. L’intégration dans l’environnement de comod-

http ://www.teraopsemb.ief.u-psud.fr/



http://gforge.inria.fr/frs/download.php/20222/fr.lifl.west.gaspard2.tools.convertor.pipsxml_0.2.2.jar



8.3 conclusions 165

élisation Gaspard2 offre la possibilité de collaborer avec les autresfonctionnalités intégrées dans l’environnement.

Dans ce sens, l’utilisation des résultats des niveaux bas de la généra-tion de code, la simulation ou l’exécution pour guider le refactoringpeut offrir une solution pour augmenter les performances du code.Cette technique d’optimisation partage des concepts avec la compila-tion itérative. Les informations des niveaux bas peuvent être remontésau niveau spécification en utilisant les mécanismes de trace étudiésdans l’équipe par Aranega et al. [5].

Une autre direction d’évolution possible est l’implémentation etl’intégration dans l’environnement de stratégies de refactoring guidéespar le concepteur, en fonction des gains en termes de taille mémoire,recalculs, granularité, etc.

8.3 conclusions

Dans ce chapitre sont présentés les travaux d’implémentation dans lecontexte de l’environnement Gaspard2, effectués pendant les annéesde thèse. Dans l’équipe DaRT de l’INRIA Lille-Nord Europe et de LIFL,une attention spéciale est mise sur l’intégration des différents travauxeffectués dans l’équipe dans Gaspard2 et de les utiliser en commun.

L’intégration des outils de refactoring nous permet la validation destravaux théorétiques autour les techniques d’optimisation basées surles transformations de haut-niveau, de bénéficier de résultats expéri-mentales remontés des niveaux simulation/exécution et d’explorerdifférentes stratégies de refactoring.

C O N C L U S I O N G É N É R A L E

bilan

Les travaux présentés dans ce document s’inscrivent dans le cadre desrecherches menées sur la modélisation et la conception des systèmes surpuce à hautes performances pour les applications de traitement intensifde signal à parallélisme massif. Dans cette thèse, nous nous sommes in-téressés premièrement à la modélisation conjointe au plus haut niveaud’abstraction des applications massivement parallèles, des architecturesrépétées et du placement distribué des concepts applicatifs (calculs,données) sur des unités matérielles (processeurs, mémoires). Une spé-cification répétitive permet la modélisation visuelle du maximum deparallélisme disponible au niveau application, une représentation com-pacte des architectures répétées interconnectées et facilite l’explorationde l’espace de conception.

Nous avons présenté les différentes approches et différents modèlesde calcul existants pour la spécification des applications de traitementintensif de signal à parallélisme massif, et nous avons vu que le langagede spécification Array-OL semblait bien adapté pour la description del’aspect parallèle et multidimensionnel des données. Ses constructionsd’accès par motifs réguliers permettent l’expression de l’ensemble desaccès complexes (mais uniformes) qu’on peut rencontrer.

Pourtant, des règles de construction définies sur la spécification pourla rendre ordonnançable statiquement interdisent la construction desdépendances cycliques. Ensemble avec les principes de base du langage(assignation unique, la non-existence des variables globales, etc.), celarendrait impossible d’exprimer des constructions d’état, essentiellesdans un langage « complet » orienté flot de données. Pour surpassercette limitation, nous avons proposé une extension du langage permet-tant l’expression des dépendances uniformes entre les répétitions dela même tâche. L’aspect uniforme de ces dépendances a un impactlimité sur le parallélisme et des méthodes d’ordonnancement des répéti-tions à dépendances uniformes sont disponibles dans la littérature. Cetype de dépendance peut également être employé dans la modélisationcompacte de topologies répétitives d’architectures matérielles.

Nous avons discuté des aspects liés à la comodélisation répétitive desapplications, des architectures et du placement en MARTE. L’utilisationextensive des paquetages RSM et HRM de MARTE sert comme pointd’entrée au niveau spécification de haut niveau de l’environnementGaspard2 développé au sein de l’équipe DaRT où j’ai préparé cettethèse. Nous avons dédié un chapitre de ce document à la modélisationrépétitive en MARTE pour Gaspard2 ; tous les concepts d’Array-OLsont disponibles dans le paquetage Repetitive Structure Modeling. Unespécification applicative en MARTE doit toujours être conforme aumodèle de calcul Array-OL pour garder la propriété de la définitionstatique et nous avons montré comment une spécification en MARTEpeut être réduite à celle du modèle de calcul Array-OL. La modélisa-tion des architectures répétées est soumisse à moins de contraintes etcela permet l’expression compacte d’une large gamme de topologiesrépétitives.

167


L’expression complète du maximum de parallélisme au niveau dela spécification est essentielle pour pouvoir exploiter la régularitédisponible dans les applications de traitement intensif de signal. Maiscela représente seulement le premier pas, tout dépend de commentcette spécification est exécutée dans le cadre des systèmes embarquésavec des unités de calcul parallèles.

Dans la deuxième partie de cette thèse, nous nous sommes intéressésau passage efficace de la spécification vers l’exécution par l’emploi destechniques d’optimisation de haut niveau permettant d’adapter unespécification aux contraintes de l’exécution, des ressources matérielles,de l’environnement, etc. Des outils de refactoring basés sur des trans-formations data-parallèles sont disponibles pour restructurer la spécifi-cation répétitive, en manipulant les concepts de granularité, hiérarchie,parallélisme.

L’ensemble des transformations déjà disponibles a été analysé etdans cette thèse nous avons proposé des extensions visant à étendre ledomaine d’applicabilité et à mieux définir certaines propriétés liées auxtransformations, à leur rôle et à leur impact sur la spécification.

Avec l’extension du langage Array-OL pour l’expression de dépen-dances uniformes, le problème de l’impact des dépendances sur lefonctionnement des transformations de haut niveau est apparu. Lescalculs des transformations se rapportaient à un formalisme d’expres-sion de dépendances entre des espaces multidimensionnels (l’ODT)et l’apparition des dépendances entre les éléments du même espacen’était pas exprimable sans des modifications au cœur du formalisme,avec des conséquences majeures à tous les niveaux du fonctionnementdes transformations.

Pour gérer cette interaction entre les dépendances uniformes et lestransformations de haut niveau sans devoir modifier radicalement toutle formalisme ODT, nous avons choisi une deuxième solution qui nousa permis de calculer les dépendances uniformes après une transforma-tion de refactoring sans toucher au formalisme ODT. On s’appuyantsur quelques caractéristiques du fonctionnement des transformationset en mettant la condition que la sémantique de l’application et doncles dépendances de données doivent rester les mêmes après une trans-formation, nous avons réussi a formaliser et prouver un algorithme quipermet le calcul des dépendances uniformes sur les nouveaux espacesde répétition.

Avec l’objectif de valider en pratique l’ensemble de travaux théoriquesautour le refactoring de haut niveau, l’implémentation et l’intégrationdans l’environnement Gaspard2 était obligatoire. Cela nous a permisde vérifier l’exactitude et la validité des calculs de refactoring par destransformations Array-OL, ainsi que de l’algorithme de calcul desdépendances uniformes après de telles transformations.

L’intégration des outils de refactoring dans l’environnement Gas-pard2 a ouvert la porte à des stratégies d’utilisation des transformationsArray-OL. Nous avons proposé une telle stratégie pour la réductiondes tailles des tableaux intermédiaires dans la spécification et nousavons illustré son fonctionnement sur la modélisation d’une applicationréelle de traitement de radar.

Néanmoins, le problème d’optimisation reste très complexe et estmulticritères, favorisant des heuristiques ou des stratégies de refactor-ing aux algorithmes exacts. Une autre possibilité intéressante est uneapproche itérative d’optimisation, pilotée par des résultats remontant

8.3 conclusions 169

des niveaux simulation/exécution/synthèse dans le cadre de l’environ-nement Gaspard2.

analyse critique

Mes travaux autour d’Array-OL, les présentations que j’ai fait et desdiscutions autour du sujet m’ont amené à émettre plusieurs critiquessur Array-OL et sur les langages de spécification en général.

Les langages de spécification facilitent la modélisation, mais sont laplupart du temps très restrictifs et très spécialisés. La sémantique de ladescription est parfois rigide et très proche au formalisme mathéma-tique interne, notamment utilisée pour le calcul d’un ordonnancementstatique. Un formalisme plus proche de l’utilisateur, plus général etplus flexible me semble plus approprié dans la perspective de l’utilisa-teur et des transformations vers la forme mathématique sont possiblesderrière, transparentes à l’utilisateur.

J’ai constaté que certains principes d’Array-OL restent souvent rel-ativement obscurs, même pour des gens qui ont déjà travaillé dessus.Même si à la fin la construction des motifs d’accès uniformes est ré-duite à la maîtrise de la construction de tiler, la présence de plus detrois dimensions dans les formes multidimensionnelles rend difficile lavisualisation des accès par le concepteur.

Une autre critique est en lien avec le formalisme ODT utilisé pourles calculs des transformations. Je considère que le formalisme est trèsrestrictif et il est extrêmement laborieux d’ajouter des fonctionnalités.C’était le cas avec l’extension pour exprimer des dépendances uni-formes ; le choix de contourner le formalisme ODT a beaucoup facilitéle travail théorique et l’implémentation.

Une autre restriction est apportée par la contrainte de spécifier desvaleurs numériques dans les tailles des tableaux et des tilers d’accès.La contrainte est principalement liée aux règles de construction pourgarantir la définition statique, mais aussi par le calcul numérique desODTs. Les règles de la définition statique peuvent être plus facilementadaptées pour permettre la spécification des paramètres, contrairementau formalisme ODT qui s’appuie sur des calculs numériques exacts (latransformation de fusion principalement).

perspectives

Plusieurs directions d’évolutions futures peuvent être envisagées.Il reste toujours des possibilités d’extension du langage Array-OL

pour améliorer encore son pouvoir d’expression. L’introduction desparamètres dans la spécification pourrait rendre une spécification plusgénérale. L’adaptation des templates UML pour la modélisation descomposants paramétrables dans Gaspard2 a été étudiée par de Mouraet al. en [26]. Des aspects dynamiques peuvent être envisagés avecl’observation que cela signifierait la perte de la définition statique etde l’utilisation des outils de refactoring. Une solution de compromispourrait être représentée par l’introduction des aspects dynamiquesuniquement à certains niveaux de la hiérarchie et en gardant des aspectsstatiques aux niveaux locaux.

Des évolutions des transformations de haut niveau peuvent êtredéveloppées aussi, mais il faut dépasser les limitations introduites par


les ODT. Le cas de la fusion avec de multiples tableaux intermédiairesreste toujours sans solution adéquate.

Avec l’intégration des outils de refactoring dans l’environnement decomodélisation Gaspard2 ouvre des nouvelles directions de développe-ment. Il s’agit des travaux de conception de nouvelles stratégies d’opti-misation pilotées par des résultats remontant des niveaux de simula-tion/exécution/synthèse par des mécanismes de trace.

Quatrième partie

A N N E X E S

AA P P L I C AT I O N D E F E N Ê T R E S G L I S S A N T E S E NARRAY-OL

Dans la Figure 2.5.4, nous avons vu que, sans l’utilisation des conceptsde Reshape et de Lien par défaut, on ne peut pas exprimer avec Array-OLexactement la même application que celle décrite en WSDF. On peutargumenter que l’utilisation des unions des jetons virtuels ne se justifiepas entièrement ; la modélisation des images d’une union comme uneseule « entité » depuis le début peut résoudre le problème.

L’extension des frontières non-cyclique est aussi possible en utilisantle concept de lien par défaut, emprunté de la spécification des dépen-dances uniformes. Dans le contexte des fenêtres glissantes, le concepta une signification similaire, il fourni des éléments avec des valeurspar défaut dans le cas où l’accès se fait à l’extérieur du tableau, ensubstitution à l’accès cyclique.

En utilisant les concepts de reshape et de lien par défaut, on peutmodéliser complètement l’application :

– le reshape pour redéfinir la forme des tableaux, un flot d’imagesavec un groupe de 2*2 images successives et traité comme un bloccontinu est transformé dans un flot de blocs, chaque bloc contenant2*2 images ;

– le lien par défaut exprime l’extension des frontières avec une valeurpar défaut.

La Figure 80 montre cette spécification dans une représentationArray-OL et la Figure 81 montre la même spécification en MARTERSM.

173

174 application de fenêtres glissantes en array-ol

A1

(2048,1024,∞)

(2048,1024,∞)

A2

(2048,1024,∞)

(4096,512,∞)

(128,256,∞)

a2

(8,4)

(16,2)

F=

10

01

00

o=

0 0 0

P=

80

0

04

0

00

1

F=

10

01

00

o=

0 0 0

P=

16

00

02

0

00

1

A3

(4096,2048,∞)

(4096,1024,∞)

(4092,1022,∞)

(4092,1022,∞)

a3(5,6)

(5,3)

(1)

F=

10

01

00

o=

0 0 0

P=

10

0

02

0

00

1

F=

10

01

00

o=

0 0 0

P=

10

0

01

0

00

1

F=()

o=

0 0 0

P=

10

0

01

0

00

1

A4

(4092,1022,∞)

(4092,1022,∞)

a4(3,3)

F=

10

01

00

o=

−1

−1 0

P=

10

0

01

0

00

1

Déf

aut

F=

10

01

00

o=

0 0 0

P=

00

0

00

0

12

4

sré

p=

2 2 ∞ s

mot

if=

( 2048

1024

)F=

10

01

00

o=

0 0 0

P=

2048

00

01024

0

00

1

F=

10

01

00

o=

0 0 0

P=

00

00

12

sré

p=

( 2 ∞)

sm

otif

=

( 4096

512

)F=

10

01

00

o=

0 0 0

P=

00

512

0

01

Fig. 80: Fenêtres glissantes en Array-OL en utilisant des Reshapes et des Liens par défaut

application de fenêtres glissantes en array-ol 175

Fig. 81: Fenêtres glissantes en MARTE

BM O D É L I S AT I O N D ’ U N E A R C H I T E C T U R E N O C E NMARTE

Figure 82 montre une topologie de NoC qui a une forme assezrégulière. Nous allons voir comment nous pouvons modéliser ce typed’architecture sous une forme compacte et facilement modifiable. Nousallons utiliser des valeurs numériques dans la description répétitivemais ces valeurs peuvent être changées facilement pour exprimer desarchitectures avec une structure similaire mais nombre de nœds dif-férents.

Fig. 82: Topologie de NoC

Même si la structure du NoC sur la Figure 82 n’est pas parfaitementrégulière, nous allons voir comment les concepts répétitives de MARTERSM peuvent être utilisés pour l’expression des architectures où larégularité n’est pas directement exprimable par les concepts répétitifsde base.

(a) Topologie de cube

=

(b) Topologie du coin

Fig. 83: Partage hiérarchique du NoC

Si nous considérons chaque groupe de trois nœds comme une entitéunique (cf Subfig. 83b), nous nous retrouvons avec une topologie de

177

178 modélisation d’une architecture noc en marte

cube (cf Subfig. 83a) qui peut être représentée facilement par un espacede répétition trois-dimensionnel et des dépendances inter-répétition.Les nœds des coins peuvent être représentés par une répétition audeuxième niveau de la hiérarchie.

(a) Cube (b) Coin

Fig. 84: Partage hiérarchique du NoC

La Figure 84 montre la modélisation en MARTE RSM du NoC, laSubfig. 84b le niveau des trois nœuds du coin et la Subfig. 84a le niveaudu cube :

– tous les ports ont une forme (shape) vide correspondant à un seulélément ({}) ;

– les trois reshapes de la Subfig. 84b expriment la séparation d’unport avec une forme de ({3}1) en trois ports, par l’utilisation des1 Parce que les

connecteurs ne sontpas des tilers, laforme du port estdonnée par laconcaténation avecl’espace derépétition, cf lesrègles des tâchesrépétitives-composées,sous-section 3.6.2.

origines différentes pour les origines des tilers sources des re-shapes.Observation. Une seule reshape est montrée sur le dessin, les autressont identiques avec la différence de l’origine du tiler source : {0}

pour le premier élément, {1} pour le deuxième élément et {2} pourle troisième élément.

– les dépendances inter-répétition sur la Subfig. 84a expriment desliens non cycliques pour chaque dimension, sur le port qui corre-sponde à cette dimension ; la dimension est donnée par la valeurnon-nulle du vecteur de dépendance.

B I B L I O G R A P H I E

[1] Cloog home page. http://www.cloog.org. (Cité à la page 70.)

[2] A. Koudri et al : Using MARTE in the MOPCOM SoC/SoPCCo-Methodology. In MARTE Workshop at DATE’08, 2008. (Cité àla page 78.)

[3] Abdelkader Amar, Pierre Boulet et Philippe Dumont : Projectionof the Array-OL specification language onto the Kahn processnetwork computation model. In International Symposium on ParallelArchitectures, Algorithms, and Networks, Las Vegas, Nevada, USA,décembre 2005. (Cité à la page 60.)

[4] C. Ancourt, D. Barthou, C. Guettier, F. Irigoin, B. Jourdan

et J. Mattioli : Automatic data mapping of signal processingapplications. In Application Spec. Array Processors, pages 350–362,Zurich, Switzerland, juillet 1997. (Cité à la page 88.)

[5] Vincent Aranega, Jean-Marie Mottu, Anne Etien et Jean-LucDekeyser : Traceability mechanism for error localization in modeltransformations. In 4th International Conference on Software and DataTechnologies (ICSOFT 2009), Sofia, Bulgaria, July 2009. (Cité à lapage 165.)

[6] Isabelle Attali, Denis Caromel, Yung syau Chen, Jean luc Gau-diot et Andrew L. Wendelborn : A formal semantics for sisalarrays. In Proc. Joint Conf. Infor. Sci., septembre 1995. (Cité auxpages 11 et 13.)

[7] David F. Bacon, Susan L. Graham et Oliver J. Sharp : Com-piler transformations for high-performance computing. Rapporttechnique, Berkeley, CA, USA, 1993. (Cité aux pages 90 et 92.)

[8] Marcus Bednara et Jürgen Teich : Automatic Synthesis of FPGAProcessor Arrays from Loop Algorithms. The Journal of Supercom-puting, 26(2):149–165, septembre 2003. (Cité à la page 78.)

[9] Rabie Ben Atitallah : Modèles et simulation de systèmes sur pucemultiprocesseurs – Estimation des performances et de la consommationd’énergie. Thèse de doctorat, „ France, décembre 2007. (Cité à lapage 70.)

[10] Rabie Ben Atitallah, Pierre Boulet, Arnaud Cuccuru, Jean-LucDekeyser, Antoine Honoré, Ouassila Labbani, Sébastien Le Beux,Philippe Marquet, Éric Piel, Julien Taillard et Huafeng Yu :Gaspard2 uml profile documentation. Rapport technique 0342,septembre 2007. URL http://hal.inria.fr/inria-00171137/en.(Cité à la page 71.)

[11] L. Benini et G. De Micheli : Networks on chips : a new SoCparadigm. Computer, 35(Issue : 1):70–78, Jan 2002. (Cité à la page 8.)

[12] Bishnupriya. Bhattacharya, Md.). Dept. of Electrical Univer-sity of Maryland (College Park et Computer Engineering. : Pa-rameterized modeling and scheduling for dataflow graphs /. 1999.URL http://worldcat.org/oclc/44599249. (Cité à la page 16.)

179

http://www.cloog.org

http://hal.inria.fr/inria-00171137/en

http://worldcat.org/oclc/44599249

180 bibliographie

[13] G. Bilsen, M. Engels, R. Lauwereins et J.A. Peperstraete : Cyclo-static data flow. In International Conference on Acoustics, Speech, andSignal Processing., Detroit, MI, USA, mai 1995. (Cité aux pages 11

et 16.)

[14] Pierre Boulet : Formal semantics of Array-OL, a domain specificlanguage for intensive multidimensional signal processing. Rap-port technique RR-6467, mars 2008. URL http://hal.inria.fr/

inria-00261178/en/. (Cité aux pages 11, 28, 38, 39, et 40.)

[15] Pierre Boulet, Philippe Marquet, Éric Piel et Julien Taillard :Repetitive Allocation Modeling with MARTE. In Forum on specifi-cation and design languages (FDL’07), Barcelona, Spain, septembre2007. Invited Paper. (Cité à la page 81.)

[16] Pierre Boulet et Xavier Redon : SPPoC : manipulation automa-tique de polyèdres pour la compilation. 20(8):1019–1048, 2001.(Cité à la page 40.)

[17] L. Cai et D. Gajski : Transaction level modeling : an overview. InCODES+ISSS’03, 2003. (Cité à la page 70.)

[18] Michael J. Chen et Edward A ; Lee : Design and implementationof a multidimensional synchronous dataflow environment. In 1995Proc. IEEE Asilomar Conf. on Signal, Systems, and Computers, 1995.(Cité aux pages 11, 16, et 18.)

[19] Arnaud Cuccuru : Modélisation unifiée des aspects répétitifs dans laconception conjointe logicielle/matérielle des systèmes sur puce à hautesperformances. Thèse de doctorat, novembre 2005. URL http://www.

lifl.fr/west/publi/Cucc05phd.pdf. (Cité à la page 71.)

[20] DaRT Team : Graphical Array Specification for Parallel and Dis-tributed Computing (GASPARD2). http://www.gaspard2.org/,2009. (Cité à la page 70.)

[21] Alain Darte : De l’organisation des calculs dans les codes répétitifs.Habilitation à diriger des recherches, École Normale Supérieurede Lyon, décembre 1999. (Cité à la page 100.)

[22] Alain Darte et Yves Robert : Constructive methods for schedulinguniform loop nests. IEEE Trans. Parallel Distributed Systems, 5(8):814–822, 1994. (Cité à la page 61.)

[23] Alain Darte, Yves Robert et Frédéric Vivien : Schedulingand Automatic Parallelization. Birkhauser Boston, 2000. http:

//www.birkhauser.com/detail.tpl?isbn=0817641491. (Cité à lapage 90.)

[24] Florent de Dinechin, Patrice Quinton et Tanguy Risset : Struc-turation of the alpha language. In Programming Models for Mas-sively Parallel Computers, pages 18–24, Berlin, Germany, octobre1995. (Cité aux pages 11 et 12.)

[25] Eddy De Greef, Francky Catthoor et Hugo De Man : Memorysize reduction through storage order optimization for embeddedparallel multimedia applications. Parallel Comput., 23(12):1811–1837, 1997. ISSN 0167-8191. (Cité aux pages 111 et 127.)

http://hal.inria.fr/inria-00261178/en/

http://hal.inria.fr/inria-00261178/en/

http://www.lifl.fr/west/publi/Cucc05phd.pdf

http://www.lifl.fr/west/publi/Cucc05phd.pdf

http://www.gaspard2.org/

http://www.birkhauser.com/detail.tpl?isbn=0817641491

http://www.birkhauser.com/detail.tpl?isbn=0817641491

bibliographie 181

[26] Cesar de Moura, Julien Taillard, Frédéric Guyomarc’h et CedricDumoulin : Adaptation des Templates UML pour la modélisationde composants paramétrables : application à Gaspard2 . In 4èmesJounées sur l’Ingénierie Dirigée par les Modèles (IDM 08), Mulhouse,France, juin 2008. (Cité à la page 169.)

[27] Alain Demeure : Les ODT : Propositions de notation pour décriredes opérateurs de distribution de tableaux. Rapport technique,Thomson Marconi Sonar, Sophia-Antipolis, France, 1998. (Cité à lapage 100.)

[28] Alain Demeure et Yannick Del Gallo : An Array Approach forSignal Processing Design. In Sophia-Antipolis conference on Micro-Electronics (SAME 98), France, octobre 1998. (Cité à la page 11.)

[29] Alain Demeure, Anne Lafarge, Emmanuel Boutillon, DidierRozzonelli, Jean-Claude Dufourd et Jean-Louis Marro : Array-OL : Proposition d’un formalisme tableau pour le traitement de sig-nal multi-dimensionnel. In Gretsi, Juan-Les-Pins, France, septem-bre 1995. (Cité à la page 11.)

[30] Tata Research Development et Design Centre : Modelmorf – amodel transformer. http://www.tcs-trddc.com/ModelMorf. (Citéà la page 64.)

[31] M. Dincbas, P. Van Hentenryck, H. Simonis, A. Aggoun, T. Graf

et F. Berthier : The constraint logic programming languagechip. In International Conference on Fifth Generation Computer Sys-tems, pages 693–264, 1988. (Cité à la page 88.)

[32] Philippe Dumont : Spécification Multidimensionnelle pour le traite-ment du signal systématique. Thèse de doctorat, „ décembre 2005.(Cité aux pages 4, 100, 105, 108, 109, 114, 115, 118, 120, 124, et 159.)

[33] Philippe Dumont et Pierre Boulet : Another multidimensionalsynchronous dataflow : Simulating Array-OL in ptolemy II. Rap-port technique RR-5516, mars 2005. URL http://www.inria.fr/

rrrt/rr-5516.html. (Cité à la page 42.)

[34] Jean-Marie Favre : Foundations of model (driven) (re-verse) engineering : Models – episode i : Stories of thefidus papyrus and of the solarus. In Jean Bezivin et ReikoHeckel, éditeurs : Language Engineering for Model-Driven Soft-ware Development, numéro 04101 in Dagstuhl Seminar Pro-ceedings. Internationales Begegnungs- und Forschungszen-trum fuer Informatik (IBFI), Schloss Dagstuhl, Germany, 2005.<http ://drops.dagstuhl.de/opus/volltexte/2005/13> [date ofcitation : 2005-01-01]. (Cité à la page 64.)

[35] P. Feautrier : Parametric integer programming. RAIRO RechercheOpérationnelle, 22(3):243–268, 1988. (Cité à la page 53.)

[36] Paul Feautrier : Dataflow analysis of array and scalar refer-ences. International Journal of Parallel Programming, 20(1):23–53,1991. URL citeseer.ist.psu.edu/feautrier91dataflow.html.(Cité à la page 93.)

http://www.tcs-trddc.com/ModelMorf

http://www.inria.fr/rrrt/rr-5516.html

http://www.inria.fr/rrrt/rr-5516.html

citeseer.ist.psu.edu/feautrier91dataflow.html

182 bibliographie

[37] Paul Feautrier : Dataflow analysis of array and scalar references.International Journal of Parallel Programming, 21(1):23–53, 1991. (Citéà la page 100.)

[38] Antoine Fraboulet : Optimisation de la mémoire et de la consom-mation des systèmes multimédia embarque. Thèse de doctorat, LIP,novembre 2001. (Cité à la page 93.)

[39] Grigori Fursin et Albert Cohen : Building a practical iterative in-teractive compiler. In 1st Workshop on Statistical and Machine Learn-ing Approaches Applied to Architectures and Compilation (SMART’07),colocated with HiPEAC 2007 conference, January 2007. (Cité à lapage 93.)

[40] Jean-Luc Gaudiot, Tom DeBoni, John Feo, Wim Böhm, WalidNajjar et Patrick Miller : Compiler optimizations for scalable par-allel systems : languages, compilation techniques, and run time systems,chapitre The Sisal project : real world functional programming,pages 45–72. Springer-Verlag New York, Inc., New York, NY, USA,2001. ISBN 3-540-41945-4. (Cité aux pages 11 et 13.)

[41] Sylvain Girbal : Optimisation dapplications - Composition de trans-formations de programme : modele et outils. Thèse de doctorat, Uni-versity Paris 11, Orsay, France, September 2005. (Cité à la page 93.)

[42] Susanne Graf, Oystein Haugen, Iulian Ober et Bran Selic : Mod-eling and analysis of real-time and embedded systems : workshopoverview. In Modeling and Analysis of Real-time and Embedded Sys-tems, 2005. (Cité à la page 78.)

[43] Pascal Van Hentenryck, Helmut Simonis et Mehmet Dincbas :Constraint satisfaction using constraint logic programming. Ar-tificial Intelligence, 58(1-3):113–159, 1992. URL citeseer.ist.psu.

edu/vanhentenryck92constraint.html. (Cité à la page 88.)

[44] High Performance Fortran Forum : High performance fortranlanguage specification version 2.0. Rapport technique, Departmentof Computer Science, Rice University, 1997. (Cité à la page 15.)

[45] American National Standards Institute : American nationalstandard programming language, fortran - extended : Ansi x3.198-1992 : Iso/iec 1539 : 1991 (e). Rapport technique, 1992. (Cité à lapage 15.)

[46] A. Jerraya et W. Wolf, éditeurs. Multiprocessor Systems-on-Chip.Elsevier Morgan Kaufmann, San Francisco, California, 2005. (Citéà la page 8.)

[47] Jürgen Teich Joachim Keinert, Christian Haubelt : Windowedsynchronous data flow. Technical Report Co-Design-Report 02,2005, Department of Computer Science 12, Hardware-Software-Co-Design, University of Erlangen-Nuremberg, Am Weichselgarten 3,D-91058 Erlangen, Germany, 2005. (Cité aux pages 11, 16, et 24.)

[48] Frédéric Jouault et Ivan Kurtev : Transforming Models withATL. In Proceedings of the Model Transformation in Practice Workshop,Montego Bay, Jamaica, octobre 2005. (Cité à la page 64.)

citeseer.ist.psu.edu/vanhentenryck92constraint.html

citeseer.ist.psu.edu/vanhentenryck92constraint.html

bibliographie 183

[49] Richard M. Karp, Raymond E. Miller et Shmuel Winograd : Theorganization of computations for uniform recurrence equations. J.ACM, 14(3):563–590, juillet 1967. (Cité à la page 12.)

[50] Joachim Keinert, Christian Haubelt et Jürgen Teich : Mod-eling and analysis of windowed synchronous algorithms. InInternational Conference on Acoustics, Speech and Signal Processing(ICASSP), pages III–892– III–895, 2006. (Cité aux pages 11, 16,et 24.)

[51] Ken Kennedy et John R. Allen : Optimizing compilers for modernarchitectures : a dependence-based approach. Morgan Kaufmann Pub-lishers Inc., San Francisco, CA, USA, 2002. ISBN 1-55860-286-0.(Cité à la page 90.)

[52] Ken Kennedy et Kathryn S. McKinley : Maximizing loop paral-lelism and improving data locality via loop fusion and distribution.In 1993 Workshop on Languages and Compilers for Parallel Computing,numéro 768, pages 301–320, Portland, Ore., 1993. Berlin : SpringerVerlag. URL citeseer.ist.psu.edu/kennedy94maximizing.html.(Cité à la page 92.)

[53] Toru Kisuki, Peter M. W. Knijnenburg, Michael F. P. O’Boyle,François Bodin et Harry A. G. Wijshoff : A feasibility studyin iterative compilation. In ISHPC ’99 : Proceedings of the SecondInternational Symposium on High Performance Computing, pages 121–132, London, UK, 1999. Springer-Verlag. ISBN 3-540-65969-2. (Citéà la page 93.)

[54] L. Bass and P. Clements and R. Kazman : Software ArchitectureIn Practice. Addison Wesley, 1998. (Cité à la page 77.)

[55] Ouassila Labbani, Jean-Luc Dekeyser, Pierre Boulet et Éric Rut-ten : UML2 profile for modeling controlled data parallel appli-cations. In FDL’06 : Forum on Specification and Design Languages,Darmstadt, Germany, septembre 2006. (Cité à la page 149.)

[56] Ouassila Labbani, Jean-Luc Dekeyser, Pierre Boulet et Éric Rut-ten : Introducing control in the gaspard2 data-parallel metamodel :Synchronous approach. International Workshop MARTES : Modelingand Analysis of Real-Time and Embedded Systems (in conjunction with8th International Conference on Model Driven Engineering Languagesand Systems, MoDELS/UML 2005), octobre 2005. (Cité aux pages 29,111, et 149.)

[57] Leslie Lamport : The parallel execution of do loops. Commun.ACM, 17(2):83–93, 1974. ISSN 0001-0782. (Cité à la page 61.)

[58] Sébastien Le Beux : Un flot de conception pour applications detraitement du signal systématique implémentées sur FPGA à based’Ingénierie Dirigée par les Modèles. Thèse de doctorat, „ France,décembre 2007. (Cité à la page 70.)

[59] Hervé Le Verge, Christophe Mauras et Patrice Quinton : The al-pha language and its use for the design of systolic arrays. The Jour-nal of VLSI Signal Processing, 3(3):173–182, septembre 1991. (Citéaux pages 11 et 12.)

citeseer.ist.psu.edu/kennedy94maximizing.html

184 bibliographie

[60] E. A. Lee et D. G. Messerschmitt : Static scheduling of syn-chronous data flow programs for digital signal processing. IEEETrans. on Computers, janvier 1987. (Cité aux pages 11, 16, et 18.)

[61] E. A. Lee et D. G. Messerschmitt : Synchronous Data Flow. Proc.of the IEEE, 75(9):1235–1245, septembre 1987. (Cité aux pages 11

et 16.)

[62] Edward A. Lee : Multidimensional streams rooted in dataflow. InProceedings of the IFIP Working Conference on Architectures and Com-pilation Techniques for Fine and Medium Grain Parallelism, Orlando,Florida, janvier 1993. North-Holland. (Cité aux pages 11, 16, 18,et 20.)

[63] Tom Mens, Krzysztof Czarnecki et Pieter Van Gorp : A tax-onomy of model transformations. In Jean Bezivin et ReikoHeckel, éditeurs : Language Engineering for Model-Driven Soft-ware Development, numéro 04101 in Dagstuhl Seminar Proceed-ings. Internationales Begegnungs- und Forschungszentrum (IBFI),Schloss Dagstuhl, Germany, 2005. http://drops.dagstuhl.de/

opus/volltexte/2005/11. (Cité à la page 64.)

[64] S. Mohanty, V. K. Prasanna, S. Neema et J. Davis : Rapid de-sign space exploration of heterogeneous embedded systems usingsymbolic search and multi-granular simulation. In Conference onLanguages, compilers and tools for embedded systems, Berlin, Germany,2002. (Cité à la page 78.)

[65] G. E. Moore : Cramming more components onto integratedcircuits. Electronics, 38(8):114–117, April 1965. URL http://dx.

doi.org/10.1109/JPROC.1998.658762. (Cité à la page 1.)

[66] A. Mozipo, D. Massicotte, P. Quinton et T. Risset : Automaticsynthesis of a parallel architecture for kalman filtering using mmal-pha. In International Conference on Parallel Computing in ElectricalEngineering (PARELEC 98), pages 201–206, Bialystok, Poland, 1998.(Cité à la page 78.)

[67] Pierre-Alain Muller, Franck Fleurey, Didier Vojtisek, Zoé Drey,Damien Pollet, Frédéric Fondement, Philippe Studer et Jean-Marc Jézéquel : On executable meta-languages applied to modeltransformations. In Model Transformations In Practice Workshop,Montego Bay, Jamaica, octobre 2005. (Cité à la page 64.)

[68] Praveen K. Murthy et Edward A. Lee : A generalization ofmultidimensional synchronous dataflow to arbitrary samplinglattices. Research report, Electronics Research Laboratory, mars1995. (Cité à la page 23.)

[69] Praveen K. Murthy et Edward A. Lee : Multidimensional syn-chronous dataflow. IEEE Transactions on Signal Processing, 50

(8):2064–2079, août 2002. (Cité aux pages 11, 16, 20, 21, 22, 23,24, et 43.)

[70] Praveen Kumar Murthy : Scheduling Techniques for Synchronousand Multidimensional Synchronous Dataflow. Thèse de doctorat, Uni-versity of California, Berkeley, CA, 1996. (Cité aux pages 11, 16,et 20.)

http://drops.dagstuhl.de/opus/volltexte/2005/11

http://drops.dagstuhl.de/opus/volltexte/2005/11

http://dx.doi.org/10.1109/JPROC.1998.658762

http://dx.doi.org/10.1109/JPROC.1998.658762

bibliographie 185

[71] Object Management Group : A UML profile for MARTE, 2007.http://www.omgmarte.org. (Cité à la page 65.)

[72] Object Management Group, Inc., éditeur. UML 2 Infrastruc-ture (Final Adopted Specifcation). http://www.omg.org/cgi-bin/

doc?ptc/2003-09-15, septembre 2003. (Cité à la page 64.)

[73] Object Management Group, Inc., éditeur. (UML) Profile forSchedulability, Performance, and Time Version 1.1. http://www.omg.

org/technology/documents/formal/schedulability.htm, janvier2005. (Cité à la page 77.)

[74] Object Management Group Inc. : Final adopted omg sysmlspecification. http ://www.omg.org/cgi-bin/doc ?ptc/06-0504,mai 2006. (Cité à la page 77.)

[75] Object Management Group, Inc. : MOF Query / Views / Trans-formations. http://www.omg.org/docs/ptc/07-07-07.pdf, juillet2007. OMG paper. (Cité à la page 65.)

[76] OMG : UML profile for Schedulability, Performance and Time(SPT), Version 1.1, 2005. (Cité à la page 77.)

[77] OMG : UML profile for System on Chip (SoC), Version 1.0.1, 2006.(Cité à la page 77.)

[78] Éric Piel : Ordonnancement de systèmes parallèles temps-réel, De lamodélisation à la mise en œuvre par l’ingénierie dirigée par les modèles.Thèse de doctorat, „ France, décembre 2007. (Cité à la page 70.)

[79] Éric Piel, Rabie Ben Attitalah, Philippe Marquet, Samy Mef-tali, Smaïl Niar, Anne Etien, Jean-Luc Dekeyser et PierreBoulet : Gaspard2 : from MARTE to SystemC simulation.In Modeling and Analyzis of Real-Time and Embedded Systems withthe MARTE UML profile DATE’08 Workshop, mars 2008. URLhttp://www2.lifl.fr/MARTEworkshop/. (Cité aux pages 65 et 70.)

[80] ProMarte partners : UML Profile for MARTE, Beta 2. http:

//www.omgmarte.org/Documents/Specifications/08-06-09.pdf,juin 2008. (Cité à la page 65.)

[81] E De Recherche, Et En Automatique, Domaine De Voluceau,Christine Eisenbeis, Christine Eisenbeis, William Jalby, WilliamJalby, Daniel Windheiser, Daniel Windheiser, Francois Bodin

et Francois Bodin : A strategy for array management in localmemory, 1990. (Cité à la page 111.)

[82] E. Riccobene, P. Scandurra, A. Rosti et S. Bocchio : A model-driven design environment for embedded systems. In Proceedingsof the 43rd annual Design Automation Conference (DAC ’06), pages915–918. ACM, 2006. (Cité à la page 77.)

[83] L. Rioux, T. Saunier, S. Gerard, A. Radermacher, R. de Simone,T. Gautier, Y. Sorel, J. Forget, J.-L. Dekeyser, A. Cuccuru,C. Dumoulin et C. Andre : MARTE : A new profile RFP forthe modeling and analysis of real-time embedded systems. InUML-SoC’05, DAC 2005 Workshop UML for SoC Design, Anaheim,CA, juin 2005. (Cité à la page 65.)

http://www.omgmarte.org

http://www.omg.org/cgi-bin/doc?ptc/2003-09-15

http://www.omg.org/cgi-bin/doc?ptc/2003-09-15

http://www.omg.org/technology/documents/formal/schedulability.htm

http://www.omg.org/technology/documents/formal/schedulability.htm

http://www.omg.org/docs/ptc/07-07-07.pdf

http://www2.lifl.fr/MARTEworkshop/

http://www.omgmarte.org/Documents/Specifications/08-06-09.pdf

http://www.omgmarte.org/Documents/Specifications/08-06-09.pdf

186 bibliographie

[84] Sven-Bodo Scholz : Single assignment c : efficient support for high-level array operations in a functional setting. J. Funct. Program., 13

(6):1005–1059, 2003. ISSN 0956-7968. (Cité aux pages 11 et 14.)

[85] Julien Soula : Principe de Compilation d’un Langage de Traitement deSignal. Thèse de doctorat, „ décembre 2001. (Cité aux pages 4, 100,105, 109, et 119.)

[86] Julien Taillard : Une approche orientée modèle pour la parallélisationd’un code de calcul éléments finis. Thèse de doctorat, Université desSciences et Technologies de Lille, feb 2009. in french. (Cité à lapage 70.)

[87] William Thies, Michal Karczmarek et Saman Amarasinghe :StreamIt : A language for streaming applications. In CompilerConstruction : 11th International Conference, CC 2002, Held as Partof the Joint European Conferences on Theory and Practice of Software,ETAPS 2002, Grenoble, France, April 8-12, 2002. Proceedings., vol-ume 2304/2002 de Lecture Notes in Computer Science, pages 49–84.Springer Berlin / Heidelberg, 2002. (Cité aux pages 11 et 14.)

[88] INRIA Triskell : Kermeta. http://www.kermeta.org/. (Cité à lapage 64.)

[89] Jan Vanhoof, Ivo Bolsens, Karl Van Rompaey, Gert Goossens

et Hug De Man : High-Level Synthesis for Real-Time Digital SignalProcessing. Kluwer Academic Publishers, Norwell, MA, USA, 1993.ISBN 0792393139. (Cité à la page 111.)

[90] W. Cesario et al : Component-Based Design Approach for Mul-ticore SoCs. Design Automatic Conference, DAC’02, 00:789, 2002.(Cité à la page 78.)

[91] P. Wauters, M. Engels, R. Lauwereins et J.A. Peperstraete :Cyclo-dynamic dataflow. Parallel, Distributed, and Network-BasedProcessing, Euromicro Conference on, 0:0319, 1996. (Cité à la page 16.)

[92] Michael Joseph Wolfe : High Performance Compilers for ParallelComputing. Addison-Wesley Longman Publishing Co., Inc., Boston,MA, USA, 1995. ISBN 0805327304. (Cité à la page 90.)

[93] Huafeng Yu : A MARTE-Based Reactive Model for Data-ParallelIntensive Processing : Transformation Toward the Synchronous Model.Thèse de doctorat, Lille, France, November 2008. (Cité à la page 70.)

[94] Hans Zima et Barbara Chapman : Supercompilers for parallel andvector computers. ACM, New York, NY, USA, 1991. ISBN 0-201-17560-6. (Cité à la page 90.)

http://www.kermeta.org/