Performances et optimisations

Transcription

1 Ecole Doctorale MathIf Performances et optimisations Violaine Louvet 1 1 ICJ - CNRS Année

2 Objectifs de ce cours Performances Déterminer les parties du code les plus coûteuses en temps. Déterminer les fonctions sur lesquelles faire porter l effort d optimisation. Savoir utiliser les outils de profiling. Optimisations Réduire le temps de calcul. Réduire l empreinte mémoire. Connaître les outils d optimisation permettant d atteindre ces objectifs.

3 Sommaire 1 Profiling Définition Mesure simple du temps Instrumentation statique gprof gcov Tau Instrumentation dynamique valgrind 2 Optimisation Optimisation haut niveau Optimisation par le compilateur Optimisations des boucles et accès mémoire

6 Définitions Outils de profiling Outils indispensables pour optimiser de manière pertinente un code : ils permettent d identifier les parties du code sur lesquelles il va falloir travailler : Temps passé dans chaque partie du programme. Nombre d appels des fonctions. Interaction du programme avec l environnement : accès mémoire, accès concurrents aux données...

7 Définitions Différentes techniques Echantillonnage : l exécution est échantillonnée régulièrement pour savoir quelles fonctions sont appelées. Pas d intrusion mais résultat dépendant notamment de la fréquence d échantillonnage. Instrumentation : Ajoute à chaque appel de fonction une fonction d instrumentation qui va mesurer le temps d appel, le nombre d instructions exécutées... grâce à des compteurs internes au processeur. Emulation : exécute le programme sur un processeur virtuel. Tout peut ainsi être mesuré de manière exacte mais cette méthode est très lente.

9 Mesure simple du temps Evaluer de façon non intrusive le temps d exécution du programme : utilisation de la commande time. $ time. / prog r e a l 0m2.671 s user 0m2.275 s sys 0m0.327 s real : temps réel écoulé lors de l exécution. user : temps d utilisation CPU en mode utilisateur. sys : temps d utilisation CPU en mode noyau (système).

10 Mesure simple du temps Evaluer plus finement de façon intrusive : utilisation de la routine système gettimeofday qui permet de connaître le temps passé dans une partie du programme. #include <sys / time. h> struct t i m e v a l s t a r t, end ; long i n t useconds ; gettimeofday (& s t a r t, ( struct timezone ) 0 ) ; / / Code a mesurer gettimeofday (&end, ( struct timezone ) 0 ) ; useconds = ( end. tv_sec s t a r t. tv_sec ) end. tv_usec s t a r t. tv_usec ; $ time. / prog Temps t o t a l : r e a l 0m2.671 s user 0m2.275 s sys 0m0.327 s

11 TP : mesure du temps Evaluer de façon globale le temps d exécution du code de multiplication matrice/matrice mat.cpp : utilisation de la commande time. Evaluer plus finement le temps passé dans l initialisation, et dans le calcul du produit : utilisation de la routine gettimeofday.

12 Profiling Techniques précédentes limitées à des évaluations ponctuelles sur le temps d exécution Nécessité d automatiser et de pouvoir avoir d autres données d analyse Intrumentation statique : effectuée au plus tard à la compilation. Instrumentation dynamique : effectuée lors de l exécution. Données recueillies par le profiler Temps d exécution de chaque fonction (profil plat). Graphe d appels du programme. Temps inclusive : fonction appelante + fonction appelée. Temps exclusive : fonction appelante uniquement.

14 gprof Instructions de profiling ajoutées à la compilation Option de compilation (compilateurs GNU) : -pg Chaque fonction est modifiée à la compilation pour mettre à jour les structures de données stockant la fonction appelante et le nombre d appels. Le temps d exécution est évalué par échantillonnage. Pour des fonctions non instrumentées (appel de bibliothèques par exemple), seul l information du temps passé dans la fonction est disponible. En pratique Compilation : g++ -pg -g prog.cpp -o prog Exécution normale du programme :./prog Génération d un fichier de données gmon.out dans le répertoire courant. Exécution de gprof : gprof prog gmon.out

