La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Analyse et Optimisation de code Principes généraux Processeur Alpha – Tru64 Unix.

Présentations similaires


Présentation au sujet: "Analyse et Optimisation de code Principes généraux Processeur Alpha – Tru64 Unix."— Transcription de la présentation:

1 Analyse et Optimisation de code Principes généraux Processeur Alpha – Tru64 Unix

2 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Optimisation séquentielle Méthodologie proposée Principes généraux Optimisation du compilateur Timing and profiling Quelques méthodes doptimisation manuelle

3 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Méthodologie conseillée Validité du programme à optimiser Utiliser des codes déja optimisés ou sy ramener Utiliser des algorithmes performants Analyser le code, et se concentrer sur les sections critiques Utiliser les capacités doptimiser du compilateur Effectuer des modifications dans le code pour optimiser les sections critiques

4 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Principes Généraux Architecture des processeurs –Augmenter le vitesse dhorloge des processeurs –Techniques de micro-architecture permettant daugmenter le nombre dinstructions par cycle Mémoire –Mémoire hiérarchique (registre, cache,…) –Mémoire virtuelle et Paging –Optimisation des accès Quelques techniques doptimisation

5 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Architecture des processeurs Fréquence dhorloge La fréquence de lhorloge détermine la durée dun cycle Chaque opération utilise un certain nombre de cycles La fréquence dhorloge détermine les performances La fréquence dhorloge est fonction de : –La technologie des semi-conducteurs –Le packaging –Les circuits –…

6 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Comment faire des processeurs plus rapides? Augmenter la fréquence dhorloge (limites techniques, solution coûteuse) Permettre lexécution simultanée de plusieurs instructions –Exécution en parallèle (duplication de composants hardware, coûteux) –Pipelining (pas de duplication de composants hardware)

7 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Architecture HPC Processeur RISC –Instruction pipelining –Branchement reporté –Load/Store Architecture –… Seconde génération de processeur RISC –Processeur superscalaire (pipes en parallèle) –Processeur « superpipelined » (profondeur des pipes) –Processeur LIW (parallélisme dinstructions logiciel)

8 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Architecture Alpha Architecture RISC –Software Pipelining –Mémoire Hiérarchique (registre, caches,mémoire principale) –Système de prédiction de branchement –Prefetching Architecture Super-Scalaire –Modification de lordre de lexécution des instructions –Exécution spéculative –… Optimisation du parallélisme dinstructions

9 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Exécution spéculative Exemple: LD R10,R2(R0) charger dans R10 à partir de la mémoire … 30 instructions de type différents(pas de FDIV) FDIV R4,R5,R6 R4=R5/R6 R5 et R6 sont déjà dans les registres pour dautres instructions et FDIV est inutilisée Le calcul par FDIV peut commencer, le résultat sera placé dans un espace temporaire Le calcul de R4 se fera sur un cycle, temps de récupération du résultat

