5.2 L’estimation appliqu´ee `a des plates-formes mono-processeur
5.2.3 Comparaison avec une approche se basant sur QEMU
Un des objectifs du projet Europ´een COMCAS est d’estimer la performance et la consommation ´electrique d’une application sur une architecture embarqu´ee. Pour ce faire, une m´ethode bas´ee sur un ´emulateur d’in- structions (QEMU) est utilis´ee. Un wrapper SystemC permettant d’ajouter des informations temporelles et des mod`eles de p´eriph´eriques mat´eriels a ´egalement ´et´e d´efini et d´evelopp´e par le laboratoire du TIMA `a Grenoble.
Les applications de test utilis´ees dans ce projet font parties de la suite de benchmark “nbench”. Pour nous comparer `a QEMU, nous avons donc utilis´e le mˆeme jeu de test. Les applications utilis´ees sont : “Numeric sort”, “String sort”, “FP Emulation”, “Bitfield” et “Huffman”, ce qui nous permet d’avoir un ensemble d’applications relativement diversifi´ees.
La figure 5.15 repr´esente l’erreur d’estimation des diff´erents benchmarks, en utilisant le projet COMCAS ou notre approche pour une plateforme OMAP4. Nous avons aussi utilis´e plusieurs fr´equences de processeur pour effectuer les comparaisons.
– Les diagrammes nomm´es “High level model” montrent l’erreur d’estimation de notre approche par rapport aux performances obtenues avec la plate-forme r´eelle.
– Les diagrammes nomm´es “COMCAS” montrent l’erreur d’estimation obtenue `a partir de QEMU par rapport `a la performance de la plate-forme r´eelle.
On observe tout d’abord que les pires estimations sont obtenues pour le benchmark “String sort”. Ce bench- mark est assez particulier et manipule des chaˆınes de 8 bits. Que ce soit notre m´ethode haut niveau, ou l’outil QEMU bas´e sur la traduction des instructions, les r´esultats d’estimation ne sont pas satisfaisants (sup´erieure `a 20%).
Dans un second temps, on observe que toutes les autres estimations fournies par FORECAST ont une erreur comprise entre 5 et 16%, et sont toujours optimistes (comme nous l’avons d´ej`a vu pr´ec´edemment) par rapport aux valeurs r´eelles. Ces estimations sont n´eanmoins tout `a fait acceptables compte tenu de nos contraintes de pr´ecisions.
12232
Figure 5.15: Comparaison des r´esultats de COMCAS (QEMU) et de notre approche.
“Huffman” ont une erreur d’estimation tr`es faible (inf´erieur `a 5%). Par contre, les autres benchmarks ont une erreur assez ´elev´ee (entre 20 et 25%). Cet outil a d’autre part plutˆot tendance `a faire une estimation pessimiste du temps d’ex´ecution des applications.
Une des sources d’erreurs de l’estimation provient certainement du fait que le dual-pipeline du Cortex-A9 n’est pas mod´elis´e dans l’´emulateur QEMU. Ceci induit donc une erreur dans l’estimation des performances de la plate-forme qui peut ˆetre diff´erente suivant les applications. De plus, la politique de remplacement des caches est aussi une source d’erreur. En effet, les constructeurs ne fournissent g´en´eralement pas d’informations sur le fonctionnement r´eel de leur politique. Par exemple le remplacement pseudo-random des processeurs ARM n’est pas document´e et une politique purement random est appliqu´ee.
La figure 5.16 montre les diff´erences de temps de lecture d’une donn´ee dans le cache de niveau un. On observe que l’erreur entre la plate-forme QEMU et la plate-forme r´eelle peut d´epasser les 20%.
L’outil QEMU n´ecessite donc des informations tr`es pr´ecises sur le fonctionnement des plates-formes pour fournir des estimations pr´ecises de performances. Or ces informations, permettant une mod´elisation grain fin du syst`eme, sont malheureusement rarement disponibles.
L’avantage du projet COMCAS utilisant un traducteur dynamique d’instructions (QEMU) r´eside dans le fait que l’application peut ˆetre d´eploy´ee telle quelle dans leur simulateur. De plus, cette approche ne n´ecessite aucune modification du code ni de phase de profiling. Il est aussi possible de d´ebugger l’application et de r´ecup´erer certaines informations comme le nombre d’acc`es aux m´emoires caches.
Cependant, un des inconv´enients majeur de QEMU est que la plate-forme est relativement lente `a simuler. Le temps d’ex´ecution des 5 benchmarks est d’environ 26 minutes : d´emarrage du Linux (1 minute) + ex´ecution des benchmarks (5 minutes par benchmark dans le cas de nbench). Notre outil d’estimation FORECAST permet quant `a lui d’effectuer l’estimation d’un seul benchmark en 6 secondes : 1 seconde de
Figure 5.16: Diff´erence du temps pour lire une donn´ee dans le cache de niveau 1 entre QEMU et la plate- forme r´eelle.
g´en´eration de code + 2 secondes de boucles d’initialisation + 3 secondes d’ex´ecution. C’est un avantage non n´egligeable de FORECAST pour effectuer une exploration rapide d’architectures.
De plus, les erreurs d’estimations de performance sont globalement ´equivalentes `a celles obtenues avec QEMU. Sur les benchmarks ex´ecut´es, une erreur maximale de 28.5% est observ´ee sur le projet COMCAS, alors qu’une erreur maximale de 25.7% est obtenue avec notre m´ethodologie. Les erreurs moyennes sont respectivement 14.4% et 14.9%.
Un autre inconv´enient d’une approche bas´ee sur QEMU est la complexit´e de mise en oeuvre d’un nouveau mod`ele de processeur. Construire un nouveau mod`ele n’est en effet pas trivial, surtout lorsqu’il s’agit de mod´eliser les multiples pipelines internes.
La plate-forme d´evelopp´ee dans le projet COMCAS est donc un tr`es bon outil pour effectuer des d´eveloppements logiciels et valider le comportement fonctionnel d’une application. Il permet ´egalement d’obtenir des estimations de performances assez larges du syst`eme, mais n´ecessite le d´eveloppement d’une plate-forme virtuelle compl`ete. Ce syst`eme de mod´elisation est donc int´eressant lorsque le choix de plate- forme cible a d´ej`a ´et´e effectu´e. La plate-forme virtuelle permet en effet de d´evelopper les ´el´ements logiciels avec des facilit´es de d´ebug tout en permettant des estimations de performances. Cependant, notre approche est plus pertinente pour effectuer des choix d’architectures et permettre d’orienter la structuration logicielle. La rapidit´e d’assemblage des mod`eles, une simulation rapide et un faible coˆut de d´eveloppement permettent son insertion dans les phases d’architecture et de r´eduction des risques.