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 ?