10 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Alpha Architecture Super-s –4 chargement dinstruction par cycle –6 instructions par cycle 4 instructions entières 2 instructions en virgule flottante –1 unité non bloquante Load/Store –4 unités fonctionnelles entières 64 bits –1 unité fonctionnelle addition virgule flottante 32/64 bits –1 unité fonctionnelle multiplication virgule flottante 32/64 bits – unité fonctionnelle SQRT en virgule lottante –(prefetch: charge les données dans le cache avant leur utilisation –déplacement conditionnel remplace les branchements à lintérieur des boucles

11 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Software Pipelining Parallélisme dinstructions Une opération sexécute en plusieurs étapes indépendantes par des éléments différents du processeur Le pipelining consiste à exécuter simultanément des étapes différentes d opérations différentes Exemple: opération seffectuant en 5 opérations Charge linstruction Charge les opérandes ExécuteDécodeEcriture

12 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Software Pipelining (suite) 3 instructions simultanées dans le pipe Décode Charge opérandes ExécuteEcriture Charge linstruction Décode Charge linstruction Charge linstruction EcritureExécute Charge opérandes Exécute Charge opérandes DécodeEcriture 3 instructions en parallèle en 7 cycles (15 cycles en séquentiel

13 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Software Pipelining (suite) Sans pipelining –résultat tous les deux cycles –pour un processeur 195Mhz: 97Mflops Avec pipelining –Après linitialisation du pipe: 1 résultat par cycle –pour un processeur 195Nhz: 195Mflops En général, lunrolling des boucles améliore le parallélisme dinstructions do i=1, t(i)=t(i)*t(I) enddo do i=1, ,2 t(i)=t(i)*t(i) t(i+1)=t(i+1)*t(i+1) enddo

14 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Pipelining: accès mémoire Laccès mémoire est une fonction coûteuse en temps qui prend plusieurs cycles. Utiliser le procédé de pipelining pour le superposer à dautres fonctions du processeur Loptimisation du compilateur peut réordonner les instructions pour favoriser ce procédé

15 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Accès Mémoire Mémoire hiérarchique –Registres –Caches –Mémoire Virtuelle Organisation des caches Optimisation des accès mémoire Outils danalyse identifiant les problèmes de cache Quelques exemples

16 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Mémoire hiérarchique (DS20-EV6) Registres Le processeur utilise uniquement les données dans les registres Temps daccès: 2ns Deux niveaux de caches (sur certaines machines 3 niveaux) –Cache primaire (L1) Accès par bloc (ligne de cache): 32 bytes Taille: 64KB Temps daccès: 2 à 3 cycles –Cache secondaire (L2) Accès par bloc : 128 bytes Taille: 4MB Temps daccès : 10 à 15 cycles Mémoire principale (DS20: taille 2.5GB/proc, latence: 220ns )

17 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Organisation des caches Le cache est divisée en lignes de cache de n mots Direct-Mapped Cache –Chaque adresse mémoire est associée à une ligne de cache Fully Associative Cache –Chaque adresse correspond à nimporte quelle ligne de cache N-way set-associative Cache (2-way et 4-Way) –Une adresse a une alternative de N lignes de cache Instruction Cache

18 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Cache Localité temporaire et spatiale des données Cache Hit –Fournit la donnée demandée à partir du cache Cache miss –Récupère la donnée dans la mémoire principale –La stocke dans le cache –Fournit la donnée demandée à partir du cache

19 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Cache thrashing parameter (max=1024*1024) dimension a(max),b(max),c(max),d(max) …… do i=1,max a(i)=b(i) + c(i)*d(i) enndo Difficultés –les vecteurs sont alloués de façon contigue –Chaque vecteur à une taille de 4MB (taille du cache secondaire) Deux méthodes pour corriger ce problème –redimensionner les vecteurs –introduire des variables entre les tableaux pour décaler les adresses

20 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Mémoire Virtuelle Dernière couche de la hiérarchie mémoire Registres Cache L1 … Cache LN Mémoire principale SWAP – disque Chaque programme utilise un espace dadressage logique en correspondance avec ladressage physique pour laccès aux données

21 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Pourquoi la mémoire virtuelle Allocation mémoire –Espace mémoire divisé en pages pas forcément contigues –Simplifie lallocation mémoire associé à un process Code relocation –Map des adresses logiques identiques à chaque run Pagination –Transfert des pages de la mémoire principale au disque en fonction de lutilisation –Disque dernier niveau de la hiérarchie mémoire (swap)

22 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Mémoire Virtuelle : Page Les transferts de la mémoire virtuelle à la mémoire physique se font par pages données Process Region Table Page Table Virtual Translation Physical Address Virtual address Location 1000

23 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry TLB (Translation Lookaside Buffer) TLB : Cache contenant les informations nécessaires aux translations adresse virtuelle – adresse physique Réduit le coût des références mémoire Taille du TLB limité TLB misses: Ladresse nest pas dans le TLB –Chercher l'information dans une page en mémoire –La page contenant la donnée est sur disque, générer une nouvelle page en mémoire

24 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Page Faults Scénario générant un page fault –Il n'existe pas de table concernant la page –La page a été restockée sur disque Chaque programme génére des "page fault" Beaucoup de "page fauts" –Mémoire partagée par plusieurs process –Mémoire requise supérieure à la mémoire réelle disponible

25 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Techniques doptimisation Analyse interprocédurale Inlining Accès mémoire –Réutilisation du cache Stride minimum Copie … –Réduction des TLB misses Optimisation de boucles

26 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Analyse Interprocédurale Par défaut: analyse du compilateur sur une seule procédure à la fois. Inconvénients: manque dinformation pour analyser les dépendances, pour mettre en évidence les constantes mettre en évidence les variables jamais utilisées traitement des variables à la frontière des procédures OPTIMISATION CONSERVATIVE

27 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Analyse Interprocédurale (IPA) Analyse plusieurs procédures simultanément Renvoie la plupart des actions du compilateur juste avant lédition de liens compilations: 2 phases –phase sommaire : récupère les informations locales utilisées ultérieurement par lIPA –création de WHIRL objets dans *.o (fe) Edition de liens –IPA: analyse et transforme les WHIRL objets –back-end du compilateur: crée les relocatables objects –édition de liens Facile à mettre en œuvre: -pipeline ou –O5 (compilation)

28 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry source.o (whirl).l.o IPA et Optimisation inter procédurale Edition de Liens Compilation: édition de liens: fe be... a.out

29 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Analyse Interprocédurale(suite) Intérets : permet des optimisations supplémentaires –Software Pipelining, –Optimisation des boucles imbriquées, –Inlining, –réduction des conflits de cache(padding,…) –élimination des fonctions jamais utilisées –détection des noms globaux –… Inconvénients: –augmente le temps global compilation/édition de liens –augmente la taille de lexécutable –peut modifier sensiblement les résultats

30 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Inlining Remplace lappel dune procédure par le code de cette procédure Intérets: –élimine loverhead dû à lappel (sauvegarde des registres, appel, instructions de retour, …) –fournit un contexte plus large pour loptimisation scalaire et de boucles. Inconvénients: –Augmente le temps de compilation –Crée des problèmes dallocation de registres plus complexes –augmente la taille du code Critères dInlining: –fréquence des appels –taille de la procédure appelée

31 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Optimisation des accès mémoire Stride –Fortran: stockage par colonne Parcourt dun tableau 2D par lindex le plus à gauche –C : stockage par ligne Parcourt dun tableau 2D par lindex le plus à droite Regroupement de données Optimisation par copie Optimisation des boucles

32 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Réutilisation du cache: stride Stride égal à 1 (Fortran) do i=1,n do j=1,n a(i,j)=b(i,j) enddo do j=1,n do i=1,n a(i,j)=b(i,j) enddo sera modifié

33 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Réutilisation du cache (suite) Regrouper les données utilisées dans une même section de code d=0 do i,1,n j=index(i) d=d+sqrt(x(j)*x(j) + y(j)*y(j) + z(j)*z(j) enddo d=0 do i,1,n j=index(i) d=d+sqrt(r(1,j)*r(1,j) + r(2,j)*r(2,j) + r(3,j)*r(3,j) enddo x,y et z seront regroupés dans un même tableau r

34 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Optimisation du cache par copie Copie d une partie des données dans un tableau temporaire –taille du tableau < 64*taille_page –suffisamment petit: réutilisation des données du cache –ne peut être pris en charge par le compilateur Performances: –diminue les " TLB misses » – " L1 et L2 misses " peuvent rester importants –Overhead du à la copie Préférer le " Cache Blocking " lorque c est possible

35 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Recouvrement des latences daccès aux données Par le système pour les faibles latences: caches primaires et secondaires data prefetch pas intégrée aux langages C et Fortran insérée automatiquement par le compilateur Manuellement par le programmeur à laide dune directive pour certains compilateurs

36 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Optimisationde boucles Unrolling Boucles imbriquées Loop interchange Références mémoire Blocking Out-OF-Score

37 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Loop Unrolling Diminue loverhead dû à la gestion des boucles Favorise le parallélisme du processeur Mais nécessite une boucle de préconditionnement Les boucles candidates à lunrolling sont: –Un nombre « raisonnable » dinstructions à chaque itération Petit: overhead de la boucle de préconditionnement, sauf si le nombre ditérations est constant –Nombre dinstructions par itération important: augmente la taille du code et des accès mémoire –Pas dappel de procédures –Condition de branchement possible dans le cas de processeur superscalaire (exécution conditionnel) –Boucle externe de boucles imbriquées dans certains cas

38 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Boucles imbriquées Unrolling : Boucle interne et/ou boucle externe ? –stride => favoriser la réutilisation des caches –Taille des boucles => favoriser les boucles à grand nombre d'itérations –Traitement des boucles non récursives => augmente le taux de parallélisme:

39 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Loop Interchange Centrer lactivité sur les boucles les plus internes Minimiser le stride Nécessite une analyse de dépendance –Par lutilisateur –Par le compilateur Parallélisation automatique –Paralléliser sur la boucle externe –Unrolling sur la boucle interne

40 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Loop Interchange? DO I=1,N DO J=1,N A(J,I)=B(I,J) ENDDO DO J=1,N DO I=1,N A(J,I)=B(I,J) ENDDO Linversion des boucles ne résoud pas les problèmes daccès

41 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Cache Blocking Principes: minimiser les transferts –utiliser entièrement la ligne de cache –réutiliser au maximun les données dans le cache –minimiser le nombre de références différentes à des pages physiques (TLB misses) Méthode –découper les données en blocs tenant dans le cache –ajouter des boucles extérieures qui contrôlent la taille des blocs Cas de la multiplication de grandes matrices: –2 matrices découpées en blocs colonnes –1 matrice en bloc ligne

42 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Cache Blocking Exemple: multiplication de deux matrices do j=1,n do i=1,m do k=1,p c(i,j)=c(i,j)+a(i,k)*b(k,j) enddo mnpldaldbldcScsMFLOPS

43 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Multiplication de matrices = Accès: Bloc C : 1fois Bloc A : nb colonnes de C Bloc B : nb lignes de A C A B

44 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Fusionner les boucles dimension a(n), b(n) do i=1,n a(i)=a(i)+alpha*b(i) enddo dot=0. do i=1,n dot=dot+a(i)*a(i) enddo dimension a(n), b(n) dot=0. do i=1,n a(i)=a(i)+alpha*b(i) dot=dot+a(i)*a(i) enddo

45 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Les pointeurs Excellent outil pour construire et manipuler toute sorte de structure de données (listes, arbres,…) MAIS Inhibe certaines optimisations du compilateur par manque dinformation. ==> Optimisation conservative POURTANT Lutilisation de structures de données appropriées peuvent améliorer les performances de certaines applications

46 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Méthodologie conseillée Validité du programme à optimiser Utiliser des codes déja optimisés ou sy ramener Utiliser des algorithmes performants Analyser le code, et se concentrer sur les sections critiques Utiliser les capacités doptimiser du compilateur Effectuer des modifications dans le code pour optimiser les sections critiques

47 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Utiliser des codes déja optimisés Libfastm: CXML ( Compaq Extended Math Library) et CXMLP (version parallèle SMP) versions optimisées des BLAS1, 2 et 3 (Basic Linear Algebra) FFT 1,2 et 3-D lapack (système linéaire et valeurs propres) solveurs de systèmes creux 2 versions : –Une version séquentielle : libcxml.a –Une version parallèle de type SMP : lincxmlp.a FFTW ATLAS

48 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Algorithmes Performants Les Mflops est un mauvais indice de performance dun code Deux algorithmes de multiplications de matrices –Même Mflops –Temps CPU très différents En priorité à loptimisation dun code, sassurer de la performance des algorithmes utilisés

49 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Mesures de performance Mesure globale du temps et autres statistiques commande UNIX " time " Mesure du temps d'une partie de code Fonctions explicites (C et Fortran) de mesure de temps Analyse complète de performance du code Outils de profiling : prof, gprof, pixie, …

50 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Mesure globale du temps Time (commande de base UNIX) : time Temps utilisateur, temps système, elapsed time CPU time = Temps utilisateur + temps système Propriétés Résolution de l'ordre de 10ms Un "system_time" disproportionné peut indiquer un disfonctionnement –Nombre important de floatig-point exceptions –Nombre important de "page faults" ou de "misaligned memory access" … CPU time < elapsed time –Partage de la machine –Grand nombre d'I/O –Largeur de bande requise > largeur de bande de la machine –Pagination et/ou swap important …

51 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Fonction TIME (CSH ou TCSH) % time program 14.9u 1.4s 0:19 83% K 27+86io 47pf+0w Temps utilisateur du process Temps system pris par le process Elapsed time Pourcentage d'utilisation Quantité moyenne de mémoire partagée (Kb) Quantité moyenne de mémoire réelle non-partagée utilisée Nombre de blocs en entrée Nommbre de blocs en sortie Fautes de pages Nombre de swaps

52 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Fonctions explicites de mesure de temps Appel explicite de sous-programmes à l'intérieur du code Fonction system_clock() Procédures de la norme Fortran90/95 (~10ms) – cpu_time() – date_and_time() Fonction etime (non standard): temps système, utilisateur et total Hors standard : fonctions constructeurs

53 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Fonctions explicites de mesure de temps Procédure system_clock real :: time Integer :: debut, fin, vitesse call system_clock(count=debut,count_rate=rate) … call system_clock(count=fin) time=float(fin-debut)/rate Fonction etime real :: actual, etime, tarray(2) actual=etime(tarray) Avec tarray(1) : temps utilisateur tarray(2) : temps du system etime : temps total

54 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Fonction dans la norme Fortran90/95 Procédure cpu_time real :: time_debut, time_fin call cpu_time(time_debut) … call cpu_time(time_fin) Print*, "temps = ", time_fin – time_debut, " secondes" Procédure date_and_time : integer :: date_time(8) character (len=12) :: real_clock(3) call date_and_time(real_clock(1), real_clock(2), real_clock(3),& date_time) Voir "Fortran Language Reference Manual"

55 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Outils de profiling Deux types de profiling : –PC Sampling : Prof : CPU-TIME Gprof : CPU-TIME associé à un graphe des appels Hiprof : CPU-TIME, graphe des appels, défaut de page,..; –Basic-Bloc Counting : prof, pixie Utilisation des Compteur Hardware : – uprofile et kprofile Profiling Mémoire Virtuelle Options de compilation de base pour le profiling : -g1 –O2

56 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Trois étapes pour le profiling Instrumentation du programme –Par le compilateur: -p, –pg –Par le profiler : hiprof, pixie Exécution du programme instrumenté Fichier de données pour le profiler (mon.out,gmon.out,…) Utilisation du profiler pour l'extraction et la lecture des résultats: prof, gprof, hiprof, pixie

57 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Hiprof (Tru64 Unix) Permet l'utilisation de fréquence d'échantillonnage plus petite et le profiling au niveau de la ligne. Les librairies partagées peuvent être analysées Profiling individuel des threads possible Indépendant des ressources hardware et de l'architecture Génére une perte de performance Ne se retrouve pas sur tous les systèmes UNIX

58 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry PC-Sampling ( prof, gprof,hiprof) Cpu_time profiling : option –p et profiler prof % f90 –g1 –O2 –p –o prog prog.f % prog => création du fichier mon.out % prof prog mon.out > prof.list (sortie par défaut à l'écran) Cpu-time profiling + graphe des appels –Compilateur : option –pg et profiler gprof % f90 –g1 –O2 -pg –o prog prog.f % prog => création du fichier gmon.out % prof prog gmon.out > prof.list (sortie par défaut à l'écran) –profiler hiprof (pas d'option particulière): Compiler le programme : f90 –g1 –O2 –o prog prog.f Instrumentation du programme: hiprof prog => prog.hiprof Exécution :./prog.hiprof ou hiprof –run prog Affichage des résultats : hiprof –run –display prog

59 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Listing: PC-Sampling Each sample covers 8.00 byte(s) for 4% of seconds %time seconds cum % cum sec procedure (file) square_ (matpower.f) square_mult_ (matpower.f) %time : pourcentage de temps passé dans la routine seconds : temps en secondes passé dans la routine cum % : pourcentage de temps cumulé cum sec : temps cumulé en secondes

60 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Basic-Bloc Counting (pixie,prof) Compilation : f90 –g1 –O2 –o prog prog.f Instrumentation: pixie prog Programme instrumenté: prog.pixie Fichier d'adresses des blocs: prog.Addrs Exécution: prog.pixie Crée le fichier compteurs de blocs: prog.Counts Extrait et affiche l'information de profiling prof –pixie prog >prog_pixie.list Réduire les informations fournies -exclude, -only -quit : troncature du listing après n lignes

61 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry PC-SAMPLING + GRAPH

62 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry PC-SAMPLING + GRAPH

63 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Optimisation par FEEDBACK Optimisation en deux compilations successives Cinq Etapes: –Compilation avec – gen_feedback (pas d'optimisation): f90 –gen_feedback –o prog prog.f –Instrumentation: pixie prog => prog.pixie, prog.Addrs –Exécution: prog.pixie => prog.Counts –Affichage : prof –pixie –feedback prog.feedback prog –Recompilation et optimisation du compilateur f90 –O5 –fast –arch host –feedback prog.feedback –o prog prog.f

64 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Mémoire virtuelle Utilisation de la zone de swap –Mémoire requise > mémoire physique de la machine –Partage des ressources entre plusieurs programme Profiling –Comparer la mémoire requise à la mémoire physique Commande size : text, data, bss Option du compilateur sur Tru64 Unix: -V Ne tient pas compte de la pile et du tas –Page faults: vmstat ( Berkeley S) et sar (System 5)

65 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Page faults Global : vmstat 5 Virtual Memory Statistics: (pagesize = 8192) procs memory pages intr cpu r w u act free wire fault cow zero react pin pout in sy cs us sy id K 138K 14K 2M 193K 2M 0 187K K 138K 14K K 138K 14K K 138K 14K Par programme / procédure : Profiler hiprof hiprof –run –display –faults matpower

66 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Compteurs Hardware Petits registres comptabilisant les occurrences dévénements associés à des fonctions du processeur –Instructions load/store –Opérations Floating Point –Nombre de cycles dattente daccès mémoire –Cache misses, TLB misses,… –… Fournies des informations utiles à lexplication des manques de performance de certaines parties de codes Le suivi de ces événements permet daffiner ladaptation du code à larchitecture cible

67 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Compteur Hardware sur EV67 et EV7 Deux registres de compteur de performances pour compter les événements hardware 1 à 16 événements hardware par compteur –2 événements: comptage exacte –plus de 2 événements: multiplexage par lOS sur les 2 compteurs, estimation statistique loverflow dun compteur provoque un hardware trap Dépend du type de processeur – inopérant sur EV6 Profiler uprofile

68 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Pourquoi PAPI? Les compteurs Hardware existent sur la plupart des processeurs Les mesures de performances associées à ces compteurs varient suivant les processeurs Ily a très peu d API permettant de les utiliser et elles sont souvent peu documentées instables et parfois inutilisables

69 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry But de PAPI Fournir une API portable, simple à utiliser pour accéder aux compteurs hardware sur la majorité des plate- formes HPC Définir des métriques de performances communes à un grand nombre de plate-formes fournissant des informations utiles à loptimisation de codes Encourager les vendeurs à standardiser les interfaces et la sémantiques des compteurs hardware

70 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Laisser faire le compilateur Idéallement, le compilateur optimise automatiquement le code. –Il na pas toujours assez dinformations (taille des données connue au run-time,…) –excessive cache performance Optimisations principales –Utilisation du parallélisme dinstructions (pipelining) –Software pipelining –Inlining –Analyse Interprocédurale –Optimisation de boucles

71 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Options de base: On, n=0,…5 (Tru64 Unix) Plus n grand: –Plus loptimisation est sophistiquée –Plus le temps de compilation est important –Plus la taille du code peut devenir grande Options de base On, n=1,…5 –Optimisations locales: -O1 et plus –Optimisation globale : -O2 et plus –Optimisation globales supplémentaires: -O3 –Analyse interprocédurale: -O4 (par défaut) –Transformation de boucles et software pipelining: -O5

72 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Autres options doptimisation (Tru64 Unix) Alignement des données dans les commons et les structure : - align ou –fast Compromis précision rapidité: -math_library fast ou accurate Contrôler linlining : -inline (speed, size,manual…) Contrôler lunrolling : -unroll num ou –O3 et plus Indiquer au compilateur la machine cible : -arch host ou –arch ev6, –fast => -arch host Contrôle du Software Pipelining : -O5 ou –pipeline –tune Permettre toutes les transformations mathématiques valides, ne respecte pas la sémantique (IEEE 754 binary floating point arithmetic) -fp_reorder ou -fast

73 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Directives #pragma optimize (Tru64 Unix) Permet de localiser loptimisation du compilateur Avec le compilateur C Options de la directive –#pragma optimize level= 0,…5 => #pragma optimize level =5 unroll=n => #pragma optimize unroll =5.. –#pragma optimize save –#pragma optimize restore Voir Programmers Guide

74 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Software Pipelining (Tru64 Unix) Le compilateur ne fait pas de Software Pipelining par défaut = > augmente le temps de compilation -pipeline ou –O5 (-pipeline + -transform_loops) Performant sur les boucles vectorisables Moins performant sur les boucles: de grande taille contenant des récurrences Nest pas effectué sur les boucles: contenant des appels de fonction contenant des instructions goto

75 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Automatique prefetching Options du compilateur Tru64 Unix: Software pipelining -pipeline, -O5 => software pipelining Pas de directives #pragmas Niveaux de prefetching plus ou moins agressif ( IRIX – SGI) –de façon conservative –pour les grosses structures de données –pour une taille des données inconnue Deux niveaux de prefetching (pas sur Tru64 Unix) –niveau 2: mémoire principale vers le cache secondaire –niveau 1: cache secondaire vers le cache primaire

76 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Contrôle de lInlining Compilateur: -inline -inline manual : uniquement les fonctions (-O2, -O3) -inline size : en fonction de la taille du code (-O1 et plus) -inline speed : quelque soit la taille et le nombre dappels (-O4 et –O5) -inline all : toutes les fonctions et les routines si cest possible -inline none: supprime linlining des sous-programmes (-O3 et moins) Compromis entre : –La taille du code –La fréquence des appels Directive #pragma inline (id,…) ou #pragma noinline(id,…) en C et C++

77 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry IEEE 754 binary floating point arithmetic Exemple de transformation non conforme avec IEEE 754 do i=1,n tmp=1/c b(i)=a(i)/c par do i=1,n enddo b(i)=a(i)*tmp enddo Lordre des opérations peut provoquer des résultats numériques différents (arrondis, overflows…) Lutilisation des ressources hardware impose parfois de modifier lordre des opérations (pipelining…)

78 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Rappel: Transformation de boucles Les différents types de transformation de boucles –loop unrolling –Loop interchange –Padding –Loop Fusion or Fission –Cache blocking –Prefetching La connaissances des techniques permet d aider le travail du compilateur

79 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Transformations de boucles (Tru64 Unix) Effectuées par le compilateur avec les options : -transform_loops -O5 Optimisation de lutilisation des caches, de la gestion des instructions Son action est suffisante pour la plupart des programmes Optimisation du compilateur inhibée par –Boucles sans compteur –Appel de sous-programmes ou de fonctions sans inlining –Condition de sortie non standard –Aliasing (pointeurs)

80 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Optimisation du Cache Transformation de boucles: -O5 ou -transform_loops Concentrée sur les boucles imbriquées et peut bénéficier de lanalyse interprocédurale: -O3 et - transform_loops résoud de nombreux problèmes de cache, ne corrige pas une mauvaise conception du code désactive les transformations de boucles peut parfois augmenter les performances –notransform_loops

81 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Obstacles à la performance Ce qui contribue à loverhead –Appel à une routine –Référence indirecte à la mémoire –Tests à lintérieur dune boucle –Conversion de type –Variables non utilisées –Tests trop verbeux Ce qui restreint la capacité doptimiser du compilateur –Appel à une routine –Référence indirecte à une procédure –Tests à lintérieur dune boucle –Pointeurs ambigus

82 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Appels de sous-programmes Réduit la capacité du compilateur à optimiser –Pas de software pipelining –Gestion des variables externes et des commons lourde Compromis entre: –La taille de la routine –Le nombre dappels Éviter un nombre faible dappels à une petite routine Modularité indispensable pour le développement de gros codes compactes et compréhensibles

83 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Appel de procédures (suite) Préférer DO I=1,N A(I)=A(I)+B(I)*C ENDDO À DO I=1,N CALL MADD(A(I),B(I),C) ENDDO SUBROUTINE MADD(A,B,C) A=A+B*C RETURN END Eviter COMMON /UTIL/K DO K=1,1000 IF (K.EQ. 1) CALL AUX ENDDO – K variable de common : le compilateur stocke en mémoire et recharge K à chaque itération –Conserver k comme variable locale

84 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Macros Principalement utilisées en C: concerne surtout les petites fonctions #define average(x,y)((x+y)/2) main () { float q=100,p=500; float a; a=average(p,q); …} 2 étapes: Pré-compilation par cpp: remplace les macros par leur code Compilation C ou Fortran Le compilateur C effectue les deux étapes automatiqument, certains compilateurs fortran également.

85 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry INLINING Concernent les fonctions de taille plus importante que les macros Selon le compilateur, plusieurs méthodes –Spécifier les procédures concernées à la compilation –Mettre dans le code des directives –Laisser le compilateur faire le travail automatiquement Compromis entre la taille du code et les performances (réutilisation optimale du cache instructions)

86 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Branchement Méthode: –Réduire les branchements si cest possible –Les sortir de certains blocs (boucles,…) Branchement à lintérieur dune boucle –Invariant conditionnel dans la boucle –Condition sur lindex de boucle=> restructuration du code –Instruction conditionnelle indépendante => unrolling, exécution en parallèle –Instructions conditionnelles dépendantes=> conservation de lordre –Réductions => Laisser faire le compilateur –Condition de transfert de contrôle

87 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Branchement à lintérieur dune boucle parameter (small=1.E-20) do i=1,n if (abs(a(i)).ge. small) then b(i)=b(i)+a(i)*c endif enddo => Éliminer le test pour permettre le software pipelining

88 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Invariant conditionnel dans la boucle DO I=1,K IF (N.EQ. 0 ) THEN A(I)=A(I)+B(I)*C ELSE A(I)=0. ENDIF ENDDO Préférer : IF (N.EQ. 0) THEN DO I=1,K A(I)=A(I)+B(I)*C ENDDO ELSE DO I=1,K A(I)=0. ENDDO ENDIF

89 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Expression conditionnelle indépendante DO I=1,N DO J=1,N IF (B(J,I).GT. 1.0) A(J,I)=A(J,I)+B(J,I)*C ENDDO Indépendance des itérations => Unrolling ou exécution en parallèle possible

90 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Condition de transfert de contrôle DO I=1,N DO J=1,N IF (B(I,J).EQ. 0) THEN PRINT*,I,J STOP ENDIF A(I,J)=A(I,J)/B(I,J) ENDDO Utiliser les procédés de récupération derreur fournit par le standard IEEE – option à la compilation

91 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Autres obstacles Conversion de type Eviter les expressions de type caractère dans les expressions conditionnelles Effectuer ses propres éliminations de sous-expressions –Le compilateur ne les reconnaît pas toutes –Ne gère pas celles qui contiennent des appels de fonctions Effectuer ses propres déplacements de code –Partie invariante dans une boucle Références multiples à un même élément de tableau On a pas toujours intérêt à le remplacer par une variable scalaire

92 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Elimination de sous-expressions x=r*sin(a)*cos(b) y=r*sin(a)*sin(b) z=r*cos(a) devient temp=r*sin(a) x=temp*cos(b) y=temp*sin(b) z=r*cos(a) Le compilateur ne fait pas lélimination dexpression avec appel de fonction

93 14 Janvier 2002 CIMENT – MIRAGE Laurence Viry Déplacement de code DO I=1,N A(I)=A(I)/ SQRT(X*X+Y*Y) ENDDO Devient TEMP=1./SQRT(X*X+Y*Y) DO I=1,N A(I)=A(I)*TEMP ENDDO


Télécharger ppt "Analyse et Optimisation de code Principes généraux Processeur Alpha – Tru64 Unix."

Présentations similaires


Annonces Google