Infrastructure de simulation

Afin d'évaluer les performances du Zero-Content Augmented Cae, nous avons uti- lisé Super Escalar Simulator (Sesc) [73]. Il s'agit d'un simulateur très détaillé.

Il offre de nombreux avantages par rapport à SimpleScalarOOO [10], principale- ment au niveau de la hiérarie mémoire. Dans Sesc, celle-ci est finement détaillée, les

Miss State Handling Register [57, 78] sont présents, les caes sont pipelinés et les bus

sont modélisés. Le cœur d'exécution est lui aussi simulé en détail avec une gestion de l'exécution dans le désordre.

Deux émulateurs utilisant le jeu d'instructions MIPS sont intégrés : l'un est nommé

Mint et l'autre Emul. Mint, l'émulateur par défaut, effectue une émulation au niveau des

appels à la bibliothèque C. Cependant, la compilation d'applications est très difficile, le format ELF étant modifié. Seul le cross-compiler fourni permet de compiler quelques applications. La bibliothèque C émulée contient de nombreux bugs empêant l'exécu- tion d'une part importante des SPEC CPU 2000 et 2006. L'émulateur Emul a été ajouté récemment à Sesc par Milos Prvulovic. Il émule au niveau des appels systèmes et résout la totalité des problèmes de Mint. Les résultats présentés ont tous été obtenus avec Emul. Sesc s'exécute beaucoup plus vite que d'autres simulateurs comme SimpleScala- rOOO [10], pour un niveau de détail supérieur. Il simule environ 500 KI/s, soit 24 heures pour cinquante milliards d'instructions.

Nous n'avons pas retenu l'utilisation de SimPoint [69] afin d'accélérer les simula- tions. SimPoint permet, d'après la structure d'un programme, d'extraire des morceaux représentatifs. Ces morceaux sont ensuite simulés et affectés d'un poids pour établir un résultat moyen sur toute l'application. Ce mécanisme est adapté aux éléments aritec- turaux ne nécessitant qu'un court temps de préauffage (warm-up). Or, notre proposi- tion permet de stoer jusqu'à 32 Mo de blocs nuls. Le temps de préauffage est alors beaucoup trop important.

3.2.1.1 Applications simulées

Nous avons utilisé les applications des SPEC CPU 2000 et 2006, avec leurs jeux d'en- trées ref. Une aention particulière a été donnée aux applications 255.vortex, 481.wrf et 482.sphinx3 dont le jeu d'entrées dépend de l'endianness. Malgré la correction de quelques erreurs dans l'émulateur, il n'a pas été possible de faire fonctionner 481.wrf correctement. Celle-ci se termine prématurément. Nos expérimentations faites avec Si-

mics dans le apitre 4 montrent que 481.wrf a un comportement très proe de 459.- GemsFDTD.

Afin de pouvoir tester toutes les applications des SPEC CPU 2000 et 2006, nous avons oisi de générer notre propre cross-compiler gérant C, C++ et Fortran. Il est basé sur gcc

4.4, eglibc 2.12 et binutils 2.20. Il produit des binaires MIPS-IV en 32 bits. Les applications

sont compilées avec le niveau d'optimisation-O3. Afin de garantir une reproductibilité

des résultats, elles sont compilées en statique.

Les applications oisies sont celles que l'on a analysées dans le apitre 2. Pour acune de ces applications, la mesure du nombre d'accès et de la proportion de blocs nuls dans ces accès est représentée dans le tableau 2.1 de la page 38.

3.2.1.2 Aritecture simulée

La hiérarie mémoire simulée est celle décrite dans la section 3.1.6. Les autres pa- ramètres importants de l'aritecture oisie sont résumés dans le tableau 3.3 page sui- vante.

3.2.2 Position du cae de zéros dans la hiérarie mémoire

Dans la section 3.1.6, nous avons discuté des différentes positions possibles du Zero-

Content Augmented Cae au sein de la hiérarie mémoire. Il s'agit principalement

d'un compromis grande taille vs faible latence.

Les histogrammes de la figure 3.4 page 63 présentent l'IPC normalisé et la réduction du nombre d'accès mémoire pour les différentes positions possibles du Zero-Content

CPU MIPS-IV, ABI O32, (Sesc avec libemul)

Decode, Issues, width 4

Retire width 5

Taille ROB 26Issues + 48 entrées

Taille LSQ 10Issues + 40 entrées

Prédicteur de branements O-GEHL [82], 64 Kbits,

6cycles de pénalité par mispred.

L1 instructions 64Ko, direct-map,

64octets/bloc, 1 cycle

