Parall´elisation de l’inf´erence de domaines prot´eiques.
Cl´ ement Rezvoy
2005-2006
Diplˆ ome pr´ epar´ e : M2 Approches Math´ ematiques et Informatiques du Vivant
Laboratoires d’accueil : Laboratoire de l’Informatique du Parall´ elisme
Laboratoire de Biom´ etrie et Biologie ´ Evolutive
Encadrant : Fr´ ed´ eric Vivien , Daniel Kahn .
ProDom est une base de donn´ees de familles de domaines prot´eiques construite automa- tiquement par comparaison de s´equences `a l’aide de l’algorithme MkDom2. Avec l’aug- mentation exponentielle du nombre de s´equences connues, le temps de construction de la base de donn´ees Prodom a explos´e jusqu’`a devenir impraticable (plus de deux ans de calcul `a l’heure actuelle). Cette ´etude montre qu’il est possible de r´epartir efficacement le temps de calcul de fa¸con `a permettre une acc´el´eration d’un facteur de plus de 50 et d´efinit les limites de cette parall´elisation impos´ees par la nature de l’algorithme MkDom2.
Table des mati` eres
1 Introduction 1
2 Analyse 2
2.1 L’algorithme MkDom2 . . . 2
2.2 Les principales charges de calcul . . . 3
2.3 Les strat´egies de parall´elisation envisageables . . . 4
2.3.1 Parall´elisation interne . . . 4
2.3.2 Parall´elisation externe . . . 5
2.3.3 Tentative pr´ec´edente de parall´elisation . . . 5
2.4 Cons´equences du relˆachement de l’heuristique biologique . . . 6
2.4.1 Conflits de r´esultats entre requˆetes parall`eles . . . 6
2.4.2 Pr´evoir les conflits pour les ´eviter . . . 7
2.4.3 Cons´equence de la parall´elisation sur les r´esultats . . . 8
2.5 Les limitations informatiques . . . 8
2.5.1 L’´equilibrage de charge entre travailleurs . . . 9
2.5.2 Gestion de l’h´et´erog´en´eit´e de la plate-forme . . . 10
2.5.3 L’´equilibrage de charge maˆıtre-travailleurs . . . 11
2.6 Les optimisations possibles . . . 12
2.6.1 Un meilleur usage des ressources . . . 12
2.6.2 Eviter les requˆ´ etes orphelines . . . 13
3 Impl´ementation et test de la solution 14 3.1 L’algorithme distribu´e MPI MkDom2 . . . 14
3.1.1 Principe g´en´eral . . . 14
3.1.2 Cr´eations des lots de s´equences requˆetes . . . 15
3.1.3 Gestion des relations d’adjacence entre s´equences . . . 15
3.1.4 Organisation et traitement des r´esultats . . . 16
3.1.5 Diff´erences d’impl´ementation entre MkDom2 et MPI MkDom2 . . 16
3.2 Tests . . . 17
3.2.1 Efficacit´e de la parall´elisation . . . 17
3.2.2 Am´eliorations lin´eaires . . . 18
3.2.3 Utilisation des processeurs . . . 18
3.2.4 Effet de la d´esynchronisation maˆıtre-travailleurs . . . 18
3.2.5 Effets de la parall´elisation sur les r´esultats . . . 18
4 Discussion 20
4.1 La pr´ediction des conflits s’av`ere efficace . . . 20
4.2 Efficacit´e des diff´erentes optimisations . . . 20
4.3 Equilibrage de charge . . . .´ 21
4.4 Limites du mod`ele maˆıtre-travailleurs . . . 21 4.5 Comparaison de l’impl´ementation parall`ele et de l’impl´ementation s´equentielle 21
5 Conclusions et perspectives 22
1 Introduction
De nombreuses prot´eines sont constitu´ees d’un arrangement d’unit´es structurales ind´e- pendantes et ´evolutivement conserv´ees appel´ees(( modules)) [1] ou(( domaines))[2]. Des domaines similaires peuvent se retrouver au sein de plusieurs prot´eines. Ces domaines si- milaires (on parlera de famille ou decluster de domaines) ont souvent des caract´eristiques fonctionnelles communes, ou adoptent des structures secondaires ou tertiaires voisines [1].
Dans le cadre de l’´etude des prot´eines, de leurs m´ecanismes ´evolutifs ou de leurs fonc- tions, il est souvent n´ecessaire de pouvoir connaˆıtre la structuration en domaines d’une prot´eine.
Plusieurs solutions ont ´et´e propos´ees pour permettre l’identification et la classifica- tion de ces domaines. Ces m´ethodes se diff´erencient par les donn´ees d’entr´ee qu’elles n´ecessitent ainsi que par leur degr´e d’automatisation. SCOP [3] et CATH [4] inf`erent et classifient les domaines en se basant sur la conformation tridimensionnelle des prot´eines.
SCOP est construite suivant une approche manuelle tandis que la construction de CATH est partiellement automatis´ee. Les m´ethodes exp´erimentales permettant d’obtenir la struc- ture 3D d’une prot´eine restent encore `a l’heure actuelle complexes et coˆuteuses. Les m´ethodes de s´equen¸cage au contraire ont connu au cours des ann´ees 90 une v´eritable in- dustrialisation qui a rendu disponible une grande quantit´e d’information. De nombreuses m´ethodes ont ´et´e d´evelopp´ees pour inf´erer le d´ecoupage des domaines ainsi que leur clas- sification en exploitant ces donn´ees de s´equences ; plusieurs bases de donn´ees comme Pfam [5], ou SMART [6] sont ainsi construites manuellement par des experts `a l’aide d’outils de comparaison de s´equences et offrent une information de haute qualit´e. Avec l’augmentation exponentielle du nombre de s´equences connues, les m´ethodes manuelles ou mˆeme semi-automatiques sont cependant vou´ees `a ne traiter qu’une faible partie des donn´ees disponibles. Un traitement exhaustif et non biais´e de l’ensemble des s´equences prot´eiques passe forc´ement par une approche automatique. C’est dans ce but que la base de donn´ees ProDom [7] a ´et´e cr´e´ee. ProDom est une base de donn´ees de familles de do- maines prot´eiques construite automatiquement `a partir des s´equences r´epertori´ees dans la base de donn´ees de s´equences prot´eiques Uniprot [8]. Les familles de domaines prot´eiques contenues dans ProDom sont inf´er´ees par comparaison de s´equences par l’algorithme s´e- quentiel MkDom2 [9]. La complexit´e de cet algorithme est Θ(n2) o`u n est le nombre de s´equences `a traiter ; le temps de calcul quadruple donc quand la quantit´e de donn´ees `a traiter double. Avec l’augmentation exponentielle du nombre de s´equences r´epertori´ees dans les banques, et malgr´e l’´evolution constante de la puissance des processeurs, le temps de calcul des versions successives de ProDom a augment´e constamment, jusqu’`a devenir prohibitif. La version 2005.1 actuellement en ligne a ´et´e calcul´ee en 6 mois `a partir de
1 067 651 s´equences. Le calcul de la version 2006.1 devant lui succ´eder a ´et´e lanc´e en Mai 2006 sur 2 001 128 s´equences, ce calcul est toujours en cours. Dans cette perspective, le calcul d’une version 2007 de ProDom prendrait plus de 2 ans.
Il apparaˆıt donc aujourd’hui impossible d’assurer la mise `a jour de ProDom `a l’aide de cet algorithme s´equentiel. L’augmentation exponentielle de la cadence des processeurs n’a pas r´eussi `a maintenir le temps de calcul de ProDom `a un niveau raisonnable. Qui plus est, cette course au m´egahertz s’est aujourd’hui ralentie ; l’augmentation de la puissance de calcul passe d´esormais par l’accr´etion de plusieurs cœurs au sein d’une mˆeme puce, de plusieurs processeurs au sein d’une machine, de plusieurs machines dans une grappe voir mˆeme de plusieurs grappes pour former une grille de calcul. Afin de pouvoir tirer parti de ces ressources, l’algorithme MkDom2 doit au pr´ealable ˆetre modifi´e de fa¸con `a pouvoir ˆ
etre ex´ecut´e en parall`ele sur plusieurs machines. Ces modifications doivent cependant ˆ
etre r´ealis´ees avec le souci double d’utiliser au mieux des ressources distribu´ees tout en modifiant le moins possible les heuristiques biologiques de l’algorithme s´equentiel original.
2 Analyse
2.1 L’algorithme MkDom2
L’algorithme MkDom2 est bas´e sur l’heuristique suivante : la s´equence prot´eique la plus courte d’un ensemble de s´equences, ou son unit´e de r´ep´etition si elle pr´esente des r´ep´etitions internes, est une s´equence mono-domaine [9]. Plus le jeu de s´equences est grand plus cette hypoth`ese a de chances d’ˆetre v´erifi´ee. L’algorithme MkDom2 est un algorithme glouton qui r´ep`ete les op´erations suivantes jusqu’`a ce que la totalit´e des donn´ees d’entr´ee ait ´et´e ´epuis´ee (voir Fig. 1) :
1. Les s´equences de moins de 20 r´esidus sont ´elimin´ees, elles sont consid´er´ees trop petites pour constituer un domaine.
2. La plus courte s´equence du jeu de donn´ees est s´electionn´ee et on v´erifie si elle contient des r´ep´etitions internes. Cette s´equence, ou sa plus petite r´ep´etition interne, est consid´er´ee comme ´etant un domaine.
3. Une recherche d’homologies sur l’ensemble du jeu de donn´ees est effectu´ee `a l’aide de l’algorithme PSI-BLAST [10] en prenant comme requˆete ce premier domaine.
4. Les r´esultats de plus de 20 r´esidus ainsi que la requˆete sont consid´er´es comme des domaines constituant une famille de domaines apparent´es. Ces domaines sont alors retir´es du jeu de donn´ees.
(a) (b)
Fig. 1 – Sch´ema d´etaillant le fonctionnement de l’algorithme MkDom2 (a) et illustration de son fonctionnement sur deux it´erations (b) [9].
2.2 Les principales charges de calcul
Dans son impl´ementation actuelle, MkDom2 consiste en un script Perl faisant appel
`
a des programmes externes de la suite ncbi BLAST [10]. L’´etude du comportement de MkDom2 (Fig. 2) montre que la sous-routine SYSTEM est la plus coˆuteuse en temps de calcul. SYSTEM est une fonction utilitaire charg´ee d’appeler les ex´ecutables externes. Le script en lui mˆeme ne repr´esente donc en fait qu’une faible partie du temps de calcul, devenant de plus en plus n´egligeable avec l’augmentation de la taille des donn´ees.
Les deux sous-routines les plus coˆuteuses apr`es SYSTEM sont PsiBlast et Upda- teDB. PsiBlast est charg´ee de la recherche d’homologies et fait appel au programme blastpgp via la fonction SYSTEM. UpdateDB effectue la mise `a jour de la base de donn´ees entre deux requˆetes. Elle fait notamment appel, via la fonction SYSTEM, au programme formatdb dont le rˆole est de formater la base de donn´ees en amont de la recherche BLAST. C’est donc sur ces deux parties de l’algorithme que les efforts de pa- rall´elisation devront ˆetre port´es en priorit´e.
0100002000030000400005000060000
Database size (kAA)
Temps d'exécution (s)
477 2449 4893 12268
sous−routines SYSTEM PsiBlast UpdateDB HSPDejaReporte NormalEndBlast
Fig. 2 – Somme des temps d’ex´ecution des appels aux 5 sous-routines les plus coˆuteuses de MkDom2 en fonction de la taille de la base de donn´ees. Les bases de donn´ees ont ´et´e d´efinies comme des sous-ensembles de la base SWISS-PROT. Il est `a noter que ces temps d’ex´ecution sont inclusifs (i.e., le temps de calcul d’une routine inclut ´egalement le temps de calcul de ses sous-routines).
2.3 Les strat´ egies de parall´ elisation envisageables
2.3.1 Parall´elisation interne
La structure de MkDom2 permet d’envisager deux approches diff´erentes pour distri- buer l’ex´ecution deblastpgpsur plusieurs processeurs. Une premi`ere strat´egie consiste `a r´epartir une recherche PSI-BLAST sur plusieurs processeurs. On appellera cette strat´egie parall´elisation interne car elle consiste `a parall´eliser l’int´erieur de la boucle principale de MkDom2. Cette premi`ere approche a l’avantage de ne pas modifier la structure de l’algorithme original, mais en pratique, elle n’offre pas de tr`es bonnes perspectives. La fa¸con la plus simple de mettre en pratique cette approche serait d’utiliser le m´ecanisme de multithreading interne `a blastpgp. Ce m´ecanisme permet, sur une machine `a m´emoire partag´ee, d’assigner `a chaque processeur une partie de la base de donn´ees et de faire traiter une mˆeme requˆete par tout les processeurs simultan´ement, chacun comparant la requˆete `a la partie de la base de donn´ees lui ayant ´et´e assign´ee. Une parall´elisation `a grande ´echelle implique l’utilisation d’une ou plusieurs machines `a m´emoire distribu´ee et l’utilisation d’un m´ecanisme de passage de messages entre les processeurs. L’algorithme
PSI-BLAST consiste en une succession de recherches BLAST [10]. Entre chaque recherche, la requˆete est modifi´ee pour prendre en compte les r´esultats trouv´es pr´ec´edemment et
´
elargir la recherche. Le processus it`ere jusqu’`a ce que l’ensemble des r´esultats se stabilise ou qu’un nombre maximum d’it´erations (en l’occurrence dix) soit atteint. Une ex´ecution distribu´ee de cet algorithme n´ecessiterait une synchronisation avec ´echange de donn´ees entre les diff´erentes machines entre chacune des it´erations constituant une recherche PSI- BLAST. Si les communications interviennent trop fr´equemment, repr´esenteront un coˆut trop important par rapport au coˆut d’une it´eration de PSI-BLAST. On peut noter que la suite mpiBLAST [11], qui est une tentative de parall´elisation sur machines `a m´emoire distribu´ee de BLAST, n’a pas parall´elis´e blastpgp pour des raisons similaires [12].
2.3.2 Parall´elisation externe
Une deuxi`eme approche est de lancer plusieurs recherches PSI-BLAST en parall`ele.
On appellera cette strat´egieparall´elisation externecar elle ne modifie pas l’int´erieur mˆeme de la boucle principale. Cette solution implique de modifier l’algorithme original et de s´electionner non plus seulement comme requˆete la plus petite s´equence mais les n plus petites s´equences. On assigne `a un processeur maˆıtre la charge de r´epartir les requˆetes sur les autres processeurs et de regrouper les r´esultats une fois les requˆetes trait´ees. Si cette seconde solution permet d’envisager une parall´elisation `a plus grande ´echelle, elle ne va pas cependant sans poser de probl`eme, comme nous le verrons dans le paragraphe 2.4.
2.3.3 Tentative pr´ec´edente de parall´elisation
La parall´elisation de MkDom2 a d´ej`a fait l’objet d’un stage de DEA [13] en 2004. Un algorithme parall`ele avait ´et´e propos´e et impl´ement´e suivant la deuxi`eme approche mais Le coˆut de la parall´elisation s’´etait r´ev´el´e trop important, l’algorithme parall`ele allant jusqu’`a 50% plus lentement que MkDom2 sur un seul processeur. L’algorithme parall`ele pr´esentait ´egalement des difficult´es de passage `a l’´echelle, l’ex´ecution sur 5 processeurs al- lant plus lentement que l’ex´ecution sur 4 processeurs.Par rapport `a la version s´equentielle initiale, lors de ce stage le temps avait ´et´e diminu´e au mieux de 40% lors de l’ex´ecution sur une machine distribu´ee Les conclusions de ce DEA furent que pour ˆetre efficace la parall´elisation devrait utiliser des machines `a m´emoire partag´ee pour ´eviter le surcoˆut li´e aux communications r´eseaux. L’utilisation d’une machine `a m´emoire partag´ee per- mettrait en effet de limiter le coˆut de la parall´elisation et de simplifier sa mise en place, elle en limiterait cependant ´egalement les b´en´efices. Les machines `a m´emoire partag´ee ne regroupent que quelques dizaines de processeurs. En concevant un algorithme pour machines `a m´emoire distribu´ee, on peut esp´erer ex´ecuter cet algorithme sur plusieurs cen-
taines de processeurs simultan´ement, si l’on utilise par exemple les nœuds d’une grappe ou d’une grille de calcul. Il est par ailleurs plus simple d’adapter un algorithme distribu´e
`
a une ex´ecution locale que l’inverse. Une parall´elisation distribu´ee avec passage de mes- sages entre les diff´erents processeurs peut cependant s’av´erer plus compliqu´ee `a mettre en place. Il existe dans le cas pr´esent plusieurs points qui peuvent poser probl`eme dans le cadre de cette parall´elisation : certains sont li´es `a la s´emantique de l’algorithme, d’autres sont des probl`emes d’ordre informatique li´es `a l’impl´ementation de l’algorithme.
2.4 Cons´ equences du relˆ achement de l’heuristique biologique
L’ex´ecution en parall`ele implique une modification de l’heuristique fondamentale de MkDom2. Au lieu de consid´erer uniquement la plus courte s´equence du jeu de donn´ees comme un domaine, on consid´erera plusieurs s´equences simultan´ement comme des do- maines potentiels. Ce changement permet l’occurrence de situations nouvelles que l’al- gorithme devra g´erer et peut amener `a des diff´erences entre les r´esultats de l’algorithme parall`ele et ceux de l’algorithme s´equentiel.
2.4.1 Conflits de r´esultats entre requˆetes parall`eles
Dans son principe MkDom2 est fortement s´equentiel puisqu’il n´ecessite que les can- didats soit trait´es les uns apr`es les autres par ordre de taille croissante. Ceci pose deux probl`emes lorsqu’on veut calculer plusieurs requˆetes simultan´ement. Avec plusieurs re- quˆetes trait´ees en parall`ele, il est possible que deux requˆetes aient des r´esultats qui se chevauchent (voir illustration Fig. 3). Dans ce cas l`a, l’arbitrage est de donner la priorit´e
`
a la s´equence qui aurait ´et´e trait´ee en premier si l’ex´ecution avait ´et´e s´equentielle, son r´esultat est pris en compte, celui de la seconde requˆete n’est pas conserv´e, la requˆete sera recalcul´ee une fois la base de donn´ees mise `a jour et les parties conflictuelles supprim´ees.
Les conflits de ce type am`enent `a faire des calculs pour rien et donc `a un gaspillage des ressources. Si ces conflits sont fr´equents, ils auront un impact n´egatif sur l’efficacit´e de la parall´elisation. Le fichier de donn´ees de d´epart peut contenir des s´equences identiques ou proches (par exemple deux prot´eines homologues). Le tri des s´equences par ordre de taille croissante a de plus tendance `a rapprocher les s´equences similaires et par cons´equent `a augmenter la fr´equence des conflits. Dans la pr´ec´edente version parall`ele [13], l’ensemble des nœuds de travail ´etaient interrompus lorsqu’un chevauchement ´etait d´etect´e, la base de donn´ees ´etait mise `a jour et les calculs ´etaient ensuite red´emarr´es sur la nouvelle version de la base de donn´ees. Cette politique permettait de coller de tr`es pr`es au fonctionnement de MkDom2 mais rendait ´egalement les conflits coˆuteux.
Fig. 3 – Illustration d’un conflit entre deux r´esultats. Dans la version s´equentielle (`a droite), la mise `a jour entre les deux requˆetes empˆeche l’occurrence du conflit.
2.4.2 Pr´evoir les conflits pour les ´eviter
La solution choisie afin d’´eviter l’occurrence de conflits entre r´esultats de requˆetes simultan´ees est de chercher `a pr´edire les s´equences potentiellement conflictuelles `a partir du r´esultat de la comparaison de chaque s´equence du jeu de donn´ees contre l’ensemble de celui-ci. Si une homologie est trouv´ee entre deux s´equences A et B, ces deux s´equences sont consid´er´ees comme ´etant adjacentes. Elle ne pourront pas ˆetre s´electionn´ees (ni aucune sous s´equence issue de A ou de B) simultan´ement comme requˆetes. `A partir de ces relations d’adjacences entre s´equences on peut d´eterminer des jeux de requˆetes non- adjacentes pouvant ˆetre trait´ees en parall`ele. Une recherche PSI-BLAST est diff´erente d’une recherche BLAST simple et aura tendance `a avoir des r´esultats plus large. Si on est sˆur que deux requˆetes adjacentes auront des r´esultats de PSI-BLAST chevauchant, l’inverse n’est pas vrai. Il est possible que deux requˆetes non adjacentes aient des r´esultats chevauchant. Par cons´equent, un syst`eme de v´erification de l’ind´ependance des r´esultats a posteriori est n´ecessaire. Cette information sur les relations a priori doit cependant permettre de maintenir la fr´equence des conflits `a un niveau acceptable afin qu’ils ne deviennent pas un handicap pour la parall´elisation.
Cette comparaison de l’ensemble des s´equences entre elles repr´esente en soi un cal- cul coˆuteux en temps. Cependant, contrairement `a MkDom2, il est tr`es facilement pa-
rall´elisable puisque les BLAST de chacune des s´equences contre le reste de la base sont ind´ependants les uns des autres. D’autre part, ce calcul est ´egalement utilis´e pour le cal- cul d’autres bases de donn´ees comme par exemple Hogenom [14] et pourrait ˆetre `a terme mutualis´e entre les diff´erentes bases.
2.4.3 Cons´equence de la parall´elisation sur les r´esultats
Le traitement simultan´e de plusieurs requˆetes peut par ailleurs amener `a une modifica- tion des r´esultats par rapport `a la version s´equentielle. Lorsqu’une mise `a jour de la base de donn´ees retire les domaines recrut´es par une requˆete, elle peut cr´eer une nouvelle plus courte s´equence qui sera s´electionn´ee comme requˆete pour la prochaine it´eration (voir exemple Fig. 1(b)). Si plusieurs requˆetes tournent en parall`ele et qu’une nouvelle plus courte s´equence est g´en´er´ee par une de ces requˆetes, elle passera syst´ematiquement apr`es les requˆetes en cours mˆeme si, en suivant scrupuleusement l’heuristique de faire passer les s´equences par ordre de taille croissante, elle aurait dˆu les pr´ec´eder. Ces diff´erences dans l’ordre de traitements des requˆetes entraˆıneront des diff´erences au niveau des r´esultats.
Les s´equences trait´ees en parall`eles ´etant non adjacentes (voir partie 2.4.2), le r´esultat de la sous-s´equence se faisant((doubler))devrait dans la majorit´e des cas ne pas ˆetre modifi´e par cette inversion. On ne peut cependant pas exclure que le r´esultat d’une requˆete PSI- BLAST recrute, du simple fait du syst`eme de score d’alignement BLAST, certains r´esidus qui auraient dˆu, en suivant l’algorithme s´equentiel, faire partie d’une autre famille de do- maines. Si ces r´esidus sont retir´es d’un domaine d´etect´e ((de justesse))par PSI-BLAST, cela peut mˆeme entraˆıner la disparition d’un domaine complet de la famille l´es´ee. Enfin, ce chevauchement entre r´esultats peut ´egalement se produire avec une s´equence qui au- rait dˆu ˆetre une requˆete en suivant l’algorithme s´equentiel, auquel cas ce chevauchement entraˆınerai la disparition d’une famille de domaine compl`ete.
Il peut toutefois arriver dans certains cas que la version parall`ele soit plus ((juste))au sens de l’heuristique que la version s´equentielle. Si deux s´equences A et B sont trait´ees en parall`ele, A ´etant plus petite que B et que B contient une r´ep´etition interne plus petite que A, la version parall`ele pourra traiter les r´esultats de la r´ep´etition interne de B avant ceux de la s´equence A, tandis que la version s´equentielle traitera en premier lieu les r´esultats de A puis, ceux de la r´ep´etition interne de B.
2.5 Les limitations informatiques
Une solution na¨ıve pour impl´ementer la parall´elisation externe serait de d´esigner un maˆıtre qui g´en`ere un jeu de s´equences non-adjacente et envoie une requˆete issue de ce jeu
`
a chaque travailleur, attend les r´esultats, les traitent puis envoie la mise `a jour de la base
de donn´ees `a tous les travailleurs avant de recommencer. Cette solution engendrerai une utilisation inefficace des ressources de calcul et est am´eliorable sur de nombreux points.
2.5.1 L’´equilibrage de charge entre travailleurs
0 50 100 150 200 250 300 350
20406080100
Appels successifs à la sous−routine PsiBlast
Temps d'exécution (s)
(a)
0 5000 10000 15000 20000 25000
−2024
Appels successifs à la sous−routine PsiBlast
Temps d'exécution (log(s))
(b)
Fig. 4 – Temps d’ex´ecution des appels successifs `a PsiBlast pendant les 8 premi`eres heures de traitement par MkDom2 d’une base de 2 000 000 de s´equences (a), ainsi que pour l’int´egralit´e du traitement par MkDom2 d’une base de 30246 s´equences (b)
L’´etude du comportement de MkDom2 r´ev`ele ´egalement que le temps d’ex´ecution de blastpgp varier au fil des ex´ecutions (voir Fig. 4). La complexit´e en temps d’une recherche BLAST est O(mn) o`u m est la taille de la s´equence requˆete et n la taille de la base de donn´ees cible. Ce temps d´ecroˆıt donc globalement en suivant la d´ecroissance de la taille du jeu de donn´ees au fil des it´erations. Il varie ´egalement en fonction de la requˆete et du nombre de r´esultats qu’elle va engendrer. Dans le cadre de MkDom2, une recherche PSI-BLAST peut ˆetre constitu´ee de une `a dix requˆetes BLAST le nombre d’it´erations variant en fonction du nombre de r´esultats et de la rapidit´e de stabilisation du jeu de r´esultats. Il peut donc th´eoriquement y avoir un ratio de plus de 1 `a 10 entre le temps d’ex´ecution de deux requˆetes successives. Dans notre solution na¨ıve, le maˆıtre attend que tous les travailleurs aient fini de traiter leur requˆete pour poursuivre. Si sur dix travailleurs, neuf finissent de traiter leur requˆete en une seconde et que le dixi`eme met dix secondes `a traiter la sienne, on aura perdu 81% du temps processeur disponible.
Cette variabilit´e des temps d’ex´ecution, d´ependant des r´esultats de la requˆete, est par nature impr´evisible. On peut cependant chercher `a minimiser son impact : en envoyant
non plus une mais plusieurs requˆetes en mˆeme temps `a chaque travailleur, on peut esp´erer niveler les diff´erences entre travailleurs et ainsi diminuer le taux d’inutilisation des pro- cesseurs.
Cette solution laisse d’autre part le temps au maˆıtre de commencer `a calculer la mise `a jour de la base de donn´ees ainsi que de nouveaux lots de s´equences de fa¸con d´esynchronis´ee par rapport aux travailleurs, en commen¸cant ce calcul avant d’avoir re¸cu la totalit´e des r´esultats. Ces lots pr´epar´es en avance peuvent ˆetre envoy´es de fa¸con asyn- chrone aux travailleurs de fa¸con `a ce que chacun re¸coive son lots au moment ou il est pr`es, sans attendre que tous les autres travailleurs aient ´egalement fini. Ceci offre ainsi un deuxi`eme moyen permettant d’´equilibrer la charge entre les diff´erents travailleurs.
Cela permet ´egalement un recouvrement du temps de calcul du maˆıtre et des travailleurs (voir illustration Fig 5). Il faudra alors tenir compte des s´equences encore en cours de traitement lors de la s´election des requˆetes. Les s´equences devront non seulement ˆetre ind´ependantes entre elles mais ´egalement ind´ependantes des requˆetes encore en cours.
(a)
(b)
Fig.5 – Utilisation des processeurs en fonction du temps (Diagramme de Gantt) avec un maˆıtre synchrone (a) et un maˆıtre d´esynchronis´e (b). Dans le premier cas les travailleurs sont utilis´es `a 44% ; dans le deuxi`eme cas ils sont utilis´es `a 54%. Le temps total d’ex´ecution dans le deuxi`eme cas est r´eduit de 25% par rapport au premier.
2.5.2 Gestion de l’h´et´erog´en´eit´e de la plate-forme
En plus des variations de temps de traitement non-pr´evisibles entre les diff´erentes requˆetes, il existe des variations syst´ematiques plus faciles `a att´enuer. Un algorithme
distribu´e pourra ˆetre ex´ecut´e dans un environnement h´et´erog`ene de grappe ou de grille. Au sein d’un tel environnement, il n’est pas garanti que toutes les machines soient identiques, certaines pourront ˆetre plus rapides que d’autres. Il est donc n´ecessaire d’adapter la taille des lots de requˆetes `a traiter `a la capacit´e individuelle de chaque machine. Pour cela, le nœud maˆıtre devra, en pr´eambule du traitement, r´ealiser un audit de la plate-forme pour estimer la puissance de calcul de chaque nœud.
2.5.3 L’´equilibrage de charge maˆıtre-travailleurs
Il faut au maˆıtre un certain temps pour pouvoir d´efinir un nouveau jeu de requˆetes non-adjacentes. Il faut pour chaque nouvelle s´equence v´erifier son ind´ependance avec les s´equences d´ej`a s´electionn´ees. Pour que notre solution soit efficace, il faut que le maˆıtre ait le temps de calculer un nouveau jeu de s´equences non-adjacentes avant que tous les travailleurs aient fini, afin de faire attendre le moins de nœuds de travail possible. Le maˆıtre ne doit cependant pas s’arrˆeter trop tˆot car il faut que les lots de requˆetes aient une certaine taille pour assurer un bon ´equilibrage de charge. Si τ(n) est le temps n´ecessaire au maˆıtre pour trouverns´equences ind´ependantes,ρle temps moyen de traitement d’une requˆete par un processeur et ω le nombre de travailleurs, on cherchera un n v´erifiant :
τ(n)≤ ρnω
τ(n) d´epend de n. Plus il y a de s´equences dans le jeu de requˆetes non adjacentes, moins il est probable qu’une nouvelle s´equence n’ait aucun voisin dans cet ensemble et plus il faut faire de tests pour le v´erifier. Ce temps de calcul augmente donc de fa¸con sur-lin´eaire en fonction den.ρ d´epend, pour sa partie pr´evisible, de la taille de la base de donn´ees, de la taille moyenne des s´equences requˆetes ainsi que de la puissance de calcul moyenne des processeurs. Pour une taille de base de donn´ees et une taille moyenne de s´equence donn´ees, le temps de calcul des nœuds de travail augmentera de fa¸con lin´eaire avec le nombre de requˆetes. Pour une taille de base de donn´ees fix´ee il existe donc unn `a partir duquel le temps de calcul du maˆıtre d´epasse de fa¸con chronique celui des travailleurs et `a partir duquel les travailleurs devront attendre le maˆıtre `a la fin de chaque it´eration.
Le nombre de travailleurs maximum utilisable sera donc limit´e par la capacit´e du maˆıtre
`
a fournir du travail de mani`ere efficace `a tous les travailleurs. Comme la taille de la base de donn´ees d´ecroˆıt au cours de l’ex´ecution, cela implique ´egalement que n devra ´evoluer au fil du temps pour s’adapter `a l’´evolution du temps de calcul des travailleurs.
On voit qu’une charge trop importante du nœud maˆıtre peut engendrer une forte inefficacit´e. On a donc int´erˆet `a all´eger au maximum la charge de travail du maˆıtre afin de faciliter l’´equilibrage. Pour cette raison le maˆıtre devra d´el´eguer aux travailleurs, en plus du calcul proprement dit, la charge de v´erifier la pr´esence de r´ep´etitions internes
0 5000 10000 15000
0500100015002000
nombre de requêtes
Temps (s)
w=100 w=50 w=10
Fig. 6 – Illustration pour une base de donn´ees 200 000 s´equences et un temps de traitement moyen par requˆete de 2 secondes. La courbe d´enote le temps n´ecessaire au nœuds maˆıtre pour g´en´erer n s´equences ind´ependantes entre elles. Les diff´erentes droites montrent le temps n´ecessaire pour traiter ces n s´equences pour diff´erents effectifs de nœuds de travail.
dans les requˆetes qui leur sont distribu´ees. De mˆeme, on ne pourra pas avoir une base de donn´ees centralis´ee mise `a jour par le maˆıtre, il faudra que chaque noeud de travail ait une copie de la base qu’il mettra `a jour lui mˆeme. Cela entraˆıne une redondance des calculs, et notamment des appels `aformatdb, ce qui peut sembler coˆuteux. Cela ne fait cependant pas perdre de temps puisque, dans le cas d’une mise `a jour centralis´ee, les travailleurs ne peuvent rien faire et doivent attendre pendant que le maˆıtre met `a jour la base de donn´ees. Avoir une base de donn´ees par travailleur est ´egalement n´ecessaire pour permettre une d´esynchronisation des travailleurs et permettre `a ceux qui ont fini en avance de mettre `a jour leur base de donn´ees sans attendre pour pouvoir commencer `a traiter les s´equences suivantes.
2.6 Les optimisations possibles
2.6.1 Un meilleur usage des ressources
MkDom2 dans son fonctionnement utilise beaucoup le disque dur. `A chaque it´eration, le fichier de donn´ees doit ˆetre ´ecrit sur le disque pour ˆetre format´e pour la recherche
BLAST parformatdb. Une fois la recherche effectu´ee et les r´esultats trait´es, il faut relire le fichier pour retirer les morceaux faisant partie de la nouvelle famille de domaine et retrier les s´equences par ordre de taille croissante. Les op´erations sur le disque sont coˆuteuses et certaines d’entre elles peuvent ˆetre ´evit´ees. En maintenant en m´emoire l’ensemble des s´equences dans une structure de donn´ees, on ´evite d’avoir `a relire la base de donn´ees `a chaque it´eration. D’autre part, cette structure de donn´ees peut ˆetre maintenue tri´ee ce qui permet ´egalement de gagner du temps sur le tri.
Le fait d’envoyer plusieurs requˆetes `a chaque it´eration permet ´egalement de faire diminuer le nombre de mises `a jour de la base de donn´ees ; on fera moins fr´equemment de grosses mises `a jours et on diminue le nombre de r´e´ecritures de la base sur le disque.
Le regroupement des requˆetes permet ´egalement de mieux utiliser le r´eseau en ´evitant d’envoyer trop souvent des petits messages. Le coup unitaire d’un message et la latence r´eseau font qu’il est pr´ef´erable d’envoyer moins souvent des messages de plus grosse taille.
Dans un sch´ema maˆıtre-travailleurs, la position centrale du maˆıtre repr´esente un goulot d’´etranglement potentiel, il est donc important que les communications du maˆıtre aux travailleurs soient faites le plus efficacement possible.
Le fait d’avoir une base de donn´ees par travailleur (voir partie 2.5.3) et non plus une seule base de donn´ees centralis´ee comme c’´etait le cas lors du stage pr´ec´edent par exemple, peut ´egalement apporter une am´elioration dans l’utilisation des ressources. Une base de donn´ees centralis´ee doit par d´efinition ˆetre accessible par tous les nœuds et par cons´equent, r´esider sur un syst`eme de fichier sur r´eseau, typiquement une syst`eme de fichier NFS. Ces syst`emes de fichier ont une latence et des taux de transferts beaucoup plus faible que les syst`eme de fichier locaux. En r´epliquant la base de donn´ees sur tous les nœuds de travail, on peut ainsi d´econgestionner le r´eseau en ´eliminant le trafic en- gendr´e par le syst`eme de fichier NFS et am´eliorer les performances des travailleurs en leur permettant d’acc´eder plus rapidement aux donn´ees.
2.6.2 Eviter les requˆ´ etes orphelines
Une recherche PSI-BLAST commence par une recherche BLAST classique. Si cette premi`ere recherche ne g´en`ere aucun r´esultat, la recherche PSI-BLAST s’arrˆete sans it´erer.
Les s´equences n’ayant donn´e aucun r´esultat dans le tout contre tout ne donneront pas non plus de r´esultat dans la premi`ere recherche BLAST de PSI-BLAST. On peut donc d´eterminer en amont `a partir du tout contre tout les recherches qui seront forc´ement in- fructueuses. Si ces requˆetes ne peuvent pas donner de r´esultat, elle peuvent tout de mˆeme faire partie du r´esultat d’une autre requˆete, on ne peut donc pas supprimer pr´ealablement tout les s´equences non-adjacentes de la base de donn´ees. On peut cependant, lorsqu’une requˆete n’ayant aucune adjacence se pr´esente, ´eviter de lancer la recherche puisqu’on est
sˆur que cette recherche n’engendrera pas de r´esultat autre que la s´equence requˆete contre elle mˆeme.
3 Impl´ ementation et test de la solution
3.1 L’algorithme distribu´ e MPI MkDom2
3.1.1 Principe g´en´eral
Fig. 7 – Diagramme de s´equence des communications entre le maˆıtre et les travailleurs.
Apr`es avoir ´etudi´e l’algorithme MkDom2, la fa¸con dont se comportent les diff´erentes parties de cet algorithme et les diff´erentes possibilit´es pour distribuer son ex´ecution, nous proposons un nouvel algorithme (voir Fig. 7). Ce nouvel algorithme suit un sch´ema maˆıtre-travailleurs qui fonctionne de la mani`ere suivante jusqu’`a ´epuisement des donn´ees :
1. Le nœud maˆıtre s´electionne un premier jeu de s´equences ind´ependantes, il envoien requˆetes ind´ependantes `a chaque travailleur en adaptant n `a la capacit´e de calcul de chaque nœud travailleur.
2. Le maˆıtre collecte ensuite les r´esultats. `A partir d’un certain seuil sur le nombre de r´esultats re¸cu, d´efini de fa¸con `a ce que le temps de calcul du maˆıtre ne d´epasse pas celui des travailleurs, le maˆıtre commence `a mettre `a jour la base de donn´ees.
3. Les indications concernant les parties qui doivent ˆetre retir´ees de la base de donn´ees ainsi qu’un nouveau jeu de requˆetes sont calcul´es par le maˆıtre et envoy´es aux travailleurs sans attendre la r´eception de l’int´egralit´e des r´esultats, de fa¸con asyn- chrone, pour que les travailleurs ayant d´ej`a fini puissent commencer l’it´eration sui- vante.
4. Retour `a l’´etape 2.
3.1.2 Cr´eations des lots de s´equences requˆetes
La premi`ere tˆache du maˆıtre est de d´efinir un jeu de s´equences ind´ependantes entre elles et de les r´epartir sur les diff´erents nœuds de travail. Pour permettre au maˆıtre d’adapter la taille de lots de requˆetes `a la capacit´e des diff´erents nœuds, un benchmark de la plate-forme est effectu´e avant de commencer `a traiter les donn´ees. Le maˆıtre envoie cinq s´equences prises au hasard dans le jeu de donn´ees `a tous les travailleurs et les travailleurs renvoient au maˆıtre le temps qu’il leur a fallu pour traiter chacune de ces cinq s´equences. `A partir de ces r´esultats le maˆıtre d´efinit la puissance de chaque nœud de calcul proportionnellement au nœud le plus rapide et peut ensuite adapter la taille des lots de requˆetes en fonction de ces r´esultats.
3.1.3 Gestion des relations d’adjacence entre s´equences
L’information concernant les relations d’adjacence entre les s´equences du jeu de donn´ees de d´epart doivent ˆetre consult´ees par le maˆıtre `a chaque fois qu’il cr´ee de nouveaux lots de requˆetes. Pour chaque nouvelle requˆete potentielle, il faut v´erifier qu’elle n’est voisine d’aucune s´equence d´ej`a s´electionn´ee dans le jeu de requˆetes. Il faut donc que cette in- formation soit accessible rapidement, sous peine de voir le maˆıtre ralentir l’ensemble du processus. Cette information est tr`es volumineuse : pour un jeux de donn´ees de 100 M´ega- octets, les relations d’adjacence occupent plus de 350 M´ega-octets. Dans la perspective de traiter de tr`es gros jeux de donn´ees, il apparaˆıt difficile de maintenir cette informa- tion en m´emoire. L’utilisation d’un fichier texte qu’il faudrait parcourir pour v´erifier l’ind´ependance de chaque requˆete serait quant `a elle beaucoup trop p´enalisante en terme de temps d’ex´ecution.
Afin de parvenir `a un compromis entre rapidit´e et occupation m´emoire, les relations d’adjacence entre s´equences sont stock´ees sur disque dans un fichier sqlite. Un fichier sqlite[15] est un fichier binaire se comportant comme une base de donn´ees relationnelle.
Les donn´ees sont ainsi maintenues tri´ees et index´ees et sont accessibles via des requˆetes en langage SQL. Seules les relations des s´equences d´ej`a s´electionn´ees comme faisant par- ties du jeu de s´equence non-d’adjacences sont maintenues en m´emoire. Cela permet de maintenir une occupation m´emoire tr`es faible tout en limitant les acc`es au disque dur.
3.1.4 Organisation et traitement des r´esultats
Les relations d’adjacence ne garantissant pas l’ind´ependance des r´esultats, il est n´ecessaire que le maˆıtre traite les r´esultats de fa¸con `a s’assurer qu’ils sont distincts les uns des autres. Afin de pr´eserver au maximum l’heuristique s´equentielle, les r´esultats sont trait´es par ordre croissant sur la taille des requˆetes. Si le r´esultat d’une requˆete arrive et que des requˆetes plus courtes sont encore en cours de calcul, il est mis en attente jusqu’`a ce que les r´esultats des requˆetes plus courtes aient ´et´e re¸cus et trait´es. Le traitement d’un r´esultat consiste `a v´erifier qu’il n’a aucun r´esidu commun avec les r´esultats des requˆetes plus petites. Si aucun chevauchement n’est d´etect´e le r´esultat est consid´er´e valide et est
´
ecrit sur le disque. Si une intersection non vide existe entre ce r´esultat et le r´esultat d’une s´equence plus courte, On consid`ere le r´esultat comme invalide. La requˆete devra ˆetre recalcul´ee sur la prochaine version de la base de donn´ees, une fois les r´esidus conflictuels
´
elimin´es.
3.1.5 Diff´erences d’impl´ementation entre MkDom2 et MPI MkDom2
Mise `a part la parall´elisation du calcul, il existe ´egalement d’autres diff´erences d’im- pl´ementation entre MkDom2 et MPI MkDom2. Afin de r´ealiser rapidement un proto- type dont on puisse ensuite tester les performances parall`eles, certain aspects du code de MkDom2 ont ´et´e volontairement simplifi´es. Dans MkDom2, les r´ep´etitions internes sont d´etect´ees en traitant les r´esultats d’un blast de la s´equence requˆete contre elle mˆeme `a l’aide du script Perl Mkrep2, qui effectue notamment un alignement la s´equence contre elle mˆeme. La reprise du mˆeme m´ecanisme dans MPI MkDom2 aurait impliqu´e soit l’int´egration de MPI MkDom2 au sein de l’environement Xdom2 dont d´ependent Mk- Dom2 et Mkrep2, ou la r´e´ecriture compl`ete de Mkrep2 dans MPI MkDom2. Ce m´ecanisme n’a pas ´et´e repris dans MPI MkDom2. Afin cependant de ne pas biaiser le temps de calcul en d´efaveur de MkDom2, Une recherche de r´ep´etition interne simplifi´ee a ´et´e incluse dans MPI Mkdom2, reprenant notamment l’alignement de la s´equence contre elle-mˆeme. Mk- Dom2 inclut ´egalement dans sa fa¸con de traiter les r´esultats la possibilit´e qu’une requˆete
g´en`ere 2 familles disjointes, ce qui n’est pas possible avec le code parall`ele actuel. Les deux programmes diff`erent ´egalement dans les versions des ex´ecutables externes qu’ils utilisent, notamment ceux de la suite BLAST. Le code parall`ele ne reprend pas non plus pour l’instant les diff´erents m´ecanismes mis en place dans MkDom2 pour g´erer les erreurs des programmes externes.
3.2 Tests
MPI MkDom2 a ´et´e test´e sur 2 grappes de la plateforme grid5000 [16], La grappe sagittaire regroupant 70 nœuds bi-processeurs cadenc´es `a 2.4 GHz et la grappe para- quad regroupant 64 nœuds bi-processeurs bi-coeurs `a 2.3 GHz. Les tests ont ´et´e effectu´es sur deux jeux de donn´ees diff´erents. Le premier jeu correspond au prot´eome complet de Caenorabditis elegans, Ce qui repr´esente une base de donn´ees de d´epart de 22 480 s´equences soit environ 11 M´ega-octets. Le second jeux de donn´ees correspond `a l’en- semble des prot´eomes eukaryotes complets compris dans Uniprot. Ce Jeu de donn´ees regroupe 169 388 s´equences soit environ 92 M´ega-octets.
●
●
●
●
● ● ●
0 20 40 60 80
050001000015000
Nombre de processeurs travaileurs
Temps de traitement (s)
●
(a)
●●
●
●
●
●
●
0 20 40 60 80
24681012
Nombre de processeurs travaileurs
Speedup
(b)
Fig. 8 – Variation du temps de traitement du prot´eome complet de C. elegans par MPI MkDom2 en fonction du nombre de processeurs de travail (i.e., maitre exclu) (a) et acc´el´eration (b). Tests effectu´es sur les machines bi-processeurs du cluster sagittaire, (i.e., 10 processeurs = 5 travailleurs bi-processeurs). Le point plein correspond au temps de calcul de MkDom2 pour le mˆeme jeu de donn´ees, la courbe marqu´ee de ronds correspond aux ex´ecutions asynchrones et la courbe marqu´ee de triangles aux ex´ecutions synchrones.
3.2.1 Efficacit´e de la parall´elisation
Le traitement du prot´eome complet deC.elegans en faisant varier le nombre de proces- seurs (voir Fig. 8) montre que la parall´elisation permet de diviser par 14 le temps de calcul par rapport `a la pr´ec´edente version de MkDom2 en utilisant 20 nœuds bi-processeurs.
A partir de ces r´esultats, on peut d´etailler les effets de diff´erentes am´eliorations de MPI MkDom2 par rapport `a MkDom2. On voit ´egalement sur le deuxi`eme test (voir Fig. 9) que l’acceleration d´epend de la taille de la base de donn´ees et qu’une base de donn´ees plus grosse permet une plus forte acc´el´eration par rapport au temps s´equentiel.
On peut estimer l’acc´el´eration pour le traitement de ce deuxi`eme jeu de donn´ees `a au moins 50 passant d’au moins 6 jours et 8 heures `a moins de 3 heures.
3.2.2 Am´eliorations lin´eaires
Avec un seul travailleur MPI MkDom2 est plus rapide que MkDom2 d’environ 6%.
Cette am´elioration est le r´esultat de la diff´erence entre les diff´erents coˆuts qu’implique la parall´elisation (s´elections des requˆetes, transmission de messages, etc.) et les diff´erentes am´eliorations s´equentielles (diminution des acc`es disques, tri de la base de donn´ees,etc.).
L’apport du nœud maˆıtre dans ce gain est jug´ee n´egligeable, le maˆıtre ne participant pas aux calculs `a proprement parl´e et n’ayant qu’un rˆole ((administratif)).
3.2.3 Utilisation des processeurs
On observe que sur des nœuds multiprocesseurs, MkDom2 n’utilise pas l’ensemble de la puissance disponible, mˆeme en param´etrant blastpgp pour utiliser le multithreading.
Les nœuds bi-processeurs bi-cœurs par exemple sont en g´en´eral utilis´es `a 50% de leur puissance totale. Une solution pour utiliser de mani`ere plus efficace tous les processeurs d’une machine serait de lancer plusieurs processus travailleurs par nœuds. Cette solution n’est cependant pas applicable, les besoins m´emoire ´etant trop importants pour que deux travailleurs puissent r´esider en mˆeme temps en m´emoire. La cohabitation de deux pro- cessus travailleurs sur une mˆeme machine entraˆınerait une utilisation accrue du disque dur via le m´ecanisme de swap, car les besoins en m´emoire d´epasseraient la capacit´e de la m´emoire physique.
3.2.4 Effet de la d´esynchronisation maˆıtre-travailleurs
L’asynchronisme entre le maˆıtre et les travailleurs permet ´egalement de gagner en effi- cacit´e, l’ex´ecution durant jusqu’`a 20% moins longtemps sur 10 processeurs. Cet avantage ne se maintient pas quand la charge du maˆıtre augmente.
3.2.5 Effets de la parall´elisation sur les r´esultats
Les r´esultats de MPI Mkdom2 et de MkDom2 ont ´et´e compar´es pour le traitement du prot´eome deC. elegans. Les r´esultats de la version parall`ele diff`erent de ceux de la version s´equentielle. MPI MkDom2 g´en`ere moins de familles de 2 s´equences ou plus que MkDom2
●
● ● ● ● ●
0 50 100 150 200
020006000
Nombre de coeurs travaileurs
Temps de traitement (m)
(a)
●
●
●
●
●
●
0 50 100 150 200
01020304050
Nombre de coeurs travaileurs
Speedup
(b)
Fig. 9 – Variation du temps de traitement de l’ensemble des prot´eomes complets eu- karyotes de Uniprot par mpi mkdom2 en fonction du nombre de processeurs de tra- vail(i.e., maitre exclu)(a) ainsi que l’acc´el´eration correspondante (b). Tests effectu´es sur les machines bi-processeurs bi-cœurs du cluster paraquad, (i.e., 60 cœurs = 15 nœuds bi-processeurs bi-cœurs). Le temps pour le points d’abscisse 1 est un temps partiel, l’ex´ecution s’´etant arrˆet´ee sur une erreur. L’acc´el´eration est par cons´equent sous-estim´ee.
(25% de moins) et g´en`ere des familles de plus grosse taille en moyenne(6,15 s´equences par famille en moyenne contre 5,75 dans le cas de MkDom2). Parmis les familles de plus de 2 s´equences d´efinies par MkDom2, 79% trouvent un homologue dans les r´esultats de MPI MkDom2 et le recouvrement des familles d´efinies par Mkdom2 par leur homologue dans les r´esultats de MPI MkDom2 est en moyenne de 49% .
Il y a plusieurs origines vraisemblables `a ces diff´erences. Dans la version parall`ele, le code des travailleurs devrait dans l’id´eal coller scrupuleusement `a la boucle de l’algo- rithme s´equentiel MkDom2, mais ce n’est actuellement pas encore le cas. Notre prototype ce diff´erencie de MkDom2 dans la fa¸con dont ils d´etecte et appr´ehende les r´ep´etitions in- ternes ou encore dans la fa¸con dont ils r´eagit aux erreurs des programmes externes (voir partie 3.1.5). Certaines de ces diff´erences entre la version s´equentielle et la version pa- rall`ele peuvent avoir une forte influence sur le r´esultat final du fait du caract`ere it´eratif de l’algorithme. Une diff´erence de quelques r´esidus sur le r´esultat de l’une des premi`eres requˆetes aura une influence sur toutes les it´erations suivantes.
Comme ´evoqu´e pr´ec´edemment (voir partie 2.4.3) la parall´elisation modifie l’ordre dans lequel les requˆetes sont trait´ee, et par cons´equent sur les r´esultats. L’ordre des diff´erentes requˆetes peut ˆetre modifi´e localement par la fonction de tri. Dans le cas d’un ex aequo sur la taille des s´equences, l’algorithme de tri dans la version parall`ele ne proc´edera pas forcement de la mˆeme mani`ere que celui de la version s´equentielle. Ces diff´erences dans l’ordre de traitement des s´equences entraˆıneront elles aussi des modifications des r´esultats.
L’influence relative de ces diff´erents facteurs n’est pas encore ´etablie. L’´evaluation des
r´esultats de l’influence des diff´erents facteurs ainsi que les tests sur de plus gros jeux de donn´ees sont encore en cours.
4 Discussion
Apr`es avoir analys´e le fonctionnement et le comportement de MkDom2, ainsi que les diff´erentes possibilit´es permettant sa parall´elisation, nous avons d´efini un nouvel algo- rithme reprenant le principe de MkDom2 tout en permettant son ex´ecution sur une ou plusieurs machines `a m´emoire distribu´ee. Ce nouvel algorithme apporte des am´eliorations par rapport `a l’algorithme s´equentiel en permettant d’envisager de traiter des jeux de donn´ees plus importants. Il pr´esente n´eanmoins lui aussi des limitations.
4.1 La pr´ ediction des conflits s’av` ere efficace
D’un point de vue biologique, la principale diff´erence de cette tentative de para- ll´elisation avec la tentative pr´ec´edente est l’utilisation des relations d’adjacence entre s´equences pour pr´evoir et ´eviter les r´esultats parall`eles se chevauchant. Pour le traitement du prot´eome deC.elegans, le nombre de ces conflits repr´esente 1% des s´equences trait´ees.
Cette approche s’av`ere efficace puisqu’elle permet de maintenir la fr´equence des conflits
`
a un niveau suffisamment faible pour qu’ils ne p´enalisent pas la parall´elisation.
4.2 Efficacit´ e des diff´ erentes optimisations
Les diff´erentes optimisations r´ealis´ees se montrent ´egalement efficaces. Elles permettent de contrebalancer les coˆuts li´es `a la parall´elisation et am`ene mˆeme une am´elioration par rapport au temps de calcul de la version s´equentielle. Il est envisageable que ces optimisa- tions, notamment celles li´ees `a l’usage des disques durs, gagnent encore en efficacit´e avec l’augmentation de la taille des jeux de donn´ees. La version parall`ele a ´et´e impl´ement´ee de fa¸con `a tirer parti au maximum des ressources disponibles sur les noeuds de calcul, les gains en performance se font au prix d’une utilisation accrue de la m´emoire vive. Cette ressource ´etant limit´ee, il est probable que une fois celle-ci ´epuis´ee l’impact de ces opti- misations diminuent `a mesure que l’usage du disque deviendra de plus en plus n´ecessaire.
A l’extrˆ` eme, cela pourra entraˆıner un swap total de la base de donn´ees entre le disque et la m´emoire `a chaque it´erations.
4.3 Equilibrage de charge ´
L’´equilibrage de charge entre le maˆıtre et les travailleurs s’av`ere ˆetre crucial pour obte- nir une bonne utilisation des ressources. Si cet ´equilibrage est fait correctement, le maˆıtre a le temps de pr´eparer l’it´eration i+ 1 pendant que les travailleurs calculent l’it´eration i. Les nœuds de travail n’ont d`es lors plus `a attendre que le maˆıtre pr´epare de nou- velles requˆetes apr`es chaque it´eration. En utilisant des communications d´esynchronis´ees, on permet ´egalement aux travailleurs de recevoir et de commencer `a traiter les requˆetes suivantes d`es qu’ils le peuvent. Cet ´equilibrage est ´etroitement conditionn´e par la taille des donn´ees `a traiter : plus la taille des donn´ees est importante, plus le maˆıtre aura de temps pendant que les travailleurs calculent pour traiter les r´esultats et pr´eparer de nou- velles requˆetes. Pour profiter pleinement de la d´esynchronisation maˆıtre-travailleurs il est pr´ef´erable de maintenir le maˆıtre `a un niveau de charge relativement bas.
4.4 Limites du mod` ele maˆıtre-travailleurs
La d´efinition de l’algorithme sur un mod`ele maˆıtre-travailleurs am`ene `a une limite sup´erieure dans le nombre de nœuds utilisables efficacement sans surcharger le maˆıtre.
De plus, Dans le cadre d’une ex´ecution `a tr`es grande ´echelle (plusieurs centaines de machines r´eparties sur plusieurs sites) le mod`ele maˆıtre-travailleurs peut devenir tr`es vite inefficace dans son utilisation du r´eseau, le maˆıtre repr´esentant un point de congestion puisqu’il est soit le destinataire soit l’exp´editeur de toutes les communications. dans le cas de MkDom2, si on veut modifier au minimum l’heuristique de d´epart, il est difficile de se passer de cette centralisation. Il est possible de repousser encore ces limitations en modifiant l´eg`erement l’impl´ementation. Par exemple en r´epartissant le travail du maˆıtre sur plusieurs processeurs, ou en organisant les communications de fa¸con hi´erarchique pour d´econgestionner le nœud maˆıtre. `A plus long terme, si le choix d’une nouvelle heuristique et la d´efinition d’un nouvel algorithme sont envisag´es, ces consid´erations informatiques devront ˆetre prises en compte.
4.5 Comparaison de l’impl´ ementation parall` ele et de l’impl´ e- mentation s´ equentielle
Au cours de cette ´etude, nous nous sommes atach´es `a r´ealiser et `a tester un prototype d’impl´ementation parall`ele de MkDom2 en nous focalisant dans un premier temps sur les aspects informatiques du probl`eme : r´epartition de la charge, usage des ressources etc.
Le prototype r´ealis´e et test´e au cours de ce stage a permis de montrer qu’il est possible d’effectuer efficacement ce calcul de fa¸con distribu´ee. Cette version parall`ele devra main-
tenant ˆetre reprise pour la rendre utilisable et y int´egrer les aspects de MkDom2 laiss´es dans un premier temps de cot´e pour les int´egrer `a MPI MkDom2 de fa¸con d’am´eliorer la qualit´e des r´esultats produits .
5 Conclusions et perspectives
L’inf´erence automatique des domaines prot´eiques est un probl`eme complexe et tr`es coˆuteux en temps de calcul. L’algorithme MkDom2 avait jusqu’ici permis d’assurer des mises `a jour r´eguli`eres de ProDom mais il se heurte `a la croissance exponentielle de la quantit´e de donn´ees `a traiter. La derni`ere version de ProDom remonte `a 2005 et il est probable que la version 2006 sera la derni`ere `a pouvoir ˆetre calcul´ee en utilisant MkDom2. ProDom est une base de donn´ees de r´ef´erence utilis´ee par de nombreux cher- cheurs `a travers le monde, notamment via son int´egration `a la m´eta-base de donn´ees Interpro [17]. L’arrˆet de la mise `a jour de ProDom signifierait l’obsolescence graduelle de son contenu, il est donc primordial pour ProDom de pouvoir continuer `a ˆetre mise `a jour r´eguli`erement, de fa¸con `a int´egrer les nouvelles donn´ees arrivant chaque jour plus nombreuses et de continuer de permettre son utilisation en conjonction avec d’autres base de donn´ees g´enomiques ou phylog´en´etiques. Ce travail montre qu’il existe des so- lutions pour r´epartir efficacement la charge de calcul d’une nouvelle version de ProDom sur plusieurs machines. Le gain permis par les diff´erentes modifications ´evoqu´ees dans ce rapport, ainsi que leurs influences relatives sur la pertinence des r´esultats restent encore
`
a d´efinir mais on peut d`es lors envisager continuer `a mettre `a jour ProDom en utilisant une version parall`ele de MkDom2. Il faut d´esormais modifier le prototype r´ealis´e au cours de ce stage et en reprenant les simplifications faites par rapport `a MkDom2 pour rendre son fonctionnement plus semblable `a celui de la version s´equentielle.
Nous avons ´egalement montr´e au cours de ce stage que MkDom2, de part sa n´ecessit´e de centralisation impose de forte contraintes limitant le passage `a l’´echelle de la pa- rall´elisation. `A moyen terme, la nature quadratique de l’algorithme associ´ee `a ce besoin intrins`eque de centralisation font que la version parall`ele atteindra elle aussi ces limites. Il est donc d`es aujourd’hui n´ecessaire de r´efl´echir `a de nouvelles approches qui permettront de calculer `a grande ´echelle la d´elimitation et la classification des domaines prot´eiques.
R´ ef´ erences
[1] R. F. Doolittle and P. Bork. Evolutionarily mobile modules in proteins. Sci Am, 269(4) :50–6, 1993.
[2] D. B. Wetlaufer. Nucleation, rapid folding, and globular intrachain regions in pro- teins. Proc Natl Acad Sci U S A, 70(3) :697–701, 1973.
[3] A. G. Murzin, S. E. Brenner, T. Hubbard, and C. Chothia. SCOP : a structural classification of proteins database for the investigation of sequences and structures.
J Mol Biol, 247(4) :536–40, 1995.
[4] C. A. Orengo, A. D. Michie, S. Jones, D. T. Jones, M. B. Swindells, and J. M.
Thornton. CATH–a hierarchic classification of protein domain structures. Structure, 5(8) :1093–108, 1997.
[5] E. L. Sonnhammer, S. R. Eddy, E. Birney, A. Bateman, and R. Durbin. Pfam : multiple sequence alignments and HMM-profiles of protein domains. Nucleic Acids Res, 26(1) :320–2, 1998.
[6] J. Schultz, R. R. Copley, T. Doerks, C. P. Ponting, and P. Bork. SMART : a web-based tool for the study of genetically mobile domains. Nucleic Acids Res, 28(1) :231–4, 2000.
[7] E. L. Sonnhammer and D. Kahn. Modular arrangement of proteins as inferred from analysis of homology. Protein Sci, 3(3) :482–92, 1994.
[8] C. H. Wu, R. Apweiler, A. Bairoch, D. A. Natale, W. C. Barker, B. Boeckmann, S. Ferro, E. Gasteiger, H. Huang, R. Lopez, M. Magrane, M. J. Martin, R. Ma- zumder, C. O’Donovan, N. Redaschi, and B. Suzek. The Universal Protein Resource (UniProt) : an expanding universe of protein information. Nucleic Acids Res, 34(Da- tabase issue) :D187–91, 2006.
[9] J. Gouzy, F. Corpet, and D. Kahn. Whole genome protein domain analysis using a new method for domain clustering. Comput Chem, 23(3-4) :333–40, 1999.
[10] S. F. Altschul, T. L. Madden, A. A. Schaffer, J. Zhang, Z. Zhang, W. Miller, and D. J.
Lipman. Gapped BLAST and PSI-BLAST : a new generation of protein database search programs. Nucleic Acids Res, 25(17) :3389–402, 1997.
[11] A.E. Darling, L. Carey, and W. Feng. The Design, Implementation, and Evaluation of mpiBLAST. Proceedings of Cluster World Conference & Expo, 2003.
[12] http ://www.mpiblast.org/Docs.FAQ.html#other-blast, 4 June 2007.
[13] Samuel Blanquart. Extraction et Classification Parall`ele des Domaines Prot´eiques.
Master’s thesis, Universit´e de Rennes-1, 2004.
[14] http ://pbil.univ-lyon1.fr/databases/hogenom.html.
[15] http ://www.sqlite.org.
[16] https ://www.grid5000.fr/mediawiki/index.php/Grid5000 :Home.
[17] N. J. Mulder, R. Apweiler, T. K. Attwood, A. Bairoch, A. Bateman, D. Binns, P. Bork, V. Buillard, L. Cerutti, R. Copley, E. Courcelle, U. Das, L. Daugherty, M. Dibley, R. Finn, W. Fleischmann, J. Gough, D. Haft, N. Hulo, S. Hunter, D. Kahn, A. Kanapin, A. Kejariwal, A. Labarga, P. S. Langendijk-Genevaux, D. Lonsdale, R. Lopez, I. Letunic, M. Madera, J. Maslen, C. McAnulla, J. McDowall, J. Mistry, A. Mitchell, A. N. Nikolskaya, S. Orchard, C. Orengo, R. Petryszak, J. D. Selengut, C. J. Sigrist, P. D. Thomas, F. Valentin, D. Wilson, C. H. Wu, and C. Yeats. New de- velopments in the InterPro database.Nucleic Acids Res, 35(Database issue) :D224–8, 2007.
