X-Git-Url: https://bilbo.iut-bm.univ-fcomte.fr/and/gitweb/these_gilles.git/blobdiff_plain/7a1f7981654e75ea330b58c7f93620ce69bf13b2..refs/heads/master:/THESE/Chapters/chapter1b/chapter1b.tex

diff --git a/THESE/Chapters/chapter1b/chapter1b.tex b/THESE/Chapters/chapter1b/chapter1b.tex
index c089c24..a4173bc 100644
--- a/THESE/Chapters/chapter1b/chapter1b.tex
+++ b/THESE/Chapters/chapter1b/chapter1b.tex
@@ -102,7 +102,7 @@ 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{SynthÃ¨se des contraintes d'implÃ©mentation}
+\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Ã©}. 
@@ -119,5 +119,6 @@ Il est toutefois possible, lorsque la sÃ©quence de traitement le permet, de rÃ©a
 \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. 
+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 les versions CPU Ã©quivalentes des algorithmes concernÃ©s.   
