• Aucun résultat trouvé

Data L1 : Footprint. Data L1 : Footprint # cycle. # cycle

N/A
N/A
Protected

Academic year: 2022

Partager "Data L1 : Footprint. Data L1 : Footprint # cycle. # cycle"

Copied!
8
0
0

Texte intégral

(1)

SympA'6

Besançon, 19 - 22 juin 2000

6ème Symposium sur les Architectures Nouvelles de Machines

Multiot Simultané, Changements de Contexte, et Eets sur les Caches

Romain DOLBEAU

IRISA, Campus de Beaulieu F-35042 Rennes Cedex

Résumé

Le Multiot Simultané (SMT [13, 4]) permet d'exploiter les unités fonctionnelles mul- tiples d'un processeur superscalaire, en utilisant les instructions de plusieurs ots indé- pendants [14]. Néanmoins, l'ecacité du SMT est limitée par la hiérarchie mémoire, qui est beaucoup plus sollicitée par les multiples ots en présence [5, 6]. Dans cet article, nous nous intéressons aux conséquences sur les caches d'un changement de contexte, du point de vue des performances du processeur. Nous montrons que le surcoût lié au réamorçage des caches suite à un context switch, bien que non négligeable, est amorti par l'utilisation des unités fonctionnelles par les autres processus présents.

1 Introduction

La recherche en architecture des machines s'intéresse de plus en plus au multiot comme moyen d'augmenter le parallélisme, depuis les classiques architectures multiprocesseurs symétriques jusqu'au multiot simultané, en passant par les multiprocesseurs sur une puce [11] et le multiot à grain n [3] ou grossier. En permettant à un processeur superscalaire d'utiliser plusieurs ots d'instructions pour saturer ses unités d'exécution [14], on exploite au mieux les ressources de calculs du processeur. De plus, contrairement à un système multiprocesseur, la perte en ressources est moindre si peu de ots sont présents [13].

L'un des inconvénients du multithreading est un plus grand stress de la hiérarchie mé- moire. La simple présence de plusieurs ots sur un processeur augmente la contention sur les caches [10], et cela se retrouve naturellement dans le cas du multiot simultané [5, 6].

On peut donc s'intéresser aux conséquences sur les performances quand la machine se re- trouve dans une situation de stress anormalement élevé de la hiérarchie mémoire. Une telle situation de stress est exactement ce qui se produit suite à un changement de contexte (passage d'un ot d'instructions à un autre): le nouveau ot n'a aucune donnée disponible à proximité (cache de premier ou même de second niveau), et doit recharger son espace de travail, générant une importante quantité d'accès à la mémoire [9].

Le but de cette étude est d'examiner les conséquences de ce changement de comportement des caches sur un processeur multiot simultané, et de déterminer si l'impact négatif sur les performances est un facteur important ou si au contraire la technique SMTpermet de masquer le coût d'un changement de contexte par l'exécution des autres ots. La Section 2

(2)

Composant Latence Cache niveau 1 1 Cache niveau 2 8

Mémoire 30

Instructions Latence

Entières, branchements, ... 1 Flottantes (pipelinées) 2 Multiplications Flottantes 3 Flottantes (non pipelinées) 17

Tab.1 Latences des diérents composants de la hiérarchie mémoire et des diérents types d'instructions

de cette étude sera consacrée aux outils et à l'environnement de simulation, et la Section 3 à l'étude des résultats expérimentaux.

2 Environnement de simulation

2.1 Outils de simulation

Nos simulations sont basées sur les outilsSalto(System for Assembly Language Trans- formation and Optimization [12]) et Calvin.Salto permet de manipuler le code assem- bleur d'une application an de l'instrumenter, etCalvinassocié àSalto, permet d'obtenir une instrumentation ecace [8].

Pour cela,Calvinduplique le code de l'application: une copie du code très légèrement modiée et sans traçage permet une exécution rapide, l'autre copie plus enrichie autorise l'obtention de traces complètes. On peut donc passer les parties peu intéressantes (initia- lisation, etc.) de manière rapide pour ne tracer et simuler que les parties signicatives du code.

