Simulation de jeux d’instructions à hautes performances

Présentation au sujet: "Simulation de jeux d’instructions à hautes performances"— Transcription de la présentation:

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

2 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

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

4 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…

5 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

6 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 »)

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

8 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

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

10 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.

11 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

12 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.

13 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.

14 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é

15 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

16 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

17 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

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

19 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

20 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é

21 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) ?

22 Simulation fonctionnelle
Analyse Optimisations Génération

23 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

24 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

25 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

26 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

27 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

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

29 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

30 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

31 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

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

33 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

34 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 ?

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

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

37 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)

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

39 Application réelle : MPEG2
39 Application réelle : MPEG2 Application de décodage vidéo Taille du code : ~ lignes de code C ~ instructions assembleur (hors nops) Machine hôte : SUN Ultra 10 Plateforme cible : TriMedia TM1000 Comparaison : simulateur Philips (tmsim)

40 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 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.

42 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

43 Conclusion Perspectives Valorisation
Pour terminer… Conclusion Perspectives Valorisation

44 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

45 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

46 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

47 Questions

48 Backup

49 Speedup simulation sur MPEG2
49 Speedup simulation sur MPEG2

50 Speedup global sur MPEG2
50 Speedup global sur MPEG2

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

52 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

53 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

54 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

55 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 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

57 Ventes de microprocesseurs
57 Ventes de microprocesseurs

58 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 … …

59 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

60 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

61 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)

62 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.

63 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é

64 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.