• Aucun résultat trouvé

Instrumentation du ode soure

III.3 Instrumentation

III.3.5 Instrumentation du ode soure

L'instrumentation du ode soure onsisteà plaer, auxpointsde trae du ode du programme à observer, des appels aux fontions d'enregistrement. Pour ela, il faut disposer du ode soure du programme et être en mesure de le reompiler, e qui peut poser problème ave les appliationspropriétaires.

L'avantage majeur de l'instrumentationdu ode soure est de pouvoir aéder à toutes les informations que gère le onepteur de l'appliation.Il est ainsi possible d'enregistrer des strutures omplexesqui ne seraient pas failement interprétables àunniveauplusbas.L'instrumentationauniveau duodesourepermetégalement d'être relativement indépendant vis-à-vis de la plateforme utilisée. Il sut de res-peter lasyntaxedu langagede programmationutilisé.Lefaitde plaerles instru-tions d'enregistrement au niveau du ode soure permet d'optimiser au maximum les opérations de sauvegarde des données. Par l'utilisation de maro-ommandes ou de fontions inline on évite les oûteux hangements de ontexte. Parmi les ontraintes, ilfaut soulignerla néessité de reompiler le programme.

L'instrumentationdu ode soured'un programme peut être eetuée manuelle-mentou automatiquement.

III.3.5.1 Instrumentation automatique

Contrairement à l'instrumentation manuelle, l'instrumentation automatique se harge de parourir le ode soure d'un programme pour le réérire en y plaçant des appelsauxfontionsd'enregistrement.L'avantageest évidementd'avoirun pro-essus bien plus rapide et simple pour l'utilisateur. Les inonvénients viennent de

la manière de spéier les fontions à traer : soit on instrumente toutes les fon-tions d'un ertain type ave une énumération en intention, soit on proède à une énumération en extension. Dans le premier as, il n'est pas possible de hoisir les fontions néessitant ou non une instrumentation; dans le seond as, on revient à une énumération s'approhant de l'instrumentation manuelle, e qui en réduit l'intérêt.

III.3.5.2 Instrumentation manuelle

L'instrumentationmanuelle oreune plus grandeliberté d'ationà l'utilisateur. Il lui est possible de plaer des points de trae il le désire et d'adapter les pa-ramètres enregistrés sans être dépendant d'unoutil d'instrumentationautomatique plus rigide. L'instrumentation manuelle est également la plus simple à mettre en ÷uvre puisque 'est à l'utilisateur de plaer dans son ode lesappels auxfontions d'enregistrement. Il doit éventuellement spéier les arguments des fontions pour sauverlesparamètres qu'ildésire. L'inonvénient de l'instrumentationmanuelle est d'être fastidieuse sile ode est omplexe.

L'utilisateur plae dans son ode une instrutiondu type:

...

ode utilisateur

FONCTION_D_ENREGISTREMENT (Variable1, Variable2, Variable3); ode utilisateur

...

Chaquefontiond'enregistrementdoitévidementêtreimplantéepourenregistrer orretementlesparamètres.Unefoisompiléetliéàlabibliothèquedefontionsde traçage, l'exéution du programme engendre leshiers de traes. En ontrepartie, il peut être fastidieux d'instrumenter un ode dont onn'a pas lamaîtrise.

Une approhe intéressante est de fournir des outils d'aide à l'instrumentation, par exemple, via une interfae graphique ahant le ode du programme. L'utili-sateur séletionne un point de trae etun type d'événement. L'insertion de l'appel de fontion est automatique, et il ne lui reste plus qu'à dénir les paramètres à enregistrer.

III.4 Fontions d'enregistrement

Les méanismes d'enregistrement font appel à des tehniques onnues pour ré-duire lessuroûts engendrés.Ces suroûts sontessentiellementdus autemps

d'exé-ution du ode du méanisme d'enregistrement, et au temps passé dans des appels bloquants pour l'enregistrementsur disque.

III.4.1 Rle des fontions d'enregistrement

