PROJET CAPS Compilation, Architecture, Processeurs Superscalaires et Spécialisées

Projet CAPS 2 CAPS: Qui sommes nous ?  1 chercheur, 2 professeurs, 11 doctorants, 3 ingénieurs  deux activités imbriquées:  architectures hautes-performances  compilation orientée performance, outils et environnements de programmation

3 Un stage, une thèse en architecture/compilation !?

Projet CAPS 4 Que sont devenus les doctorants de CAPS ?  Depuis 1997:  S. Hily, Intel, USA  S. Chauveau, Philips National labs, NL  D. Truong, HP labs, USA  E. Rohou, ST Microelectonics, USA  P. Michaud, INRIA (en sabattique chez Intel)  Y. Mével, Sogitec, Rennes  T. Lafage, Philips, Limeil-Brevannes

5 CAPS: que faisons nous ?

Projet CAPS 6 Architecture des microprocesseurs  Comprendre les architectures hautes performances  veille techno  académiques et industriels  Proposer les nouvelles architectures  caches: skewed associative caches,..  prédiction de branchement  Simultaneous Multithreading  nouvelles organisations de processeurs  le « low power »

Projet CAPS 7 Les outils pour l’architecture  Simulation fine: cycle par cycle  Tracer les applications  Calvin2 + DICE  ABSCISS: Génération automatique de simulateurs

Projet CAPS 8 Les infrastructures logicielles pour la compilation  La nécessité d’expérimenter !  Des systèmes prototypes:  TSF : aide au portage des programmes Fortran orienté performance  SALTO: manipulation de langage assembleur

Projet CAPS 9 Compilation: projets en cours  CAHT: Intégration du Case Base Reasoning dans TSF  Compilation itérative pour les systèmes enfouis  ALISE: une infrastructure pour l ’optimisation bas-niveau  ATTLAS: optimisation haut niveau/ bas niveau  Compilation et « low power »

10 Les stages proposés

Projet CAPS 11 Génération d’aléa irreproductible  Besoin d’aléa irreproductible en CRYPTOGRAPHIE  Méthodes actuelles: 1 Kbit/s logiciel, 75Kbits/s matériel  Les microprosseurs modernes:  nombreux états non directement accessibles  compteurs de cycles  Principe établi, stage: étude et développement du générateur sur différentes platteformes (matérielles, OS)

Projet CAPS 12 Préchargement matériel pour les processeurs hautes performances du futur  performance globale très dépendante du système mémoire  cache L1: 1 cycle, cache L2 : 10 cycles mémoire principale 100 cycles  bientôt 1000 cycles  On ne peut pas toujours perdre ces cycles:  préchargement logiciel ou matériel  marche relativement bien pour masquer 10 cycles  Stage: peut-on faire qq chose en utilisant l ’espace mémoire sur le composant

Projet CAPS 13 Criticalité et non-criticalité des accès mémoire  Le problème:  on ne connaît la présence d’une donnée dans un cache que très tard, conflits d ’accès idem  Entre-temps on peut avoir pris la décision de lancer de nombreuses instructions dépendantes d ’où annulation, perte de performances, consommation inutile dénergie etc  Le stage:  explorer les solutions pour éviter (tant que faire se peut) ses situations: prédiction de la criticalité d ’un load utilisation de load à latences multiples

Projet CAPS 14 Simulation parallèle de systèmes complexes  Étude d’architectures utilise la simulation:  pb surcout important: donc jeu de données plus petits  approche développée pour ABSCISS: simulation compilée partie importante faite à la compilation mais toujours des problèmes de performances pour systèmes très complexes (multiprocesseurs, composants hétérogènes)  Stage:  Simulation parallèle : Pas parallèliser le simulateur, mais générer le simulateur parallèle

Projet CAPS 15 Exploitation interprocédurale du parallélisme d’instruction  Le parallélisme d ’instruction sur les architectures VLIW:  au niveau du bloc de base  au niveau des boucles: pipeline logiciel  au niveau de la procédure: trace scheduling  Le stage: un coup plus loin  entre les procédures  Faisabilité, analyse du potentiel:  sur l ’architecture Trimedia de Philips

Projet CAPS 16 Gestion semi-statique d’un cache d ’instruction  Les performances d ’un processeur dépendent des performances de son cache d’instruction.  Le logiciel/OS a (parfois/souvent) une bonne connaissance de qui devrait rester dans le cache.  Gestion tout matériel ne convient pas toujours: Temps réel: Worst Case Execution Time optimisation de la performance du code: –préchargement  Stage:  que verouiller dans le cache d ’instructions ?  Que, quand précharger dans le cache d’instructions

Projet CAPS 17 Contacts:   André Seznec, François Bodin  {seznec,