Aspects qualitatifs

-ST230 SMP ST230 MT ST230 Asycnhrone Synchrone Plate-forme Mode d'exécution

TAB. 9.2 – Temps d’exécution du décodeur MPEG-2 sur différentes plates-formes matérielles.

Toutes les autres lignes du tableau présentent des résultats obtenus avec un modèle d’exécution asyn-chrone. Les contrôleurs d’exécution sont alors générés de manière à découpler l’exécution des réactions sur des flots séparés. La version mono-thread permet de voir le surcoût de ce mécanisme de découplage. On aperçoit que le fait d’enregistrer des réactions qui seront exécutées plus tard rend l’exécution de l’ap-plication 1,7 fois plus lente6. Dés gains sont obtenus lorsque la version asynchrone est exécute sur des architectures avec des ressources physiques multiples. Alors que la plate-forme MT montre peu d’accé-lération avec quatre threads, la plate-forme SMP présente une accéd’accé-lération importante. Nous observons que sur la plate-forme MT, l’augmentation du nombre de threads à 7 diminue les performances. Ceci est sûrement dû au coût de la gestion sous-jacente de threads qui devient trop important. Nous n’avons pu mesurer les performances sur une plate-forme SMP a 7 processeurs car la simulation n’a pu être terminée au bout de quelque jours.

Enfin, bien que nous ayons évalué notre approche sur des architectures matérielles à mémoire par-tagée (en raison de la disponibilité de ces plates-formes), nous remarquons que notre approche est plus adaptée à des architectures à mémoire répartie. En effet, puisque la programmation à base de composants fournit une encapsulation forte des données, il est nécessaire de faire circuler, entre les composants, un flux de données plus important que dans le cas d’une programmation à base de threads classique. Néanmoins, la tendance au niveau des architectures matérielles étant plutôt favorable à l’utilisation de la mémoire répartie, notre approche nous semble justifiée pour la programmation des applications de

streamingà destination des prochaines générations de plates-formes.

9.4.6 Aspects qualitatifs

L’approche proposée nous satisfait en grande partie en ce qui concerne la programmation des applica-tion de streaming. En effet, grâce à cette méthodologie, deux métiers peuvent être réellement distingués dans le processus de développement. Les programmeurs de composants sont ceux qui ont l’expertise des fonctions et de l’algorithmique à implanter. Leur tâche est simplifiée car ils sont dégagés des problèmes

liés au modèle d’exécution ou à la synchronisation. Les architectes sont chargés d’assembler une confi-guration optimale du logiciel en tenant compte des spécificités de la plate-forme cible. Ils disposent des outils de haut niveau comme l’ADL et JoinDSL pour adapter les composants dans un contexte d’exé-cution spécifique. En particulier, au travers de notre expérimentation, nous sommes plutôt satisfait du langage JoinDSL qui permet une bonne maîtrise de la synchronisation des composants dans un modèle d’exécution à base d’événements. Remarquons que ce langage peut être encore étendu pour donner des constructions de synchronisation plus sophistiquées (réception d’un nombre fixé d’éléments du même type, synchronisation en fonction des valeurs de messages, etc.) et pour spécifier les événements qui seront produits par la réaction déclenchée. En effet, la spécification des événements produits peut ou-vrir des perspectives de compilation d’un ordonnancement statique de l’ensemble de composants pour optimiser les performances.

Enfin, nous avons démontré que la génération automatique des contrôleurs d’exécution des compo-sants à partir de leur description de comportement permet d’adapter ces derniers à des modèles d’exécu-tions différents. Cela permet entre autre de paralléliser ou de répartir les composants d’une application. Grâce aux outils de génération de code de haut niveau qui supportent les langages ADL et JoinDSL, les architectes peuvent explorer différents choix architecturaux afin de trouver une solution optimale. 9.5 Conclusion

Ce chapitre était dédié à la mise en œuvre d’applications de streaming reparties à destination des MPSoC. Deux applications ont été présentées dans l’ordre chronologique de leur développement.

