Changeset 19 for trunk/doc

Timestamp:

Jun 26, 2009, 5:23:11 AM (15 years ago)

Author:

guillaumeb

Message:

relecture des slides

Location:

trunk/doc

Files:

• . (modified) (1 prop)
• slides (modified) (1 prop)
• slides/1_contexte_sujet.tex (modified) (5 diffs)
• slides/2_definition_analyse_probleme.tex (modified) (1 diff)
• slides/3_principe_solution.tex (modified) (2 diffs)
• slides/4_identification_taches.tex (modified) (1 diff)
• slides/plan.txt (added)

trunk/doc

@@ -5 +5 @@
 *.toc
 *.snm
+.*.swp

@@ -5 +5 @@
 *.toc
 *.snm
+.*.swp

trunk/doc/slides/1_contexte_sujet.tex

@@ -3 +3 @@
 %==============================================================================
 
+% reviewed 0.2
+% [Contexte : La simulation c'est bien mais c'est lent]
 \begin{frame} \FT{Contexte}
     \BI
@@ -8 +10 @@
     développement de compilateurs et d'applications, pour bon nombre de raisons :
        \BI
-       \o Il n'est pas nécessaire d'avoir à sa disposition le micro-processeur
+       \o Il n'est pas nécessaire d'avoir à sa disposition le processeur
        \o Elle permet un diagnostic spécifique à un processeur des performances
        d'un programme
@@ -15 +17 @@
     très nombreux des processeurs, il en découle des simulations très lentes,
     voire inutilisables pour simuler des architectures multic\oe ur.
+
+    \o Un facteur de ralentissement de 10 à 10000 est constaté entre
+    l'exécution native et la simulation d'un programme. À titre d'exemple, il
+    n'est pas rare que la simulation d'un programme s'exécutant nativement en
+    dix minutes dure jusqu'à trois semaines.
     \EI
 \end{frame} %-------------------------------------------------------------------
+
+% reviewed 0.2
+% [Problématique : Est-ce qu'on peut simplifier la simulation pour aller plus
+%   vite ?]
+\section{Problématique et approche}
+\begin{frame} \FT{Problématique}
+    \BI
+    \o Les simulations complètes sont trop longues pour être exploitables
+    \o Les simulations entraînent souvent des approximations du fait de
+    certaines spécificités non toujours documentées des différents processeurs.
+    \o Les modèles de simulation doivent donc être simplifiés, tout en
+    préservant la pertinence de la simulation : on doit garder une bonne
+    approximation du comportement des applications, notamment dans le cas
+    d'applications utilisant des fonctionnalités  multic\oe urs.
+    \EI
+\end{frame}
+
+% reviewed 0.1++
+% [Approche : simuler seulement le comportement de la mémoire]
+\begin{frame} \FT{Approche}
+    \BI
+    \o % simulation gros grain
+    \o %    hum hum : la mémoire est un facteur déterminant
+    \o % modèle choisi : intégrer uniquement la simulation
+        % des accès mémoire et un temps de traitement des
+        % instructions
+    \o %    et le 1
+    \EI
+\end{frame}
+
+
 \begin{frame} \FT{Description détaillée}
     \BI
@@ -22 +60 @@
     l'aspect mémoire :
         \BI
-        \o La hierarchie de cache
+        \o La hiérarchie de cache
         \o La communication entre les cache
         \o La gestion de la cohérence entre les caches partagés
@@ -42 +80 @@
         \BI
         \o SimpleScalar, qui est inutilisable (sans extension) pour simuler
-        des systèmes multi-processeurs ou multic\oe urs.
+        des systèmes multiprocesseurs ou multic\oe urs.
         \o Unisim, qui est beaucoup plus modulaire, mais qui procure un
         framework assez important, dont il aurait fallu extraire la 
         simple modélisation de cache.
         \o Simics, semble offrir des avantages considérables sur les autres,
-        notemment quant à sa vitesse d'exécution, mais c'est un logiciel
+        notamment quant à sa vitesse d'exécution, mais c'est un logiciel
         propriétaire que nous n'avons pas testé
         \EI

trunk/doc/slides/2_definition_analyse_probleme.tex

@@ -3 +3 @@
 %==============================================================================
 
-\begin{frame} \FT{Simulation de caches de processeurs multicoeurs}
+\begin{frame} \FT{Simulation de caches de processeurs multic\oe urs}
     \BI
     \o La simulation doit prendre en compte les aspects suivants :
-        - hierarchie paramétrabe de plusieurs caches, de façon modulaire
+        - hiérarchie paramétrable de plusieurs caches, de façon modulaire
         (cache L1, L2, etc.)
-    \o communications entres les caches hierarchiques
-    \o gestion de caches de processeurs multicoeurs :
+    \o communications entres les caches hiérarchiques
+    \o gestion de caches de processeurs multic\oe urs :
         \BI
         \o caches partagés

trunk/doc/slides/3_principe_solution.tex

@@ -5 +5 @@
 \begin{frame} \FT{Principe de la solution}
     \BI
-    \o Modélisation de la hierarchie de cache
+    \o Modélisation de la hiérarchie de cache
     \o Traitement d'une séquence d'accès (read, write) à des adresses
     \o Un modèle très simplifié pour le reste des instructions:
@@ -11 +11 @@
         \o pas d'analyse de dépendances
         \o pas de prédiction de branchement
-        \o constantes pour les temps d'execution des instructions
+        \o constantes pour les temps d'exécution des instructions
         \EI
     \o le traitement des autres instructions est encore à définir

trunk/doc/slides/4_identification_taches.tex

@@ -7 +7 @@
     \o Étude modèle simplifié du processeur, différentes approches possibles
         \BI
-        \o intrumentation d'un exécutable (modèle de valgrind)
+        \o instrumentation d'un exécutable (modèle de Valgrind)
         \o émulation
         \EI

@@ -5 +5 @@
 *.toc
 *.snm
+.*.swp