15 Sorties de gprof Profil plat F l a t p r o f i l e : Each sample counts as 0.01 seconds. % cumulative s e l f s e l f t o t a l time seconds seconds c a l l s s / c a l l s / c a l l name compute ( int, int, double, double ) vsum ( int, double )... Graphe d appels granularity : each sample h i t covers 2 byte ( s ) for 0.23% of 4.26 seconds index % time s e l f children called name <spontaneous > [ 1 ] main [ 1 ] /2 compute ( int, int, double, double ) [ 2 ] /10000 vsum ( int, double ) [ 3 ] /2 main [ 1 ] [ 2 ] compute ( int, int, double, double ) [ 2 ] /10000 main [ 1 ] [ 3 ] vsum ( int, double ) [ 3 ]...

16 Description des sorties de gprof : profil plat % time : pourcentage du temps d exécution total passé à exécuter cette fonction. cumulative seconds : temps total cumulé que le processeur a passé à exécuter cette fonction, ajouté au temps passé à exécuter les fonctions précédentes dans le tableau. self seconds : nombre de secondes passées à exécuter cette seule fonction. calls : nombre d appels de la fonction. self ms/calls : nombre de millisecondes passées dans la fonction par appel. total ms/calls : nombre de millisecondes passées dans cette fontion et ses enfants. name : nom de la fonction

17 Description des sorties de gprof : graphe d appels Différentes parties séparées par des tirets. Chaque partie débute par la ligne primaire : Elle comprend en début de ligne un nombre entre crochets).. Elle se termine par le nom de la fonction concernée. Les lignes précédentes décrivent les fonctions appelantes. Les lignes suivantes décrivent les fonctions appelées : fonctions enfants. Les entrées sont classée par temps passé dans la fonction et ses enfants. index : Index référençant la fonction. % time : pourcentage du temps passé dans la fonction, incluant les enfants. self : temps total passé dans la fonction. Children : temps total passé dans les appels aux enfants. called : nombre d appels de la fonction. Si appels récursif, la sortie est de la forme n+m, n désigne le nombre d appels non récursifs et m le nombre d appels récursifs. name : nom de la fonction avec son index.

18 TP : gprof Utiliser gprof pour retrouver les résultats obtenus précédemment. Sur quelle portion de code faire porter l effort d optimisation?

19 gcov Outil de couverture de code. Permet de savoir quelles lignes de code sont effectivements exécutées et combien de fois elles le sont. Complémentaire de gprof. Permet notamment de vérifier que le jeu de test utilisé pour valider un programme est suffisant. En pratique Compilation : g++ -fprofile-arcs -ftest-coverage prog.cpp -o prog Exécution normale du programme :./prog Génération de fichiers de données *.gcda et *.gcno dans le répertoire courant pour chaque fichier compilé avec les options précédentes. Exécution de gcov : gcov prog.cpp. Génération de fichiers de données *.gcov : indexation des lignes par le nombre d appels par ligne et leur numéro.

20 Description des sorties de gcov Réécriture du programme source en préfixant chaque ligne par le nombre de fois où elle a été exécutée. Les résultats sont clairement dépendants des données : des exécutions avec des données différentes donneront des résultats différents. Pour un branchement, pourcentage représentant le nombre de fois où la branche a été prise, divisé par le nombre de fois où le test a été exécuté. Si la branche n a jamais été exécutée, message «never executed». Pour un appel de fonction, pourcentage indiquant le nombre de fois que l on est revenue de l appel sur le nombre d appels (en général 100% sauf en cas d exit dans la fonction). Les traces d exécutions (contenues dans les fichiers.gcda) s accumulent : ceci permet de mener des campagnes de statistiques sur un grand nombre de données, afin d obtenir des informations plus fiables.

