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

Plan de la présentation 2 Plan de la présentation Contexte des travaux et problématique 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 Résultats expérimentaux Conclusion et perspectives

Systèmes enfouis Niveaux de simulation Le contexte Systèmes enfouis Niveaux de simulation

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

Niveaux de simulation Simulation de jeu d’instructions 5 Niveaux de simulation Simulation de jeu d’instructions SimpleScalar, etc. Modèle VHDL Niveau de détail / vitesse de simulation

Simulation de jeux d’instructions 6 Simulation de jeux d’instructions Simulation fonctionnelle 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

Notre point de départ Constatation Objectif 8 Notre point de départ Constatation 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

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

Rapidité de simulation 10 Rapidité de simulation Performances des processeurs enfouis se rapprochent des processeurs généralistes Applications enfouies 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 deux tendances : ... là dessus se rajoutent les besoins de validation d’une architecture, d’un compilateur, d’une application qui vont nécessiter de tester de nombreux programmes ou de nombreux jeux de données.

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

Techniques existantes 12 Techniques existantes Deux techniques principales Interprétation technique traditionnelle, bien maîtrisée faibles performances Simulation compilée plus rapide adoption encore lente Maintenant que je vous ai exposé le contexte et la problématique de la simulation de jeux d’instructions pour les systèmes enfouis, je vais vous présenter les 2 principales techniques utilisées pour cette simulation.

Interprétation Principe : « machine virtuelle » Avantages 13 Interprétation Principe : « machine virtuelle » exécution du programme cible pas à pas boucle dite « charger, décoder, exécuter » Avantages assez simple à mettre en oeuvre grande souplesse Inconvénients faibles performances La technique la plus couramment utilisée est l’interprétation.

Simulation compilée Deux étapes 14 Simulation compilée 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é

Avantages de la simulation compilée 15 Avantages de la simulation compilée Portabilité indépendance par rapport à la machine hôte besoin seulement d’un compilateur C ou C++ Performances potentiellement élevées 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

Contraintes de la simulation compilée 16 Contraintes de la simulation compilée Technique statique : tout le code doit être connu lors de la génération 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

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

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

Notre approche Utiliser la simulation compilée Trois objectifs 19 Notre approche Utiliser la simulation compilée 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

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

Choix de la forme assembleur 21 Choix de la forme assembleur Méthodes existantes : code objet en entrée Avantages de l’assembleur cycle de développement plus rapide pas d’assemblage ni d’édition de liens pas de description de l’encodage binaire informations de plus haut niveau 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

Simulation fonctionnelle 23 Simulation fonctionnelle Principe 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

Construction de la représentation 24 Construction de la représentation Partie frontale basée sur Salto système de manipulation de code assembleur Construction d’arbres sémantiques 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

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

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

Phase de génération Génération de code C si possible 27 Phase de génération Génération de code C si possible exploiter les types et opérateurs standards Sinon, utilisation d’une bibliothèque C++ 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

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

Appels de bibliothèques 30 Appels de bibliothèques Appel à des fonctions externes 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

Utilisation de la machine hôte 31 Utilisation de la machine hôte Méthode 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

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

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

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

Temps de compilation (GCC 2.95) 35 Temps de compilation (GCC 2.95)

Noyaux de calcul Décodage vidéo MPEG2 Synthèse Performances Noyaux de calcul Décodage vidéo MPEG2 Synthèse

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

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

Application réelle : MPEG2 39 Application réelle : MPEG2 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 : TriMedia TM1000 Comparaison : simulateur Philips (tmsim)

40 Performances MPEG2 (1/2) Vidéo très courte. Avec ABSCISS le temps de simulation est négligeable, et le coût de démarrage (ici de 5 à 8 minutes) domine. Mais dès que celui-ci est amorti, ABSCISS devient plus rapide.

41 Performances MPEG2 (2/2) Sur une vidéo un peu plus volumineuse, le gain est flagrant puisqu’ABSCISS est déjà 16 fois plus rapide. Et avec des vidéos encore plus grosses, le gain augmenterait encore puisque le rapport de vitesse sur la simulation seule (hors coût de démarrage) est entre 75 et 100.

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

Conclusion Perspectives Valorisation Pour terminer… Conclusion Perspectives Valorisation

44 Conclusion Une nouvelle approche pour la simulation compilée de jeux d’instructions 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

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

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

Questions

Backup

Speedup simulation sur MPEG2 49 Speedup simulation sur MPEG2

Speedup global sur MPEG2 50 Speedup global sur MPEG2

Performances : MPEG2 (38 Ko) 51 Performances : MPEG2 (38 Ko)

Exemple d’optimisation 52 Exemple d’optimisation Instruction assembleur IF r1  iadd r5,r0,r6 Sémantique $0  $3 = add($1,$2) Repr. intermédiaire r1  r6 = add(r5,r0) Règles d’optimisation r0  0 r1  1 add(x,0)  x true  x  x Repr. optimisée r6 = r5

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

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

Une infrastructure extensible 55 Une infrastructure extensible ABSCISS fournit 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 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++ Compilés dans ABSCISS scripts Python Pas de recompilation nécessaire d’ABSCISS Rapide à développer et à tester

Ventes de microprocesseurs 57 Ventes de microprocesseurs

Jeu d’instructions Ensemble des « commandes de base » d’un processeur 58 Jeu d’instructions Ensemble des « commandes de base » d’un processeur Architecture : interface matériel-logiciel Micro-architecture : implémentation …001011010100100110110101101…

Variété des jeux d’instructions 59 Variété des jeux d’instructions Processeurs enfouis (multimédia, télécoms, automobile, etc.) Adelante Saturn Tensilica ARM TMS C6x Infineon TriCore MIPS ST200 ARCtangent ColdFire PowerPC Philips TriMedia Equator MAP Infineon CARMEL Hitachi SH-x StarCore Siroyan  Foisonnement de nouveaux jeux d’instructions

Simulation de jeux d’instructions 60 Simulation de jeux d’instructions Reproduire sur une machine hôte le comportement d’un programme destiné à une machine cible Machine hôte Machine cible

Traduction de binaires 61 Traduction de binaires Principe : produire directement du « code machine » Traduction statique produire un binaire pour la machine hôte Traduction dynamique traduction au fur et à mesure de la simulation utilisation d’une cache de traductions possibilité d’optimiser le code produit en s’adaptant au profil d’exécution Traduction statique systèmes ad-hoc en général (sauf UQBT)

Techniques mixtes Interprétation + traduction de binaires 62 Techniques mixtes Interprétation + traduction de binaires 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) Support matériel Utilisation d’un processeur spécialement adapté à la simulation d’une autre architecture Découplage entre le jeu d’instructions réel du processeur (de type VLIW ici) et l’architecture exposée à l’utilisateur : Intel x86 pour Transmeta, PowerPC pour les systèmes d’IBM. Possibilité de changer le jeu d’instructions visible en changeant la partie logicielle : Transmeta a fait une démonstration d’une version de sa technologie qui exécutait directement du bytecode Java.

Processus de génération 63 Processus de génération Source C tmcc Assembleur TriMedia Description de l’architecture ABSCISS tmas Source C/C++ Binaire TriMedia gcc tmsim Simulateur compilé

Développement de la chaîne d’outils et des applications 64 Développement de la chaîne d’outils et des applications Validation du compilateur génération de code et optimisations vérifier que la sémantique est préservée Faciliter la mise au point développement sur une station de travail profiling, débogage, etc. On a déjà un compilateur pour la famille de processeurs -> on va développer des optimisations spécifiques. Il faut vérifier qu’elles fonctionnent corrrectement.