Projet : CAPS - caps

<body bgcolor="#FFFFFF" text="#000000" link="#9944EE" vlink= "#0000FF" alink="#00FF00">  <a name="CHILD_LINKS" id= "CHILD_LINKS"><strong>Sous-sections</strong></a> <ul> <li><a name="tex2html300" href= "resul_module-18_mn.html#SECTION00062100000000000000" target="main" id="tex2html300"><small>Aide au portage sur les architectures hautes performances</small></a></li> <li><a name="tex2html301" href= "resul_module-18_mn.html#SECTION00062200000000000000" target="main" id="tex2html301"><small>Compilation itérative</small></a></li> <li><a name="tex2html302" href= "resul_module-18_mn.html#SECTION00062300000000000000" target="main" id="tex2html302"><small>Utilisation des instructions multimédia</small></a></li> <li><a name="tex2html303" href= "resul_module-18_mn.html#SECTION00062400000000000000" target="main" id="tex2html303"><small>Analyse et évaluation de performance de code pour architectures embarquées hautes performances</small></a></li> <li><a name="tex2html304" href= "resul_module-18_mn.html#SECTION00062500000000000000" target="main" id="tex2html304"><small>Infrastructure flexible pour l'ordonnancement et l'optimisation de code</small></a></li> <li><a name="tex2html305" href= "resul_module-18_mn.html#SECTION00062600000000000000" target="main" id= "tex2html305"><small>A<small>BSCISS</small> : génération de simulateurs hautes performances de jeu d'instructions</small></a></li> <li><a name="tex2html306" href= "resul_module-18_mn.html#SECTION00062700000000000000" target="main" id="tex2html306"><small>Collecte de traces d'exécution et sélection de tranches d'exécution représentatives</small></a></li> </ul> <hr /> <h2><a name="SECTION00062000000000000000" id= "SECTION00062000000000000000"></a><a name="performances" id= "performances"></a><br /> Environnement pour architectures hautes performances (cf. <a href= "prese_module-3_Toc.html#environnements">2.2</a>)</h2> <a name="CAPS_resultats_module-18" id= "CAPS_resultats_module-18"></a> <p><strong>Mots clés :</strong> <i>compilation, programmation parallèle, parallélisation automatique, portage d'applications, optimisation, simulation, multimédia .</i></p> <p><br /> <br /> <span class="textbf">Participants :</span> Ronan Amicel, FranÇois Bodin, Laurent Bertaux, Laurent Morin, Karine Heydemann, Thierry Lafage, Antoine Monsifrot, Gilles Pokam, André Seznec.<br /> <br /></p> <h3>Résumé :</h3> <div class="ABSTRACT"> <i>L'obtention de performances sur les architectures hautes performances nécessitent des outils logiciels adaptés qui cachent à l'utilisateur la complexité des matériels et des systèmes.</i> <p><i>Les actions de recherche que nous menons visent à fournir aux utilisateurs de calculateurs hautes performances des outils tels que compilateur, aide au portage, optimiseur pour permettre des développements et/ou portages d'applications hautes performances.</i></p> <p><i>Ainsi, nous développons <small>TSF</small>, un outil d'aide au portage de codes Fortran sur architectures hautes performances et Salto un environnement de manipulation de langage d'assemblage.</i></p> </div> <h3><a name="SECTION00062100000000000000" id= "SECTION00062100000000000000">Aide au portage sur les architectures hautes performances</a></h3><br /> <br /> <span class="textbf">Participants :</span> FranÇois Bodin, Antoine Monsifrot.<br /> <br /> <p>L'ensemble des techniques mises en oeuvre dans les compilateurs donnent généralement de bons résultats mais échouent fréquemment. De plus, toutes les techniques non conservatrices de la sémantique des codes sont interdites au compilateur. En conséquence l'activité de tuning de code reste en partie manuelle tout en étant techniquement difficile et en faisant appel à beaucoup de savoir faire.</p> <p>L'approche développée vise à accélérer cette activité grâce à l'utilisation conjointe de techniques issues de deux domaines : l'analyse statique et dynamique des programmes et le raisonnement à partir de cas («Case-Based Reasoning»).</p> <p>Un prototype est en cours de développement au dessus de TSF. TSF [<a href="bibliographie_Toc.html#Mv99" target= "contents">9</a>] est une infrastructure de transformation de programmes qui est construite au dessus de FORESYS, un outil de la société Simulog qui fournit à TSF l'infrastructure de base à l'analyse de programmes Fortran. Le prototype a pour objectif d'aider au choix des transformations adaptées en s'appuyant sur des expériences d'optimisation de situations similaires répertoriées.</p> <p>TSF permet de calculer une représentation abstraite des nids de boucles qui nous permet de déduire pour chacun d'eux un ensemble d'indices. Ces indices informent le système sur les accès de tableaux et les dépendances de données afin de connaître les propriétés de la boucle par rapport à l'architecture du processeur. De plus, cette représentation abstraite est utilisée pour reconnaître certains motifs correspondant par exemple aux produits de matrices ou aux réductions creuses. A l'aide de ces indices, le système propose ensuite à l'utilisateur les transformations à effectuer sur le code. En procédant ainsi nous pouvons proposer des transformations de code à l'utilisateur et ainsi accélérer le tuning. TSF nous permet aussi d'instrumenter les codes pour les analyser dynamiquement. Des expérimentations sur des codes de grandes tailles sont en cours.</p> <h3><a name="SECTION00062200000000000000" id= "SECTION00062200000000000000">Compilation itérative</a></h3><br /> <br /> <span class="textbf">Participants :</span> François Bodin, Karine Heydemann.<br /> <br /> <p>Les applications embarquées hautes performances posent de nouveaux défis pour la production de code optimisé. Un compilateur optimisant joue un rôle clé dans la chaîne de développement. Les optimisations permettant d'exploiter le parallélisme d'instruction, intégré dans les processeurs enfouis (VLIW), provoquent en général un accroissement significatif de la taille du code. En effet, l'amélioration d'une propriété (temps d'exécution, exploitation du parallélisme d'instruction) grâce à une optimisation s'accompagne souvent de la dégradation d'une autre (taille du code, pression sur les registres) et ainsi des compromis sont nécessaires.<br /> Aborder cette problématique remet en cause la structure même des compilateurs classiques, qui ne permettent pas un contrôle fin des interactions entre les optimisations au niveau du code source et au niveau du code machine. En effet les optimisations, offertes par des compilateurs standards, sont appliquées localement, alors que les contraintes pour les applications enfouies sont globales.<br /> L'approche itérative de la compilation a été validée pour l'exploration de l'espace des paramètres des optimisations et l'évaluation de l'impact/l'interaction des transformations appliquées [<a href="bibliographie_Toc.html#IJPP2000" target= "contents">16</a>]. Cependant seules des stratégies simples et deux optimisations ont été étudiées. Les travaux en cours visent à définir de nouveaux schémas de compilation permettant de respecter/optimiser des contraintes globales étendues (consommation d'énergie, comportement de l'application vis-à-vis du cache ou la taille du code). L'étude des interactions entre les transformations avec d'autres optimisations et la définition de stratégies d'exploration de l'espace des paramètres sont au coeur de ces travaux.</p> <h3><a name="SECTION00062300000000000000" id= "SECTION00062300000000000000">Utilisation des instructions multimédia</a></h3><br /> <br /> <span class="textbf">Participants :</span> François Bodin, Gilles Pokam.<br /> <br /> <p>La majorité des processeurs sont aujourd'hui équipés de supports architecturaux permettant le traitement efficace d'applications multimédia. Pour ce faire, ces processeurs proposent de nouvelles instructions dédiées, appelées instructions multimédia. Leur exploitation au niveau du code source n'est cependant pas facile. En effet, les instructions multimédia ne sont souvent disponibles que sous forme de fonctions intrinsèques ou de macros prédéfinies, écrits en langage assembleur. Leur exploitation dans le code source n'est donc pas automatique, puisque cette tâche requiert une intervention manuelle qui peut s'avérer fastidieuse. De plus, l'aspect variable de ces instructions d'une plateforme à l'autre pose également des problèmes de portage de code.</p> <p>Des travaux de recherche ont donc été initiés pour pallier cette carence. Leur aspect porte sur la spécification et le développement d'un module reciblable de pré-traitement de code source C. Ce pré-processeur recherche les séquences d'instructions - ou les expressions - susceptibles d'être remplacées par des instructions multimédia vectorisées, disponibles dans le langage sous forme d'instructions spécialisées (fonctions intrinsèques ou prédéfinies). Un prototype est en cours de réalisation. Ce travail s'effectue actuellement dans le cadre du contrat SMT Medea.</p> <h3><a name="SECTION00062400000000000000" id= "SECTION00062400000000000000">Analyse et évaluation de performance de code pour architectures embarquées hautes performances</a></h3><br /> <br /> <span class="textbf">Participants :</span> FranÇois Bodin, Laurent Morin.<br /> <br /> <p>Un environnement de développement destiné à la mise au point de programmes multimédias embarqués nécessite une prise en compte à la fois du programme à implémenter et du code qui est exécuté. Pour cela elle doit incorporer les deux représentations de l'application - le code assembleur et le code source - et améliorer les analyses en calculant leurs relations et leurs caractéristiques. L'efficacité de l'évaluation est conditionnée par la qualité et le nombre de ces données. Ces dernières devront être complétées par des informations obtenues par simulation ou exécution du programme. Les analyses pourront aussi être perfectionnées par des modélisations basées sur plusieurs niveaux d'abstractions. Une étude en partenariat avec Thomson Multimédia vise à expérimenter une plate-forme pour des média processeurs. Les analyses doivent pouvoir prendre en compte une description complète de l'architecture cible qui paramètre l'environnement. La flexibilité pourra être augmentée par la possibilité d'intégrer des traitements ou des bibliothèques d'optimisations à l'interface de développement.</p> <h3><a name="SECTION00062500000000000000" id= "SECTION00062500000000000000">Infrastructure flexible pour l'ordonnancement et l'optimisation de code</a></h3><br /> <br /> <span class="textbf">Participants :</span> FranÇois Bodin, Laurent Bertaux.<br /> <br /> <p>La production de code hautement optimisé pour des processeurs spécialisés dans le cadre d'applications embarquées hautes performances nécessite de nouveaux outils de compilation. D'un cÔté, il s'agit de définir des outils flexibles compatibles avec le temps de développement très court de ce type de système. De l'autre, il faut mettre en oeuvre des techniques d'optimisation très sophistiquées prenant en compte les caractéristiques fines des processeurs embarqués hautes performances. Ce code très optimisé doit respecter des contraintes de taille de code, de performances, de consommation électrique et finalement les contraintes temps réel. Il s'agit de définir une infrastucture flexible pour la mise en oeuvre des techniques d'ordonnancement et d'optimisation du code machine. Ce travail s'appuie sur les travaux antérieurs autour du système Salto [<a href= "bibliographie_Toc.html#rohou98" target= "contents">10</a>].</p> <p>Un des concepts de base de cette infrastructure est l'abstraction spécialisée pour permettre le développement de phases d'optimisation de manière indépendante la définition de l'architecture cible. Cette approche a pour but de simplifier la réutilisation et la mise en oeuvre des algorithmes. Afin de valider cette approche, nous avons spécifié une interface de communication entre le compilateur et un allocateur de registres.</p> <p>Ces travaux font l'objet d'une collaboration avec ST Microelectronics (Central R&D - site de Crolles).</p> <h3><a name="SECTION00062600000000000000" id= "SECTION00062600000000000000">A<small>BSCISS</small> : génération de simulateurs hautes performances de jeu d'instructions</a></h3> <p><br /> <br /> <span class="textbf">Participants :</span> FranÇois Bodin, Ronan Amicel.<br /> <br /></p> <p>La simulation de jeu d'instructions consiste à exécuter sur une machine <span class="textit">hÔte</span> un programme compilé pour une machine <span class="textit">cible</span>. Le projet A<small>BSCISS</small> vise à générer automatiquement des simulateurs de jeu d'instructions rapides à partir d'une description de l'architecture cible. Le système est basé sur l'infrastructure S<small>ALTO</small>, ce qui le rend reciblable. L'utilisation de la technique de <span class="textit">simulation compilée</span> permet d'atteindre des performances élevées par rapport aux méthodes interprétées traditionnelles, et donc de simuler des programmes plus gros et plus réalistes. Les applications d'un tel système sont de pouvoir évaluer différents jeux d'instructions, valider le <span class= "textit">back-end</span> d'un compilateur ou tester des programmes, sans disposer d'une implémentation matérielle du processeur. Un prototype est en cours de réalisation pour l'architecture TriMedia. Les premiers tests montrent des performances nettement supérieures à celles d'un simulateur classique, ce qui valide l'approche retenue.</p> <h3><a name="SECTION00062700000000000000" id= "SECTION00062700000000000000">Collecte de traces d'exécution et sélection de tranches d'exécution représentatives</a></h3><br /> <br /> <span class="textbf">Participants :</span> FranÇois Bodin, Thierry Lafage, André Seznec.<br /> <br /> <p>Dans le cadre de la simulation dirigée par la trace, les outils logiciels d'instrumentation actuellement disponibles (Pixie, Atom, ...) ont le défaut de ralentir de manière très significative l'exécution des applications (facteur 10-50), même si la trace générée n'est pas utilisée dans sa totalité. En effet, la trace d'une application est très volumineuse (plusieurs giga-octets pour de petites applications) et donc très difficile à utiliser en ce sens qu'une simulation sur une trace entière est très (trop) coûteuse en temps. Alors, des techniques telles que l'<span class= "textit">échantillonnage de trace</span> sont utilisées pour réduire ce volume. D'autre part, tout programme comporte une phase d'initialisation qui n'est pas représentative de l'exécution totale. De ce fait, les premiers milliards d'éléments de trace qui correspondent à cette phase d'initialisation sont, dans la plupart des cas, ignorés.</p> <p>Le ralentissement induit par l'instrumentation est trop important et pour cela ne permet pas, actuellement, de collecter des échantillons de traces sur de réelles (grosses) applications exécutées dans leur totalité. Par réelles applications, nous entendons par exemple les applications de calcul intensif, les applications de type client-serveur (X, gestion de bases de données), mais aussi le système d'exploitation lui-même qui génère une activité rarement prise en compte.</p> <p><br /></p> <p>Afin d'adresser ce problème, nous avons défini une nouvelle méthode de collecte de traces qui permet de ne pas trop ralentir les parties du programme testé dont la trace sera rejetée. Pour cela, l'exécution directe d'un code cible légèrement instrumenté produit un mode d'exécution dit <span class="textit">rapide</span>. D'autre part, un émulateur de jeu d'instructions embarqué gère un mode dit <span class="textit">émulé</span> et permet la simulation. L'émulation de jeu d'instructions permet d'avoir accès à la trace de tout le code utilisateur (par opposition à celui du système d'exploitation) : bibliothèques partagées, code auto-compilé, code auto-modifiant. Aussi, en mode « émulation », la trace est aisément générée par des appels de fonctions d'analyse écrites en langage de haut niveau (C) et regroupées dans une bibliothèque partagée à chargement dynamique. Ainsi, la génération d'une trace différente nécessite uniquement de modifier les fonctions d'analyse et de régénérer la bibliothèque dynamique : les programmes cibles instrumentés et contenant l'émulateur peuvent être réutilisés tels quel.</p> <p>À l'exécution, cette approche permet des changements de mode dynamiques entre le mode rapide et le mode émulé afin de ne simuler que quelques tranches d'exécution déterminées.</p> <p><br /></p> <p><span class="textbf">calvin2</span> et l'émulateur DICE constituent une implémentation de cette approche sur plates-formes d'architecture SPARC. Le système <span class= "textbf">calvin2</span><span class="MATH">+</span>DICE introduit un facteur de ralentissement moyen de seulement 1,38 en mode rapide sur les <span class= "textit">benchmarks</span> SPEC95.</p> <p><br /></p> <p>Ce faible taux de ralentissement pour l'« avance rapide » de l'exécution permet d'atteindre rapidement n'importe quelle tranche d'exécution pour la simuler. Ceci conduit naturellement au problème de la sélection de tranches d'exécution représentatives de l'exécution des programmes cibles.</p> <p>Pour cela, nous caractérisons le comportement dynamique des programmes cibles pour, ensuite, extraire quelques tranches d'exécution représentatives. Grâce à la classification automatique, des ensembles de tranches d'exécution à comportements proches sont sélectionnés puis dans chaque ensemble (classe) un représentant est choisi. Des tests sur les <span class="textit">benchmarks</span> SPEC95 ont été réalisés en utilisant la méthode CHAVL de classification hiérarchique développée par I. Lerman du projet AIDA [<a href="bibliographie_Toc.html#Lerman91" target="contents">Ler91</a>]. Ils ont montré que, pour des simulations de caches et de prédicteurs de branchements, en simulant de 2% à 5% de l'activité, des résultats comparables à ceux par échantillonnage à 10% sont obtenus.</p> </body>