21 Exemple de sorties de gcov Extrait de test3.cpp.gcov 2: 7: void compute ( i n t n1, i n t n2, double mat, double vmean ) : 8: 10002: 9: for ( i n t j = 0 ; j < n2 ; j ++) : 10: for ( i n t i = 0 ; i < n1 ; i ++) : 11: mat [ i ] [ j ] = rand ( ) ; : 12: 10002: 13: for ( i n t j = 0 ; j < n2 ; j ++) { 10000: 14: double tmp = 0. ; : 15: for ( i n t i = 0 ; i < n1 ; i ++) { : 16: tmp += mat [ i ] [ j ] ; : 17: } 10000: 18: vmean [ j ] = tmp / n1 ; : 19: } 2: 2 0 : } : 21: 10000: 22: double vsum ( i n t n1, double vect ) { 10000: 23: double mn = 0. ; : 24: for ( i n t j = 0 ; j < n1 ; j ++) : 25: mn += vect [ j ] ; 10000: 26: return mn; : 2 7 : }

22 Exemple de sorties de gcov Extrait de gcov -f test3.cpp -f : statistiques par fonction plutôt que par fichier. Function _Z7computeiiPPdS_ Lines executed :100.00% of 10 Function main Lines executed :83.33% of F i l e t e s t 3. cpp Lines executed :90.00% of 40 t e s t 3. cpp : c r e a t i n g t e s t 3. cpp. gcov

23 TP : gcov Utiliser gcov pour identifier les parties de code inutiles.

24 Tau, Tuning and Analysis Utilities Limites de gprof TAU Contenu des traces assez limité. On veut pouvoir stocker dans ces traces des évènements définis par l utilisateur. Profilage des applications parallèles. Ensemble d outils d analyse de performances de programmes. Permet de traiter beaucoup plus d informations que gprof : applications parallèles : informations par processus, par thread, par machine, temps inclusif et exclusif pour chacune des fonctions, accès aux compteurs internes, information par classe, par instance, séparation des données selon les différentes instanciation des templates, possibilité de profiler certaines parties arbitraires du code, statistiques sur des évènements définis par l utilisateur...

26 Valgrind Suite d outils de profilage et de débogage mémoire qui permet de détecter des problèmes de gestion mémoire dans des programmes écrits en C / C++ : Memcheck : un détecteur de fuites mémoires Cachegrind : un simulateur de caches Callgrind : un profileur Fonctionnement Le code est exécuté dans une machine virtuelle émulant un processeur équipé de nombreux outils d analyse donnant des informations poussées sur le comportement d un programme, qui ne pourraient être obtenues à l aide d un processeur matériel.

27 Débogage mémoire En pratique Compilation du code : $ g++ g prog. cpp o prog On peut vérifier que l exécution du code se déroule correctement : $. / prog Fin du programme Exécution sous valgrind : $ v a l g r i n d t o o l =memcheck. / prog

