Changeset 23 for trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/article-morpheo-share_architectural_ressources_between_hardware_context
- Timestamp:
- May 21, 2007, 12:01:51 PM (17 years ago)
- Location:
- trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/article-morpheo-share_architectural_ressources_between_hardware_context
- Files:
-
- 7 deleted
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/article-morpheo-share_architectural_ressources_between_hardware_context/common/bibliographie.bib
r2 r23 1214 1214 @article{2000_barroso, 1215 1215 title={{Piranha: a scalable architecture based on single-chip multiprocessing}}, 1216 author={Barroso, L.A. and Gharachorloo, K. and McNamara, R. and Nowatzyk, A. and Qadeer, S. and Sano, B. and Smith, S. and Stets, R. and Verghese, B.},1216 author={Barroso, L.A. and al.}, 1217 1217 journal={Proceedings of the 27th annual international symposium on Computer architecture}, 1218 1218 pages={282--293}, -
trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/article-morpheo-share_architectural_ressources_between_hardware_context/fr/root.tex
r2 r23 1 \input{\dirroot/01_abstract} 2 \input{\dirroot/02_introduction} 3 \input{\dirroot/03_experimentation.tex} 4 \input{\dirroot/04_methodologie.tex} 5 \input{\dirroot/05_resultat.tex} 6 \input{\dirroot/06_conclusion.tex} 1 \begin{abstract} 2 Dans ce document nous allons étudier l'incidence du partage par les contextes matériels d'un processeur, de ces caches de niveau 1, de sa partie opérative et de sa partie exécutive. 3 Il s'agit d'une étude de performance, en terme d'exécution, utilisant les benchmarks SPECINT2000. 4 Nous montrons que le partage de la partie exécutive n'a que peu d'incidence sur les performances, alors que le partage des caches fait perdre 10\% de performances et que le partage de la partie opérative fait tomber les performances d'un facteur de 2,7 entre un CMP de degré 4 et un SMT de même degré. 5 6 \end{abstract} 7 8 %------------------------------------------------------------------------- 9 \Section{Introduction} 10 11 De nos jours, la capacité d'intégration augmente. 12 Un concepteur possède un ``tas'' de transistors toujours plus grand à sa disposition. 13 L'objectif des vingts dernières années était d'avoir un processeur monolithique pouvant extraire des programmes le plus d'ILP (Instruction Level Parallelism) possible. 14 Les études de David W. Wall \cite{1991_wall} montre que l'ILP moyen dans un programme est de 3-5 instructions. 15 Les mono-processeurs de la fin du XX ème siècles comme le MipsR10000 \cite{1996_yeager}, l'Alpha 21264 \cite{1998_kessler}, le Pentium 4 \cite{2001_hinton} ou encore l'Itanium 1 et 2 d'Intel (\cite{2000_sharangpani}, \cite{2003_mcnairy}) exploitent tous fortement l'ILP. 16 17 Dans le même laps de temps des systèmes CMP (Chip Multi Processors) firent leur apparition. 18 De telles puces peuvent exécuter plusieurs tâches simultanément. 19 Ces CMP exploitent le TLP (Thread Level Parallelism). 20 Dans cette catégorie nous pouvons citer le piranha de Compaq \cite{2000_barroso}, l'Hydra de Stanford \cite{2000_hammond}. 21 On peut également citer le Power4 \cite{2002_tendler} ou l'Alpha 21364 \cite{2002_mukherjee} qui sont des processeurs monolithiques mais conçus pour être intégrés dans un environnement multiprocesseur. 22 23 L'exploitation de l'ILP de manière aggressive, (prédiction de branchement, lancement désynchronisé) entraine une sous exploitation des ressources internes des processeurs. 24 Une technique consiste en l'éxecution de plusieurs contextes par coeur de processeur en exploitant le TLP. 25 Ceci est la technique du Multi-threading et de sa principale variante le SMT (Simultaneous multi threading). 26 C'est l'objet des travaux de recherches de l'équipe de Tullsen \cite{1996_tullsen}, \cite{1998_tullsen}. 27 Pour un ajout minime en surface (une duplication de quelques registres d'état, ajout de multiplexeurs pour sélectionner un contexte... ), nous pouvons avoir des processeurs mono-coeur multi-thread. 28 Cette technique est exploitée dans le Pentium 4 Hyper-Threading d'Intel \cite{2003_koufaty} (ajout de 5\% en surface pour un gain de performance de 30\%). 29 30 Il y a deux grands axes de recherches : 31 \begin{enumerate} 32 \item le CMP où chaque thread s'execute sur un coeur spécifique. 33 L'intégralité des ressources d'un coeur est mit à la disposition d'un thread. 34 Les ressources internes du coeur sont dédiées à un thread. 35 36 \item le SMT où tous les threads s'éxecutent dans un unique coeur. 37 Tous les threads entrent en compétition pour l'obtention des ressources d'un coeur. 38 Les ressources internes du coeur sont partagées entre plusieurs threads 39 \end{enumerate} 40 Entre ces deux axes, il y a une multitude de variation du degré de partage des ressources entre les tâches. 41 Ceci a pour conséquence l'émergence de CMP de SMT (plusieurs coeurs multi contexte). 42 Le POWER 5 \cite{2004_kalla} est un bi-coeurs où chaque coeur est SMT de degré 2. 43 De même pour le montecito d'Intel \cite{2005_mcnairy}. 44 Alors que le Niagara de Sun intègre 8 coeurs de CMT (Corse Grain Multi Threading) de degré 4 \cite{2005_kongetira}. 45 46 L'objectif de ce papier est d'analyser les performances d'exécution entre plusieurs partages des ressources d'un processeur. 47 Pour cela, nous allons voir dans la section \ref{experimentations} les expérimentations que nous avons réalisées, ainsi que celles qui ont déjà été effectuées. 48 Dans la section \ref{methodologie} nous allons montrer nos hypothèses de travail. 49 Enfin une section où nous allons interpréter les résultats. 50 51 %------------------------------------------------------------------------- 52 \Section{Expérimentations}\label{experimentations} 53 Le SMT est une solution faible-coût pour obtenir un processeur MT (multi-thread). 54 Les ressources sont intégralement partagées, dans le cas où il n'y a qu'un seul thread à exécuter, ce dernier pourra utiliser l'intégralité des ressources du processeur. 55 56 Malheureusement cette solution à deux problèmes importants. 57 58 Le premier est que la rapidité d'exécution d'un thread dépend des autres threads. 59 Ceci est dut à la compétition entre les threads pour obtenir les ressources. 60 Par exemple si tous les threads font des accès mémoires fréquents, l'unité mémoire va rapidement saturer. 61 62 Le deuxième problème est la pollution des ressources partagées. 63 Les meilleurs exemples sont les caches et le Buffer des destinations de branchement (BTB). 64 La gestion du SMT peut être gérer de manière très simple en concaténant le numéro du thread l'adresse de l'instruction ou de la donnée. 65 Dans ce cas, le cache peut évincer des lignes très utiles d'un thread au profit de lignes d'autres threads. 66 %De plus les actions comme le prefetch ou la prédiction de branchement risque de priver des threads de lignes utiles contre une hypothétique ligne utile pour le thread bénéficiaire. 67 68 Nous allons faire varier le degré de partage des ressources. 69 Des travaux équivalents ont été réalisés. 70 Dans \cite{2004_dolbeau}, ils étudient l'influence du partage des unités à latence longue (multiplication, division...), du prédicteur de branchement, ainsi que des caches Instructions et Données. 71 Pour ce faire, ils ont implémentés l'architecture {\bf CASH} (CMP And SMT Hybrid) qui consiste en 4 coeurs ce partageant les ressources cités. 72 Dans un autre article, \cite{2004_kumar}, il y a une étude en terme de performance d'exécution mais également en terme de surface. 73 Les blocs concernés sont les unités flottantes, les caches de premiers niveaux, et enfin les ports du crossbar reliant les Caches à la mémoire. 74 Ici l'équipe de Tullsen à validée leurs hypothèses sur un système à 8 coeurs. 75 Le partage des ressources ce fait entre deux coeurs voisins. 76 77 Leurs résultats ainsi que ceux que nous obtenons sont compatibles entre eux. 78 79 Notre approche consiste à tester l'incidence du partage des caches, des Unités d'exécutions et de la partie opérative. 80 81 Nous nommons les partages comme suit : 82 \begin{description} 83 \item[Cluster :] Les clusters ce partage les caches de niveaux 2 et les unités d'exécutions. 84 \item[Unité de lancement :] Les unités de lancement ce partage les ports des caches de niveaux 1 et les unités d'exécutions. 85 \item[Contexte :] Les contextes se partagent l'accès au décodeur, au Icache et au prédicteur de branchement. 86 \end{description} 87 88 L'expérimentation ce fait avec le générateur de processeur Morpheo (acronyme de ``Multi ORganisation for a Processor HEterogeneous and Open''). 89 Une vue d'ensemble de l'architecture résultante est donnée dans la figure \ref{MORPHEO_overview}. 90 91 \begin{figure}[h] 92 \begin{center} 93 \resizebox{8cm}{!}{ 94 \includegraphics{\dirschema/MORPHEO_overview.eps}} 95 \caption{\label{MORPHEO_overview}MORPHEO - Vue d'ensemble} 96 \end{center} 97 \end{figure} 98 99 Notre allons analyser l'incidence du partage des ressources au niveau Cluster, UL et Contexte dans un système à 4 Threads, pouvant lancer à chaque cycle 8 instructions. 100 Trois tableaux résument les caractéristiques communes de chaque instance ainsi que les paramètres spécifiques pour les configurations avec 1,2 et 4 coeurs. 101 (nous définissons un coeur étant équivalent à une UL). 102 Le troisième tableau résume le système mémoire. 103 104 \begin{table}[h] 105 \begin{center} 106 \begin{tabular}{|l|c|} 107 \hline 108 Unité d'exécutions & 8 \\ 109 Profondeur des Stations de Réservations & 4 \\ 110 Nombre de branchements spéculés & 8 \\ 111 Return Address Stack & 16 \\ 112 Réseau de by-pass & Complet \\ 113 Nombre de port de lecture & 12 \\ 114 Nombre de port d'écriture & 8 \\ 115 \hline 116 \end{tabular} 117 \end{center} 118 \caption{Caractéristiques communes} 119 \end{table} 120 121 \begin{table}[h] 122 \begin{center} 123 \begin{tabular}{|l|ccc|} 124 \hline 125 & 1 coeur & 2 coeurs & 4 coeurs \\ 126 \hline 127 Largeur du pipeline & 8 & 4 & 2 \\ 128 Taille-Ifetch\_queue & 8 & 4 & 2 \\ 129 Taille-Issue queue & 32 & 16 & 8 \\ 130 Taille-ReOrder Buffer & 128 & 64 & 32 \\ 131 Taille-Autres files & 16 & 8 & 4 \\ 132 Largeur des fenêtres & 16 & 8 & 4 \\ 133 Branch Target Buffer & 256 & 128 & 64 \\ 134 Méta prédicteur & 16k & 8k & 4k \\ 135 Banc de Registres & 256 & 128 & 64 \\ 136 \hline 137 \end{tabular} 138 \end{center} 139 \caption{Caractéristiques spécifiques} 140 \end{table} 141 142 \begin{table}[h] 143 144 \begin{center} 145 \begin{tabular}{|l|cc|} 146 \hline 147 & L1 & L2 \\ 148 & I/D séparé & unifié \\ 149 \hline 150 Taille & 8 ko \footnote{divisé par le nombre de cluster} & 2 Mo \\ 151 Nombre de lignes & 128 \footnote{divisé par le nombre de cluster} & 16k \\ 152 Nombre de mots/ligne & 16 & 32 \\ 153 Associativité & 4 voies & 4 voies \\ 154 Latence - Hit & 2 cycles & 6 cycles \\ 155 Pénalités - Miss & 4 cycles & 100 cycles \\ 156 \hline 157 \end{tabular} 158 \end{center} 159 \caption{Caractéristiques du système mémoire} 160 \end{table} 161 162 %(Le nombre de lignes du premier niveau de cache est divisé par le nombre de cluster). 163 164 165 %------------------------------------------------------------------------- 166 \Section{Méthodologie}\label{methodologie} 167 168 \subSection{Charge de travails} 169 170 Dans un premier temps, nous avons sélectionné 6 benchmarks parmi les SPECINT2000 (164.gzip, 175.vpr, 181.mcf, 255.vortex, 256.bzip2, 300.twolf). 171 %Nous ne les avons pas tout sélectionnés afin de ne pas avoir trop de simulations à effectuer et car tous les benchmarks ne fonctionnes pas (problème de compatibilité avec gcc 4 et avec notre modèle). 172 173 Chaque archtecture est soumise à une charge de travails composée de 15 simulations (Le nombre de simulations est décrit par la combinaison $C_{nb\_benchmarks}^{nb\_threads}$). 174 175 Pour les librairies standard (libc et libm) ainsi que les fonctions bas niveaux (read, write, open, close ...) qu'un système d'exploitation se doit d'offrir, nous utilisons la librairie {\it Newlib}. 176 177 \subSection{Simulation} 178 179 Pour les simulations, nous avons pris 14 instances de notre modèle. 180 Elles sont déterminées par le nombre de cluster (A), le nombre d'ULs de chaque cluster (B) et le nombre de contexte de chaque UL (C). 181 De plus chaque UL n'a accès qu'a un sous-ensemble distinct d'ALUs. 182 Ce nombre définit la taille du groupe (D). 183 Nous nommons une instance X$E$\_$A$\_$B$\_$C$-$D$ avec E=A*B*C. 184 185 %Le tableau suivant récapitules toutes les instances que nous avons sélectionnées. 186 187 % 188 %\begin{table}[h] 189 %\begin{center} 190 %\begin{tabular}{ccccc} 191 %Nom & Cluster & UL & Contexte & Taille groupe d'ALUs\\ 192 %X4-1\_1\_4-8 & 1 & 1 & 4 & 8\\ 193 %X4-1\_2\_2-8 & 1 & 2 & 2 & 8\\ 194 %X4-1\_2\_2-4 & 1 & 2 & 2 & 4\\ 195 %X4-1\_4\_1-8 & 1 & 4 & 1 & 8\\ 196 %X4-1\_4\_1-2 & 1 & 4 & 1 & 2\\ 197 %X4-2\_1\_2-8 & 2 & 1 & 2 & 8\\ 198 %X4-2\_1\_2-4 & 2 & 1 & 2 & 4\\ 199 %X4-2\_2\_1-8 & 2 & 2 & 1 & 8\\ 200 %X4-2\_2\_1-4 & 2 & 2 & 1 & 4\\ 201 %X4-2\_2\_1-2 & 2 & 2 & 1 & 2\\ 202 %X4-4\_1\_1-8 & 4 & 1 & 1 & 8\\ 203 %X4-4\_1\_1-4 & 4 & 1 & 1 & 4\\ 204 %X4-4\_1\_1-2 & 4 & 1 & 1 & 2\\ 205 %\end{tabular} 206 %\end{center} 207 % \caption{Instances sélectionnées} 208 %\end{table} 209 210 Chaque simulation ce fait sur 110 millions de cycles. 211 Les 10 premiers millions sont ignorés afin de chauffer les caches et les unités de prédictions. 212 Pour chaque instance, nous prenons le nombre d'instructions exécutées des 15 simulations. 213 Ce résultat est comparé à la moyenne des 6 benchmarks exécutés dans la version Single Thread du processeur (exécution séquentielle des 6 benchmarks avec la même instance). 214 215 Nous pouvons remarquer que les instances ne vont pas être comparées avec une instance de référence, mais seront comparées avec l'accéllération de la version MT par rapport à la version ST. 216 Ceci à la bonne propriété d'avoir une borne maximale à l'accélération qui est le nombre de thread (ici 4). 217 218 %------------------------------------------------------------------------- 219 \Section{Résultat}\label{resultat} 220 221 La simulation nous fournit le graphe \ref{simulation_all} 222 223 \begin{figure}[h] 224 \begin{center} 225 \resizebox{8cm}{!}{ 226 \includegraphics{\dirschema/simulation_all}} 227 \label{simulation_all} 228 \end{center} 229 \end{figure} 230 231 Première constatation simple : plus on dédit les ressources, plus on approche de l'accélération maximale. 232 La version du X4\_4\_1\_1-2 ne partage que les caches de niveau L2, et est donc une version CMP pure, atteint une accélération de 3,92. 233 Alors que la version X4-1\_1\_4-8 qui est un SMT pur à une accélération de 1,46. 234 235 En terme de performance, il y a une accélération de 2,7 entre la version CMP et la version SMT. 236 Attention dans l'interprétation des résultats, car ici nous ne comparons qu'en terme de performances l'incidence du partage des ressources matérielles. 237 Pour que l'étude soit complète, nous devons aussi ajouter l'augmentation de la surface entre la version MT et la version ST. 238 Ensuite il faudrait comparer le rapport entre l'augmentation de la performance sur le coût matériel. 239 Nous pouvons néanmoins faire une étude abstraite du coût en surface. 240 Le rapport de surface entre la version MT et ST de l'instance X4-4\_1\_1-2 est de 4. 241 Ceci donne un rapport performance/surface pour la version CMP de degré 4 de 0,98. 242 Pour le SMT, nous réutilisons les estimations d'Intel pour le Pentium 4 HT \cite{2003_koufaty}. 243 Trois contextes de plus nous amène à 15\% de surface en plus. 244 Ce qui donne un rapport de surface entre la version MT et ST de l'instance X4\_1\_1\_4-8 de 1,15. 245 Dans ce cas, le rapport performance/surface pour la version SMT de degré 4 nous donne 1,27. 246 Ce qui donne l'avantage à une implémentation SMT. 247 248 Pour le partage du cache, nous analyserons les 3 instances suivantes : 249 \begin{itemize} 250 \item X4-4\_1\_1-2 avec 4 Icaches et Dcaches L1 de 2k chacun et accessible par un seul thread . L'accélération de 3,92. 251 \item X4-2\_2\_1-2 avec 2 Icaches et Dcaches L1 de 4k chacun et accessible par deux threads. L'accélération de 3,63. 252 \item X4-1\_4\_1-2 avec 1 Icache et Dcache L1 de 8k chacun et accessible par quatre threads. L'accélération de 3,27. 253 \end{itemize} 254 255 Le partage du cache induit des conflits d'accès au port. 256 Dans le premier cas, il y a 4 ports d'accès au Icache de largeur de deux instructions. 257 Alors que dans le troisième cas, il n'y a qu'un port de largeur de 8 instructions. 258 Les paquets de 8 instructions permettent de mieux exploiter l'ILP mais moins le TLP : chaque contexte accède au cache tous les 4 cycles. 259 Nous notons aussi que le partage du cache entraîne un effet de bord qui est le pourrissement du contenu du cache par les autres threads. 260 Ainsi qu'un allongement du temps de réponses des échecs d'accès au cache du au plus grand nombre de miss et à la plus grande longueur des lignes. 261 Le cache, optimisé pour tirer parti de la localité spatiale et temporelle d'un flot d'instructions ou de données se retrouve maintenant confrontés à plusieurs flots. 262 263 Pour le partage de la partie exécutive, nous pouvons observer les instances suivantes : 264 \begin{itemize} 265 \item X4-2\_2\_1-2 où il y a 4 groupes de 2 ALUs et chacune est accessible par 1 Threads. L'accélération est de 3,63. 266 \item X4-2\_2\_1-4 où il y a 2 groupes de 4 ALUs et chacune est accessible par 2 Threads. L'accélération est de 3,41. 267 \item X4-2\_2\_1-8 où il y a 1 groupe de 8 ALUs et est accessible par 4 Threads. L'accélération est de 3,38. 268 \end{itemize} 269 270 Le partage des unités d'exécutions n'influe que légèrement sur les performances. 271 Les ressources sont mieux utilisées. 272 Or il y a une augmentation de la sensibilité du aux erreurs de routages (envoie vers une ALUs surchargés alors que d'autres ALUs sont en famine). 273 Ceci est également du à notre politique de routage actuel qui est un round robin classique. 274 Notons que dans le cas où il y aurait plus d'un contexte par coeur, le partage des unités d'exécutions est favorable. 275 Par exemple X4-1\_2\_2-8 et X4-1\_2\_2-4 qui ont une accélération de 2,37 alors que les instances X4-2\_1\_2-8 et X4-2\_1\_2-4 ont respectivement une accélération de 2,51 et 2,4. 276 Ceci est la conséquece d'une meilleur exploitation du TLP. 277 La fenêtre de lancement est mieux utilisé et le réseau de routage à plus d'instructions à sa disposition. 278 279 % Il y a aussi une hétérogénéité des instructions longues. 280 281 Pour le partage opérative, voyons les instances suivantes : 282 \begin{itemize} 283 \item X4-1\_1\_4-8, 1 cluster possédant chacun 1 UL avec 4 contextes chacun. L'accélération est de 1,46. 284 \item X4-1\_2\_2-8, 1 cluster possédant chacun 2 ULs avec 2 contextes chacun. L'accélération est de 2,37. 285 \item X4-1\_4\_1-8, 1 cluster possédant chacun 4 ULs avec 1 contexte chacun. L'accélération est de 2,94. 286 \item X4-2\_1\_2-8, 2 clusters possédant chacun 1 UL avec 2 contextes chacun. L'accélération est de 2,51. 287 \item X4-2\_2\_1-8, 2 clusters possédant chacun 2 ULs avec 1 contexte chacun. L'accélération est de 3,38. 288 \item X4-4\_1\_1-8, 4 clusters possédant chacun 1 UL avec 1 contexte chacun. L'accélération est de 3,94. 289 \end{itemize} 290 291 Le partage de la partie opérative donne des résultats très disparates et demande une analyse plus poussée des résultats. 292 Nous pouvons néanmoins dire qu'il y a une augmentation de la sensibilité des instructions de synchronisation et d'accès aux registres spéciaux (nous imposons qu'avant d'accèder au registre spéciaux, le pipeline doit être vide). 293 Il y a également une augmentation des miss de spéculations du au partage du prédicteur de branchement. 294 Ceci implique qu'il y a une augmentation des instructions inutiles dans le pipeline. 295 Elles représentent 6,12\% des instructions dans X4-1\_1\_4-8, alors qu'elles ne représentent que 2,17\% dans l'instance X4-4\_1\_1-8. 296 Ceci est aussi du à la largeur du pipeline et donc à la sous exploitation de L'ILP. 297 Lors du décodage, nous choisissons de manière round robin la fetch queue contenant un paquet. 298 Dans l'instance X4-4\_1\_1-8, 4 décodeurs décodent chacun en moyenne 1,63 instructions sur des paquets de 2 instructions (soit un total de 6,52 instructions), alors que dans l'instance X4-1\_1\_4-8, 1 décodeur prend un paquet de 8 instructions et décode en moyenne 3,7 instructions. 299 La cause venant à des paquets d'instructions devant être alignés et à la présence de branchements. 300 301 %------------------------------------------------------------------------- 302 \Section{Conclusion} 303 304 Cette étude à démontrer un fait déjà acquis, que l'accélération entre la version MT et la version ST d'un processeur diminue avec l'augmentation du partage des ressources. 305 Notre modèle de processeur étant encore en cours de développement, nous nous destinons à fournir un modèle VHDL synthétisable. 306 Ainsi la prochaine étude portera sur le coût surfacique du partage des ressources matérielles et ainsi déterminer quel degré de partage apporte le meilleur rapport performance/surface. 307 7 308 \bibliography{\dircommon/bibliographie}
Note: See TracChangeset
for help on using the changeset viewer.