La première application était un décodeur H.264 monolithique qui a été componentisé sans modifi-cation de son architecture d’implantation. Cette expérimentation nous a permis de tirer les conclusions suivantes. Premièrement, une architecture monolithique, qu’il soit implantée à l’aide des composants ou non, reste très difficilement maîtrisable, modifiable et répartissable. Deuxièmement, l’utilisation des composants Think, même à une granularité très fine, ont peu d’impacte sur les performances globales comparées à une implantation entièrement écrite en C. Cela confirme que les pertes de performances telles que nous avons constaté dans le chapitre précédent sont plutôt dues à une conception privilégiant la modularité et la clarté architecturale. Troisièmement, nous avons constaté que les propriétés de répar-tition des composants d’une telle application étaient non seulement liées à son architecture modulaire, mais aussi à la transparence de l’implantation de ses composants vis-à-vis de leurs modèles d’exécution et de synchronisation.

Ce dernier point nous a motivé à investir dans une extension du modèle de programmation des

com-posants FRACTAL. Dans ce cadre, nous avons opté pour un modèle d’exécution événementiel, pour ses

bonnes propriétés en ce qui concerne la programmation répartie, et avons proposé le langage JoinDSL pour simplifier la gestion de la synchronisation des composants répartis. À l’aide de ce langage, les concepteurs peuvent décrire les contraintes de synchronisation qui sont nécessaires à l’exécution d’un composant sous forme de jointure d’événements. Le support nécessaire à cette extension (i.e. la géné-ration des machines à états pour la synchronisation) a été implanté sans difficulté dans la chaîne de compilation sous forme d’un plugin. Le développement de ce dernier a démontré les capacités de la chaîne proposée à accepter un nouveau langage d’entrée et à effectuer les opérations de vérifications et de génération de code associées.

Pour évaluer l’approche suscitée, un décodeur MPEG-2 a été développé. Concernant les aspects quantitatifs, nous avons mesuré des pertes de performances importantes par rapport au décodeur de ré-férence, ayant une implantation monolithique en C. Ces pertes sont à relativiser car (i) notre version à base de composants constitue une première implantation, sans doute un peu naïve pour obtenir de bonnes performances et (ii) elle propose une architecture répartissable, uniquement à l’aide des options de com-pilation et de modification de description d’architecture. Les évaluations de performance effectuées ont

9.5. Conclusion

montré l’importance de pouvoir explorer facilement des stratégies de répartition différentes. En effet, nous avons observé des taux d’accélérations importantes sur des architectures de type SMP. Enfin, bien que nos évaluations soient effectuées uniquement sur des architectures matérielles à mémoire partagée pour des raisons de disponibilité de plate-forme, notre approche nous semble tout à fait compatible avec des architectures à mémoire répartie.

Chapitre 10

Conclusion

Dans ce dernier chapitre, nous dressons un bilan des apports de nos travaux et énumérons les pers-pectives qui pourront êtres poursuivies.

10.1 Principaux apports

Les systèmes sur puce sont devenus de véritables systèmes répartis intégrant plusieurs processeurs couplés à des architectures de mémoire variées. Cette transformation se traduit par une croissance im-portante du nombre de logiciels déployés sur ce type de plates-formes. Or, la programmation de telles plates-formes n’est pas triviale. En plus de la difficulté de programmation d’un système réparti hétéro-gène, elle nécessite une maîtrise totale de la programmation de bas niveau afin d’exploiter au mieux les spécificités du matériel. Pour ces raisons, les concepteurs de systèmes sur puce cherchent à élaborer des modèles de programmation pouvant simplifier le processus de développement de logiciel.

Le travail de thèse présenté dans ce rapport s’inscrit dans ce contexte. Notre objectif était de propo-ser une méthodologie de développement de logiciels à base de composants, adaptée aux contraintes des systèmes sur puce. Pour ce faire, nous avons analysé l’état de l’art des modèles de composants existants

et choisi le modèle FRACTALqui convenait aux besoins identifiés. Puis, nous avons mis au point une

in-frastructure de développement permettant d’assembler des logiciels à base de composants FRACTALen

utilisant des descriptions d’architectures. Enfin, nous avons évalué cette infrastructure en programmant deux applications significatives dans le cadre des systèmes sur puce : la première illustre le développe-ment de systèmes d’exploitation pour ceux-ci, la deuxième illustre la définition d’un nouveau langage facilitant l’expression de la synchronisation au sein d’application de traitement de flux multimédia répar-tis.

Les sections suivantes rappellent les principales contributions de nos travaux. Proposition d’un canevas logiciel pour la construction de compilateurs ADL