28 Débogage mémoire : analyse des sorties ==28889== I n v a l i d w r i t e of s ize 8 ==28889== at 0x400C58 : main ( prog. cpp : 5 3 ) ==28889== Address 0x59341e0 i s 0 bytes a f t e r a block of s ize 800 a l l o c d ==28889== at 0x4C2188C : operator new [ ] ( unsigned long ) ( vg_replace_mallo ==28889== by 0x400C28 : main ( prog. cpp : 5 2 ) Fin du programme ==28889== ==28889== ERROR SUMMARY: 1 e r r o r s from 1 contexts ( suppressed : 8 from 1) ==28889== malloc / f r e e : i n use at e x i t : 165,600 bytes i n 206 blocks. ==28889== malloc / f r e e : 206 a l l o c s, 0 frees, 165,600 bytes a l l o c a t e d. ==28889== For counts of detected errors, rerun with : v ==28889== searching for p o i n t e r s to 206 not freed blocks. ==28889== checked 183,712 bytes. ==28889== ==28889== LEAK SUMMARY: ==28889== d e f i n i t e l y l o s t : 165,600 bytes i n 206 blocks. ==28889== p o s s i b l y l o s t : 0 bytes i n 0 blocks. ==28889== s t i l l reachable : 0 bytes i n 0 blocks. ==28889== suppressed : 0 bytes i n 0 blocks.

29 Débogage mémoire : évaluer les fuites mémoires $ v a l g r i n d t o o l =memcheck leak check= f u l l. / prog ==28904== ==28904== 800 bytes i n 1 blocks are d e f i n i t e l y l o s t i n l oss record 1 of 8 ==28904== at 0x4C2188C : operator new [ ] ( unsigned long ) ( vg_replace_mallo ==28904== by 0x400C8E : main ( prog. cpp : 5 6 ) ==28904== ==28904== ==28904== 800 bytes i n 1 blocks are d e f i n i t e l y l o s t i n l oss record 2 of 8 ==28904== at 0x4C2188C : operator new [ ] ( unsigned long ) ( vg_replace_mallo ==28904== by 0x400C78 : main ( prog. cpp : 5 5 ) ==28904== ==28904== ==28904== 800 bytes i n 1 blocks are d e f i n i t e l y l o s t i n l oss record 3 of 8 ==28904== at 0x4C2188C : operator new [ ] ( unsigned long ) ( vg_replace_mallo ==28904== by 0x400C57 : main ( prog. cpp : 5 3 ) ==28904== ==28904== ==28904== 80,800 (800 d i r e c t, 80,000 i n d i r e c t ) bytes i n 1 blocks are d e f i ==28904== at 0x4C2188C : operator new [ ] ( unsigned long ) ( vg_replace_mallo ==28904== by 0x400BD8 : main ( prog. cpp : 4 9 )

30 Utilisation du profiler $ v a l g r i n d t o o l = c a l l g r i n d dump i n s t r =yes. / prog dump-instr=yes : permet d enregistrer les instructions exécutées (facilite la comparaison avec le source). Génération d un fichier callgrind.out.numéro_pid. Utilisation de l outil KCacheGrind pour l analyser.

31 kcachegrind

32 Graphe d appels

33 Analyse de l utilisation des caches $ v a l g r i n d t o o l =cachegrind. / prog Il est possible de spécifier la configuration des caches I1/D1/L2. ==29727== ==29727== I r e f s : 3,358,368 ==29727== I1 misses : 1,288 ==29727== L2i misses : 1,271 ==29727== I1 miss r a t e : 0.03% ==29727== L2i miss r a t e : 0.03% ==29727== ==29727== D r e f s : 1,475,337 (1,149,931 rd + 325,406 wr ) ==29727== D1 misses : 16,516 ( 12,225 rd + 4,291 wr ) ==29727== L2d misses : 9,531 ( 5,755 rd + 3,776 wr ) ==29727== D1 miss r a t e : 1.1% ( 1.0% + 1.3% ) ==29727== L2d miss r a t e : 0.6% ( 0.5% + 1.1% ) ==29727== ==29727== L2 r e f s : 17,804 ( 13,513 rd + 4,291 wr ) ==29727== L2 misses : 10,802 ( 7,026 rd + 3,776 wr ) ==29727== L2 miss r a t e : 0.2% ( 0.1% + 1.1% )

34 Usage des caches

35 TP : valgrind Utiliser valgrind et son outil callgrind pour retrouver les informations de profilage déjà obtenues. Utiliser valgrind et son outil memcheck pour évaluer les problèmes liés à la mémoire (et notamment les aspects fuite mémoire). Utiliser valgrind et son outil cachegrind pour évaluer les problèmes liés à l utilisation des caches. Vous pouvez utiliser Kcachegrind pour visualiser ces analyses.

37 Niveaux d optimisation Différents niveaux d optimisations : niveau algorithmique et numérique : il est souvent plus efficace de choisir un algorithme, une structure de données ou une méthode numériques plus adaptés au problème que de s attaquer à de l optimisation bas niveau. niveau intermédiaire : choix du langage, utilisation de bibliothèques existantes, parallélisation. bas niveau : travail sur les sources en lien avec le profiler, instructions sse, options du compilateur,...

39 Optimisation haut niveau Réutilisation : il y a de fortes chances que les opérations numériques nécessaires au code aient déjà été écrites : utiliser des bibliothèques existantes, souvent très optimisées et fiables. Algorithme : évaluer la complexité de l algorithme utilisé (nombre d opérations), vérifier qu il n en existe pas de moins coûteux en temps, en mémoire, parallélisables... Accès aux données : évaluer la pertinence de la structure de données : l accès est-il efficace, adapté à l algorithme utilisé? Méthode numérique : la méthode numérique choisit est-elle adaptée au problème, parallélisable, cohérente avec les structures de données...? Ces optimisations pouvaient suffire il y a quelques années. Ce n est plus le cas : complexité des architectures, augmentation des unités de calcul, problème de l accès à la mémoire... La puissance des machines n est plus facilement accessible

41 Optimisation par le compilateur Idéalement, le compilateur optimise automatiquement le code. En pratique, il n a pas toujours assez d informations (notamment la taille des données connue au run-time,...). allocation optimale des registres ; élimination des redondances ; optimisation des boucles, en ne conservant à l intérieur que ce qui est modifié ; optimisation du pipeline ; optimisation du choix des instructions.

42 Aider le compilateur Code peu optimisé par le compilateur car il est souvent incapable de savoir si le code de la boucle modifie ou non le compteur d itérations : un pointeur ou une référence pourrait le modifier. void v e c t o r : : p r i n t ( ) const { for ( i n t i = 0; i < n ; ++ i ).... ; } On indique clairement qu on utilise un nombre d itérations fixé à l avance et qui ne sera jamais modifié, autorisant le compilateur à effectuer des optimisations plus agressives. void v e c t o r : : p r i n t ( ) const { const i n t nb = n ; for ( i n t i = 0; i < nb ; ++ i ).... ; }

43 Aider le compilateur Mot-clé inline : pas de génération de la fonction f. i n l i n e i n t f ( i n t a, i n t b ) { return a b ; } i n t g ( i n t a ) { switch ( a ) { case 10: return f ( a, a ) ; case 11: case 12: return f ( a 2, a ) ; case 1200: return f ( a 2, a ) ; default : return f ( a, a ) ; } } Ce code sera traduit par le compilateur en : i n t g ( i n t a ) { i n t eax, b ; i f ( a > 12) / / a == 1200 goto L14 ; eax = a 2; i f ( a >= 11) / / a == 11,12 goto L15 ; eax=100; / / = b=10; L17 : i f ( a == b ) / / a == 10 goto L2 ; / / cas " d e f a u l t " eax=a ; L15 : eax=eax a ; L2 : return eax ; L14 : eax = ; / / = 1200 (1200 2) b = 1200; goto L17 ; }

45 Pourquoi est-ce critique? Hiérarchie mémoire des processeurs actuels. En général, les boucles concentrent en peu de ligne un maximum de temps de calcul. Le compilateur fait ce qu il peut mais il ne peut pas tout. Comportement régulier et répétitif : relativement simple à analyser statiquement. Objectifs Améliorer l accès aux données et donc leur localité spatiale. Aller plus vite. Réduire la surcharge dûe au contrôle des boucles. Investiguer les possibilité de vectorisation ou de parallélisation.

46 Invariant des boucles Sortir les invariants des boucles : Code original : for ( i n t i =0; i <10; i ++) a [ i ] = b [ i ] + c / d ; Code optimal : tmp = c / d ; for ( i n t i =0; i <10; i ++) a [ i ] = b [ i ] + tmp ;

47 Déroulage de boucles Loop Unrolling : réduit le coût de la gestion de la boucle (nombre de comparaison total, branchements, incréments) et augmente le parallélisme d instructions potentiellement exploitable par les processeurs. Code original : for ( i n t i =0; i <50; i ++) a [ i ] = b [ i ] ; Code optimal : for ( i n t i =0; i <50; i +2) { a [ i ] = b [ i ] ; a [ i +1] = b [ i + 1 ] ; }

48 Permutation de boucles Permutation des boucles imbriquées : alignement en mémoire des accès aux tableaux, réduction des défauts de cache. Ce n est pas toujours légal : attention aux dépendances des accès aux données dans les boucles. Code original : for ( i n t j =0; j <m; j ++) for ( i n t i =0; i <n ; i ++) a [ i ] [ j ] = 0. ; Code optimal : for ( i n t i =0; i <n ; i ++) for ( i n t j =0; j <m; j ++) a [ i ] [ j ] = 0. ;

49 Fusion de boucles Fusion de boucles : améliore la localité temporelle des données et réduit le nombre de branchements. Code original : for ( i n t i =0; i <n ; i ++) a [ i ] =... ; for ( i n t i =0; i <n ; i ++)... =... a [ i ]... ; Code optimal : l accès en lecture de a[i] se fait encore après son accès en écriture. La dépendance des données est respectée. for ( i n t i =0; i <n ; i ++) { a [ i ] =... ;... =... a [ i ]... ; }

50 Distribution de boucles Distribution de boucles : améliore la vectorisation et/ou la parallélisation des boucles et optimise l usage du cache pour chaque boucle. Code original : for ( i n t i =1; i <n ; i ++) { a [ i +1] = b [ i 1] + c [ i ] ; b [ i ] = a [ i ] k ; c [ i ] = b [ i ] 1; } Code optimal : for ( i n t i =1; i <n ; i ++) { a [ i +1] = b [ i 1] + c [ i ] ; b [ i ] = a [ i ] k ; } for ( i n t i =1; i <n ; i ++) c [ i ] = b [ i ] 1;

51 Boucles avec condition Eliminer les conditions des boucles : pas de test ni de branchement dans le corps de la boucle. Code optimal : Code original : for ( i n t i =0; i <n ; i ++) { a [ i ] = a [ i ] + b [ i ] ; i f ( expression ) d [ i ] = 0; } i f ( expression ) { for ( i n t i =0; i <n ; i ++) { a [ i ] = a [ i ] + b [ i ] ; d [ i ] = 0; } } else { for ( i n t i =0; i <n ; i ++) { a [ i ] = a [ i ] + b [ i ] ; } }

52 Partage de l espace d itération Partage de la boucle : permet souvent d éliminer des itérations problématiques. Code original : for ( i n t i =0; i <n ; i ++) { a [ i ] = b [ i ] + c [ i ] ; i f ( i > 10) d [ i ] = a [ i ]+ a [ i 10]; } Code optimal : for ( i n t i =0; i <=10; i ++) a [ i ] = b [ i ] + c [ i ] ; for ( i n t i =11; i <n ; i ++) { a [ i ] = b [ i ] + c [ i ] ; d [ i ] = a [ i ]+ a [ i 10]; }

53 Expansion des scalaires Expansion des scalaires : élimine de «fausses» dépendances. Code original : for ( i n t i =0; i <n ; i ++) { t = a [ i ] + b [ i ] ; c [ i ] = t + 1; } Code optimal : la boucle peut maintenant être parallélisée. i f ( n >= 1) { t = new double [ n ] ; for ( i n t i =0; i <n ; i ++) { t [ i ] = a [ i ] + b [ i ] ; c [ i ] = t [ i ] + 1; } }

54 Partitionnement de boucles Calcul par blocs : adapte la granularité (en gros la taille des blocs) à la hiérarchie mémoire. Code original : for ( i n t i =0; i <n ; i ++) for ( i n t j =0; j <n ; j ++) for ( i n t k =0; k<n ; k ++) c [ i ] [ j ] += a [ i ] [ k ] b [ k ] [ j ] ; Code optimal : on choisit S pour qu un bloc de a, de b et de c tiennent dans le cache. for ( i n t i i =0; i i <n ; i i +=S) for ( i n t j j =0; j j <n ; j j +=S) for ( i n t kk =0; kk<n ; kk+=s) for ( i n t i = i i ; i < i i +S ; i ++) for ( i n t j = j j ; j < j j +S ; j ++) for ( i n t k=kk ; k<kk+s ; k ++) c [ i ] [ j ] += a [ i ] [ k ] b [ k ] [ j ] ;

55 TP : optimisation A partir des éléments issus du profilage, retravailler les sources pour améliorer le temps de calcul et l utilisation de la mémoire. Tester les différentes options d optimisation du compilateur. Il existe déjà des bibliothèques (blitz, boost/ublas...) permettant de faire ce type de manipulations : les utiliser pour améliorer encore le code.