X-Git-Url: https://bilbo.iut-bm.univ-fcomte.fr/and/gitweb/these_gilles.git/blobdiff_plain/e81bd9912542bc52e4b0fd1206e0b6f9b93a5fda..c9d0c3dd6f80e930b253e821696e7cab543423be:/THESE/Chapters/chapter1b/chapter1b.tex?ds=sidebyside

diff --git a/THESE/Chapters/chapter1b/chapter1b.tex b/THESE/Chapters/chapter1b/chapter1b.tex
index 1cd0756..3066242 100644
--- a/THESE/Chapters/chapter1b/chapter1b.tex
+++ b/THESE/Chapters/chapter1b/chapter1b.tex
@@ -11,14 +11,14 @@ La technologie de fabrication des GPUs Ã©tant identique Ã  celle des CPUs, c'est
   \label{fig-gpucpu1}
 \end{figure}
 
-Cette spÃ©cialisation des circuits GPU a permis d'en amÃ©liorer les performances brutes beaucoup plus rapidement que pour les CPUs, au fil des Ã©volutions de la technologie. Il en est allÃ© de mÃªme pour les dÃ©bits mÃ©moire thÃ©oriques. Les graphiques de la figure \ref{fig-gpucpu2} comparent les rythmes de ces Ã©volutions pour les GPUs Nvidia\textregistered et pour les CPUs Intel\textregistered.  
+Cette spÃ©cialisation des circuits GPU a permis d'en amÃ©liorer les performances brutes beaucoup plus rapidement que pour les CPUs, au fil des Ã©volutions de la technologie. Il en est allÃ© de mÃªme pour les dÃ©bits mÃ©moire thÃ©oriques. Les graphiques de la figure \ref{fig-gpucpu2} comparent les rythmes de ces Ã©volutions pour les GPUs Nvidia\textregistered~ et pour les CPUs Intel\textregistered.  
 
 Les problÃ¨mes requÃ©rant les capacitÃ©s de calcul spÃ©cifiques des GPUs ne sont cependant pas limitÃ©s aux questions de rendu graphique, aussi les scientifiques ont-ils trÃ¨s vite cherchÃ© Ã  tirer parti de la puissance de calcul croissante des GPUs pour traiter d'autres types de problÃ¨mes, faisant sens Ã  l'acronyme GPGPU (General Purpose Graphical Processing Unit).
 
 \begin{figure}[h]
   \centering
