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