Mesure de performances
Transcription
Mesure de performances
Mesure de performances [Architecture des ordinateurs, Hennessy & Patterson, 1996] Croissance des performances des microprocesseurs Avant le milieu des années 80, le gain dépendait de la technologie. Après, le gain est dû à de nouvelles idées architecturales. 1. La performance des processeurs Comment dire qu’un ordinateur est plus rapide qu’un autre? Que donneriez-vous comme mesure de performance d’un ordinateur ? 1. La performance des processeurs Comment dire qu’un ordinateur est plus rapide qu’un autre? L’utilisateur est intéressé par la réduction du temps de réponse Temps écoulé entre le début et la fin d’un événement (ou temps d’exécution) Le responsable système est intéressé par l’augmentation du débit : la nombre de travaux effectués en un temps donné a. Temps de réponse Dire d’un ordinateur (X) est n fois plus rapide qu’un autre (Y) sur une tâche signifie : Temps d ' exécutionY = n Temps d ' exécutionX Comme la performance est l’inverse du temps d’exécution : Temps d ' exécutionY Performance X n= = Temps d ' exécutionX PerformanceY b. Débit Dire que le débit de X est k=1,3 fois supérieur à celui de Y signifie : NbTacheParSecondex Debit X = k= DébitY NbTacheParSecondeY La différence entre les deux est La mesure d’une tâche (latence) La mesure de plusieurs tâches (débit) Dans les 2 cas il faut mesurer le temps 2. Mesurer la performance Mesurer le temps de réponse d’une application sur un PC prends en compte : Le temps nécessaire pour terminer la tâche Le temps d’accès disque Les accès mémoire (principale) Les activités d’E/S Le surcoût de l’OS Temps UC = uniquement le temps de travail de l’UC Temps UC utilisateur Temps UC Système a. Présenter les résultats Principe de base : la reproductibilité Donner la liste de tout ce dont un autre expérimentateur a besoin pour retrouver les résultats. Exemple Machine A Machine B Machine C Programme 1(s) 1 10 20 Programme 2(s) 1000 100 20 Temps Total (s) 1001 110 40 Quelle est la machine la plus performante ? b. Temps d’exécution total Comparer la performance de 2 machines pour une série d’applications tests par moyenne arithmétique (n est le nombre de programmes) : 1 n .∑ Tempsi n i= 1 Si la performance est exprimée comme un débit, alors la mesure utilisée est la moyenne harmonique : n n ∑ i= 1 1 Débiti Exemple (suite) Machine A Machine B Machine C Total 1001 110 40 Moyenne Arith. 500,5 55 20 c. Temps d’exécution pondéré La moyenne arithmétique suppose une répartition identique des travaux. Les programmes 1 et 2 s’exécutent-ils vraiment de manière égale dans la charge de travail ? Sinon, on peut affecter un poids wi à chaque programme pour indiquer sa fréquence. (avec Σ wi=1) n ∑ i= 1 Poidsi × Tempsi Exemple (suite) Machine A Machine B Machine C W(1) W(2) W(3) Programme 1 1,00 10,00 20,00 0,50 0,909 0,999 Programme 2 1000,00 100,00 20,00 0,50 0,091 0,001 Moyenne Arith. W(1) 500,5 55 20 Moyenne Arith. W(2) 91,82 18,18 20 Moyenne Arith. W(3) 2,00 10,09 20 Bien mesurer et maîtriser les fréquences d’apparition des événements 3. Rendre rapide le cas courant Le principe le plus répandu dans la conception des ordinateurs est de rendre rapide les cas les plus fréquents au détriment des cas rares. 1. 2. Déterminer quel est le cas fréquent Quel est le gain potentiel Ce gain peut être calculé par la loi d’Amdahl a. Loi d’Amdahl Si seule une portion d’une application peut être améliorée (en performance), alors elle définit l’accélération comme le gain max en vitesse d’une tâche utilisant cette amélioration : ComportementAmélioré Accélération = ComportementD ' origine Exemple : Si l’amélioration n’affecte que 12% de la tâche, la meilleure accélération possible sera : 1 = 1,136 fois plus rapide 1 − 0,12 Loi d’Amdahl Acc = 1 Fractionaméliorée (1 − Fractionaméliorée ) + Accélérationaméliorée • Elle sert de guide pour calculer l’impact d’un dispositif d’amélioration. • Elle sert à répartir proportionnellement les ressources aux endroits où le temps est utilisé. Loi d’Amdahl Portion de code non parallélisable La loi d'Amdahl a été initialement proposée pour chiffrer le gain de performance des architectures parallèles b. Exemple Considérons un dispositif d’amélioration dix fois plus rapide que la machine de base, mais que l’on ne peut utiliser que 40% du temps. Quelle est l’accélération totale obtenue en intégrant ce dispositif ? Exemple Considérons un dispositif d’amélioration dix fois plus rapide que la machine de base, mais que l’on ne peut utiliser que 40% du temps. Quelle est l’accélération totale obtenue en intégrant ce dispositif ? Fraction améliorée = 0,4 Accélération améliorée = 10 Acc = 1/(0,6+(0,4/10)) =1/(0,64) = 1,56 4. Performance UC a. Temps de cycle Les processeurs sont construits à partir d’une horloge fonctionnant à une certaine fréquence. Ces événements discrétisés sont appelés impulsions d’horloge ou cycle d’horloge. On caractérise la période d’horloge Soit par sa durée : 2ns Soit par sa fréquence: 500MHz Le temps UC d’un programme peut donc être exprimé par : TempsD' exécutionUC = NombreDeCyclesUC × TempsDeCycle b. CPI A partir du nombre de cycles et du nombre d’instructions (NI), on peut calculer le nombre moyen de cycles d’horloge par instruction (CPI): NombreDeCyclesUCPourUn Pr ogramme CPI = NI Donc TempsUC = NI × CPI × TempsDeCycle CPI (suite) En développant, on obtient : Instructions CycleD' hor log e Secondes Seconde × × = = TempsUC Pr ogramme Instruction CycleD' hor log e Pr ogramme La performance de l’UC dépend de trois facteurs Le temps de cycle (ou fréquence) Le nombre de cycles par instruction Le nombre d’instructions. Améliorer l’un d’eux de 10% conduit à une amélioration globale de 10%. CPI (suite) Mais aucune ne peut être modifiée indépendamment des autres Fréquence d’horloge – Technologie et architecture matérielle CPI – Architecture du Jeu d’instruction Nb d’instructions – ISA + efficacité des compilateurs 2e calcul de CPI NombreDeCyclesUC = n ∑ i= 1 TempsUC = n ∑ i= 1 n CPI i × NI i (CPI i × NI i ) × tempsCycle NI i CPI = ∑ (CPI i × ) NombreInstructions i= 1 Mesure des composantes Temps de cycle : Circuit existant : mesure Circuit en cours : estimation Nombre d’instructions : Nécessite un compilateur, puis Circuit existant : mesure Circuit en cours : ISS, long (10 à 1000 fois + lent) Insertion de code d’instrumentation dans le binaire (compteurs) (2 fois plus lent) CPI = information dynamique difficile à estimer Accès mémoire Effet du pipeline … Localité des références Les programmes ont tendance à réutiliser des données et des instructions qu’ils ont utilisées récemment. Un programme passe 90% de son temps sur 10% des instructions. Donc on peut prédire avec une précision raisonnable les données ou instructions qu’un programme utilisera dans un futur proche. Localité spatiale et temporelle Les objets accédés récemment ont beaucoup de chances d’être accédés à nouveau dans un futur proche. Des objets dont les adresses sont proches ont beaucoup de chances d’être accédés dans un temps rapproché. Utilisation de la localité Les caches Cette petite mémoire contient les données et instructions récemment accédées. On y place les informations accédées récemment : localité spatiale Et les éléments mémoires dont les adresses sont proches : localité spatiale L’élément demandé par l’UC est dans le cache : Succès cache (HIT), accès en 1 cycle Sinon c’est un défaut de cache (MISS), suspension de l’UC pour le temps de lecture en mémoire principale. Extension de l’équation de performances Prise en compte du nombre de cycles d’attente des accès mémoire, appelés cycle de suspension mémoire. avec TempsExecutionUC = (cyclesUC + CyclesSuspension) × TempsCycle CyclesSuspension = NbEchecs × PénalitésEchec = NI × EchecsParInstruction × PénalitésEchec = NI × AccèsMemParInstr × TauxEchec × PénalitésEchec Mesures des composantes L’avantage de la dernière formulation du calcul de cycles de suspension mémoire est que les composantes peuvent être facilement mesurées. NI, déjà vu Accès mémoire par instruction, idem TauxEchec, par des simulateurs de cache (NbMISS/NbAcces) Autres mesures de performances MIPS (G)MOPS Millions d’instructions par seconde Millions d’opérations par seconde MIPS = NI Temps d' exécution × 106 FréquenceHor log e = CPI × 106 NOp MOPS = Temps d' exécution × 106 (G)MFLOPS Millions d’opérations flottantes par seconde N opérations flottantes MFLOPS = Temps d' exécution × 106 Illusions Les MIPS sont une mesure précise pour comparer les performances des ordinateurs. NI TempsExecution = 6 MIPS × 10 Le nombre de MIPS dépend du jeu d’instructions Il dépend des programmes de test (benchmark) Et il peut varier en sens inverse de la performance! Exemple des machine à coprocesseur matériel de calcul flottant. Pour un programme flottant, l’utilisation du copro donne un temps d’exécution plus court mais un MIPS plus faible. Amélioration des performances L'amélioration des performances d'une machine (d'un processeur) consiste principalement à réduire le temps nécessaire à l'exécution des instructions. Améliorations par : Augmentation de la fréquence d'horloge Simplifier le décodage et l'exécution des instructions (RISC) Exécuter plusieurs instructions «en même temps» par : Parallélisme temporel (pipeline) Parallélisme spatial (superscalaire, VLIW) Prédiction de branchements Exécution spéculative V. Mesure de temps d’exécution A la recherche du temps perdu Mesures 1. 2. 3. 4. Mesures externes Mesures internes Problèmes de mesures Temps d’attente Echelles de temps Macroscopique • Disk access • Screen refresh • Keystroke Microscopique : • Integer Add • FP Mul • FP divide Interrupt handler 1ns 1us 1ms 1s 1) Critères d’utilisation des méthodes de mesure Résolution Représente l’unité de temps minimale mesurable Précision Représente l’erreur de mesure La précision est d’autant plus importante que le taux d’utilisation du processeur est important Granularité Représente la granularité de l’élément logiciel mesuré (processus, procédure, boucle, instruction) Difficulté Représente la difficulté de mise en œuvre de la méthode de mesure 1) Mesures externes - linux a) Stop-watch c) date Une horloge extérieure (temps extérieur) Identique à stop-watch avec une horloge CPU Date > output Program >> output Date > output b) time ou times Cette méthode contrairement aux précédentes prend en compte les preemption, les I/Os et les autres évènements qui prennent la main sur le programme time program 8.400 u 0.040s 0:18.40 56,1% Ces méthodes sont : Simples à utiliser Pas de modification du code Précision de l’ordre de 0,5s Résolution de l’ordre de 0,01s 1) Mesures externes d) prof/gprof Permet d’identifier les portions critiques d’une application Ralentie l’exécution et altère donc la mesure Utilisation : gcc –p –o program program.c // -pg pour gprof program prof program Comparatif Méthode Résolution Précision Granularité Difficulté Stop-watch 1s 0,5s Programme Simple Date 1s 0,5s Programme Simple Time 0,01s 0,1s Programme Simple Prof 10ms 20ms Routine Moyen 2) Mesures internes en C a) time, retourne le temps écoulé (secondes) depuis le 1er janvier 1970, minuit : type time_t Convertissable en données plus pratiques (man ctime) struct tm{ } Précision en secondes ! b) gettimeofday, mesure de temps beaucoup plus fine, de l’ordre de la microseconde Int tm_sec; Int tm_min; Int tm_hour, mday, mon, year, wday, yday, isdst; c) clock #include <time.h> Clock_t start, finish; Double total; Start = clock(); // code Finish = clock(); Total = (double)(finish-start)/(double)CLK_TCK; On obtient la résolution de l’horloge système par Sysconf(_SC_CLK_TCK); // unistd.h c) Mesure du nombre de cycles CPU Intel x86 : ReaD TimeStamp Counter __inline__ unsigned lon long int rdtsc(){ unsigned lon long int x; __asm__ volatile (‘’.byte 0x0f, 0x31 : ‘’-A’’ (x)); return x; } c) Mesure du nombre de cycles CPU Fonction inline : Principe identique à une macro du préprocesseur Le compilateur ne génère pas de symbôle associé mais intègre le code de la fonction dans l’appelant Variable volatile : Précise au compilateur que la valeur de la variable peut changer à n’importe quel moment sans action explicite du code (registres mappés mémoire, variable modifiée par intérruptions, application multi-thread) Utilisé surtoût en contexte embarqué Exemple 1 : Registres périphériques Exemple d’un registre 8-bit mappé à l’adresse 0x1234. Le code doit tester s’il passe à non-zéro UINT *ptr = (UINT *) 0x1234; // wait until non-zero While (*ptr==0) // do treatment Le compilateur génère mov ptr, #0x1234 mov a, @ptr loop : bz loop // infinite loop En déclarant ptr volatile (UINT volatile *ptr), sa valeur est relue mov ptr, #0x1234 loop : mov a, @ptr bz loop Exemple 2 : routine d’interruption Teste de fin de message (ETX) sur un port série int etx_rcvd = FALSE; void main(){ … while (!etx_rcvd){ // wait } // unused code } interrupt void rx_isr(void){ … if (ETX == rx_char) etx_rcvd = TRUE; } Problème : le compilateur ne voit pas le changement possible de etx_rcvd par l’ISR, la boucle d’attente est donc considérée comme toujours vraie. Le code après la boucle est simplement supprimé du code compilé !! Exemple 3 : préemption et variables partagées Le compilateur n’a pas de vision des changements de contexte, Les variables globales partagées (même par mutex) peuvent donc changer inopinément Donc elles doivent être déclarées volatile ! int cntr; void task1(){ cntr = 0; while (cntr==0){ sleep(1); } … } void task2(){ … cntr++; sleep(10); … } d) Timer matériels Lecture d’un timer matériel externe avant et après la portions de code à mesurer 3) Problèmes de mesures Comparaison entre systèmes différents difficile : Noyau, type de processeur, caches… Normalisation par rapport à un temps de boucle vide Temps d’exécution variable Pas de maîtrise sur la portion réellement mesurée Utilisateur, système Changement de contexte, IRQ La mesure ajoute elle-même un biais Autres possibilités Modification du noyau (fonctions hook) référence : 4) Temps d’attente Plusieurs options sont possibles pour mettre un programme en attente un certains temps : Lire le temps et boucler jusqu’au temps voulu … Pour éviter de consommer du temps CPU pour rien, il faut utiliser la fonction sleep, pour une attente en secondes. La précision du temps réellement écoulé est mauvaise. usleep Attente en microsecondes nanosleep int nanosleep(const struct timespec *req, struct timespec *rem); struct timespec{time_t tv_sec; long tv_nsec;}; La fonction peut terminer plus tôt (signal), elle retourne alors -1 et écrit le temps restant dans rem On peut donc relancer l’attente jusqu’au temps voulu Plus Mesures de performances Benchmarks Codes spécialisés dans le test d’architectures Applications réelles Logiciels de traitement de textes, tableurs, audio, etc. Problème : la portabilité Applications modifiées Ciblent les performances Noyaux Extraire une partie d’un programme réel Isole les caractéristiques de la machine Jeux Programmes simples (dizaine de lignes de code) Facilement portable (tri rapide, puzzle, etc.) System Performances and Evaluation Cooperative - SPEC 1. 2. 3. 4. 5. 6. Options de compilations prédéfinies Même compilateur et même options pour tous les programmes test Les assertions sont interdites Aucun nom de (sous-)programme dans les options de compilation Aucun retour en arrière Les options de changement de taille des éléments sont interdites Les besoins Serveurs Services de calculs et stockage à grande Capacité de stockage importante Disponibilité, fiabilité, extensibilité Les ordinateurs personnels Premier marché aujourd’hui Grandes performances Applications multimédia Applications réseaux Les architectures embarquées Faible consommation Performances temps réel Contraintes dures Contraintes molles Moindre coût échelle Matériel vs Compilateur Qui doit prendre la responsabilité de la gestion de la performance entre L’architecture matérielle Le compilateur Le compilateur peut-il profiter au mieux de l’architecture sous-jacente ?