Evaluation d’une trace dynamique ´

Les m´ethodes d’estimation du temps d’ex´ecution par ´evaluation d’une trace commencent par r´ealiser une simulation fonctionnelle de l’application. Une trace d’´ev`enements est ensuite extraite de cette simulation. Cette trace est ensuite analys´ee pour en estimer la performance sur diverses architectures sans avoir `a simuler l’application sur chacune de ces architectures. 2.4.3.1 Evaluation par analyse statique´

Dans (Cai et al., 2004), les processus d’une simulation SpecC sont instrument´es afin d’ex- traire le nombre d’ex´ecutions de chacun de leurs blocs de base et le nombre d’acc`es `a chacun de leurs ports d’entr´ee et de sortie. Une analyse statique d´etermine, pour chaque bloc de base, le nombre et le type d’op´erations SpecC correspondant `a une ex´ecution et, pour chaque port, le nombre d’octets transf´er´es correspondant `a un acc`es. En combinant cette analyse statique `a la trace fonctionnelle, on obtient pour chaque processus le nombre et le type d’op´erations SpecC ex´ecut´ees ainsi que le nombre d’octets transf´er´es. Les processus SpecC peuvent ensuite ˆetre assign´es `a une architecture compos´ee de processeurs et de bus pr´ealablement caract´eri- s´es. Cette caract´erisation associe un temps d’ex´ecution `a chaque type d’op´eration SpecC sur le processeur de mˆeme qu’un temps de communication selon le nombre d’octets transf´er´es. Cela permet d’obtenir des m´etriques de temps d’ex´ecution et de communication pour chaque processus du syst`eme. Cependant, cette estimation suppose que le compilateur g´en`erera tou- jours la mˆeme s´erie d’instructions assembleur pour une mˆeme op´eration SpecC et que le CFG de chaque module ne sera pas modifi´e par les optimisations du compilateur.

(Jaddoe et al., 2009) suit une approche similaire en simulant un r´eseau KPN pour obte- nir, pour chaque processus, une trace d’´ev`enements de calcul et de communication. Chaque processus est compil´e pour le processeur cible puis analys´e pour extraire le nombre et le type

d’instructions assembleur ex´ecut´ees en moyenne pour un ´ev`enement de calcul d’un processus. Un temps d’ex´ecution est associ´e `a chaque type d’instruction. Selon le nombre d’´ev`enements de calcul et de communication produits, un temps d’ex´ecution est ensuite associ´e `a chaque processus en additionnant les temps de calcul et de communication. Le temps d’ex´ecution d’un processeur est consid´er´e comme la somme des temps d’ex´ecution des processus qui lui sont assign´es et le temps d’ex´ecution du syst`eme est celui du processeur avec le plus long temps d’ex´ecution. Ces m´ethodes d’estimation purement additives ne tiennent pas compte de l’ordonnancement des processus ou de leurs d´ependances de donn´ees.

2.4.3.2 Evaluation par analyse dynamique´

