Comparaison `a QEMU (projet COMCAS)

Apr`es avoir compar´e les r´esultats de notre approche avec l’approche utilis´ee dans le projet COMCAS (QEMU + SystemC) pour les plates-formes mono-coeur, nous avons d´ecid´e de comparer les processeurs multi-coeurs. Pour cela, nous avons ´etudi´e les erreurs d’estimation en performance de l’application H.264. La figure 5.29 montre l’erreur d’estimation des deux approches pour diff´erentes fr´equences d’utilisation des processeurs. Dans un premier temps, une estimation est effectu´ee dans le cas o`u un seul coeur de la plate- forme est utilis´e. Bien que l’erreur d’estimation de la plate-forme QEMU soit acceptable pour des fr´equences de 300 et 600MHz (inf´erieur `a 20%), l’erreur est tr`es importante pour une fr´equence de 1GHz (33%). On remarque quasiment le mˆeme comportement pour le cas o`u l’on utilise les deux coeurs. L’estimation est satisfaisante pour une fr´equence de 600MHz mais d´erive fortement pour les autres fr´equences. En effet, lorsque l’on passe d’une fr´equence de 300MHz `a 1000MHz, le facteur multiplicateur est de 3.3 alors que la performance estim´ee n’est augment´ee que 2 fois. Cela provient en partie du fait que les p´enalit´es pour les acc`es m´emoires (cache-miss) sont en temps et non en cycles processeur.

La figure 5.32 montre au contraire que nos estimations, bas´ees sur des mod`eles gros grain, ont une erreur comprise entre 9 et 13%. Ces r´esultats montrent que notre approche permet de fournir des estimations respectant la limite qui avait ´et´e fix´ee au d´ebut de ces travaux. reste assez constante (entre 9 et 13%) et ne d´epasse jamais la limite autoris´ee.

Figure 5.29: Comparaison de l’erreur d’estimation de la plate-forme QEMU et de notre approche haut niveau.

5.4

Conclusion

Pour conclure, les multiples comparaisons nous ont permis de valider notre m´ethodologie et les mod`eles utilis´es. Pour l’estimation de la performance, l’erreur moyenne avoisine les 10% alors que l’erreur maximale est de 17% ce qui correspond `a nos attentes. Six applications ont ´et´e test´ees ainsi que six plates-formes mat´erielles, ce qui permet de couvrir un large spectre de syst`emes.

L’estimation de consommation d’´energie a pos´e plus de difficult´es. En effet, le mod`ele fin grain ne nous a pas permis d’obtenir des r´esultats d’estimations respectant nos contraintes de pr´ecisions. Nous avons avanc´e l’hypoth`ese que des param`etres architecturaux significatifs manquaient `a nos mod`eles. Une autre hypoth`ese serait que la calibration initiale est perfectible.

Le mod`ele gros grain a quant `a lui montr´e de bon r´esultats. En effet, une erreur maximale de 19% et une erreur moyenne de 12% ont ´et´e observ´e pour les diff´erentes applications test´ees.

Nous avons montr´e au cours de ces exp´erimentations que les mod`eles tr`es fins sont souvent tr`es compliqu´es `a mettre en place et peuvent mener `a des erreurs d’estimations importantes. D’un autre cot´e, les mod`eles haut niveau sont plus ais´es et rapide `a mettre en oeuvre et ont moins de chance que l’erreur maximale d´erive. Par contre, l’erreur moyenne sera logiquement plus ´elev´e qu’un bon mod`ele `a grain fin.

Un avantage certain de FORECAST est sa rapidit´e de mise en oeuvre et d’ex´ecution. En effet, le fait d’utiliser de la g´en´eration de code avec ex´ecution sur un ordinateur hˆote permet d’effectuer une simulation en 6 secondes environ quelque soit l’application et la plate-forme. Cette rapidit´e de simulation a ´et´e exploit´e pour l’exploration d’architecture qui n’aurait pas ´et´e possible si la dur´ee d’une simulation avaient ´et´e de plusieurs minutes.

Dans les exp´erimentations pr´esent´ees dans ce chapitre, les explorations auront demand´e entre 1 et 3 minutes pour trouver une solution respectant les contraintes. Ceci n’aurait pas ´et´e possible avec des approches `a base d’ISS par exemple du fait du temps de simulation important de ces approches.

Chapitre 6

Conclusion et perspectives

6.1

Bilan

La d´ecision d’une architecture mat´erielle et logicielle lors du lancement d’un nouveau projet est une tˆache qui peut s’av´erer fastidieuse et complexe. Pour assister les architectes syst`emes et logiciels dans les phases de conception, il existe aujourd’hui de nombreux outils. Dans certains d’entre eux, on commence `

