Simulation de jeux dinstructions hautes performances Ronan AMICEL

Simulation de jeux d’instructions à hautes performances Ronan AMICEL IRISA, équipe CAPS Université de Rennes 1

2 Plan de la présentation l Contexte des travaux et problématique l Méthode de génération de simulateurs – – approche générale simulation fonctionnelle simulation : aspects temporels, appels système maîtrise des coûts de démarrage l Résultats expérimentaux l Conclusion et perspectives

Le contexte Systèmes enfouis • Niveaux de simulation •

4 Systèmes informatiques enfouis l Systèmes haute performance – Multimédia l – Télécommunications l – l Télévision numérique, caméscopes, MP 3… Téléphonie, équipements réseau… Automobile, radar, GPS, etc. Tendance : toujours plus de calculs…

5 Niveaux de simulation l Simulation de jeu d’instructions Microarchitecture l Simple. Scalar, etc. Modèle logique l Modèle VHDL Architecture

6 Simulation de jeux d’instructions l Simulation fonctionnelle – l comportement du programme Simulation des performances – – directement (architectures « statiques » ) via un modèle externe de la micro-architecture (processeurs « superscalaires » )

Problématique : accélérer la simulation de jeux d’instructions Besoin de rapidité • Techniques existantes •

8 Notre point de départ l Constatation – – l les besoins en vitesse de simulation croissent les performances des systèmes classiques deviennent insuffisantes Objectif – Accélérer la simulation, en appliquant des techniques d’optimisation

9 Besoin de rapidité l Deux aspects complémentaires – Rapidité de la simulation – Rapidité du « reciblage »

10 Rapidité de simulation l Performances des processeurs enfouis – l Applications enfouies – – l se rapprochent des processeurs généralistes de plus en plus de calculs données de plus en plus volumineuses Validation (architecture, compilateur, application) – – tester de nombreux programmes tester de nombreux jeux de données

11 Rapidité de « reciblage » l Exploration architecturale – – évaluer différentes configurations ajouter, modifier des instructions Spécification de l’architecture Simulation pour évaluer les performances Compilation des applications Temps de développement du système

12 Techniques existantes l Deux techniques principales – Interprétation l l – technique traditionnelle, bien maîtrisée faibles performances Simulation compilée l l plus rapide adoption encore lente

13 Interprétation l Principe : « machine virtuelle » – – l Avantages – – l exécution du programme cible pas à pas boucle dite « charger, décoder, exécuter » assez simple à mettre en oeuvre grande souplesse Inconvénients – faibles performances

14 Simulation compilée l Deux étapes – – produire un simulateur spécifique pour le programme à simuler, en langage C ou C++ ce simulateur est ensuite compilé et exécuté sur la machine hôte Programme cible Générateur Compilateur Simulateur compilé

15 Avantages de la simulation compilée l Portabilité – – l Performances potentiellement élevées – – l indépendance par rapport à la machine hôte besoin seulement d’un compilateur C ou C++ le décodage des instructions est fait une fois pour toutes le compilateur peut optimiser le code final du simulateur Complexité acceptable – génération du code final à la charge du compilateur

16 Contraintes de la simulation compilée l Technique statique : tout le code doit être connu lors de la génération – – l pas de bibliothèques chargées dynamiquement pas de code auto-modifiant Systèmes enfouis : ces contraintes sont généralement acceptables – – édition de liens statique programmes souvent en ROM

17 Problème principal : coût de démarrage Génération Compilation Coût de démarrage Simulation

Notre méthode Approche • Schéma général • Forme assembleur •

19 Notre approche l Utiliser la simulation compilée – – l indépendance par rapport à la machine hôte potentiel de performance Trois objectifs – – – système reciblable optimiser la vitesse de simulation maîtriser le coût de démarrage

20 Schéma général Description de l’architecture Programme cible Générateur (ABSCISS) Source C++ du simulateur Compilateur Simulateur compilé

21 Choix de la forme assembleur l Méthodes existantes : code objet en entrée l Avantages de l’assembleur – cycle de développement plus rapide l l – informations de plus haut niveau l l pas d’assemblage ni d’édition de liens pas de description de l’encodage binaire flot de contrôle (points d’entrée des blocs de base) Inconvénients – – adresse des instructions ? agencement des sections (code, données) ?

Simulation fonctionnelle Analyse • Optimisations • Génération •

23 Simulation fonctionnelle l Principe – l produire du code C++ sémantiquement équivalent au code assembleur Deux phases – – construction d’une représentation optimisée de la sémantique du programme génération du code C++ correspondant, selon un schéma de génération

24 Construction de la représentation l Partie frontale basée sur Salto – l Construction d’arbres sémantiques – – – l système de manipulation de code assembleur instanciation de la sémantique contrôle des types optimisations Autres tâches – – – analyse du flot de contrôle gestion des données statiques affectation des adresses

25 Optimisations (1/2) l Une optimisation doit : – – accélérer la simulation avoir un impact réduit sur le coût de démarrage l Compromis comparable aux systèmes d’optimisation dynamiques (p. ex. JIT) l Incluses dans la phase de construction – optimisations locales coût réduit

26 Types d’optimisations l Évaluation statique – l Règles algébriques – – l opérations dont les arguments sont connus if( true, x, y ) x add(x, 0) x Règles spécifiques à la cible – – R 0 0 R 0 =. . . nop

27 Phase de génération l Génération de code C si possible – l Sinon, utilisation d’une bibliothèque C++ – l exploiter les types et opérateurs standards gestion des valeurs de taille arbitraire (24 bits. . . ) Génération du code de soutien – – aiguillage du flot de contrôle données statiques