Une mani`ere plus pr´ecise d’estimer la performance d’une application embarqu´ee sur une architecture donn´ee est de repr´esenter la trace sous la forme d’un graphe G(V, E) dont les noeuds V sont les ´ev`enements de calcul ou de communication de la trace et dont les arcs E sont les relations de pr´ec´edence entre ces ´ev`enements, telles que des d´ependances de donn´ees ou de s´equence. Selon l’assignation des ´el´ements de l’application `a l’architecture, un temps d’ex´ecution ou de communication est associ´e `a chaque ´ev`enement de calcul ou de communi- cation de ce graphe, qui est ensuite ordonnanc´e pour en estimer le temps d’ex´ecution. Une telle m´ethode a quelques similarit´es avec l’ordonnancement statique d’un TPG. Cependant, alors qu’un TPG repr´esente l’application elle-mˆeme, une trace contient les ´ev`enements cor- respondant `a une ex´ecution donn´ee de l’application, qui ne peut pas n´ecessairement ˆetre ordonnanc´ee statiquement. Ainsi, l’ordonnancement statique d’un TPG vise `a d´ecider dans quel ordre les tˆaches du TPG s’ex´ecutent alors que l’ordonnancement d’une trace vise `a simu- ler comment les ´ev`enements de la trace auraient ´et´e ordonnanc´es dynamiquement sur les bus et les processeurs d’une architecture donn´ee. Le gain de vitesse par rapport `a une simulation compl`ete vient du tr`es haut niveau d’abstraction de la trace : un segment de programme y est simul´e comme un seul ´ev`enement de calcul au lieu de simuler s´epar´ement chacune de ses instructions.

(Lahiri et al., 2001) utilise une m´ethode d’ordonnancement de trace pour ´evaluer la per- formance de diff´erentes architectures de communication pour une application une fois que sont fix´es le partitionnement logiciel/mat´eriel et l’assignation des tˆaches aux processeurs. La trace est extraite en instrumentant une co-simulation logiciel/mat´eriel de l’application r´ealis´ee avec Ptolemy (Buck et al., 1994). Cette co-simulation fixe le temps d’ex´ecution de chaque ´ev`enement de calcul de la trace, mais les temps des ´ev`enements de communication peuvent varier selon l’architecture de communication qui reste `a d´eterminer. La performance d’une architecture de communication donn´ee est estim´ee en simulant l’ordonnancement de la trace sur cette architecture. Ainsi, diff´erents bus partag´es ou liens point-`a-point peuvent

ˆetre caract´eris´es par leur largeur de bits, leur latence et leur fr´equence. Les bus partag´es sont ´egalement caract´eris´es par leur politique d’arbitrage, ce qui permet de tenir compte de la contention sur le bus et de l’arbitrage lors de l’estimation du temps d’ex´ecution du syst`eme. Cependant, cette m´ethode ne permet pas d’explorer le partitionnement logiciel/mat´eriel ou de modifier l’assignation des tˆaches aux processeurs.

Dans (Ueda et al., 2005), le temps d’ex´ecution des ´ev`enements de calcul peut varier de mˆeme que le temps des ´ev`enements de communication. Ainsi, les tˆaches de l’application peuvent ˆetre assign´ees `a des blocs IP, qui peuvent eux-mˆemes ˆetre assign´es `a un ensemble de bus partag´es. Chaque bloc IP est caract´eris´e par l’ensemble des tˆaches qu’il peut ex´ecuter et le temps d’ex´ecution qu’il prend pour chacune des tˆaches. Chaque bus est caract´eris´e par sa largeur de bits et sa fr´equence. La trace est extraite en instrumentant une simulation SystemC fonctionnelle de l’application et le temps d’ex´ecution pour une architecture donn´ee est es- tim´e en simulant l’ordonnancement de la trace pour cette architecture. Cette estimation tient compte de l’arbitrage des bus et de l’ordonnancement des tˆaches sur chaque bloc mat´eriel, en supposant que ceux-ci utilisent un ordonnancement `a priorit´es statiques. Contrairement `a notre m´ethode, cette m´ethode d’estimation ne tient pas compte du temps pris par l’arbitrage et l’ordonnancement eux-mˆemes et suppose que toutes les op´erations de calcul d’une mˆeme tˆache ont exactement le mˆeme temps d’ex´ecution. De plus, elle n’automatise pas la caract´e- risation du temps d’ex´ecution des tˆaches sur les blocs IP alors que notre m´ethode automatise la caract´erisation du temps d’ex´ecution logiciel et mat´eriel de chaque tˆache.