-  \subfigure[Nombre maximum thÃ©orique d'opÃ©rations en virgule flottante par seconde en fonction de l'annÃ©e et de l'architecture.]{\includegraphics[height=5cm]{Chapters/chapter1b/img/gpucpu2a.png}}\quad
-  \subfigure[Bande passante thÃ©orique maximale des diverses architectures.]{\includegraphics[height=5cm]{Chapters/chapter1b/img/gpucpu2b.png}}
+  \subfigure[Nombre maximum thÃ©orique d'opÃ©rations en virgule flottante par seconde en fonction de l'annÃ©e et de l'architecture.]{\includegraphics[width=9cm]{Chapters/chapter1b/img/gpucpu2a.png}}\\
+  \subfigure[Bande passante thÃ©orique maximale des diverses architectures.]{\includegraphics[width=9cm]{Chapters/chapter1b/img/gpucpu2b.png}}
   \caption{Comparaison des performances des GPUs Nvidia et des CPU Intel (d'aprÃ¨s \cite{CUDAPG}).}
   \label{fig-gpucpu2}
 \end{figure}
@@ -66,7 +66,7 @@ Une petite quantitÃ© de mÃ©moire on-chip est prÃ©sente sur chaque SM et permet l
           Globale  &   off-chip  &grille&580/80/350 &144 & 6G         \\
       \bottomrule
 \end{tabular}
-   \caption{CaractÃ©ristiques des diffÃ©rents types de mÃ©moire disponibles sur le GPU. Pour les mÃ©moires cachÃ©es, les latences sont donnÃ©es selon l'accÃ¨s \textit{sans-cache/L1/L2}. Les mesures ont Ã©tÃ© obtenues Ã  l'aide des microprogrammes de test de \cite{wong2010demystifying}.}
+   \caption{CaractÃ©ristiques des diffÃ©rents types de mÃ©moire disponibles sur le GPU. Pour les mÃ©moires cachÃ©es, les latences sont donnÃ©es selon l'accÃ¨s \textit{sans-cache/L1/L2} et ont Ã©tÃ© obtenues Ã  l'aide des microprogrammes de test de \cite{wong2010demystifying}. Les valeurs de dÃ©bit sont donnÃ©es par le constructeur.}
       \label{tab-gpu-memoire}
 \end{table}
 
@@ -102,5 +102,23 @@ Les limitations de l'\textit{occupancy} ont pour origine :
 
 Nous verrons que cette notion d'\textit{occupancy}, si elle conserve du sens, peut toutefois Ãªtre remise en question en optimisant d'autres aspects permettant d'arriver Ã  une rÃ©duction de l'effet des latences, comme le parallÃ©lisme d'instructions ou l'augmentation du volume des transactions. En effet, ces techniques, et surtout l'utilisation avisÃ©e des diffÃ©rents types de mÃ©moire du GPU permettent d'obtenir des performances Ã©levÃ©es, parfois inenvisageables en suivant les prescriptions du constructeur.
 
-
-
+\section{Contraintes de conception}
+Certaines de ces contraintes ont dÃ©jÃ  Ã©tÃ© Ã©voquÃ©es rapidement, mais il nous semble important d'en donner ici une prÃ©sentation synthÃ©tique. 
+\begin{enumerate}
+\item \textbf{ContiguÃ¯tÃ©}. 
+Les accÃ¨s alÃ©atoires Ã  la mÃ©moire globale sont en rÃ¨gle gÃ©nÃ©rale trÃ¨s pÃ©nalisants. Toutefois, il est possible de tirer parti du cache de niveau 1 (Ã  une dimension) en organisant les donnÃ©es pour que tous les threads d'un mÃªme warp accÃ¨dent Ã  des donnÃ©es appartenant au mÃªme bloc de 128 octets de mÃ©moire. Le non-respect de cette contrainte de contiguÃ¯tÃ© (\textit{coalescence}) induit des accÃ¨s rÃ©alisÃ©s en plusieurs transactions serialisÃ©es et donc une perte potentiellement importante de performances.
+\item \textbf{Conflits de banques}.
+La mÃ©moire partagÃ©e, plus rapide que la mÃ©moire globale, peut sembler une solution Ã©vidente pour obtenir des performances Ã©levÃ©es. Cependant, elle est physiquement organisÃ©e en 32 \og banques \fg{} de largeur 32 bits et prÃ©sente elle aussi une contrainte majeure. Sur architecture Fermi, l'exÃ©cution des threads d'un warp est assurÃ©e par deux \textit{moteurs d'exÃ©cution} qui activent en parallÃ¨le chacun des deux demi-warp.  
+Un \textbf{conflit de banque} se produit lorsque deux threads n'appartenant pas au mÃªme demi-warp accÃ¨dent Ã  des donnÃ©es localisÃ©es dans la mÃªme banque de mÃ©moire partagÃ©e. La transaction parallÃ¨le est alors interrompue et sÃ©rialisÃ©e.
+Ici encore, la perte de performance peut Ãªtre importante, mais il peut s'avÃ©rer trÃ¨s complexe, coÃ»teux, voire impossible d'organiser les donnÃ©es en mÃ©moire partagÃ©e de sorte Ã  Ã©viter tout conflit de banque.
+\item \textbf{Branches divergentes}.
+Toute branche d'exÃ©cution divergente entraine une sÃ©rialisation des exÃ©cution des threads du warp auquel ils appartiennent. Il convient donc d'Ã©viter cette situation et d'organiser les traitements en consÃ©quence en privilÃ©giant le plus souvent un dÃ©coupage plus fin en plusieurs kernels Ã©lÃ©mentaires plutÃ´t que des kernels \og lourds \fg{}.
+\item \textbf{Transferts GPU$\leftrightarrow$CPU}.
+Les transferts de donnÃ©es entre la mÃ©moire globale du  GPU et celle de son hÃ´te CPU peuvent reprÃ©senter l'essentiel du temps de traitement total et doivent donc Ãªtre optimisÃ©es pour en rÃ©duire la frÃ©quence et le volume des donnÃ©es Ã  copier. Cela peut parfois Ãªtre contradictoire avec la multiplication de petits kernels Ã©lÃ©mentaires.
+Il est toutefois possible, lorsque la sÃ©quence de traitement le permet, de rÃ©aliser des transferts en temps masquÃ©, pendant l'exÃ©cution d'un kernel, en crÃ©ant plusieurs flux d'exÃ©cution.
+\item \textbf{Partage des ressources d'un SM}
+Le paragraphe sur l'\textit{occupancy} a abordÃ© cet aspect par un exemple. Il faut retenir que chaque SM possÃ¨de des ressources mÃ©moire (registres, mÃ©moire partagÃ©e) que les threads des blocs logiques de la grille de calcul se partagent au cours de l'exÃ©cution d'un kernel. L'Ã©quilibre entre l'utilisation de ces ressources et le dimensionnement de la grille de calcul relÃ¨ve d'un compromis parfois dÃ©licat Ã  trouver pour obtenir les meilleures performances possibles. 
+\item \textbf{Les latences}. L'exÃ©cution des kernels subit l'effet de latences d'origines diverses. Les latences d'accÃ¨s aux mÃ©moires (voir Table \ref{tab-gpu-memoire}), les latences des diffÃ©rentes instructions arithmÃ©tiques ou encore les latences crÃ©es par l'inter dÃ©pendance d'instructions consÃ©cutives. Il est impÃ©ratif de les prendre en considÃ©ration et de mettre en \oe uvre des techniques adaptÃ©es pour les masquer au mieux.   
+\item \textbf{La mise au point}. L'ordonnancement des threads n'est pas prÃ©visible et les quelques outils d'aide Ã  la mise au point (debug) permettent simplement de cibler un  thread  prÃ©sÃ©lectionnÃ© de la cible. Cela ne permet en aucun cas de dÃ©celer, par exemple, les conflits de banques provoquÃ©s par l'interaction d'au moins deux threads. Un outil de profilage dÃ©veloppÃ© par le fabricant fournit des informations importantes sur le nombre de conflits de banques et les origines probables des limitations de performance des kernels d'un programme. Il ne s'appuie cependant que sur un bloc de threads pour en extrapoler les rÃ©sultats Ã  l'ensemble de la grille.        
+\end{enumerate}   
+L'ensemble de ces aspects rend difficile la conception d'implÃ©mentations GPU rapides car rares sont les transcriptions directes d'un code CPU qui ne se heurtent pas sÃ©vÃ¨rement Ã  l'une ou l'autre des contraintes que l'on vient d'Ã©numÃ©rer. Les performances qui en rÃ©sultent sont alors trÃ¨s en deÃ§a de celles attendues, voire infÃ©rieures Ã  celles de l'implÃ©mentation CPU. La mise au point Ã©tant par ailleurs trÃ¨s dÃ©licate, il nous semble important de proposer des kernels Ã©lÃ©mentaires dont on peut aisÃ©ment garantir les rÃ©sultats par des mÃ©thodes de test ne nÃ©cessitant pas de devoir implÃ©menter conjointement (et mettre au point) les versions CPU Ã©quivalentes des algorithmes concernÃ©s.   
