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

diff --git a/THESE/Chapters/chapter1b/chapter1b.tex b/THESE/Chapters/chapter1b/chapter1b.tex
index 3066242..a4173bc 100644
--- a/THESE/Chapters/chapter1b/chapter1b.tex
+++ b/THESE/Chapters/chapter1b/chapter1b.tex
@@ -121,4 +121,4 @@ Le paragraphe sur l'\textit{occupancy} a abordÃ© cet aspect par un exemple. Il f
 \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.   
+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.   
