Nous allons maintenant aborder les diff´erentes parties qui sont fournies en sortie de l’outil d’estimation (l’exploration sera abord´ee dans la section suivante) comme le montre la figure 4.20. Comme nous l’avons vu
Figure 4.20: Graphique de la partie ex´ecution et traces de sorties.
pr´ec´edemment, Waveperf est capable de g´en´erer du code ex´ecutable d’un mod`ele d’application pour n’im- porte quel processeur utilisant POSIX. Nous combinons donc les estimations de performance et le profiling des tˆaches avec Waveperf afin d’ˆetre capable de simuler des tˆaches s’ex´ecutant sur la plate-forme cible. Le but est de simuler le comportement dynamique de l’application, en d’autres termes les interactions entre les diff´erentes tˆaches. Le code g´en´er´e est ex´ecut´e sur l’ordinateur hˆote utilisant Linux et la norme POSIX. Chaque tˆache ayant un temps d’ex´ecution calcul´e pour le processeur embarqu´e sur lequel elle doit s’ex´ecuter, la simulation se comporte comme si l’application r´eelle s’ex´ecutait sur la plate-forme r´eelle.
Les diff´erents processeurs de l’ordinateur hˆote sont en fait utilis´es comme si ils faisaient partis des diff´erentes unit´es de calcul (GPP, DSP) de la plate-forme embarqu´ee. En particulier, le parall´elisme de l’application est simul´e de la mˆeme mani`ere que sur la plate-forme cible.
La figure 4.21 repr´esente sur la droite le mod`ele de l’application vid´eo decodeur H.264. Les diff´erentes tˆaches y sont repr´esent´ees ainsi que leurs d´ependances et les processeurs auxquels elles sont assign´ees. De plus, une tˆache suppl´ementaire (periodic task) est ajout´ee afin d’effectuer des tests de pr´eemptions. Le graphique de gauche montre l’ex´ecution de chaque tˆache.
1234 5673893ABC2DE DF3A6B DF3A6B FC67B FC67B 73C6B67 3167B 3167B B B B B B B B
Figure 4.21: Parall´elisme des tˆaches et pr´eemptions.
diff´erents. On observe bien sur le graphique de gauche, que deux tˆaches sont capables de s’ex´ecuter en par- all`ele (par exemple : slice 1 et slice 2). De mˆeme, lorsque la tˆache “Periodic task” pr´eempte une tˆache qui s’ex´ecute sur son processeur (slice 2 ou filter 2), le temps d’ex´ecution de cette derni`ere est augment´e par rapport `a son temps d’ex´ecution “normal”. On est donc bien capable d’ex´ecuter des applications parall`eles et d’assigner (statiquement dans un premier temps) des tˆaches `a certains processeurs.
Les op´erations li´ees `a l’ordonnanceur, comme les pr´eemptions et les priorit´es, sont ex´ecut´ees par le syst`eme d’exploitation de la machine hˆote (typiquement un PC). En effet, en utilisant Posix, les d´efinitions des parties propri´et´es d’ordonnancement sont standards. Ainsi, lorsque les tˆaches sont prˆetes `a ˆetre ex´ecut´ees, le syst`eme d’exploitation (Linux) va alors les ordonnancer dynamiquement suivant leurs priorit´es et leur affinit´e de processeurs.
FORECAST est capable de fournir plusieurs traces d’ex´ecutions. Tout d’abord, comme nous l’avons d´ej`a vu plusieurs fois, il est possible de tracer l’ex´ecution des diff´erentes tˆaches de l’application qui nous int´eressent. Ceci permet de visualiser le comportement fonctionnel de l’application, et de s’assurer que ce fonctionnement est bien celui recherch´e.
Ensuite, il est aussi possible de tracer l’activit´e de chaque processeur. Ceci permet `a la fois de visualiser la charge des diff´erents processeurs, mais aussi d’´evaluer le niveau de parall´elisme de l’application. En effet, si il apparaˆıt que les processeurs sont rarement occup´es ensemble, c’est que le parall´elisme n’est pas satisfaisant et qu’il n’est peut ˆetre pas n´ecessaire d’avoir plusieurs processeurs.
D’autre part, FORECAST est aussi capable de tracer les acc`es aux diff´erentes m´emoires de la plate- forme. ´Etant donn´e que l’on connaˆıt le nombre d’acc`es effectu´e par chaque tˆache, d`es qu’une tˆache est d´eclench´ee, on trace le nombre d’acc`es m´emoire pendant la dur´ee de la tˆache. Ceci peut ˆetre tr`es utile pour ´evaluer les m´emoires les plus utilis´ees, si les caches sont correctement dimensionn´es, ou encore si il y a des pics d’acc`es m´emoire.
La figure 4.22 montre un exemple de trace des acc`es m´emoire obtenu pour l’application vid´eo d´ecodeur H.264 d´ecodant les vid´eos `a 8 images par seconde sur une plate-forme ARM Cortex-A8. Le graphique permet de visualiser les acc`es pour chaque m´emoire, et ainsi d’analyser que la m´emoire la plus sollicit´ee est le cache
Figure 4.22: Graphique permettant de visualiser le nombre d’acc`es dans les diff´erentes m´emoires.
d’instructions de niveau un, puis le cache de donn´ees de niveau un. Viennent ensuite le cache de niveau deux, et enfin la m´emoire principale (RAM) qui est tr`es peu utilis´ee.
Ces traces sont aussi n´ecessaires afin d’effectuer des estimations de la consommation d’´energie. Comme on l’a vu dans la section 4.3.2, nous avons utilis´e deux types de mod`eles de consommation : les estimations gros grain et les estimations `a grain fin.
Pour les estimations haut niveau (gros grain), nous n’utilisons que la courbe des activit´es processeurs pour d´eterminer si le processeur est en activit´e ou si il ne fait rien. Ceci nous permet de calculer l’´energie d´epens´ee par le syst`eme au bout d’un certain temps.
Pour les estimations grain fin, nous utilisons des mod`eles de consommation bas´es sur la consommation de fuite (n´ecessite le temps d’ex´ecution) mais aussi la consommation d’un ´el´ement de base (par exemple un acc`es pour les m´emoires ou l’ex´ecution d’une instruction pour le processeur). Il est alors n´ecessaire d’utiliser des traces plus complexes que celles pr´esent´ees pr´ec´edemment.
Comme nous savons caract´eriser les acc`es aux diff´erents ´el´ements m´emoire, il est alors possible de mod´eliser la consommation d’´energie de chaque m´emoire. Il est aussi possible d’obtenir la consommation li´ee `a l’ex´ecution des instructions.
En conclusion, grˆace `a FORECAST, nous sommes donc capables d’obtenir un grand nombre d’informa- tions portant `a la fois sur l’ordonnancement, les performances ou la consommation ´electrique.