17-21 Octobre 2005 Formation Continue - CNRS Laurence Viry Analyse et Optimisation de code Analyse de performance

17-21 Octobre 2005 Formation Continue - CNRS Laurence Viry

Analyse et Optimisation de code

Analyse de performance

17 – 21 Octobre 2005 Formation Continue - CNRS Laurence Viry

Méthodologie conseillée

Valider le programme à optimiser

Utiliser des codes déja optimisés ou s’y ramener

Utiliser des algorithmes performants

Analyser le code, et se concentrer sur les sections critiques

Utiliser les capacités d’optimiser du compilateur

Effectuer des modifications dans le code pour optimiser les sections critiques


Compteurs HardwareCompteurs 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 d’attente d’accès mémoire Cache misses, TLB misses,… …

Fournies des informations utiles à l’explication d’un manque de performance de certaines parties de codes

Le suivi de ces événements permet d’affiner l’adaptation du code à l’architecture cible


Mesures de performance Mesure du temps

Global :User, CPU et wall ou elpased time, autres statistiques… Partie de code : appel à une fonction explicite (C, Fortran,

system…) Profiling: Analyse détaillée de performance

Nombre d’appels des procédures, temps passé dans ces procédures, graphe des appels…

Utilisation des compteurs hardware: comptage ou statistique sur des événements (nombre de floating point, caches misses, TLB misses,…)

Traçage: analyse et/ou visualisation à postériori de l’exécution d’un programme Enregistrement des informations sur des événements (caches

misses, …) par process/thread pendant l’exécution Reconstruction dynamique du comportement du programme à

partir de ces informations Nécessite l’instrumentation du code


Mesures de performance

Mesure globale du temps (autres statistiques)commande UNIX "time"

Mesure du temps d'une partie de code par une

Fonctions explicites (C et Fortran)

Analyse complète de performance du code

Outils standard de profiling: prof, gprof, pixie, …


Mesure globale du temps - time

time (commande de base UNIX/LINUX) : Temps utilisateur, temps système, elapsed ou wall

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 « floating-point

exceptions » Nombre important de "page faults" ou de

"misaligned memory access" …


Mesure globale du temps - time

Propriétés 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 …


Fonction TIME (CSH ou TCSH)

%time program

14.9u 1.4s 0:19 83% 4+1060K 27+86io 47pf+0w

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

Nombre de blocs en sortie

Fautes de pages

Nombre de swapsUser time

System time

Elapsed time


Fonctions explicites de mesure de temps

Appel explicite de sous-programmes à l'intérieur du code

Fonction system_clock(): elapsed time

Procédures de la norme Fortran90/95 (~10ms)

cpu_time() : temps CPU

date_and_time() :elapsed time

Fonction etime (non standard): temps système, utilisateur et total

Hors standard : fonctions constructeurs


Fonctions explicites de mesure de temps system_clock

Procédure system_clock: elapsed time

real :: time

integer :: debut, fin,rate

call system_clock(count=debut,count_rate=rate)

…

call system_clock(count=fin)

time= float(fin-debut)/rate


Fonctions explicites de mesure de tempsetime

Fonction etime (non standard)

real :: actual, etime, tarray(2)

actual=etime(tarray)

Avec tarray(1) : temps utilisateur

tarray(2) : temps du system

etime : temps total

Non standard


Fonction dans la norme Fortran90/95

Procédure cpu_timereal :: time_debut, time_fincall cpu_time(time_debut)…call cpu_time(time_fin)print*, "temps = ", time_fin – time_debut, "

secondes" Procédure date_and_time : elapsed 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"


Profiling

Permet de déterminer les parties de code les plus consommatrices avant le travail d’optimisation

Récupère des informations sur: Le temps, le nombre d’appels des procédure, le graphe des appels,

des statistiques sur des compteurs hardwares… Différentes granularités, fonction, boucle, bloc de base et même

ligne de code Coût de développement relativement faible Plusieurs types de profiling :

PC Sampling: interruption périodique du système ou trap des compteurs hardware. Ne nécessite en général pas de modification du code

Basic-Bloc Counting : l’unité d’analyse est le bloc de base Méthode intrusive qui consiste à insérer directement des instructions

de mesure dans le code (par le profiler ou manuellement)


Outils de profiling

