Précédent : Logiciels Remonter : Avant-projet A3, Analyse Avancée Appliquée Suivant : Actions industrielles
Précédent : Logiciels Remonter : Avant-projet A3, Analyse Avancée
Appliquée Suivant : Actions industrielles
analyse du flot des données: étude des programmes,
faites par un compilateur, consistant à déterminer les
initialisations et les utilisations des données
Les techniques de parallélisation automatique des programmes impératifs se sont lontemps limitées aux imbrications (<< nids >>) de boucles for. Des analyses sophistiquées du flot des données portées par les tableaux avaient été mises au point pour cette classe de programmes dits << à contrôle statique >>. Cependant, cette classe présente l'avantage que l'ensemble exact des calculs est connu statiquement, c'est-à-dire lors de la compilation.
Par contre, dans le cas des programmes impératifs à contrôle dynamique, une analyse de flot de données ne peut qu'être approximative, conservatrice, ou << floue >>. Une telle analyse floue été mise au point [8].
Participants : Albert Cohen , Jean-Francois Collard , Paul
Feautrier
Mots-clés : récursion
Si les analyses de flot conviennent bien à FORTRAN, qui n'est pas récursif, elles échouent complètement dès que les programmes à traiter sortent du cadre strict du modèle. Par ailleurs, les structures de données récursives ne sont pas prises en compte de façon satisfaisante par les techniques existantes.
Nous avons donc étudié l'analyse d'une part des dépendances et, d'autre part, du flot de données de ces programmes. Pour ce dernier point, le résultat le plus fort est que le flot des données d'un programme récursif sur tableau monodimensionnel peut être décrit par un automate à pile, et donc par une grammaire hors-contexte. Ce résultat laisse présager des travaux prometteurs liant analyses statiques et langages formels [22].
Participant : Jean-Francois Collard
Mots-clés : Analyse de flot de données
Le but de ce travail est l'implémentation dans l'environnement de programmation FORESYS d'une analyse robuste de flot de données, où l'on cherche un compromis entre précision et complexité de la mise en oeuvre. Ce travail est un partenariat avec Simulog et l'INRIA Sophia.
Participant : Olivier Temam
Le principe est d'analyser en détail le fonctionnement des codes
sur les hiérarchies mémoires et d'en déduire les transformations
à apporter aux programmes. Plusieurs approches ont déjà été
entreprises. Tout d'abord, des études extensives, toujours en
cours, sur le comportement des programmes numériques sur les
caches [5], ont été
conduites. Ces études ont déjà permis de montrer que plusieurs
propriétés supposées des programmes numériques étaient fausses et
donc que les optimisations associées étaient en partie inutiles,
et plusieurs directions de recherche nécessaires à l'optimisation
des codes ont ainsi été dégagées. Ensuite, une série d'outils
complémentaires ont été développés pour permettre une analyse
détaillée du comportement d'un programme sur le cache : un
outil de profil de cache, un outil de debugging pour le
cache [14], et un outil
permettant de faire la jonction entre programme source et code
objet. Ce dernier outil permet de passer directement à
l'architecture des informations recueillies dans le programme
source où un compilateur est à même d'extraire un grand nombre
d'informations. Enfin, on a montré qu'en modélisant les
phénomènes complexes du cache (conflits de cache) on pouvait
augmenter de manière significative l'efficacité des méthodes
d'optimisation telles que le blocking [13]. Le projet ESPRIT MHAOTEU
(décrit dans la partie ![[*]](../icons/cross_ref_motif.gif){kind=icon}
) est
un prolongement direct de ces études.
Cependant, cette technique d'expansion est trop brutale :
Nous avons donc proposé une méthode qui expanse au maximum les structures de données tout en conservant aux lectures un caractère statique[17]. Cette méthode trouve donc un équilibre entre parallélisme et surcoût à l'exécution de la gestion de la mémoire expansée.
Nous avons mis au point et implémenté une mécanisme de gestion de la mémoire dans les programmes parallèles à contrôle statique qui, à partir de l'ordonnancement, produit les structures de données minimales sans perte de parallélisme [21].
Participants : Christine Eisenbeis , Sylvain Lelait
Cette action concerne le problème de l'allocation des variables en registres dans les boucles.
Nous savons qu'un dépliage de la boucle peut nous permettre de ne pas utiliser plus de registres que le nombre maximal de variables simultanément en vie à chaque pas de temps. De plus, le pipeline logiciel déplace des tâches entre les itérations et engendre finalement des variables dont la durée de vie est supérieure à la durée d'une itération et qui ne peuvent donc être allouées au même registre à chaque itération. Ceci nécessite, ou bien de déplier la boucle et allouer dans chaque itération du code déplié un registre différent, ou bien de tourner sur plusieurs registres, en effectuant un décalage à chaque itération - par l'introduction d'instructions de copie. Dans les deux cas, on augmente la taille du code, ce qui peut coûter cher en taille de code engendré et en nombre de défauts de cache ou de tampon d'instructions.
Il faut donc réaliser un compromis entre nombre de registres utilisés, dépliage, introduction d'instructions de copie.
Dans sa thèse, Sylvain Lelait avait défini un nouveau type de graphe, dit ``meeting graph'', qui permet de modéliser le coloriage et le dépliage dans un même cadre [11]. Cette année a été consacrée à une étude structurelle des propriétés du meeting graph. D. de Werra [24], de l'EPFL à Lausanne a redémontré les propriétés du meeting graph en se basant sur une modélisation par graphe orienté des intervalles. Ce dernier modèle a des propriétés classiques en théorie des graphes, et le meeting graph n'est autre que son em adjoint.
Dans une seconde étude [26], nous avons développé un algorithme qui combine le dépliage avec l'introduction de copies. L'idée est d'utiliser systématiquement les copies pour les morceaux de durée de vie de taille exactement égale à la durée de l'itération. Le dépliage est utilisé pour les morceaux restants. L'algorithme de dépliage utilisé est heuristique. Il est basé sur la notion de bâton, sorte de témoin que se passent 2 intervalles dont l'un finit et l'autre commence en un même point. Cette méthode est implémentée dans la plate-forme MOST développée à McGill University.
Nous avons ensuite démontré formellement [19] une propriété asymptotique en
du nombre chromatique du graphe 
des interférences de la boucle dépliée 
fois: à partir d'un certain niveau de dépliage, le nombre
chromatique de 
est 
ou
, où 
est l'épaisseur de
la famille d'intervalles.
Enfin, les différentes heuristiques développées autour de ce
problème ont été intégrées dans un noyau appelé
LORA (Loop Register Allocation), voir
la section .
LORA est utilisé dans la plate-forme
MOST (voir ci-dessus), ce qui nous a permis de faire des
évaluations systématiques sur des benchmarks classiques et de
mettre en évidence les propriétés des différents
algorithmes [25]. De
plus, LORA a été connecté à SALTO
dans le cadre du projet OCEANS par l'intermédiaire de
PILO.
Ensuite, dans le cadre de la modélisation du problème de pipeline logiciel avec contraintes de registres par programme linéaire en nombres entiers, nous avons développé des calculs de majorants et minorants pour les 3 paramètres de la modélisation (intervalle d'initialisation, nombre de registres et durée d'une itération). Ces bornes sont destinées à réduire les intervalles de recherche lorsqu'on cherche à optimiser un des 3 critères. Un driver, qui enchaîne la résolution des PLNE successifs, a été développé.
Enfin, dans le cadre du projet OCEANS (section ), nous
avons développé le logiciel
PILO
(Pipeline Logiciel), basé sur l'algorithme DESP (voir la
section ).
PILO
prend en entrée une boucle et ses dépendances de données,
représentée sous la forme d'un graphe orienté, ainsi qu'une
architecture de machine (tables de réservation des instructions
et nombre de registres).
PILO sort
un ordonnancement par pipeline logiciel, ainsi qu'un degré de
dépliage et une allocation de registres, calculée par
LORA (section ).
PILO
est utilisé dans l'environnement SALTO. Il est aussi interfacé
avec SAGE pour le pipeline logiciel source à source (section
).
Des expériences ont été réalisées sur le processeur DEC-Alpha pour certaines boucles critiques du Perfect Club Benchmark [18]. Elles s'avèrent assez encourageantes, puisque le code transformé est souvent meilleur que celui généré par le compilateur sans transformation préalable.
Précédent : Logiciels Remonter : Avant-projet A3, Analyse Avancée
Appliquée Suivant : Actions industrielles