Autres fonctionnalités Aspects temporels • Appels de bibliothèques •

29 Simulation cycle à cycle l Limitée aux architectures de type RISC ou VLIW à pipelines statiques l Exploitation des tables de réservation pour calculer statiquement le coût d’un bloc de base l Surcoût négligeable à la simulation

30 Appels de bibliothèques l Appel à des fonctions externes – – l appels au système d’exploitation appels à des bibliothèques Deux stratégies – – simuler l’ensemble application+bibliothèques+OS utiliser les services de la machine hôte

31 Utilisation de la machine hôte l Méthode – – l interception de l’appel externe extraction des paramètres appel de la fonction sur la machine hôte insertion du résultat dans l’état simulé Convention pour les paramètres (ABI) – – passage via les registres ou la pile dépend de l’architecture et du compilateur

Coût de démarrage Temps de compilation • Segmenter le code •

33 Le problème l Le temps de compilation dépend de la taille des fonctions générées Code C original l Code assembleur Code C du simulateur Ce temps ne croît pas linéairement…

34 Maîtrise du temps de compilation l Réduire la taille des fonctions dans le code du simulateur généré l Segmentation naturelle de l’application – l plusieurs fichiers assembleur Segmentation automatique – – génération du simulateur en « tranches » taille optimale des tranches ?

35 Temps de compilation (GCC 2. 95)

Performances Noyaux de calcul • Décodage vidéo MPEG 2 • Synthèse •

37 Performances : noyaux l Calculs de type traitement de signal l Programmes courts (boucles) – – < 300 instructions assembleur (hors nops) 500 K à 2 M itérations par test • Machine hôte : SUN Blade 100 • Plateforme cible : Tri. Media TM 1000 • Comparaison : simulateur Philips (tmsim)

Temps de simulation (secondes) hors coût de démarrage 38 Performances : noyaux

39 Application réelle : MPEG 2 l l Application de décodage vidéo Taille du code : – – ~ 10 000 lignes de code C ~ 16 000 instructions assembleur (hors nops) • Machine hôte : SUN Ultra 10 • Plateforme cible : Tri. Media TM 1000 • Comparaison : simulateur Philips (tmsim)

40 Performances MPEG 2 (1/2)

41 Performances MPEG 2 (2/2)

42 Performances : synthèse l Un à deux ordres de grandeur plus rapide qu’un simulateur industriel classique l Le coût de démarrage est rapidement amorti l Sur une station d’entrée de gamme – – ~ jusqu’à 30 millions d’opérations par seconde ~ jusqu’à 20 MHz simulés pour le Tri. Media

Pour terminer… Conclusion • Perspectives • Valorisation •

44 Conclusion l Une nouvelle approche pour la simulation compilée de jeux d’instructions – – l utilisation du langage assembleur en entrée application d’optimisations dans le générateur Performance – – un à deux ordres de grandeur plus rapide que les méthodes traditionnelles maîtrise des coûts de démarrage

45 Perspectives l Quantifier l’impact précis des optimisations l Reciblage vers d’autres architectures – l Power. PC, MIPS, ARM… Intégration de plusieurs simulateurs – – processeur + blocs matériels multiprocesseurs pour applications parallèles

46 Valorisation l Dépôt du logiciel déposé à l’APP l Transféré dans le cadre de la création d’une entreprise issue de l’équipe de recherche

Questions

Backup

49 Speedup simulation sur MPEG 2

50 Speedup global sur MPEG 2

51 Performances : MPEG 2 (38 Ko)

52 Exemple d’optimisation l Instruction assembleur – l IF r 1 iadd r 5, r 0, r 6 Règles d’optimisation – – l – Sémantique Repr. intermédiaire – – $0 $3 = add($1, $2) r 1 r 6 = add(r 5, r 0) l r 0 0 r 1 1 add(x, 0) x true x x Repr. optimisée – r 6 = r 5

53 Description de l’architecture cible l Basée sur Salto – l Pour la simulation fonctionnelle – – l système de manipulation de code assembleur Sémantique des instructions Registres, mémoires Pour la simulation « cycle à cycle » – – Unités fonctionnelles Usage temporel des ressources

54 Un système reciblable l Description de la cible basée sur SALTO – Ressources : l l – ressources de mémorisation unités fonctionnelles Instructions l syntaxe assembleur tables de réservation l Ajout : description de la sémantique l

55 Une infrastructure extensible l ABSCISS fournit – – l le « coeur » lié à la simulation comportementale une API pour ajouter des fonctions supplémentaires Exemples d’extensions existantes ou possibles – – – simulation au cycle près de pipelines statiques émulation des appels de bibliothèques ou au système simulation des caches modèles de consommation électrique génération de traces, profiling et débogage

56 Extension d’ABSCISS l Le code de l’utilisateur peut être appelé par le générateur lors d’événements grâce à un système de « call-backs » – modules d’extension C++ l – Compilés dans ABSCISS scripts Python l l Pas de recompilation nécessaire d’ABSCISS Rapide à développer et à tester

57 Ventes de microprocesseurs

62 Techniques mixtes l Interprétation + traduction de binaires – – – l permet d’accélérer l’interprétation des portions fréquemment exécutées statique en tâche de fond : FX!32 dynamique : Support matériel spécifique – – Crusoe (Transmeta) Daisy et BOA (IBM)

63 Processus de génération Source C Description de l’architect ure tmcc Assembleur Tri. Media ABSCISS tmas Source C/C++ Binaire Tri. Media gcc tmsim Simulateur compilé