source: trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/article-morpheo-share_architectural_ressources_between_hardware_context/fr.old/05_resultat.tex @ 2

\section{Résultat}\label{resultat}

La simulation nous fournit le graph \ref{simulation_all}

\printgraphonly{simulation_all}{0.6}

Première constation simple : plus on dédicace les ressources, plus nous approchons du speed up maximal. La version du x4\_4\_1\_1-2 ne partage que les caches de niveau L2, et est donc une version CMP pure, atteind un speed up de 3,92. Alors que la version x4-1\_1\_4-8 qui est un SMT pur à un speed up de 1.46. 

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ériels. Pour que l'études soit complètes, nous devons aussi ajouté l'augmentation de la surface entre la version MT et la version ST et comparé alors le rapport entre l'augmentation de la performance sur le coût matériel.

En terme de performance, il y a une speedup de 2,7 entre la version CMP et la version SMT. Si nous faisons une étude abstraite du coût en surface, le rapport de surface entre la version MT et ST de l'instance x4-4\_1\_1-2 est de 4. Si nous réutilisons les estimations d'intel pour le Pentium 4 HT \cite{2003_koufaty} indiquant que l'ajout d'un Contexte est de 5\%, trois contextes de plus nous amène à 15\% soit un rapport de surface entre la version MT et ST de l'instance x4\_1\_1\_4-8 est de 1,15. Le rapport performance/surface pour la version CMP de degré 4 nous donnes 0,98 alors que la version SMT de degré 4 nous donnes 1,27.

Pour le partage du cache, nous pouvons tirer enseignement des 3 instances suivantes :
\begin{itemize}
\item x4-4\_1\_1-2 avec 4 Icaches et Dcaches L1 de 2k chacun et accessible par un seul thread . Le speed-up de 3,92.
\item x4-2\_2\_1-2 avec 2 Icaches et Dcaches L1 de 4k chacun et accessible par deux    threads. Le speed-up de 3,63.
\item x4-1\_4\_1-2 avec 1 Icache  et Dcache  L1 de 8k chacun et accessible par quatre  threads. Le speed-up de 3,27.
\end{itemize}

Le partage du cache induit des conflits d'accès au port : dans le premier cas, il y a 4 ports d'accés au icache de largeur de deux instructions. Alors que dans le troisième cas, il n'y a qu'un port de largeur de 8 instructions. Les paquets de 8 instructions permettent de mieux exploiter l'ILP mais moins le TLP : chaque contexte doit attendre 4 cycles avant de prendre un nouveau paquet. De plus, le partage du cache entraîne un effet de bord : le pourrissement du contenus du caches par les autres threads, et un allongements du temps de réponces des miss dut au plus grand nombre de miss et à la plus grande longueur des lignes. Le cache, optimisé pour être tirer partie de la localité spatiale et temporelles des instructions et des données ce retrouve confrontés à plusieurs flots.

Enfin pour le partage de la partie éxecutive, nous pouvons observé les instances suivantes :
\begin{itemize}
\item x4-2\_2\_1-2 où il y a 4 groupes de 2 ALUs et chacune est accéssible par 1 Threads. Le speed-up est de 3.63.
\item x4-2\_2\_1-4 où il y a 2 groupes de 4 ALUs et chacune est accéssible par 2 Threads. Le speed-up est de 3.41.
\item x4-2\_2\_1-8 où il y a 1 groupe  de 8 ALUs et         est accéssible par 4 Threads. Le speed-up est de 3.38.
\end{itemize}

Le partage des unités d'éxecutions n'influe que légèrement sur les performances. Les ressources sont plus utilisés, mais implique un effet de bord : elle augmente la sensibilité du aux erreux de routages (envoye vers une ALUs surchargés alors que d'autres ALUs sont en famine). Ceci est également du à notre politique actuel qui est un round robin classique.

Notons que dans le cas où il y a plus d'un contexte par core (x4-1\_2\_2-8 et x4-1\_2\_2-4 qui ont eu deux un speed-up de 2.37 alors que les instances x4-2\_1\_2-8 et x4-2\_1\_2-4 on un speed-up respectif de 2.51 et 2.4) le partage des unités d'executions est favorable. Ceci peut être expliquer par une bonne exploitation du TLP : la fenêtre de lancement est mieux exploiter et le réseau de routage à plus d'instruction à sa disposition. 

% Il y a aussi une hétérogéneité des instructions longues.

Pour le partage opérative, voyons les instances suivantes :
\begin{itemize}
\item x4-1\_1\_4-8, 1 cluster  possèdant chacun 1 UL  avec 4 contextes chacun. Le speed-up est de 1.46.
\item x4-1\_2\_2-8, 1 cluster  possèdant chacun 2 ULs avec 2 contextes chacun. Le speed-up est de 2.37.
\item x4-1\_4\_1-8, 1 cluster  possèdant chacun 4 ULs avec 1 contexte  chacun. Le speed-up est de 2.94.
\item x4-2\_1\_2-8, 2 clusters possèdant chacun 1 UL  avec 2 contextes chacun. Le speed-up est de 2.51.
\item x4-2\_2\_1-8, 2 clusters possèdant chacun 2 ULs avec 1 contexte  chacun. Le speed-up est de 3.38.
\item x4-4\_1\_1-8, 4 clusters possèdant chacun 1 UL  avec 1 contexte  chacun. Le speed-up est de 3.94.
\end{itemize}

Le partage de la partie opérative donne des résultats très disparates et demande une analyse plus poussés des resultats. Nous pouvons noté qu'il y a une augmentation de la sensiblité des instructions de synchronisation et des instructions d'accès au registres spéciaux (car nous imposons qu'avant d'éxecuter une instruction d'accès au registres spéciaux que le pipeline soit vide.)

Tous comme une augmentation des miss de spéculations dut au partage du prédicteur de branchement. Ceci implique qu'il y a une augmentation de nombres des instructions inutiles dans le pipeline (dans x4-1\_1\_4-8 représente 6,12\% des instructions, alors qu'il ne représente que 2,17\% dans l'instance x4-4\_1\_1-8). Ceci est aussi dut à la largeur du pipeline et donc à la sous exploitation de L'ILP. Lors du decodage, nous choissisons de manière round robin la fetch queue contenant un paquet. Dans l'instance x4-4\_1\_1-8, 4 decodeurs décode chacun en moyenne 1,63 instruction sur des paquets de 2 instruction alors que dans l'instance x4-1\_1\_4-8, 1 décodeur prend un paquet de 8 instructions et en décodent en moyenne 3,7. Ceci est dut qu'un paquet d'instruction est aligné et à la présence de branchements.