Lors du traçageévénementiel, lesfontionsd'enregistrement sonthargéesde ré-upérerlesdonnéesutilesàlareonstitutiondudéroulementduprogrammeobservé. Pour ela, il faut enregistrer pour haque événement sadate, son lieu d'ourrene et les informationsassoiées. Le prinipe généralement utilisé est de plaer es in-formations dans des tampons mémoire avant de les enregistrer sur un support de stokage loalou distant.

III.4.2 Eaité de l'enregistrement

An de limiter l'intrusion due à l'observation, il est important de minimiser le oûtdesfontionsdetraeetdesméanismesd'enregistrementdedonnées.Les prin-ipales auses de perturbation viennent du bloage des proessus lors de l'ériture des donnéesréoltées etdessuroûts de hangementde ontextelorsdes appelsaux fontions d'enregistrement.

Pour limiterlesbloagesinhérentsauxéritures sur disque,il estlassique d'uti-liserdes tampons mémoire (buer)dans lesquels sontenregistréeslesdonnées avant leur ériture. On diminue ainsi lesoûts d'enregistrement superus dus à l'ériture de petites quantités de données. Dans un environnement multi-thread, il est né-essaire de protéger par un verrou l'aès au tampon dans lequel les données sont érites pour éviter des aès onurrents et des éritures inohérentes. Cette ma-nièrede proéderpose desérieux problèmesde performane arlenombrede opies de données peut être important et entraîner des bloages fréquents de threads, e qui perturbetrès fortementleomportementdu programme.Pour éviter ela, nous utilisons un tampon mémoire par thread, e qui permet d'éviter l'utilisation d'un verrou.

Pour limiter le suroût d'appel des fontions d'enregistrement, nous utilisons des maro-ommandes. Chaque fontion d'enregistrement est dénie omme une maro-ommande. Celle-i est expansée avant la ompilation par le préproesseur pour produireleode néessaireàl'enregistrementaux emplaementsdes pointsde trae. On éviteainsi un appelde fontionet leoût des hangements de ontexte.

La mise en ÷uvre de es méanismes est lassique et eetive dans tous les programmes d'enregistrement de données. Il est ependant déliat de rendre es méanismes exibles ar l'utilisation de branhements onditionnels risque de ré-introduire lessuroûts qu'on a herhé à éliminer.

III.4.3 Ativation / désativation du traçage

Quandoninstrumenteleode soure,ilest parfois utileounéessairede désati-ver dénitivementoutemporairement letraçage. Sil'utilisateur désireeetuer des mesures de performane par d'autres méthodes que letraçage, ilfaut supprimer les perturbationsimputablesautraçage.Ilest égalementourantdenevouloirobserver qu'une partie d'un programme; il faut pour ela pouvoir désativer une partie des fontions d'enregistrement.

Traditionnellement,ilestpossiblededésativerlessystèmesdetraçageàplusieurs moments:

À la ompilation par des diretives de ompilation ela onsiste à inlure le ode àl'intérieur de diretivesde ompilation onditionnelles:

#ifdef USE_TRACER

... ode pour l'enregistrement ... #endif

On élimineainsitotalementlessuroûts liésautraçagesil'évaluationdeladiretive de ompilationest négative.Ilest parontre néessaire dereompiler leprogramme observé.

À l'exéution Cela onsiste à plaer le ode de prise de trae à l'intérieur d'un test :

if (UseTraer)