Notre thèse se base sur l’adoption de la programmation à base de composants à tous les niveaux logiciels des systèmes sur puce, de la construction de systèmes d’exploitation, au développement des applications multimédias. Nous défendons l’idée que cette technologie est dotée des bases convenant à la programmation de systèmes répartis complexes dont les systèmes sur puce font partie. Compte tenu de la diversité des contraintes que l’on peut rencontrer dans différents domaines de calcul de ces plates-formes hétérogènes, la flexibilité des modèles de composants, c’est-à-dire leur capacité d’extension pour satisfaire des besoins spécifiques, constitue une propriété cruciale.

Ce raisonnement nous a amené à considérer le modèle FRACTALcomme base de nos travaux. Nous

avons repris une de ses implantations, THINK, et nous avons contribué à son amélioration dans la

pers-pective de la rendre plus légère et plus flexible. Nous avons montré au travers du développement de

les contraintes de mise en œuvre de logiciels répartis sur puce.

La programmation à base de composants permet un raisonnement au niveau de l’architecture des logiciels. Ce raisonnement doit être supporté par des outils de compilation permettant d’automatiser en partie le processus de développement des logiciels. Or, d’une part, le caractère ouvert du modèle de com-posants considéré et, d’autre part, la diversité des utilisations possibles dans le cadre de la programmation de systèmes sur puce, rend très difficile la construction d’une chaîne d’outils universelle.

En partant de cette problématique, nous avons proposé un canevas logiciel facilitant la mise au point d’outils spécifiques [LÖQS07]. Le canevas proposé se concentre sur la définition d’un certain nombre de patrons de programmation et de composants utilitaires et n’impose aucune interface de programmation. En résumé, ce canevas définit une architecture minimale pour constituer une chaîne d’outils ADL qui peut être étendue par les tierces parties par le biais du développement de plugins. Une des particularités intéressantes de cette architecture est qu’elle repose sur un AST extensible permettant d’intégrer les in-formations décrites dans des langages de description différents. De plus, un canevas de tâches extensible est fourni pour décrire les dépendances des opérations de traitements, afin d’exécuter ces dernières en respectant des contraintes d’ordonnancement.

Nous avons utilisé ce canevas logiciel pour mettre au point un outil de traitement d’ADL dédié à la génération de code. Cet outil a pour fonction d’automatiser l’assemblage d’un système écrit en

FRACTAL. Cette chaîne d’outils peut actuellement être utilisée pour assembler des composants écrits

dans des langages de programmation différents (C, C++ et Java). De plus, cette chaîne intègre un canevas de génération d’adaptateurs de communication permettant d’automatiser la création des composants de liaison implantant des protocoles arbitrairement complexes.

Enfin, notons que la chaîne de génération de code mise au point a été intégrée au sein du projet THINK

pour remplacer l’outillage existant et est actuellement utilisée dans divers projets de développement. Mise au point d’un micro-noyau L4 à base de composants

Dans le cadre de nos travaux, nous avons implanté un micro-noyau L4 en utilisant la technologie de programmation proposée. Le but de cette expérimentation était d’identifier les avantages et les inconvé-nients d’un choix de conception privilégiant les aspects architecturaux par rapport aux aspects liés aux performances. Bien qu’elle soit préliminaire, notre implantation constitue une alternative modulaire aux implantation existantes qui ont la caractéristique d’être monolithiques. Nous avons constaté que l’orga-nisation à base de composants et la disposition d’un outil de génération de code qui assemble le système à partir de la description de son architecture jouaient un rôle essentiel pour la maîtrise d’un tel système. Cette maîtrise est selon nous cruciale pour assurer une bonne qualité d’implantation, surtout concernant des noyaux comme L4 qui sont employés pour garantir des aspects de type sécurité. Enfin, nos analyses ont montré que les pertes de performances observées par rapport aux architectures monolithiques étaient

en partie liées au format d’implantation des composants THINK. Cela montre que les performances

pour-raient être améliorées par le biais de l’intégration de certaines fonctions d’optimisation dans la chaîne de génération de code proposée.

Proposition d’un modèle de programmation pour le développement d’application de streaming réparties

Nos expérimentations dans le cadre de la programmation d’applications multimédia ont montré que la programmation à base de threads n’était pas satisfaisante pour la répartition de telles applications sur plusieurs processeurs. En partant de ce constat, nous avons défini un modèle de programmation basé sur le Join Calcul, afin de découpler les aspects fonctionnels des composants des aspects liés à leurs modèles d’exécution et de synchronisation. Ce modèle de programmation est réifié par la définition d’un langage de description de comportements qui est utilisé par la chaîne de génération de code afin de tisser des