source: trunk/doc/slides/1_contexte_sujet.tex

%==============================================================================
\section{Contexte et Sujet}
%==============================================================================

% reviewed 0.2
% [Contexte : La simulation c'est bien mais c'est lent]
\begin{frame} \FT{Contexte}
    \BI
    \o La simulation de processeurs a acquis une importance capitale pour le
    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 processeur
       \o Elle permet un diagnostic spécifique à un processeur des performances
       d'un programme
       \EI
    \o Les simulateurs les plus répandus prennent en considération des détails
    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
    \o On cherche à simuler le comportement d'un programme en se focalisant sur
    l'aspect mémoire :
        \BI
        \o La hiérarchie de cache
        \o La communication entre les cache
        \o La gestion de la cohérence entre les caches partagés
        \o La simulation des délais de traitement
        \EI
    \o L'objectif est donc d'obtenir des estimations suivantes :
        \BI
        \o le nombre de hit/miss
        \o comptabiliser ces hit/miss pour chaque c\oe ur et pour chaque cache, 
        \EI
    \EI
\end{frame}

\begin{frame} \FT{État de l'art}
    \BI
    \o Il existe quelques simulateurs, qui sont, pour la plupart orientés vers
    une simulation complète et précise, il en résulte qu'ils sont toujours
    relativement lents :
        \BI
        \o SimpleScalar, qui est inutilisable (sans extension) pour simuler
        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,
        notamment quant à sa vitesse d'exécution, mais c'est un logiciel
        propriétaire que nous n'avons pas testé
        \EI
    \EI

\end{frame} %-------------------------------------------------------------------