{ ... ode pour l'enregistrement ...}

Il n'est alors pas néessaire de reompiler le programme. Le hoix d'enregistrer ou non peut être préisé au lanement du programme ou même durant l'exéution. Même ave lestraesdésativées, ilresteleoûtde l'appelautest. Bienqueelui-i soitfaible,ilpeutêtredetropdansleasdeprogrammesherhantuneperformane maximale.

La solution que nous avons adoptée est un mélange des tehniques préédentes. nous ombinons les méthodes par diretive de ompilation etde test à l'exéution. L'instrumentation d'un événement a laformesuivante :

#ifdef USE_TRACER // test à la ompilation NOM_MACRO (parametres) // maro d'enregistrement #endif

La maro NOM_MACRO orrespond à l'enregistrement d'un événement préalablement déni. Elleest dénie de la manièresuivante :

#define NOM_MACRO(parametres)\

if(!( TRACER_msk || NOM_NIVEAU_msk || NOM_MACRO_msk))\ {

enregistrement(parametres); }

La maroest expansée en un test ontrlantl'appel àla fontion d'enregistrement. Le test est eetué sur une ombinaison de masques. Chaun des trois masques permet de désativer les points de trae d'un événement partiulier, de tout un niveau ou de la totalité des points de trae. Les niveaux permettent de grouper de manière logique un ensemble d'événements (voir setion VI.2). Le oût du test existe toujours (quelques instrutions),mais il est bien inférieur à elui d'un appel de fontion (hangement de ontexte).

Il est, de ette manière, possible de supprimer totalement les points de trae à la ompilation à l'aide des diretives de ompilation. Il est également possible de désativer l'enregistrement des données à l'exéution en positionnant de manière adéquate les masques orrespondants. Ce système de masques permet un ontrle très n des événements dont l'enregistrement doit être désativé.

III.5 Conlusion

Au regarddes ontraintes liées àl'observationpourledébogagede performanes des intergiielsdéveloppésaulaboratoireID-Imag,nousavons hoiside nous baser sur l'observation omportementale qui, seule, permet une ompréhension ne du déroulement d'un programme parallèle. Le but est d'identier les auses de baisse deperformane,lesonditionsdanslesquellesellesseproduisentetlesraisonsdeleur apparition.Andegarantirunmaximumde souplessed'utilisation,nousavons basé nostravauxsurletraçagelogiielpourlaolletededonnéesetsurl'instrumentation manuelle du ode soure. Nous laissons ainsi le ontrle total des points de trae auxutilisateurs. Les utilisateursétant prinipalementlesonepteurs d'intergiiels, ils sont les plus aptes àeetuer l'instrumentationde leur ode.

Nous allons voir au hapitre suivant omment peuvent être exploitées les infor-mationsolletées auours du traçage.

Interprétation des observations

IV

L'interprétation n'a pas plus à être vraie quefausse; elleaà être juste. Jaques Laan C'est à la leture de Freud...

La ollete des informations relatives au déroulement d'un programme est la première phase du proessus d'observation. Il faut ensuite pouvoir les exploiter ef-aement. Notre objetif est l'élimination des problèmes de oneption entraînant des baisses de performane. Nous herhons à fournir des outils d'aide à leur iden-tiation puis àleur éradiation.

Certains outils (Kojak [MW03, Koj03℄, DeepStart [RM02℄) reherhent automa-tiquement lessituationssuseptibles de relever de problèmes de performane. Pour que des erreurspuissent ainsi êtredétetées, ilfaut qu'ellessuivent un motifonnu. Il n'est don possible de reonnaître et d'analyser automatiquement que des types de problèmes onnus et formalisés. Pour es raisons, nous préférons nous orienter vers une aide à la détetion de es erreurs. Nous ne herhons pas à automatiser la détetion des erreurs, mais àguider l'utilisateur dans l'analyse des problèmes de performane par une représentation adéquate du omportementdu programme.

Les représentations possibles des données enregistrées au ours de l'exéution sont nombreuses :textuelles,graphiques en 2ou3dimensions, sonoresouen réalité virtuelle. Chaune de es méthodes présente des avantagesetdes inonvénients que nous allonsexposer. Nousallonsauparavantexpliiterlerledes outilsde représen-tation ainsi que lesaratéristiques prinipales quenous herhons àdévelopper.

IV.1 Rle des outils de représentation

Par dénition, dans un programme parallèle,ontrairement à un programme sé-quentiel oùles instrutionss'exéutentles unesà lasuitedes autres,des opérations sont eetuées simultanément. Cela pose non seulement des problèmes relatifs à la programmationmais aussi àla représentation du déroulement du programme.

ations sesont déroulées.

Il est diiled'interpréter olletivementun très grand nombred'informations fournies sous formetextuelle. Une représentation textuelle sera réservée à des tehniques d'analyse.

Il estimportantde pouvoirmettreen orrespondane l'ourrened'un événe-mentave saou ses auses. Cela peut être diile en raison du grand nombre de ots d'exéution simultanés.

C'est pour es raisons que la plupart des logiiels d'observation orent une re-présentation graphique du déroulement d'un programme permettant de fournir une vision ompréhensible du grand nombre de données générées. Ces représentations graphiques jouent sur des variations de formes, de tailles et de ouleurs d'objets géométriques pour orir le maximum d'informations à l'utilisateur sous la forme la plus simple à omprendre possible. Le but de es outils n'est pas de mettre en évidene des phénomènes onnus, mais de failiter la reherhe de omportements pathologiques [Mil93℄.

Touslesmodes dereprésentation poursuivent lesdeux objetifsantagonistes sui-vants : maximiser la quantité d'informations exposées tout en simpliant la om-préhension de l'ensemble des données. L'utilisation d'outils de représentation de données a divers objetifs. Leur rle et leur fontionnement sont souvent liés à la méthode de ollete de données utilisée. Une ollete d'informations eetuée par prolagefournitune représentationglobale dudéroulementdu programmeobservé. De telles informations peuvent eaement aider à identier les zones les pro-grammes onsomment du temps,qui sont don a optimiseren priorité.Le traçage, quantàlui,permetlareprésentationomplète du omportementde l'appliation.Il est possiblede distinguer lesdiérentes phases d'ativitédu programme etainsi de mieux omprendre lamanière dont se déroulel'appliation.

La visualisationnous intéresseprinipalementdans leadre de l'optimisationde performanes. Les prinipaux problèmes viennent des interations entre proessus dont on ne peut que diilement prévoir ave exatitude les évolutions. Les dif-férents modes de présentation liés à une observation détaillée herhent à failiter la ompréhension des interations entre les proessus onurrents. Il est évidement possible d'utiliser des outils d'observation pour le débogage pour la orretion. La représentation d'une exéution permet en eet de oneptualiser plus aisément la manière dont s'exéute un programme et don de voir peuvent apparaître des problèmes d'ordre fontionnel (inter-bloage, attente d'un proessus ou ommuni-ationsanormales, et.).Connaissantela, ilest plus aisé de orrigerleséventuelles erreurs de programmation.

de données IV.2

IV.2 Caratéristiques des tehniques de représentation de données

An de remplir leur rle, les outils de représentation doivent satisfaire ertains ritères permettant une bonne exploitation des données. Il est souhaitable que les outilsorentlemaximumdeesritères, maisilestsouventdiiledelesombiner. Nous présentons iiquatre aratéristiques quinous paraissent fondamentales.

IV.2.1 Salabilité

Pour un programme de alul hautes performanes, la salabilité est la a-paité à tirer pleinement parti des ressoures qu'on lui alloue. Pour un outil d'ob-servation, ette propriété signie que l'outil est apte à traiter de grosses quantités de données issues d'un grand nombre de n÷uds de alul et ela sur une longue durée d'exéution. Un outil parfaitement salable, aura le même omportement pour l'observationd'une exéutionsur un petit nombre de n÷uds quesur un grand nombre.

On peut distinguer deux aspets de lasalabilitéd'un outilde représentation de données :elui liéàl'eaitédu logiiel,eteluiliéà lamanièrede représenter les informations.

L'eaité du logiiel est importante pour permettre une utilisation interative et onfortable. Si les opérations d'ahage prennent un temps prohibitif, il sera extrêmement malaiséd'utiliser l'outil.

Pour la représentation, la salabilité résulte de la apaité à présenter les informations d'une manière ompréhensible par l'utilisateur quel que soit le temps d'exéution et le nombre de n÷uds de alul ou de proessus impliqués dans la trae. An de parvenir à e résultat, les outils d'observation doivent utiliser des méanismes pour limiter la quantité de données présentées. Il ne faut en eet pas surharger l'utilisateur d'informations . L'ahage doit ependant rester pertinent et reéter ou donneraès auxinformationsimportantes. Nousverrons àlasetion V.2.3 quelques tehniques utiliséespour favoriser la salabilité.

IV.2.2 Interativité

Lesinterationspossiblesentre un utilisateuretunoutilde présentation permet-tantdemodierleomportementdeelui-ietdenaviguerautraversdesdonnées

présentées onstituent un aspet importantde la reherhe de problèmes de perfor-mane. Pouvoir par exemple masquer une partie des informations non pertinentes permet de larier une représentation. Obtenir une représentation sous diérentes vues des mêmes informations permet souvent de mieux omprendre les situations auxquelles l'utilisateur est onfronté.

Laplupartdes outilsdisposantd'unereprésentation graphiqueorentdes méa-nismes permettant d'obtenir des informationsdétaillées sur un objet ouune repré-sentation diérente (histogramme, diagramme irulaire ou enore diagramme de Gantt)des données.

Si les méanismes de modiation néessitent une re-onguration ou une ré-initialisationdu logiielde présentation,leonfortd'utilisationestfortementréduit. Ilfautquel'outildeprésentationsoitinteratifetquesonfontionnementsoitleplus intuitifpossiblepourquel'utilisateurnesoitpasontraintàunmodede fontionne-ment rigide.L'introdutionde l'interativitédans les outils néessite une attention partiulière lors de leur implantation. Comme es outils sont amenés à traiter de grandes quantités de données, il faut utiliser des algorithmes et des strutures de données eaes pour assurer une bonne réativité.

IV.2.3 Observation multi-niveaux

La plupart des appliations, aussi bien séquentielles que parallèles, se basent sur unempilementdeouhes d'abstration logiiellespourfailiterlaoneptionet favoriserlaréutilisationduode.Pourunprogrammeparallèle,onpeuttypiquement énumérerles ouhes suivantes :

système d'exploitation;

ouhe de gestion de proessus légers; bibliothèque de ommuniation optimisée; langagede programmationparallèle; appliation.

Les performanes des appliations parallèles dépendent d'un grand nombre de fateurs logiiels et matériels. S'il est diile de proter de la puissane des ar-hitetures parallèles,ela est en partie à la grande omplexité des interations entre les diérentes ouhes logiielles et le matériel. Il est don important de dis-poser d'informations relatives àhaune de es ouhes logiiellespour orrélerdes données issues de niveaux diérents. Cela permet de mieux omprendre les auses d'unproblèmeoulesonséquenesd'uneation[Ott01℄.Pourrendreomptedu fon-tionnement d'une appliation onçue sur la base de telles ouhes, il faut pouvoir eetuer une observation multi-niveaux. Le prinipe est de présenter à l'utilisateur des représentations simultanées issues de diérents niveaux d'abstration.

de données IV.2

trouver les auses des problèmes de performane dans la struture du programme (taille des travauxtrop petite par rapport auoût des ommuniations ou simulta-néité des envoisà tous leseslaves). Une fois es auses déterminées, il est possible de tenter de les élimineren établissant une politique de distribution du travailplus adaptée.

Pour fournir une visualisation des diérents niveaux d'abstration, il faut na-turellement disposer d'informations les onernant. Il existe un grand nombre de systèmes pour aquérir desinformationsde haque niveaupossible,du registre pro-esseur aulangagede hautniveauen passantpar lesinterfaesdes bibliothèques de programmation:

auniveaumatériel:registredu proesseur, informationsde débitsur les inter-faes réseau Papi [Sey01℄,Vtune [VTu03 ℄;

au niveau du système d'exploitation: /pro,ganglia[Mas ℄, Bwath[Rad℄, Pp [SGI℄;

au niveau des bibliothèques de ommuniation : bibliothèques instrumentées Vampir,Xmpi;

au niveau appliatif: traçagelogiiel.Tau [Mal℄,SvPablo [DZR98℄

Il est, par ontre, peu fréquent de trouver des outils orant une vue ombinée ou globale de toutes es données. Dans le as d'un programme MPI, ela onsiste par exempleàdisposer d'informationsissues dusystèmed'exploitation,des ommu-niations de la bibliothèque MPI, et de l'appliation elle-même. À l'aide de toutes es informations, on peut être à même de déterminer plus aisément les soures de problèmes potentiels.Vampir[NAW

+

96℄,parexemple,permetde mixerun traçage événementiel des opérations MPI et des informations des ompteurs matériels via l'interfaePapi.

Destravauxontparexempleétéeetuéspourledéveloppementdel'observation

Documents relatifs