![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() ![]() |
|
Stratégies d'écriture et évaluations des protocoles de cohérence de caches pour les architectures manycore CC-NumaDurée :6 mois Financement :Suivant les règles de l'université UPMC. Équipe d'accueilLaboratoire LIP6, Département SoC, équipe Alsoc ContexteCe stage s’inscrit dans le cadre du projet Européen SHARP piloté par BULL, dont les partenaires Français sont THALES, le LIP6 et le CEA/LETI. Ce projet vise la définition et l’implémentation d’une architecture de processeur many-cores utilisable dans des ordinateurs de type serveurs, c'est-à-dire une architecture matérielle supportant la mémoire virtuelle, et fournissant un mécanisme de cohérence des caches garantie par le matériel. L’architecture TSAR a été définie dans le cadre d’un premier projet Européen. Cette architecture NUMA (Non Uniform memory Access) supporte des systèmes d’exploitation généralistes de type UNIX (ou LINUX). Son originalité est d’utiliser un grand nombre de "petits" coeurs de processeurs RISC 32 bits, plutôt que quelques gros processeurs, pour minimiser la consommation énergétique. L’architecture doit donc être réellement scalable (pour atteindre plusieurs milliers de coeurs sur une seule puce), tout en fournissant une mémoire partagée cohérente. Une première version de l’architecture TSAR, comportant jusqu'à 512 coeurs a été modélisée en langage SystemC, en utilisant la plate-forme de prototypage virtuel SOCLIB et un style de modélisation "au cyle près". Différentes applications logicielles ont pu être déployées et exécutées (en simulation) sur ce prototype virtuel. MotivationsLa particularité du protocole de cohérence de l'architecture, appelé DHCCP (décrit dans la thèse de Yang Gao) est de mettre en oeuvre une stratégie "Write-Through" hybride qui mélange des mises à jour et des invalidations. Des expérimentations ont été menées pour essayer de déterminer la scalabilité du protocole, mais ce point est délicat. En effet, si pour pouvoir conclure que le protocole est scalable, il faut obtenir un speedup proportionnel au nombre de coeurs utilisés sur l'application, il faut que tous les maillons de la chaine logicielle et matérielle soit scalables. En particulier, cela nécessite que :
C'est précisément ce dernier point qui pose problème : une ligne partagée en écriture entre plusieurs threads provoquera du faux partage avec un protocole write-back mais pas avec un protocole write-through. En allant plus loin, on peut même dire qu'une application parallèle qui accède à beaucoup de données partagées est pensée pour un type de protocole, ce qui rend difficile une évaluation objective des performances d'un protocole de cohérence. Néanmoins, on pourrait aussi argumenter que là où un protocole efficace se démarque d'un protocole non efficace, c'est justement lorsqu'il est stimulé, et donc que la quantité de requêtes de cohérence est grande. Ceci montre la difficulté à évaluer un protocole de cohérence. Une première idée a été d'implémenter un protocole write-back MESI conservant certaines caractéristiques de DHCCP : stratégie hybride de stockage de la liste des copies d'une ligne (explicite ou implicite), requêtes de types multicast ou broadcast. Ce protocole a été nommé HMESI. Si la comparaison est intéressante, elle ne permet pas de déterminer le surcout lié au protocole car déjà en mono-thread les performances entre le write-through et le write-back peuvent être très différentes. Par ailleurs, HMESI est une alternative intéressante à DHCCP car les résultats préliminaires montrent qu'il offre de meilleures performances que DHCCP dans la plupart des cas. C'est pourquoi dernièrement une autre approche a été adoptée : concevoir un protocole de cohérence "idéal" afin de pouvoir mesurer le surcout lié à la cohérence, tout en s'affranchissant des autres paramètres limitant la scalabilité d'une application. L'idée de ce protocole idéal est d'avoir une exécution avec une cohérence à cout zéro, et il n'a donc pas pour but d'avoir une réalité matérielle. On peut le voir comme une borne inférieure du surcout induit par la cohérence. Ce protocole "idéal" doit se décliner en deux variantes : une write-through et une write-back. La variante write-through a déjà été conçue et implémentée, et elle est en cours d'évaluation. RéalisationLe sujet de ce stage consiste en la spécification, l'implémentation et l'évaluation de la variante write-back du protocole idéal. Il comportera notamment les étapes suivantes :
Si le stage se déroule suffisamment vite, un autre problème pourra être abordé. En effet, l'implémentation actuelle du protcole write-through idéal n'est pas compatible avec une exécution sur la version parallèle du simulateur SystemCass, et il est probable que la première version du protocole write-back idéal ne le soit pas non plus. Le travail associé consistera donc à réfléchir à une technique permettant d'utiliser ce simulateur parallèle. Compétences souhaitées
Références[1] Tera Scale ARchitecture. Project Home Page. web: tmp-soc.lip6.fr/trac/tsar [2] Soclib. Project Home Page. web: www.soclib.fr [3] JOUPPI, Norman P. Cache write policies and performance. ACM, 1993. [4] ADVE, Sarita V., ADVE, Vikram S., HILL, Mark D., et al. Comparison of hardware and software cache coherence schemes. ACM, 1991. [5] DAYA, Bhavya K., CHEN, Chia-Hsin Owen, SUBRAMANIAN, Suvinay, et al. SCORPIO: 36-Core Shared-Memory Processor Demonstrating Snoopy Coherence on a Mesh Interconnect. [6] ROS, Alberto, ACACIO, Manuel E., et GARCÍA, José M. A direct coherence protocol for many-core chip multiprocessors. Parallel and Distributed Systems, IEEE Transactions on, 2010, vol. 21, no 12, p. 1779-1792. [7] YUAN, Fengkai et JI, Zhenzhou. DP&TB: a coherence filtering protocol for many-core chip multiprocessors. The Journal of Supercomputing, 2013, vol. 66, no 1, p. 249-261. Encadrant :Quentin Meunier |