Le simulateur proprement dit,Hobbesest basé sur les classes d'ASF[2]. Il lit les traces d'instructions (opcode SPARCv9 et adresse de l'instruction) et d'adresses mémoires, qui seront transférées aux diérentes unités d'exécution lorsque d'une part le simulateur aura conrmé l'arrivée de ces instructions du cache d'instruction de premier niveau, et d'autre part les dépendances de registres auront été vériées. La seule véritable activité des unités se trouve dans les unités de Load/Store, qui doivent obtenir les données des caches avant de pouvoir terminer.

2.2 Architecture simulée

Par défaut, l'architecture simulée est la même en monoot et en multiot, que ce soit pour le nombre, la latence ou la taille des unités et des caches. Seuls les bancs de registres ont été répliqués pour assurer le support du multiot. Les architectures simulées sont ainsi de complexité similaire.

Nous avons supposé que l'exécution des instructions se fait in-order, l'exécution dans le désordre apportant un bénéce relativement limité pour l'exécution parallèle enSMT[7].

Les caches de niveau 1 sont associatifs par ensembles de 4 blocs, avec une associativité de type LRU (Least Recently Used). Le cache L2 est de type direct-mapped (conguration assez courante dans les processeurs à large distribution). Par défaut, les tailles utilisées sont de 16K et 256K avec une taille de bloc de 32 octets, les bus ayant une largeur de 64 bits (mémoire) ou 128 bits (cache niveau 2), avec les latences pour le premier bloc dans le tableau 1. Le processeur est assez riche en unités d'exécution: 5 entières, 3 ottantes

(3)

pipelinées, une ottante non pipelinée (instruction fdiv), et deux unités de Load/Store ; seule l'une des deux pouvant assurer lesstore(cas assez fréquent dans les caches de niveau 1 double port). Les latences des unités sont dans le tableau 1. Le processeur est en mesure d'émettre une instruction dans chaque unité à chaque cycle.

Les branchements conditionnels n'introduisent pas de pénalités particulières, agissant donc comme s'ils étaient toujours correctement prédits, le seul eet étant la nécessité de charger des instructions provenant d'une adresse diérente. Le pipeline résultant est assez simple: un étage de chargement de données (au départ des registres), un ou plusieurs (selon l'unité) étages d'exécution, puis l'écriture des résultats (avec bien entendu des bypass pour minimiser l'eet des dépendances).

3 Résultats expérimentaux

Le premier travail avant de pouvoir déterminer le coût réel des changements de contexte est de dénir les métriques à utiliser; en eet, le simple examen des taux de succès des caches, bien qu'utile, ne sut pas, l'un des buts des architectures multiots pouvant être le masquage des latences mémoires [1]. Un fort taux d'échec ne signiera pas forcément des performances moindres (et vice-versa) pour peu que la bande passante vers la mémoire soit susante. De plus, les comparaisons directes monoot - multiot ne sont pas toujours aisées; par exemple le taux d'occupation du processeur (Instruction Per Cycle, IPC) n'a pas le même sens selon qu'un ou plusieurs ots contribuent au remplissage des unités.

3.1 Métriques et traces

Nous avons donc choisi d'examiner pour diérents paramètres les pénalités relatives inigées au cas monoot et au cas multiot, plutôt que de regarder des valeurs absolues qui, comme dit précédemment, n'ont pas nécessairement le même sens dans les deux modes.

Plusieurs paramètres ont nalement été retenus:

le taux de succès des caches, métrique classique pour ce type d'études;

l'occupation des bus mémoire et cache niveau 2;

le débit moyen en instructions, intéressant car c'est l'un des points forts du SMT; la date de n d'exécution des processus, donnant la vitesse d'exécution du point

de vue de l'utilisateur;

le nombre de cycles où le processus a eu le droit d'émettre des instructions.

Le dernier point mérite éclaircissement: si, en monoot, seul un processus peut émettre des instructions à un cycle donné, cela n'est pas le cas en multiot simultané; c'est pour cela que l'on comptabilise les cycles pendant lesquel un processus avait le droit d'émettre, qu'il ait eectivement émis ou non, et que la raison de l'émission ou non-émission soit interne (dépendance de donnée...) ou non (toutes les unités sont occupées par des ins- tructions d'autres processus). L'intérêt de ce paramètre est d'être représentatif du débit en instructions par cycle d'un processus - la date de terminaison n'a pas vraiment de sens dans le cas où un changement de contexte intervient, le processus ayant un débit constant de 0 instruction par cycle quand il n'est pas sur le processeur. Par contre, il n'y a pas, comme expliqué plus haut, de comparaison directe possible de ce paramètre entre monoot et multiot.

Les traces de programmes proviennent d'un sous-ensemble de la suite de benchmark

(4)

Jeu 1 Jeu 6

N cycles évolution vs. alt, cont

évolution

2 vs. 1 N cycles évolution vs. alt, cont

évolution 2 vs. 1

mono.alt 7977063 - - 7848897 - -

mono.switch 8062764 +1;07% - 8761157 +11;62% -

mono.switch2 8264921 +3;61% +2;51% 9231211 +17;61% +5;37% multi.chgt 13720892 ;1;60% - 16205048 ;3;96% -

multi.chgt2 13912920 ;0;23% +1;40% 16754912 ;0;7% +3;40% multi.chgtall 12778616 ;8;36% - 14572144 ;13;64% -

multi.chgtall2 12899032 ;7;50% +0;94% 14680948 ;13;00% +0;75%

multi.cont 13944310 - - 16872785 - -

Tab.2 Temps d'exécution des dix premiers millions d'instructions du processus 4 dans les Jeux 1 et 6

SPECcpu95. 8 programmes sont utilisés, 7 provenant deSPECint951et un deSPECfp952, ce dernier générant beaucoup d'appels mémoires en utilisant peu les unités entières requises par les autres programmes. Diérentes combinaisons (nommées jeux) ont été utilisées, dont seul un sous-ensemble jugé signicatif sera présenté plus loin pour des raisons de clarté.

3.2 Nombre de possibilités d'émissions d'instructions

Comme annoncé par [9], les changements de contexte pénalisent ce paramètre de manière très importante (si les changements sont fréquents, tous les 200000 cycles en switch2, on peut approcher les 18% de perte de performances (cf. tableau 2).

Dans ledit tableau qui présente les résultats pour deux jeux de 5 processus3, la ligne indique le mode d'exécution des processus: le préxe monoindique une exécution en mode monoot,multien multiot; altindique une exécution alternée (un processus se termine avant de passer la main), la présence de changements de contexte est indiquée parswitchet

switch2(respectivement tous les millions ou tous les200000cycles).contcorrespond à une exécution simultanée de tous les processus,chgtetchgt2à l'exécution de 4 des 5 processus en simultané, les changements de contexte impliquant toujours les deux mêmes processus (c'est à dire que 3 des 5 processus sont toujours susceptibles d'émettre des instructions, tandis que seul un des deux processus alternant est actif à un instant donné), et nalement

chgtall etchgtall2indiquant une rotation de 4 des 5 processus sur le processeur. On y voit en colonne le nombre de cycles où le processus a pu émettre, la variation relative au mode alt(cas monoot) ou cont(cas multiot), et la variation lors de l'augmentation de fréquence des changements (évolution 2 vs. 1, tous les200000cycles contre un million). Le processus dont les résultats sont rapportés est le dernier du Jeu (respectivement ijpeget

li pour les jeux 1 et 6).

La présence de variation négative montre qu'il est préférable d'utiliser un nombre plus faible de processus si les ressources sont insusantes, quitte à payer le prix d'un change-

1.compress95,vortex,go,ijpeg,m88,li,perl

2.swim

3.Jeu1:swim, compress95, vortex, go, ijpeg;Jeu6:swim, compress95, perl, go, li

(5)

Data L1 : Footprint

1.0 ×107 1.2 ×107 1.4 ×107 1.6 ×107 1.8 ×107 2.0 ×107 0

20 40 60 80 100

# cycle

%

Data L1 : Footprint

1.0 ×107 1.2 ×107 1.4 ×107 1.6 ×107 1.8 ×107 2.0 ×107 0

10 20 30 40 50 60

# cycle

%

Fig. 1 Jeu 1, occupation du cache de données de niveau 1, pour mono.switch et

multi.chgtall, en pourcentage du nombre de lignes par processus. Chaque type de trait représente un processus.

ment de contexte de temps en temps. On le constate en comparant les troisièmes colonnes:

l'augmentation du nombre de context switches entraîne une augmentation de la durée d'exécution. Et l'on constate que cette augmentation est du même ordre de grandeur qu'en monoot, mais un peu plus faible. Si l'on exécute seulement 4 processus en multiot si- multané, sans changement de contexte et que l'on compare avec les modes chgt etchgt2 (l'environnement du processus examiné est donc le même), on obtient des résultats simi- laires (quoiqu'un peu plus élevés) au cas monoot: 6;54% et 8;04% de ralentissement dans le jeu 1,14;84%et18;74%dans le jeu 6.

3.3 Les caches et les bus

Intéressons-nous d'abord au comportement du cache de données de niveau 1 (gure 1, chacune des 5 courbes de chaque graphe correspond à un processus diérent). Le cas monoot (à gauche) est trivial: à chaque changement de contexte, le nouveau processus chasse les données de son prédécesseur, sur une période qui dépend du comportement du processus. Le cas multiot (gure 1, à droite) ore, lui, un graphe beaucoup moins clair, Néanmoins on constate un comportement similaire: lorsqu'un processus est remplacé par un autre, ses données sont immédiatement chassées du cache, et les donnés de remplacement proviennent essentiellement du processus nouvellement arrivé. On observe également que la répartition de l'espace disponible est très inégale, un processus pouvant occuper jusqu'à près de50%des lignes du cache. On retrouve là l'eet de partage des caches constaté dans [13].

Le taux de réussite du cache de niveau 1 en multiot est susamment proche du taux en monoot pour que, combiné avec le masquage de la latence par l'exécution des autres

(6)

Jeu 6, date de n Jeu 6, évolution Jeu 1, date de n Jeu 1, évolution

mono.alt 162577950 167370386

mono.switch 167029846 +2:74% 170551530 +1:90%

mono.switch2 171711809 +5:62% 176884809 +5:68%

multi.chgt 83421055 +6:77% 85047375 +6:04%

multi.chgt2 85269250 +9:13% 84832343 +5:77%

multi.chgtall 78209182 +0:10% 81725443 +1:90%

multi.chgtall2 79718172 +2:03% 82098655 +2:36%

multi.cont 78133132 80202481

Tab.3 durée d'exécution totale pour170000000 instructions, et évolution par rapport aux modes mono.alt etmulti.cont.

ots, le surcoût après un changement de contexte ne soit pas signicativement plus impor- tant en multiot. On observe d'ailleurs fort bien l'eet de masquage lorsque l'on examine l'occupation des bus (entre caches de niveau 1 et 2 et entre cache de niveau 2 et mémoire):

le taux d'occupation par chacun des processus est là aussi proche (par l'inférieur) quand on compare le multiot au monoot, pour un usage combiné notablement supérieur.

3.4 Durée d'exécution et

IPC

Les durées totales d'exécution ne peuvent être comparées que pour des ensembles de processus, les contentions faussant les résultats pour un processus unique en multiot.

On observe dans le tableau 3 que par rapport à un processeur monoot exécutant dans l'ordre, le multiot ore d'excellentes performances. D'autre part, pour cette métrique on retrouve également des pénalités similaires, le mode multi.chgtall se révélant sans véritable surprise meilleur que le mode multi.chgt, qui verrouille certains processus en mode actif. Dans tous les cas, le nombre d'instructions par cycle est environ double pour le multiot (entre 0;9et1;1 en monoot, entre 1;9 et 2;1 en multiot).

Un aspect intéressant est de constater que même avec des changements plus fréquents, le mode multi.chgtalln'est pas plus pénalisé que le monoot; en eet, les changements de contexte risquent d'être plus fréquents en mode multiot pour cause de raisons extérieures (entrée/sortie, fautes de pages, etc.), contrairement au simple changement dû au système pour assurer la multiprogrammation.

Le cas de multi.chgt2 plus rapide que multi.chgt dans le Jeu 1 est lié au mode; les trois processus verrouillés subissent moins de contention par les deux processus alternant (ralenti par les changements de contexte comme on l'observe dans la partie précédente), et sur-compense les pertes subies par ces derniers. On a ici une illustration de la nécessaire adéquation entre ressources disponibles et nombre de ots en simultané (par exemple [13]).

Si l'on s'intéresse au surcoût relatif quand on quintuple la fréquence des changements, hormis le cas évoqué précédemment, on observe une évolution similaire dans tous les modes:

le Jeu 6 par exemple révèle une variation de l'ordre de 2%(+2;8%,+2;2%,+1:9%pour respectivement mono.switch,multi.chgtet multi.chgtall).

(7)

4 Conclusion

La perte de performance liée à la hiérarchie mémoire consécutive à un changement de contexte est comme on peut s'y attendre [9] loin d'être négligeable. Mais malgré la contention plus grande sur les caches [5] qui aurait pu être un handicap sérieux dans ces circonstances, le multiot simultané reste très attractif.

L'importance relative des diérentes métriques dépend du point de vue pris en compte.

Une meilleure exploitation des bus et des caches est très intéressante pour un architecte, mais la durée d'exécution reste la mesure la plus importante pour l'utilisateur. La mesure la plus signicative est pourtant probablement la première étudiée, le nombre de possibilités d'exécution, qui traduit bien les blocages supplémentaires postérieurs à un changement de contexte.

Les propriétés d'exploitations du parallélisme du multiot [14] lui permettent en eet de mieux résister aux aléas de performances consécutives à un changement de contexte:

ce qu'un processus perd à attendre ses données, un autre peut l'exploiter car ses données sont, elles, encore disponibles. On observe également dans ces périodes une diminution de la contention sur le processeur, favorable aux processus qui ne sont pas bloqués. Le coût global légèrement supérieur en matière d'accès mémoire n'est donc pas pénalisant.

Bibliographie

1. Robert Alverson, David Callahan, Daniel Cummings, Brian Koblenz, Allan Portereld, and Burton Smith. The Tera computer system. In Proceedings of the 1990 ACM International Conference on Supercomputing, pages 16, 1990.

2. Jean-Luc Béchennec. ASF: A teaching and research object-oriented simulation tool for computer architecture design and performance evaluation. In Proceedings of the Workshop on Computer Architecture Education (WCAE-98), Barcelona, Spain, June 27, 1998.

3. M. Gulati and N. Bagherzadeh. Performance study of a multithreaded supersca- lar microprocessor. In Proceedings of the Second International Symposium on High- Performance Computer Architecture (HPCA '96), pages 291302. IEEE, February 1996.

4. Sébastien Hily. Étude du parallélisme monolithique: cas du multiot simultané. PhD thesis, IRISA / IFSIC, 1997.

5. Sébastien Hily and André Seznec. Contention on 2nd level cache may limit the eec- tiveness of simultaneous multithreading. Technical Report PI-1086, IRISA, University of Rennes 1, 35042 Rennes, France, February 1997.

6. Sébastien Hily and André Seznec. Standard memory hierarchy does not t simul- taneous multithreading. In Proceedings of the Workshop on Multithreaded Execution Architecture and Compilation (MTEAC) held in conjonction with IEEE High Perfor- mance Computer Architecture (HPCA-4), 1998.

7. Sébastien Hily and André Seznec. Out-of-order execution may not be cost-eective on processors featuring simultaneous multithreading. In Proceedings of the Fifth Inter- national Symposium on High-Performance Computer Architecture (HPCA '99). IEEE, January 1999.

(8)

8. Thierry Lafage, André Seznec, Erven Rohou, and François Bodin. Code cloning tracing:

A pay per trace approach. In P. Amestoy, P. Berger, M. Daydé, I. Du, V. Frayssé, L. Giraud, and D. Ruiz, editors, EuroPar'99 Parallel Processing, Lecture Notes in Computer Science, No. 1685. Springer-Verlag, 1999.

9. Jerey C. Mogul and Anita Borg. The eect of context switches on cache performance.

In Proceedings of the Sixth International Conference on Architectural Support for Pro- gramming Languages and Operating Systems, pages 7585, Santa Clara, California, 1991.

10. Mario Nemirovsky and Wayne Yamamoto. Quantitative study of data caches on a multistreamed architecture. In Proceedings of the Workshop on Multithreaded Exe- cution Architecture and Compilation (MTEAC) held in conjonction with IEEE High Performance Computer Architecture (HPCA-4), 1998.

11. Kunle Olukotun, Basem A. Nayfeh, Lance Hammond, Ken Wilson, and Kunyung Chang. The case for a single-chip multiprocessor. In Architectural Support for Pro- gramming Languages and Operating Systems (ASPLOS-VII), pages 211, 1996.

12. Erven Rohou, François Bodin, and André Seznec. Salto: System for assembly- language transformation and optimization. In Proceedings of the Sixth Workshop Com- pilers for Parallel Computers, December 1996.

13. D. M. Tullsen, S. J. Eggers, and H. M. Levy. Simultaneous multithreading: Maximizing on-chip parallelism. In Proceedings of the 22nd Annual International Symposium on Computer Architecture, pages 392403. ACM Press, June 2224 1995.

14. Dean M. Tullsen, Susan J. Eggers, Joel S. Emer, Henry M. Levy, Jack L. Lo, and Rebecca L. Stamm. Converting thread-level parallelism to instruction-level parallelism via simultaneous multithreading. ACM Transactions on Computer Systems, 15(3):75 85, August 1997.

Références

Documents relatifs

Once generated, the ensemble of reconstructions are constrained using a suite of observational data (including constraints on relative sea level, past ice thickness,

Environmental footprint of building elements using Life Cycle Analysis methodology.. Congrès Français de Mécanique, Association Française de Mécanique, Aug 2013,

Sur les trois années du cycle, des projets ambitieux qui s’inscrivent dans la durée peuvent associer les activités langagières, les pratiques artistiques (notamment dans le cadre

Sur les trois années du cycle, des projets ambitieux qui s’inscrivent dans la durée peuvent associer les activités langagières, les pratiques artistiques (notamment dans le cadre

In this study we present a carbon cycle data as- similation system that assimilates three major data streams, namely the Moderate Resolution Imaging Spectroradiometer

CON 01 GERER LES ACQUISITIONS DE SOLUTIONS CON 02 GERER LE DEVELOPPEMENT DE SOLUTIONS CON 03 GERER LE CATALOGUE DE SERVICES CON 04 GERER LES NIVEAUX DE SERVICE CON 05 GERER

Bon, c’est sûr que la motricité fine, effectivement dans tous les exercices de motricité fine où on peut voir… parfois, c’est pas flagrant, il y a un enfant qui peut tout à

Pour cela, on exhibera un graphe connexe d’ordre 5 qui n’admet pas de sommet d’articulation ni de sommet de degré 1, mais qui n’est