L1 Cae principal 32Ko, 4 voies, ligne de 64 octets,

données LRU, 1 cycle, WB

Cae de zéros 128entrées, secteurs de 8 Ko

(Optionnel) 4voies, LRU, 1 Mo (pour un coût de 2, 5 Ko)

L2 Cae principal 256Ko, 4 voies, ligne de 64 octets,

unifié LRU, 11 cycles, WB

Cae de zéros 1024entrées, secteurs de 8 Ko

(Optionnel) 4voies, LRU, 8 Mo (pour un coût de 20 Ko)

L3 Cae principal 1Mo, 8 voies, ligne de 64 octets,

unifié LRU, 30 cycles, 16 B/cycle, WB

Cae de zéros 4096entrées, secteurs de 8 Ko

(Optionnel) 4voies, LRU, 32 Mo (pour un coût de 78 Ko)

Mémoire principale 500cycles, 16 octets/cycle

T 3.3 – Configuration du simulateur Sesc. 3.2.2.1 Zero-Content Augmented Cae placé en L1, L2 ou L3

Les trois premières barres des histogrammes de la figure 3.4 page ci-contre repré- sentent un Zero-Content Augmented Cae positionné en L1, L2 ou L3. Sans surprise, plus le Zero-Content Augmented Cae est large, meilleure est la réduction du nombre d'éecs.

Sur la figure représentant la réduction du nombre d'éecs L3, on remarque que pour quelques applications un Zero-Content Augmented Cae placé en L1 est suffisant. C'est le cas de 435.gromacs, 465.tonto et 482.sphinx3. Pour 401.bzip2, 447.dealII et 459.-

GemsFDTD, un cae de zéros L2 est nécessaire. 416.gamess, 434.zeusmp et 437.leslie3d

nécessitent un Zero-Content Augmented Cae placé en L3.

Sur la figure représentant les performances en IPC normalisé ², les applications qui se contentaient d'un Zero-Content Augmented Cae placé en L1 n'affie de gain de performance supérieur en L1 qu'en L2 ou L3. Le compromis grande taille vs faible latence pene en faveur d'un cae de zéros de grande taille en L3.

0 5 10 15 20 25 30 35 40

400.perlbench401.bzip2403.gcc410.bwaves416.gamess429.mcf433.milc434.zeusmp435.gromacs436.cactusADM437.leslie3d444.namd445.gobmk447.dealII450.soplex453.povray454.calculix456.hmmer458.sjeng459.GemsFDTD462.libquantum464.h264ref465.tonto470.lbm471.omnetpp473.astar482.sphinx3483.xalan.

Réduction du nombre d'échecs L3 (en %)

L1 L2 L3 L1 L2 L1 L3 L2 L3 L1 L2 L3 1,0 1,1 1,2 1,3 1,4 1,5

400.perlbench401.bzip2403.gcc410.bwaves416.gamess429.mcf433.milc434.zeusmp435.gromacs436.cactusADM437.leslie3d444.namd445.gobmk447.dealII450.soplex453.povray454.calculix456.hmmer458.sjeng459.GemsFDTD462.libquantum464.h264ref465.tonto470.lbm471.omnetpp473.astar482.sphinx3483.xalan.

IPC normalisé L1 L2 L3 L1 L2 L1 L3 L2 L3 L1 L2 L3

F 3.4 – Réduction du nombre d'éecs L3 (en %) et IPC normalisé pour différentes

positions du Zero-Content Augmented Cae dans la hiérarie mémoire.

3.2.2.2 Zero-Content Augmented Cae placé à plusieurs niveaux

Les quatre dernières barres de la figure 3.4 représentent l'utilisation de plusieurs

Zero-Content Augmented Cae au sein de la hiérarie mémoire. Le mécanisme de

passage de secteurs décrit dans la section 3.1.6.4 est présent. Ainsi, "L1 L3" désigne une hiérarie mémoire comportant deux Zero-Content Augmented Cae placés en L1 et en L3, le cae L2 étant un cae conventionnel.

Lorsque des Zero-Content Augmented Caes sont utilisés sur plusieurs niveaux, la réduction du nombre d'éecs est sensiblement identique à celle du plus grand des

Zero-Content Augmented Cae. Ainsi, une configuration "L1 L2" aura presque le même

nombre d'éecs qu'une configuration "L2". De même, les configurations "L1 L3", "L2 L3" et "L1 L2 L3" se comportent comme une "L3".

Presque aucun gain en termes d'IPC n'est visible en utilisant des Zero-Content Aug-

mented Caes à plusieurs niveaux. Le compromis grande taille vs faible latence pene