Dans (Isshiki et al., 2009), les structures de contrˆole (if, for, while) d’un code source C s´equentiel sont instrument´ees afin d’extraire, `a chaque ´evaluation de celles-ci, la valeur false (0) ou true (1) de la condition de la structure de contrˆole. L’ex´ecution native de ce code C avec un stimulus donn´e permet d’extraire une trace sous la forme d’un train de bits de branchement, qui correspondent aux valeurs des conditions dans la s´erie de structures de contrˆole visit´ees. `A partir du CFG du code C, il est donc possible de reconstituer la s´erie de blocs de base visit´es en utilisant chaque valeur du train de bits pour choisir le chemin false ou true `a chaque branchement dans le CFG. Cela permet ´egalement de d´eterminer le nombre d’ex´ecutions de chaque bloc de base. Le temps d’ex´ecution de chaque bloc de base est extrait par une analyse statique du code assembleur obtenu suite `a une compilation crois´ee vers le processeur cible. Cette m´ethode suppose donc que la compilation crois´ee ne modifie pas le CFG du code. Le programme peut ˆetre divis´e en plusieurs tˆaches. Dans ce cas, le CFG est partitionn´e en plusieurs CFG, chacun correspondant `a une tˆache, et des noeuds de synchronisation sont ajout´es aux CFG pour repr´esenter les d´ependances de donn´ees. Le train de bits est ´egalement partitionn´e entre les tˆaches. Une r´eduction remplace, dans chaque CFG, chaque sous-graphe correspondant `a un segment de programme par un nouveau noeud

dont le temps d’ex´ecution est ´egal au temps d’ex´ecution moyen du segment. En d´eroulant s´equentiellement chaque CFG selon le train de bits r´eduit qui lui est associ´e, on obtient donc une trace d’ex´ecution compos´ee d’´ev`enements de calcul et de communication pour plusieurs tˆaches. Les tˆaches peuvent ˆetre assign´ees `a un ensemble de processeurs homog`enes eux-mˆemes connect´es par un ensemble de bus et le temps d’ex´ecution de cette architecture est estim´e en simulant l’ordonnancement de ces tˆaches pour l’architecture donn´ee. Cette simulation suppose un ordonnancement dynamique non pr´eemptif des tˆaches sur les processeurs. Cette estimation ne supporte pas les acc´el´erateurs mat´eriels et ne tient pas compte de l’implication du processeur dans les communications des tˆaches.

Notre m´ethode extrait une trace d’´ev`enements en r´ealisant un profilage au niveau sys- t`eme d’une simulation SystemC de l’application avec SPACE (Bois et al., 2010). Pour chaque module de l’application, le temps d’ex´ecution logiciel de chaque ´ev`enement de calcul, qui correspond `a une ex´ecution d’un segment de programme, est caract´eris´e par une ex´ecution du code assembleur cible sur un ISS. Cela permet de tenir compte des effets de la compilation crois´ee sur le CFG et des branchements effectu´es `a l’int´erieur de chaque ex´ecution de chaque segment. Notre m´ethode automatise la caract´erisation des temps d’ex´ecution mat´eriel des diff´erents ´ev`enements de calcul et simule l’ordonnancement de ces ´ev`enements en tenant no- tamment compte de l’arbitrage, de l’ordonnancement dynamique pr´eemptif des tˆaches sur les processeurs par le RTOS ainsi que de l’implication des processeurs dans les communications. Les travaux ant´erieurs utilisent la s´emantique op´erationnelle des KPN pour les ´ev`ene- ments de communication captur´es par la trace : il est suppos´e que toutes les lectures sont bloquantes. Cela permet d’assurer que, pour un stimulus donn´e, toutes les ex´ecutions de l’application produiront exactement la mˆeme trace fonctionnelle d’´ev`enements peu importe l’ordonnancement des tˆaches. Cela permet notamment d’assurer que la trace extraite de la simulation fonctionnelle et la trace obtenue pour une impl´ementation donn´ee contiennent les mˆemes ´ev`enements de calcul et de communication et que seuls leurs temps diff`erent. Cela assure la validit´e de l’estimation du temps d’ex´ecution par analyse de trace. Notre m´ethode ´etend ces travaux en permettant aux tˆaches d’utiliser un mod`ele de calcul plus g´en´eral que les KPN et une s´emantique op´erationnelle qui inclut des lectures non-bloquantes. Cela fait en sorte que la trace produite peut d´ependre de l’ordonnancement des tˆaches, mais la validit´e de l’estimation par trace est pr´eserv´ee en v´erifiant si l’ordonnancement simul´e de la trace pour une impl´ementation donn´ee correspond `a un ordonnancement fonctionnellement ´equivalent de la trace initialement extraite.