Méthode non intrusives prof, gprof sur les OS UNIX/linux VPROF (http://aros.ca.sandia.gov/~cljanss/perf/vprof/) SvPablo TAU (OpenMP, MPI, MPI/OpenMP) VAMPIR / VampirTrace : MPI HPCView Dynaprof (nécessite dyninst ou DPCL) Outils constructeurs: perfex et ssrun (SGI IRIX), tprof et trace

(IBM), PAT (CRAY), histx, pfmon (Linux), Vtune (Intel), hiprof, pixie (Alpha Tru64) …

… Méthodes intrusives

PAPI: interface portable des compteurs hardware et mesure du temps


Profiling

Deux types de profiling : PC Sampling :

prof, gprof hiprof

Basic-Bloc Counting : prof, pixie

Utilisation des Compteur Hardware : PAPI

pfmon, lipfpm, histx (linux)

uprofile et kprofile (Tru64) …


Trois étapes pour le profilingprof, gprof, hiprof…

Instrumentation automatique du programme Par le compilateur (prof, gprof): -p, –pg Par le profiler (hiprof, pixie, histx…)

Exécution du programme instrumentéCrée le 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, iprep…


PC-Sampling prof

Cpu_time profiling : option –p et profiler prof

Trois étapes

% f90 <options> –p –o prog prog.f

% prog => création du fichier mon.out

% prof prog mon.out > prof.list (sortie par défaut à l'écran)


PC-Sampling gprof -hiprof

Cpu-time profiling + graphe des appels Compilateur : option –pg et profiler gprof

% f90 <options> -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 à la compilation): Compiler le programme : f90 <options> –o prog prog.f Instrumentation du programme: hiprof prog =>

prog.hiprof Exécution : ./prog.hiprof ou hiprof –run <options> prog Affichage des résultats : hiprof –run –display <options>

prog


Listing: PC-Sampling

Each sample covers 8.00 byte(s) for 4% of 0.0244 seconds %time seconds cum % cum sec procedure (file) 80.0 0.0195 80.0 0.02 square_ (matpower.f) 20.0 0.0049 100.0 0.02 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


called/total parentsindex %time self descendents called+self name index called/total children

0.00 0.02 1/1 matrixpower_ [2][1] 100.0 0.00 0.02 1 matpower_ [1] 0.02 0.00 9/9 square_ [4] 0.00 0.00 1/1 square_mult_ [5]

-----------------------------------------------

0.00 0.02 1/1 main [3][2] 100.0 0.00 0.02 1 matrixpower_ [2] 0.00 0.02 1/1 matpower_ [1]

-----------------------------------------------

PC-SAMPLING + GRAPH


granularity: each sample hit covers 8 byte(s) for 4.00% of 0.02 seconds

% cumulative self self total time seconds seconds calls ms/call ms/call name 80.0 0.02 0.02 9 2.17 2.17 square_ [4] 20.0 0.02 0.00 1 4.88 4.88 square_mult_ [5] 0.0 0.02 0.00 1 0.00 24.41 matpower_ [1] 0.0 0.02 0.00 1 0.00 24.41 matrixpower_ [2]

Index by function name

[1] matpower_ [4] square_ [2] matrixpower_ [5] square_mult_

PC-SAMPLING + GRAPH


Basic-Bloc Counting pixie,prof (Alpha – Tru64)

4 étapes

Compilation : f90 –g1 –O2 –o prog prog.f

Instrumentation: pixie <options> 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


Basic-Bloc Counting (pixie,prof)

Réduire les informations fournies -exclude <procédure>, -only <procédure>

-quit <n> : troncature du listing après n lignes


Outils d’analyse de PerformancesSGI -IRIX

speedshop (commande ssrun): localise les sections de code consommatrices de temps CPU

prof: analyse et édite les données de performance issues de Speedshop ou ssrun

dprof: échantillonne un programme et enregistre les informations concernant les accès mémoire

perfex: exécute le programme et récupère les données des compteurs hardware


Outils d’analyse de PerformancesHP/Compaq – TRU64

prof Extrait les informations produites par –p ou pixie

pixie Basic Bloc Profiler

gprof Extrait les informations produites par –pg ou hiprof

hiprof Crée un programme instrumenté pour le profing des

appels, du graphe des appels, des défauts de page,… uprofile: interface avec les coumpeurs Hardware

des processeurs Alpha


Outils d’analyse de Performances Altix350 - Linux

pfmon: analyseur de performance utilisant le Performance Monitoring Unit (PMU) de l’IA-64

profile.pl : script perl utilisant pfmon et d’autres scripts pour effectuer un profiling au niveau procédural

histx et lipfpm(SGI): outils de profiling , exploitation des compteurs de l’Itanium

Vtune: Outil Intel de monitoring de code


Analyse de performance Itanium/linux – pfmon

Outil d’analyse de performance d’un ou plusieurs processus sur un ou plusieurs processeurs Itanium sous Linux (OpenSource)

Récupère des données au niveau utilisateur et au niveau noyau

Analyse des événements issus des compteurs hardware (jusqu’à 4)

Profiling sur tous les nœuds/processeurs gérés par le système (System-Wide Profiling)

Génère un faible overhead


Itanium/linux – pfmon

Quelques options: -h : aide -e <event1,event2,…>: spécifie jusqu’à 4

événements (CPU_CYCLES par défaut) -l : liste des événements ( 475 sur Itanium2) -i <event> : fornit la description de l’événement -k : profiling au niveau du noyau --system-wide: system-wide profiling -c <range> : restreint le « system-wide profiling » à

une liste de processeurs Une seule session de profiling par CPU



Événements disponibles: pfmon –l Descrition sommaire d’un compteur:

pfmon –i <NomDuCompteur>ex: pfmon –i FE_BUBBLE_TLBMISS

Inclure le détail du temps passé dans les appels système: faire une copie dans le répertoire d’exécution du fichier /boot/System.map

Documentations: pfmon 2.0 User’s Guide:

/usr/share/doc/pfmon-2.0/pfmon_usersguide.txt Supplément Itanium et Itanium2

/usr/share/doc/pfmon-2.0/pfmon_itanium.txt/usr/share/doc/pfmon-2.0/pfmon_itanium2.txt



Evénements importants: L2_MISSES : nombre de L2 Misses L3_MISSES : nombre de L2 Misses L2DTLB_MISSES : Nombre de TLB Misses L2_OZQ_CANCELS1_BANK_CONF nombre de

conficts de cache L2 BR_MISPRED_DETAIL_ALL_WRONG_[PATH|

TARGET] : branchements mal prédits …

Exemple:% ifort –O3 –o multmat multmat.f90% pfmon –e CPU_CYCLES,L2_MISSES,L3_MISSES ./multmat


Itanium/linux – profile.pl

Script utilisant pfmon Compilation avec l’option –g profile.pl utilise dplace pour les programmes

parallèles, une sélection d’un sous ensemble de processeurs: options –K et –K

Appels aux scripts: makemap.pl : analyse.pl :

Analyse du temps passé dans les appels système: copie du fichier /boot/System.map dans le répertoire d’exécution


Analyse de performance Altix350 – histx (SGI)

Programme et liste d’outils d’analyse de performance sur Altix, développés par SGI

Compatible OpenMP et MPI

Utilisent les compteurs Hardware de l’Itanium2

Capable de suivre les enfants d’un processus (fork, thread…)

Compatible Propack 2.x :

www.sgi.com/products/evaluation/altix_histx/


Analyse de performance Altix350 – histx (SGI)

Liste des outils d’analyse de performance lipfpm: permet d’exploiter le « Performance Monitor Unit »

(PMU) intégré au processeur Itanium2 (~perfex sous IRIX) samppm: échantillonage des événements PMU à la vitesse

spécifiée dans la commande histx: Suit la trace de l’exécution d’un binaire, y compris

une commande système et dresse la liste des points de passage les plus fréquents

dumppm: convertit les fichiers binaires issus de samppm en informations humainement lisibles

iprep: interprétation des analyses de histx en mode « Instructions Pointers »

csrep : interprétation des analyses de histx en mode « Callstack»


HISTX: lipfpm Linux IPF Performance Monitor

Utilisation du cache L2 et du cache L3:

lipfpm -e L2_MISSES -e L2_REFERENCES -e L3_MISSES -e L3_REFERENCES ./a.out

lipfpm summary ====== ======= L2 Misses....................... 65 738 117 L2 References................... 9 509 187 682 L3 Misses....................... 8 967 201 L3 References................... 43 830 734


HISTX: lipfpm

utilisation du cache L2 et le Mflop :

lipfpm -e FP_OPS_RETIRED -e L2_MISSES -e L2_REFERENCES $COMMANDE

lipfpm summary

====== =======Retired FP Operations .................. 152499228284L2 Misses .............................. 3159051506Requests Made To L2 ..................... 69829240763CPU Cycles ............................. 348231157730Percentage of L2 misses .................. 0.0452397Average MFLOP/s .......................... 569.303Average MB/s requested by L2 ............. 1509.53


HISTX: lipfpm

utilisation du cache L3 et des debits des accès en mémoire

lipfpm -e FP_OPS_RETIRED -e L3_READS.DATA_READ.ALL \ -e L3_READS.DATA_READ.MISS $COMMANDE

lipfpm summary

====== =======

Retired FP Operations ....................... 152499228205

L3 Reads -- L3 Load References .............. 2499734811

L3 Reads -- L3 Load Misses .................. 1712387197

CPU Cycles .................................. 348636126093

Average MFLOP/s ............................. 568.642

Average data read MB/s requested by L3 ...... 817.303


Programme HISTX

Donne des détails : Par ligne (du code) : option -g Par fonction (du code) Par librairie Jusqu’à N niveaux d’appels de fonctions des librairies

(mode callstack) Par thread, process forké,…

Exemple :%icc –g prog.c%histx –l –o sorties_histx ./a.out%iprep sorties_histx


Mémoire virtuelle

Utilisation de la zone de swap Mémoire requise > mémoire physique de la machine Partage des ressources entre plusieurs programmes

Profiling Comparer la mémoire requise à la mémoire physique

Commande size : text, data, bss Option du compilateur sur Tru64 Unix: -V

Détails de la mémoire utilisée: bss ,data,text(bss <0 si la mémoire requise < mémoire physique de la machine)

Ne tient pas compte de la pile et du tas

Page faults: vmstat ( Berkeley S) et sar (System 5)


Page faults

Global : vmstat 5Virtual 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

4 258 131 166K 138K 14K 2M 193K 2M 0 187K 0 119 213 531 22 1 77

4 258 131 166K 138K 14K 3 17 18 0 29 0 3 115 299 50 0 50

4 258 131 166K 138K 14K 0 0 0 0 0 0 3 35 319 50 0 50

4 258 131 166K 138K 14K 0 0 0 0 0 0 2 28 294 50 0 50

Par programme / procédure: Profiler hiprof

hiprof –run –display –faults matpower


Compteur Hardwareexemple de l’OX000(SGI)

deux registres de compteur de performances

1 à 16 événements hardware par compteur

2 événements: comptage exacte plus de 2 événements: multiplexage par l’OS

sur les 2 compteurs, estimation statistique l’overflow d’un compteur provoque un “hardware

trap”

Nécessité d’une interface gérant les informations récupérées par les compteurs hardware

ssrun, perfex sur Origin 2000


Compteur Hardware EV67, EV68 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 l’OS

sur les 2 compteurs, estimation statistique l’overflow d’un compteur provoque un “hardware

trap” Dépend du type de processeur – inopérant sur EV6 Profiler uprofile


Compteur Hardware Itanium2 - Altix350

Quatre registres de compteur de performances pour compter les événements hardware (1 à 4 événements hardware par compteur)

l’overflow d’un compteur provoque un “hardware trap”

Profiler: pfmon,lipfpm, histx


Pourquoi PAPI?

Les compteurs Hardware existent sur la plupart des processeurs

Les mesures de performances associées à ces compteurs varient suivant les processeurs

Il y a très peu d’API permettant de les utiliser et elles sont souvent peu documentées instables et parfois inutilisables


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 à l’optimisation de codes

Encourager les vendeurs à standardiser les interfaces et la sémantiques des compteurs hardware


Traceanalyser – VampirTrace (4.0)

Outils d’analyse et de visualisation de performance d’un programme // MPI MPI multi threads Multithreads java

Deux composants: Trace Collector ou Vampirtrace: permet la

génération automatique de la trace d’un programme parallèle MPI

Traceanalyser ou Vampir : programme de visualisation graphique de la trace générée par Vampirtrace


Traceanalyser – VampirTrace (4.0)

Implémenté sur la plupart des plate-formes Intel Itanium, Redhat et MPI/mpich

Ia32 architecture avec LAM/MPI

Itanium-2 avec HP-UX et HP-MPI

Compaq,CRAY,Fujitsu,Hitachi,HP,IBM,NEC,SGI,Sun

Documentation sur le site de Pallas

http://www.pallas.com/products/index.htm

Documents

17-21 Octobre 2005 Formation Continue - CNRS Laurence Viry Analyse et Optimisation de code Analyse de performance