Enseignements retenus

L’´etude des biblioth`eques de communication existantes et l’analyse des raisons expliquant leur manque de performance dans un environnement multi-thread´e nous ont permis d’en retirer des enseignements. Nous voyons ici les points cl´es qu’il faut garder en tˆete lors de la conception d’une biblioth`eque de communication moderne.

Nous l’avons vu, la majorit´e des biblioth`eques de communication existantes ont ´et´e conc¸u `a une ´epoque o`u les applications m´elangeant communications et threads ´etaient tr`es peu nombreuses. L’ajout de m´ecanismes permettant de g´erer les probl`emes li´es au multi-threading dans des biblioth`eques de com-munication optimis´ees pour les environnements mono-thread´es a donn´e des r´esultats m´ediocres. Les probl´ematiques du multi-threading – que ce soit le support d’applications multi-thread´ees ou la progres-sion des communications – doivent ˆetre pris en compte d`es la conception de la biblioth`eque de com-munication faute de quoi les modifications `a apporter pour ajouter des m´ecanismes de protection des donn´ees ou de progression des communications sont trop importantes et entraˆınent une complexification du code et une d´egradation des performances.

Malgr´e les nombreux travaux ayant port´e sur les mod`eles de programmation hybrides m´elangeant pas-sage de mespas-sage et multi-threading, la plupart des biblioth`eques de communication reste peu adapt´ee `a ce type de paradigme. Les acc`es concurrents sont rarement maˆıtris´es et la progression des communications en arri`ere-plan est souvent inexistante. Par cons´equent, les applications multi-thread´ees d´eveloppent des techniques pour pallier ces manquements : thread de progression dans l’application, ajout de primi-tives de progression (MPI Test par exemple) au milieu des phases de calcul, m´ecanismes d’exclusion mutuelle prot´egeant les primitives de communication ou threads d´edi´es aux communications, etc. Bien que ces techniques permettent de contourner les limitations des biblioth`eques de communication, elles posent des probl`emes de portabilit´e : le d´eveloppement de tels m´ecanismes dans l’application n´ecessite de r´einventer la roue dans chaque application alors que leur impl´ementation dans une bi-blioth`eque de communication permettrait de disposer de m´ecanismes efficaces une fois pour toute. De plus, le d´eveloppement de ces techniques dans la biblioth`eque de communication permet de profiter de la grande connaissance du mat´eriel exploit´e, notamment des caract´eristiques de la technologie r´eseau sous-jacente. Ainsi, l’application acc´ederait `a la biblioth`eque “naturellement” : sans se soucier des acc`es concurrents et uniquement pour ´echanger des donn´ees avec les autres machines. La biblioth`eque de com-munication n’est en fait pas seulement une abstraction des interfaces r´eseau sous-jacentes, elle fournit des fonctionnalit´es n´ecessaires au bon fonctionnement des communications : progression des commu-nications, m´ecanisme d’appariement, communications collectives, etc. L’impl´ementation dans l’appli-cation de techniques palliant les manquements des biblioth`eques de communil’appli-cation pose ´egalement des probl`emes plus fonctionnels : l’ajout de threads de communication complexifie le code, l’insertion de primitives de communication dans les phases de calcul peut entraˆıner des d´efauts de cache, etc.

Une pile logicielle dans laquelle les diff´erents ´el´ements se contentent de fournir les fonctionnalit´es pour lesquelles ils ont ´et´e conc¸us – l’application traite un probl`eme, la biblioth`eque de communication g`ere les ´echanges de donn´ees par le r´eseau, etc. – permet donc de simplifier le d´eveloppement. Cela ´evite ´egalement que les d´eveloppeurs d’applications n’impl´ementent des m´ecanismes pr´eexistant de mani`ere

46 CHAPITRE 4. PROPOSITION

non-optimale. La biblioth`eque de communication a donc `a sa charge tous les aspects des communica-tions (appariement, gestion des flux de communication concurrents, progression des rendez-vous, etc.) et l’application se borne `a calculer et `a transmettre des messages en passant par la biblioth`eque de com-munication.

D’une mani`ere g´en´erale, les probl`emes rencontr´es par les biblioth`eques de communication du fait des applications multi-thread´ees sont ´etroitement li´es `a l’ordonnancement des threads. Par exemple, l’or-donnanceur joue un rˆole important dans la r´eactivit´e aux ´ev´enements r´eseau. La collaboration entre la biblioth`eque de communication et l’ordonnanceur de threads permet donc des communications plus ef-ficaces. Le fait que l’ordonnanceur connaisse parfaitement la charge des processeurs de la machine et que la biblioth`eque de communication connaisse l’´etat des cartes r´eseau permet `a cette collaboration de d´egager une vision globale du syst`eme. Grˆace `a cette vue de l’´etat g´en´eral de la machine, des strat´egies intelligentes – prenant en compte `a la fois l’utilisation des processeurs et l’´etat des r´eseaux – peuvent ˆetre d´evelopp´ees.

Chapitre 5

Pour une prise en compte des

communications dans l’ordonnancement

Sommaire

5.1 Pour une biblioth`eque de communication adapt´ee au multi-threading . . . . 48 5.1.1 D´emarche . . . . 48 5.1.2 Axes directeurs . . . . 48 5.1.3 Architecture g´en´erale . . . . 49 5.2 Int´egration des communications dans l’ordonnanceur de threads . . . . 50 5.2.1 Sous-traiter la d´etection des ´ev´enements de communication . . . . 50 5.2.2 Collaboration avec l’ordonnanceur de threads . . . . 52 5.2.3 Gestion de la r´eactivit´e sur un syst`eme charg´e . . . . 53 5.2.4 Progression des communications en arri`ere-plan . . . . 56 5.3 Gestion des flux de communication concurrents . . . . 57 5.3.1 Protection contre les acc`es concurrents . . . . 57 5.3.1.1 Verrous `a gros grain . . . . 57 5.3.1.2 Verrous `a grain fin . . . . 58 5.3.2 Attentes concurrentes . . . . 60 5.4 Traitement des communications en parall`ele . . . . 61 5.4.1 M´ecanisme d’exportation de tˆaches . . . . 62 5.4.2 D´ecomposer le traitement des communications . . . . 63 5.4.3 Utilisation de plusieurs r´eseaux simultan´ement . . . . 65 5.5 Bilan de la proposition . . . . 66

Les chapitres pr´ec´edents nous ont permis de relever les principales probl´ematiques pos´ees par les appli-cations multi-thread´ees qui utilisent des biblioth`eques de communication. Comme nous l’avons vu, les impl´ementations actuelles ne parviennent pas `a r´esoudre ces probl`emes de mani`ere satisfaisante. Nous pr´esentons donc ici les m´ecanismes cl´es que nous proposons d’utiliser pour exploiter efficacement les grappes de calcul modernes. Nous commenc¸ons par une pr´esentation de l’architecture g´en´erale avant de d´etailler les diff´erents m´ecanismes mis en œuvre.

48 CHAPITRE 5. PROPOSITION

5.1 Pour une biblioth`eque de communication adapt´ee au multi-threading

Le chapitre pr´ec´edent nous a montr´e les approches utilis´ees par les biblioth`eques de communication existantes pour g´erer les interactions entre multi-threading et communication. Nous avons tir´e des ensei-gnements de cette analyse et proposons une architecture qui soit une meilleure solution `a ces probl`emes. Nous commenc¸ons par ´enoncer les contraintes `a respecter lors de la conception d’une telle architecture. Nous montrons ensuite les axes directeurs avant de pr´esenter l’architecture g´en´erale du projet.