a trouver des fonctionnalit´es permettant d’obtenir des estimations de performance et de consommation d’´energie. Malheureusement, comme nous l’avons vu, la plupart poss`edent des inconv´enients majeurs comme le temps de prise en main, le temps de d´eveloppement des mod`eles, le temps de simulation, la pr´ecision des r´esultats, ou encore la richesse de composants d´ej`a pr´edisponible. On note ´egalement que les estimations de performance et la consommation ne sont souvent pas r´eunis dans un seul outil. C’est dans ce contexte et au vu de ce constat que nous avons d´evelopp´e une m´ethodologie et des outils associ´es permettant d’´evaluer diff´erentes conceptions logicielles et mat´erielles.

L’approche qui a ´et´e propos´ee repose sur un langage de description haut-niveau (qui a ´et´e ´etendu), qui se veut simple d’utilisation permettant `a la fois de d´ecrire une application mais aussi une plate-forme mat´erielle. Ensuite, un flot d’estimations ´evalue le temps d’ex´ecution de chaque tˆache puis FORECAST effectue une ex´ecution dynamique du mod`ele.

Grˆace `a la simulation et aux possibilit´es de l’ordonnanceur de la machine hˆote (syst`emes de pr´eemptions, de priorit´es et de parall´elismes), il est alors possible d’observer le comportement dynamique du syst`eme complet.

Les estimations sont bas´ees sur des param`etres qu’il est facilement possible d’obtenir, que ce soit pour le mat´eriel ou le logiciel. Par exemple, du cot´e logiciel il est n´ecessaire de fournir le nombre d’instructions ou d’acc`es m´emoire, ce qui est faisable avec un outil de profiling, et du cot´e mat´eriel les param`etres sont pr´esents dans les datasheets constructeurs (fr´equence, taille de pipeline, DMIPS...).

Grˆace `a l’utilisation du standard POSIX et de logiciels libres (Gnuplot, Valgrind), nous nous assurons une compatibilit´e et une r´e-utilisabilit´e sur d’autres plates-formes. En effet, nous ne souhaitions pas utiliser de logiciel propri´etaire qui n´ecessiterait des licences ou ne serait pas compatible d’un ordinateur `a l’autre.

Nous avons ´et´e capables de valider le bon fonctionnement de la m´ethodologie grˆace `a diff´erentes appli- cations, dont nous avons compar´e les estimations avec les valeurs r´eelles de performance. Les outils ont aussi ´et´e utilis´es dans le cadre d’un projet d’´etude interne `a Thales Communications and Security. Enfin, nous avons compar´e notre approche `a deux projets de recherche COMCAS (projet Europ´een) et Open-PEOPLE (projet ANR).

l’erreur n’exc`ede pas 20%), notre m´ethodologie fonctionne correctement. D’une part la mod´elisation se fait rapidement et simplement et l’ex´ecution est rapide (environ 5 secondes). D’autre part, l’erreur d’estimation reste correcte dans tous les cas pr´esent´es avec une erreur moyenne autour de 10% et une erreur maximale de 17%. Pour le cas du multi-coeurs, des exp´erimentations plus pouss´ees sont n´ecessaires afin de valider totalement les premiers r´esultats satisfaisants obtenus.

Par la suite, un explorateur a aussi ´et´e d´evelopp´e afin d’ajouter la possibilit´e d’effectuer automatiquement des it´erations permettant de trouver le meilleur compromis pour un syst`eme logiciel/mat´eriel. En effet, grˆace `

a la sp´ecification de contraintes (taux de charge des processeurs, temps maximum d’ex´ecution de certaines tˆaches) l’explorateur va ex´ecuter des it´erations en essayant de trouver le meilleur compromis de r´epartition des tˆaches sur le syst`eme avec les fr´equences d’ex´ecution les plus faibles afin de consommer le moins d’´energie possible.

Il est de plus tout `a fait possible de cr´eer d’autres algorithmes d’exploration ´etant donn´e que notre simulateur ressort un grand nombre d’informations utiles (taux de charge des processeurs, nombre d’instructions et d’acc`es m´emoire de chaque tˆache, temps d’ex´ecution de chaque tˆache...).

Le coeur de FORECAST ´etant un g´en´erateur de code ex´ecutable, il permet aussi de g´en´erer des bench- marks utilisables directement sur des plates-formes embarqu´ees `a partir de mod`eles haut niveau [84]. Cela permet de g´en´erer des applications de test fin d’´evaluer diff´erentes plates-formes facilement sans avoir `a cr´eer d’applications r´eelles. Il est aussi possible d’´evaluer diff´erentes architectures logicielles (parall´elisme, priorit´e des tˆaches, affinit´e processeur) afin de d´eterminer la plus adapt´ee `a la plate-forme.

Pour conclure, le choix d’utiliser un langage haut niveau afin de mod´eliser le syst`eme, coupl´e `a de la g´en´eration de code ex´ecutable s’av`ere un bon choix pour l’estimation de performance et consommation en phase amont d’un projet. Ceci facilite le choix des architectes tout en ´etant rapide `a mettre en place grˆace `a la possibilit´e de cr´eer des biblioth`eques de composants logiciels et mat´eriels.

Un des probl`emes de la m´ethodologie r´eside dans le fait d’utiliser l’ordonnanceur pr´esent sur la machine ex´ecutant la simulation (ordonnanceur Linux ´etant souvent par priorit´e) ce qui nous empˆeche d’utiliser des ordonnanceurs exotiques. Cette limitation n’a cependant pas ´et´e gˆenante dans notre contexte car dans les produits qui ont ´et´e prospect´es, la plupart utilisent un ordonnanceur par priorit´e.

De plus, nous utilisons les coeurs de la machine hˆote afin de simuler le fonctionnement des coeurs de la plate-forme embarqu´ee, ce qui limite le nombre de processeurs que l’on peut simuler. Mais les serveurs 8 ou 16 coeurs ´etant de plus en plus pr´esent dans les entreprises/laboratoires et les plates-formes embarqu´es n’ayant souvent que 2 ou 4 coeurs, il reste encore de la marge avant d’atteindre les limites de l’approche. De plus, les cibles de cette th`ese sont les plates-formes mono-coeur et multi-coeurs, et non pas les plates-formes many-coeurs ou GPU.

Des am´eliorations peuvent ˆetre propos´ees `a la suite des travaux de la th`ese, en particulier l’ajout de mod`ele pour des unit´es de calcul de type DSP et la consolidation des mod`eles de consommation d’´energie.