[23] | 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 | |
---|
[2] | 308 | \bibliography{\dircommon/bibliographie} |
---|