                 Le traitement en parallle sous Linux

  Version franaise du Parallel Processing HOWTO

  Hank Dietz

   <hankd CHEZ engr POINT uky POINT edu>

   Adaptation franaise : Dominique van den Broeck

   Relecture de la version franaise : Isabelle Hurbain

   Prparation de la publication de la v.f. : Jean-Philippe Gurard

   Version : 980105.fr.1.1

   4 septembre 2005

   +----------------------------------------------------------------+
   | Historique des versions                                        |
   |----------------------------------------------------------------|
   | Version 980105.fr.1.1       | 2005-09-04     | DV              |
   |----------------------------------------------------------------|
   | Quelques amliorations mineures de la version franaise        |
   |----------------------------------------------------------------|
   | Version 980105.fr.1.0       | 2004-09-13     | DV, IH, JPG     |
   |----------------------------------------------------------------|
   | Premire traduction franaise                                  |
   |----------------------------------------------------------------|
   | Version 980105              | 1998-01-05     | HGD             |
   |----------------------------------------------------------------|
   | Version originale                                              |
   +----------------------------------------------------------------+

   Rsum

   Le traitement en parallle ( Parallel Processing ) se rfre 
   l'ide d'acclrer l'excution d'un programme en divisant celui-ci
   en plusieurs fragments pouvant tre excuts simultanment, chacun
   sur son propre processeur, un programme excut sur N processeurs
   pouvant alors fonctionner N fois plus vite qu'il le ferait en
   utilisant un seul processeur. Ce document traite des quatre
   approches de base du traitement en parallle accessibles aux
   utilisateurs de Linux : les systmes Linux SMP, les grappes
   ( cluster ) de systmes Linux mis en rseau, l'excution en
   parallle avec utilisation des instructions multimdia (ex : MMX),
   et l'utilisation des processeurs secondaires embarqus dans une
   machine fonctionnant sous Linux.

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

   Table des matires

   1. Introduction

                1.1. Le traitement en parallle correspond-il  mes
                besoins ?

                1.2. Terminologie

                1.3. Algorithme d'exemple

                1.4. Structure du document

                1.5. Note du traducteur

   2. Linux sur SMP

                2.1. L'lectronique SMP

                2.2. Introduction  la programmation en mmoire
                partage

                2.3. bb_threads

                2.4. LinuxThreads

                2.5. La mmoire partage de System V

                2.6. Projection mmoire (Memory Map Call)

   3. Clusters de systmes Linux

                3.1. Pourquoi un cluster ?

                3.2. Le matriel rseau

                3.3. Interface Logicielle Rseau

                3.4. PVM ( Parallel Virtual Machine )

                3.5. MPI ( Message Passing Interface )

                3.6. AFAPI ( Aggregate Function API )

                3.7. Autres bibliothques de gestion de clusters

                3.8. Rfrences gnrales aux clusters

   4. SIMD Within A Register : SWAR (Ex : utilisation de MMX)

                4.1. Quels usages pour le SWAR ?

                4.2. Introduction  la programmation SWAR

                4.3. SWAR MMX sous Linux

   5. Processeurs auxiliaires des machines Linux

                5.1. Un PC Linux est une bonne station d'accueil

                5.2. Avez-vous essay le DSP ?

                5.3. Calcul  l'aide des FPGA et circuits logiques
                reconfigurables

   6. D'intrt gnral

                6.1. Compilateurs et langages de programmation

                6.2. Question de performance

                6.3. Conclusion -- C'est fini !

1. Introduction

   L'excution en parallle ( Parallel Processing ) se rapporte 
   l'ide d'acclrer l'excution d'un programme en le divisant en
   plusieurs fragments pouvant tre excuts simultanment, chacun
   sur son propre processeur. Un programme excut sur N processeurs
   pourrait alors fonctionner N fois plus vite qu'il ne le ferait en
   utilisant un seul processeur.

   Traditionnellement, les processeurs multiples sont fournis avec un
    ordinateur en parallle  spcialement conu. De ce fait, Linux
   gre dsormais les systmes SMP (souvent vendus en tant que
    serveurs ) dans lesquels plusieurs processeurs partagent le
   mme bus et la mme mmoire au sein d'un mme ordinateur. Il est
   galement possible  un groupe d'ordinateurs (par exemple un
   groupe de PC fonctionnant chacun avec Linux) d'tre interconnects
   par un rseau pour former un ensemble de traitement en parallle
   ( cluster ). La troisime alternative pour l'excution parallle
   sous Linux est l'utilisation du jeu d'instructions multimdias
   tendu (MultiMedia Extend : MMX) pour agir en parallle sur des
   vecteurs de donnes entires. Il est enfin possible d'utiliser un
   systme Linux comme  hte  hbergeant un moteur de calcul en
   parallle ddi. Toutes ces approches sont traites en dtails
   dans ce document.

  1.1. Le traitement en parallle correspond-il  mes besoins ?

   Bien que l'emploi de multiples processeurs puisse acclrer nombre
   d'oprations, la plupart des applications ne peuvent encore tirer
   profit du traitement en parallle. A la base, le traitement en
   parallle est appropri si :

     o Votre application est suffisamment paralllise pour faire bon
       usage de multiples processeurs. C'est, en partie, une question
       d'identification des diffrentes portions du programme pouvant
       tre excutes indpendamment et simultanment sur des
       processeurs spars, mais vous dcouvrirez aussi que certaines
       choses qui peuvent tre excutes en parallle ralentissent le
       traitement si elles sont excutes en parallle sur un systme
       particulier. Par exemple, un programme qui s'excute en quatre
       secondes sur une machine unique pourrait tre capable de
       n'occuper qu'une seconde du temps de chacune de quatre
       machines, mais n'apportera pourtant aucun gain de temps s'il
       faut trois secondes ou plus  ces machines pour coordonner
       leurs actions.

     o Soit l'application qui vous intresse en particulier a t
       paralllise, c'est--dire rcrite pour tirer profit du
       traitement en parallle, soit vous comptez produire au moins
       un peu de code original qui le fasse.

     o Vous tes intress par la recherche de nouvelles solutions
       impliquant un traitement en parallle, ou au moins souhaitez
       vous familiariser avec. Le traitement en parallle sous Linux
       n'est pas forcment difficile, mais ce n'est pas une notion
       familire  beaucoup d'utilisateurs, et il n'existe pas de
       livre intitul  Le Parallel Processing pour les nuls , en
       tout cas pas encore. Ce guide est un bon point de dpart, mais
       il ne contient pas l'intgralit de ce que vous devez
       connatre.

   La bonne nouvelle, c'est que si tout ce qui vient d'tre dit est
   vrai, vous dcouvrirez cependant que le traitement en parallle
   sous Linux peut apporter les performances d'un supercalculateur 
   des programmes effectuant des oprations complexes ou travaillant
   sur de trs grandes quantits de donnes. Mais en plus, cela peut
   tre fait en utilisant du matriel peu onreux et que vous
   possdez srement dj. Avec , il reste ais d'utiliser un
   systme de traitement en parallle sous Linux  d'autres choses
   lorsqu'il n'est pas en train d'accomplir un traitement en
   parallle.

   Si le traitement en parallle ne correspond pas  vos besoins,
   mais que vous souhaitez tout de mme amliorer sensiblement les
   performances de votre machine, il reste des choses que vous pouvez
   faire. Par exemple, vous pouvez amliorer les performances d'un
   programme squentiel en remplaant votre processeur par un plus
   rapide, en ajoutant de la mmoire, en remplaant un disque IDE par
   un  fast wide SCSI , et ctera. Si c'est ce qui vous intresse,
   sautez directement  la section 6.2, sinon poursuivez votre
   lecture.

  1.2. Terminologie

   Bien que le traitement en parallle ait t utilis pendant de
   nombreuses annes par de nombreux systmes, il reste tranger  la
   plupart des utilisateurs. Aussi, avant de traiter des diffrentes
   alternatives, il est important de se familiariser avec une poigne
   de termes usuels :

   SIMD :

           SIMD ( Single Instruction stream, Multiple Data stream ,
           ou  Un seul flot d'instruction, plusieurs flots de
           donnes ), fait rfrence  un modle d'excution en
           parallle dans lequel tous les processeurs traitent la
           mme opration  la fois, mais o chaque processeur est
           autoris  agir sur sa propre donne. Ce modle convient
           naturellement au concept o l'on applique le mme
           traitement sur chaque lment d'un tableau, et est ainsi
           souvent associ  la manipulation de vecteurs ou de
           tableaux. Toutes les oprations tant implicitement
           synchronises, les interactions entre processeurs SIMD
           tendent  tre facilement et efficacement mises en uvre.

   MIMD :

           MIMD ( Multiple Instruction stream, Multiple Data
           stream , ou  Plusieurs flots d'instructions, plusieurs
           flots de donnes ), se rapporte au modle d'excution en
           parallle dans lequel chaque processeur agit
           essentiellement seul. C'est le modle qui convient le
           mieux  la dcomposition d'un programme pour une excution
           en parallle sur une base fonctionnelle. Par exemple, une
           processeur peut mettre  jour une base de donnes pendant
           qu'un autre produit l'affichage graphique de la nouvelle
           entre. C'est un modle plus flexible que l'excution en
           SIMD, mais qui s'accomplit au risque d'un cauchemar pour
           le dbogueur, les  race conditions  ou  accs
           concurrents , dans lesquels un programme peut planter de
           faon intermittente  cause des diffrences de minutage
           entre les oprations des diffrents processeurs lorsque
           celles d'un de ces processeurs sont rorganises en
           fonction de celles d'un autre.

   SPMD :

           SPMD ( Single Program, Multiple Data ), ou  Un seul
           programme, plusieurs donnes , est une version restreinte
           du MIMD dans laquelle tous les processeurs excutent le
           mme programme. Contrairement au SIMD, chaque processeur
           peut suivre un chemin diffrent dans le programme.

   Bande passante :

           La bande passante ( bandwidth ) d'un systme de
           communication correspond  la quantit maximum de donnes
           que l'on peut transmettre en une unit de temps... une
           fois que la transmission de donnes a commenc. La bande
           passante des connexions srie est souvent mesure en bauds
           ou en bits par seconde (b/s), ce qui correspond en gnral
            huit fois ou dix fois le nombre d'octets par secondes
           (O/s ou B/s, B =  Byte  =  Octet ). Par exemple, un
           modem  1200 bauds (N.D.T. : comme celui du Minitel) peut
           transfrer environ 120 octets  la seconde (B/s), tandis
           qu'une connexion rseau ATM  155 Mb/s est environ 130 000
           fois plus rapide, en transfrant environ 17 Mo/s. Une
           bande passante leve permet un transfert efficace de
           larges blocs de donnes entre processeurs.

   Latence :

           La latence d'un systme de communication reprsente le
           temps minimum ncessaire pour la transmission d'un objet,
           en incluant toutes les donnes  forfaitaires 
           logicielles pour l'mission et la rception
           ( overhead ). Le temps de latence est trs important
           dans les traitements en parallle car il dtermine la
           granularit, la dure minimum d'excution d'un segment de
           code pour gagner en vitesse d'excution grce au
           traitement en parallle. Concrtement, si un segment de
           code s'excute en moins de temps qu'il n'en faut pour
           transmettre son rsultat (ce dlai-ci formant la latence),
           excuter ce segment en srie plutt qu'en parallle sera
           plus rapide puisqu'il n'y aura pas de dlai de
           transmission.

   Envoi de messages ( Message passing ) :

           Les envois de message sont un modle d'interaction entre
           les diffrents processeurs d'un systme parallle. En
           gnral, un message est construit logiciellement sur un
           processeur et envoy via une interconnexion rseau  un
           autre processeur. Bien que le surcot en temps
           ( overhead ) engendr par la gestion de chaque message
           (ce dlai formant la latence) soit lev, typiquement, il
           n'y a que peu de restrictions quant  la quantit
           d'informations que ce message peut contenir. Ainsi,
           l'envoi de messages peut assurer une bande passante leve
           en apportant une mthode efficace pour transmettre de
           grandes quantits d'informations d'un processeur  un
           autre. En revanche, afin de rduire les besoins en
           coteuses oprations d'envoi de message, les structures de
           donnes  l'intrieur d'un programme doivent tre
           rparties  travers tous les processeurs de faon  ce que
           la plupart des donnes rfrences par chaque processeur
           se trouve dans sa mmoire locale... Cette tche porte le
           nom de  rpartition des donnes  ( data layout ).

   Mmoire partage :

           La mmoire partage est elle aussi un modle d'interaction
           entre les processeurs d'un systme parallle. Les systmes
           comme les machines biprocesseurs Pentium faisant
           fonctionner Linux partagent physiquement la mme mmoire
           entre tous leurs processeurs, si bien qu'une valeur crite
           par un processeur est directement accessible par un autre
           processeur. A l'inverse, la mmoire partage logiquement
           peut tre implmente sur les systmes o chaque
           processeur dispose d'une mmoire qui lui est propre, en
           convertissant chaque rfrence  une zone non locale de la
           mmoire en une communication inter-processeur approprie.
           Cette implmentation de la mmoire partage est
           gnralement considre comme tant plus facile  utiliser
           que les files de messages. La mmoire partage
           physiquement peut prsenter  la fois une bande passante
           leve et des temps de latence trs bas, mais seulement
           lorsque les diffrents processeurs n'essaient pas
           d'accder au bus simultanment. Ainsi, le modle de
           rpartition des donnes peut avoir une srieuse influence
           sur les performances, et les effets de cache et autres
           peuvent rendre trs difficile la dtermination du meilleur
           modle.

   Fonctions d'agrgation (Aggregate Functions) :

           Dans le modle des files de messages comme dans celui de
           la mmoire partage, une communication est initie par un
           processeur seul. Par contraste, une fonction d'agrgation
           est un modle implicitement parallle dans lequel tous les
           processeurs d'un groupe agissent ensemble. Le cas le plus
           simple est celui des barrires de synchronisation, dans
           lequel chaque processeur se met en attente jusqu' ce que
           le groupe entier ait atteint la barrire. Si chaque
           processeur met une donne en atteignant une barrire, il
           est possible de demander  l'lectronique responsable des
           communications d'mettre en retour une valeur  chaque
           processeur, valeur qui pourrait tre fonction des donnes
           collectes sur tous les processeurs. Par exemple, la
           valeur de retour pourrait tre la rponse  la question
            Est-ce qu'un processeur a trouv la rponse ?  ou
           pourrait tre la somme d'une valeur propre  chaque
           processeur. Les temps de latence peuvent tre bas, mais la
           bande passante a tendance  tre basse elle aussi.
           Traditionnellement, ce modle est surtout utilis pour
           contrler l'excution en parallle, plutt que pour
           distribuer les donnes.

   Communication collective :

           C'est un autre nom pour les fonctions d'agrgation,
           utilis le plus souvent en rfrence  celles qui sont
           construites en utilisant de multiples oprations d'envoi
           de message.

   SMP :

           SMP ( Symmetric Multi-Processor ) se rapporte au concept
           d'un groupe de processeurs travaillant ensemble en tant
           qu'homologues, si bien que chaque partie d'un travail peut
           tre effectue de la mme faon par n'importe quel
           processeur de ce groupe. Typiquement, le SMP implique la
           combinaison du MIMD et de la mmoire partage. Dans
           l'univers IA32, SMP signifie souvent  compatible MPS 
           ( Intel MultiProcessor Specification ).  l'avenir, cela
           pourrait signifier  Slot 2 ...

   SWAR :

           SWAR ( SIMD Within A Register , ou  SIMD  l'intrieur
           d'un registre ) est un terme gnrique qui dsigne le
           concept consistant  partitionner un registre en plusieurs
           champs entiers et  effectuer des oprations sur toute la
           largeur du registre pour faire du calcul en parallle SIMD
           sur tous les champs  la fois. En considrant une machine
           avec des registres longs de k bits (et donc autant pour
           les chemins de donnes, et les units des fonctions), on
           sait depuis longtemps que les oprations sur les registres
           ordinaires peuvent fonctionner comme des oprations
           parallle SIMD sur n champs de k/n bits. Bien que ce type
           de paralllisme puisse tre mis en uvre en utilisant les
           registres entiers et les instructions ordinaires,
           plusieurs modles rcents de microprocesseurs intgrent
           des instructions spcialises pour amliorer les
           performances de cette technique pour des tches orientes
           multimdia. En plus du MMX ( MultiMedia eXtension )
           d'Intel/AMD/Cyrix, il existe : MAX ( MultimediA
           eXtension ) sur l'Alpha de Digital, MAX ( Multimedia
           Acceleration eXtension ) sur le PA-RISC de
           Hewlett-Packard, MDMX ( Digital Media eXtension ,
           prononc  Mad Max ) sur MIPS, et VIS ( Visual
           Instruction Set ) sur le SPARC V9 de Sun. En dehors des
           trois constructeurs qui ont adopt le MMX, tous ces jeux
           d'instructions sont comparables, mais incompatibles entre
           eux.

   Processeur auxiliaires, ddis. ( Attached Processors ) :

           Les processeurs auxiliaires sont essentiellement des
           calculateurs ddis  une tche particulire, relis  un
           systme hte et servant  acclrer certains types de
           calculs. Par exemple, de nombreuses cartes vido et son
           pour PC embarquent des processeurs ddis conus pour
           acclrer respectivement les oprations graphiques et le
           DSP audio (DSP :  Digital Signal Processing , soit
            Traitement Numrique du Signal ). Il existe aussi une
           large varit de processeurs de tableaux ( array
           processors ), nomms ainsi car ils sont conus pour
           acclrer les oprations arithmtiques sur les tableaux. 
           dire vrai, un certain nombre de supercalculateurs
           commerciaux sont en ralit forms de processeurs ddis
           rattachs  des stations de travail htes.

   RAID :

           RAID ( Redundant Array of Inexpensive Disks , soit
            Batterie Redondante de Disques Peu Coteux ) est une
           technologie simple servant  amliorer tant la bande
           passante que la fiabilit des accs disque. Mme si le
           RAID se dcline en plusieurs variantes, toutes ont en
           commun deux concepts-cls : D'abord, chaque bloc de
           donnes est dcoup en segments distribus  un groupe de
           n+k disques de faon  ce que chaque disque n'ait  lire
           que 1/nime de la donne... offrant ainsi n fois la bande
           passante d'un seul disque. Ensuite, des donnes
           redondantes sont crites pour que les donnes puissent
           tre recouvres si un des disques vient  dfaillir. C'est
           important car autrement, si l'un des n+k disques tombait
           en panne, le systme de fichiers entier pourrait tre
           perdu. Il existe une bonne prsentation du systme RAID
           sur http://www.dpt.com/uraiddoc.html
           [http://www.dpt.com/uraiddoc.html], ainsi que des
           informations concernant le RAID pour Linux sur
           http://linas.org/linux/raid.html
           [http://linas.org/linux/raid.html]. Hormis la prise en
           charge du matriel RAID spcialis, Linux gre aussi le
           RAID logiciel 0, 1, 4 et 5  travers plusieurs disques
           hbergs sur un systme Linux unique. Reportez-vous aux
           Software RAID mini-HOWTO et Multi-Disk System Tuning
           mini-HOWTO pour plus de dtails. Le RAID au travers de
           plusieurs disques sur plusieurs machines en clusters n'est
           pas directement pris en charge.

   IA32 :

           L'IA32 ( Intel Architecture , 32 bits) n'a rien  voir
           avec le traitement en parallle, mais se rfre  la
           classe de processeurs dont les instructions sont
           compatibles avec celles de l'Intel 386. Concrtement, tout
           processeur Intel x86 aprs le 286 est compatible avec le
           modle de mmoire   plat^[1]  qui caractrise l'IA32.
           AMD et Cyrix font eux aussi une multitude de processeurs
           compatibles IA32. Comme Linux a volu principalement sur
           des processeurs IA32 et que c'est l qu'est centr le
           march de la grande consommation, il est commode
           d'utiliser le terme IA32 pour distinguer ce type de
           processeur des PowerPC, Alpha, PA-RISC, MIPS, SPARC, et
           ctera. La future IA64 (64 bits avec EPIC,  Explicitly
           Parallel Instruction Computing ) va certainement
           compliquer les choses, mais la production de Merced, le
           premier processeur IA64, n'est pas envisage avant 1999.

   Produits du commerce :

           Depuis la mort de plusieurs fabricants de
           supercalculateurs en parallle, les solutions commerciales
           toutes faites et prtes  l'emploi (en anglais
            Commercial Off-The-Shelf  ou COTS, pour  disponibles
           en rayons ) sont couramment considres comme une
           ncessit dans le monde des systmes de calcul en
           parallle. En tant totalement puriste, les seuls moyens
           de traitement en parallle disponibles sous forme de
           produits du commerce utilisant des PC sont des choses
           comme les serveurs Windows NT en SMP et les diffrentes
           applications Windows utilisant le MMX. tre aussi puriste
           ne mne  rien. L'ide fondamentale de l'utilisation de
           produits du commerce est de rduire les cots et les temps
           de dveloppement. Ainsi, une manire plus complte et plus
           utile de comprendre l'utilisation de ce type de produit
           serait de dire que la plupart des sous-systmes tirent
           profit du march de masse mais que d'autres technologies
           sont utilises l o elles servent vraiment. Le plus
           souvent, les produits du commerce pour le traitement en
           parallle sont utiliss au sein d'un groupe de machines
           ( cluster ) dans lequel les postes sont des PC courants,
           mais dont l'interface rseau et les logiciels ont t
           quelque peu personnaliss... classiquement, fonctionnant
           sous Linux avec des applications dont le code source est
           libre et disponible (par exemple sous copyleft ou dans le
           domaine public), mais pas littralement des produits du
           commerce.

  1.3. Algorithme d'exemple

   Afin de bien comprendre l'usage des diffrentes approches de
   programmation en parallle mises en vidence dans ce guide, il est
   utile d'tudier cet exemple. Bien qu'un algorithme simple de
   traitement en parallle et suffi, si l'on en choisit un qui a
   dj t utilis pour faire la dmonstration d'autres systmes de
   programmation parallle, il devient un peu plus facile de comparer
   et mettre en vidence les caractristiques de ces diffrentes
   approches. le livre de M. J. Quinn, Parallel Computing Theory And
   Practice ( Thorie et Pratique du Calcul en Parallle ), seconde
   dition, dit par McGraw Hill, New York en 1994, utilise un
   algorithme parallle qui calcule la valeur de Pi pour prsenter
   diffrents environnements de programmation sur supercalculateurs
   parallles (par exemple, le message passing du nCube ou la mmoire
   partage des Sequent). Dans ce guide, nous utiliserons le mme
   algorithme.

   Cet algorithme calcule la valeur approche de Pi en faisant la
   somme de l'aire situe sous x au carr. En tant que programme C
   purement squentiel, l'algorithme ressemble  :

 #include <stdlib.h>
 #include <stdio.h>

 main(int argc, char **argv)
 {
   register double largeur, somme;
   register int intervalles, i;

   /* Lit le nombre d'intervalles dsir */
   intervalles = atoi(argv[1]);
   largeur = 1.0 / intervalles;

   /* fait le calcul */
   somme = 0;
   for (i=0; i<intervalles; ++i) {
     register double x = (i + 0.5) * largeur;
     somme += 4.0 / (1.0 + x * x);
   }
   somme *= largeur;

   printf("Estimation de la valeur de pi: %f\n", somme);

   return(0);
 }

   En revanche, cet algorithme squentiel conduit facilement  une
   implmentation  parallle et embarrassante . L'aire est
   subdivise en intervalles, et un nombre quelconque de processeurs
   peut faire la somme de l'intervalle qui lui est assign
   indpendamment des autres, sans ncessit d'interaction entre les
   processeurs. Une fois que les sommes locales ont toutes t
   calcules, elles sont additionnes pour former la somme globale.
   Cette tape requiert un certain niveau de coordination et de
   communication entre les diffrents processeurs. Enfin, cette somme
   globale est renvoye  l'cran par un seul processeur, en tant que
   valeur approximative de Pi.

   Dans ce guide, les diffrentes implmentations parallles de cet
   algorithme apparaissent l ou les diffrentes mthodes de
   programmation sont traites.

  1.4. Structure du document

   Le reste de ce document est divis en cinq parties. Les sections
   2, 3, 4 et 5 correspondent aux trois diffrents types de
   configuration matrielle pouvant assumer le traitement en
   parallle en utilisant Linux.

     o La section 2 traite des systmes Linux sur SMP, lesquels
       prennent directement en charge l'excution MIMD en utilisant
       la mmoire partage, mme si les files de messages sont
       facilement mises en place, elles aussi. Bien que Linux sache
       grer les configurations SMP jusqu' 16 processeurs, la
       plupart des ordinateurs SMP de type PC sont dots soit de
       deux, soit de quatre processeurs identiques.

     o La section 3 traite des batteries d'ordinateurs en rseau
       ( clusters ), chaque machine fonctionnant sous Linux. Un
       cluster peut tre utilis comme un systme de traitement en
       parallle grant directement l'excution en MIMD et l'change
       de messages, et peut-tre mme aussi la mmoire partage
       logique. L'excution SIMD simule et la communication des
       fonctions d'agrgation peuvent aussi tre prises en charge,
       selon le rseau exploit. Le nombre de processeurs compris
       dans un cluster peut s'tendre de deux  plusieurs milliers,
       la principale limitation tant le cblage physique du rseau.
       Dans certains cas, des machines de diffrents types peuvent
       tre mlanges au sein d'un cluster. Par exemple, un rseau
       qui combinerait des Alpha DEC et des Pentium sous Linux serait
       appel cluster htrogne.

     o La section 4 traite du SWAR, le  SIMD dans un registre .
       C'est une forme trs restrictive d'excution en parallle,
       mais d'un autre cot, c'est une possibilit intgre aux
       processeurs ordinaires. Ces derniers temps, les extensions MMX
       et autres des processeurs modernes ont rendu cette approche
       encore plus efficace.

     o La section 5 traite de l'utilisation de PC sous Linux comme
       htes pour des systmes de calcul parallle simples. Sous
       forme de carte d'extension ou de botiers externes, les
       processeurs auxiliaires peuvent apporter  des systmes Linux
       une formidable puissance de traitement pour des applications
       spcifiques. Par exemple, des cartes ISA disponibles  peu de
       frais fournissent de multiples processeurs DSP, offrant
       plusieurs centaines de MgaFLOP aux calculs de grande
       envergure. En revanche, ces cartes ne sont que des
       processeurs. Elle n'embarquent gnralement pas de systme
       d'exploitation, de disque dur, ou de connecteur pour terminal
       de contrle, et ctera. Pour rendre ces systmes exploitables,
       l' hte  Linux doit fournir ces facilits.

   La section finale de ce document couvre les aspects d'intrt
   gnral concernant le traitement en parallle sous Linux, non
   spcifique  l'une des approches listes ci-dessus.

   En lisant ce document, gardez  l'esprit que nous n'avons pas tout
   test, et que beaucoup de choses rapportes dans ce document ont
   toujours  un caractre exprimental  (une jolie manire de dire
   que cela ne fonctionne pas tout  fait comme espr ;-) ). Cela
   dit, le traitement en parallle sous Linux est dsormais
   exploitable, et un groupe incroyablement vaste de personnes
   travaille  le rendre encore meilleur.

   L'auteur de la version originale de ce guide est le Dr (Ph.D) Hank
   Dietz, actuellement Professeur Associ de l'Electrical and
   Computer Engineering  l'universit de Purdue, West Lafayette, IN,
   47907-1285. Dietz est propritaire des droits sur ce document,
   conformment aux rgles du Linux Documentation Project (LDP). Bien
   qu'un effort ait t fait pour assurer l'exactitude de cette
   prsentation, ni Dietz ni l'Universit de Purdue ne peuvent tre
   tenus responsables d'ventuels problmes ou erreurs, et
   l'Universit de Purdue n'endosse la responsabilit d'aucun produit
   ou travaux traits dans ce document.

  1.5. Note du traducteur

   Chers lecteurs, avant de poursuivre la lecture de ce guide, il est
   important de revenir, notament au vu de la date de publication de
   cette version franaise, sur plusieurs points :

     o Le Professeur Henry G. Dietz (dit  Hank ), aprs avoir
       enseign plusieurs annes  l'Universit de Purdue et y avoir
       dvelopp la plupart de ce qui forme ce document, mne
       aujourd'hui ses recherches  l'Universit du Kentucky. Son
       site personnel se trouve dsormais ici:
       http://aggregate.org/hankd/ [http://aggregate.org/hankd/].
       Cela signifie galement que la plupart des rfrences 
       l'Universit de Purdue sont dsormais caduques. Toutefois, un
       certain nombre de ces rfrences ont t conserves en l'tat
       dans ce guide, ce lorsque le contenu rfrenc tait toujours
       disponible sur le site de l'Universit sans avoir t
       transfr vers le nouveau site. En tout tat de cause,
       dirigez-vous en priorit sur le site de l'Universit du
       Kentucky pour tout contact ou pour obtenir les informations
       les plus rcentes.

     o La totalit des termes, notament techniques, employs dans ce
       documents ont t traduits en franais,  quelques exceptions
       prs. C'est par exemple le cas du mot  cluster , qui dsigne
       en informatique la mise en parallle de plusieurs machines
       individuelles et coordonnes de manire  les faire agir comme
       un seul super-ordinateur. Le terme franais homologue est
        grappe . Toutefois, la frquence  laquelle ce mot est
       employ tant dans ce document (un chapitre entier est consacr
        ce sujet prcis) que dans la communaut du traitement en
       parallle en gnral est telle que le terme original a t
       conserv dans la prsente version franaise. Dans le mme
       esprit, la notion de  bande passante  se retrouve trs
       frquement tout au long de ce guide. C'est  la base un abus
       de langage, mais la popularit de cette formule est galement
       suffisament grande pour la conserver en l'tat.

     o La version originale de ce document a t crite en 1998, la
       version franaise est parue en 2004. Il va sans dire qu'au
       cours d'une aussi longue priode, le paysage informatique a
       beaucoup volu, spcialement en ce qui concerne le
       dveloppement du noyau Linux. Certaines technologies rseau
       (telles que ATM, FireWire, ou Fiber Channel) ou de clustering
       (comme MOSIX), recenses comme indisponibles en 1998, ont
       depuis intgr le noyau, ou sont devenues disponibles. En
       revanche, il est trs peu probable qu'une technologie connue
       pour fonctionner sous Linux lors de la rdaction de ce
       document soit devenue inutilisable depuis.

     o Plus encore que celui de l'industrie informatique, le paysage
       du World Wide Web s'est transform de faon  rendre la
       plupart des liens proposs obsoltes. Un effort a t fait
       pour assurer leur mise  jour ou leur remplacement, ainsi que
       la pertinence de leur contenu. En dpit de cela, un certain
       nombre d'entre eux, en particulier ceux dont les projets
       taient hbergs sur les pages personnelles d'tudiants de
       grandes coles, n'ont pu tre corrigs et ont t retirs du
       document.

   Malgr toutes ces rserves, les techniques couvertes par ce
   document sont suffisament gnrales pour rester valables au cours
   du temps et au travers des diffrents modles de machines, et son
   contenu prsente toujours un intrt  la fois pdagogique et
   historique, qui restera encore longtemps profitable au lecteur.
   Tout ceci justifie une publication mme tardive.

   Enfin, le traducteur s'est efforc de rendre le prsent document
   aussi correct et fidle  son original que possible, mais n'est
   pas infaillible. Tout signalement d'un contresens, d'une erreur
   technique, ou tout autre dfaut de traduction sera apprci  sa
   juste valeur  l'adresse suivante : <dvandenbroeck CHEZ free POINT
   fr>.

   Bonne lecture !

2. Linux sur SMP

   Ce document donne un bref aperu de la manire dont on utilise le
   SMP sous Linux [http://www.linux.org.uk/SMP/title.html] pour le
   traitement en parallle. L'information la plus  jour concernant
   le SMP sous Linux est fort probablement disponible via la liste de
   diffusion du SMP Linux Project (N.D.T. : en anglais). Envoyez un
   courrier lectronique  <majordomo CHEZ vger POINT rutgers POINT
   edu> avec le texte subscribe linux-smp pour rejoindre la liste.

   Le SMP sous Linux fonctionne-t-il vraiment ? En juin 1996, j'ai
   fait l'achat d'un bi-Pentium 100MHz flambant neuf. Le systme
   complet et assembl, comprenant les deux processeurs, la
   carte-mre Asus, 256 kilo-octets de mmoire cache, 32 mga-octets
   de RAM, le disque dur d'1.6 giga-octet, le lecteur de CD-ROM 6X,
   une carte Stealth 64 et un moniteur 15'' Acer m'a cot 1800
   dollars. Cela ne fait que quelques centaines de dollars de plus
   qu'un systme monoprocesseur. Pour faire fonctionner le SMP sous
   Linux, il a suffi d'installer le Linux monoprocesseur d'origine,
   de recompiler le noyau en dcommentant la ligne SMP=1 dans le
   Makefile (bien que je trouve le fait de mettre SMP  1 un peu
   ironique ! ;-) ), et d'informer lilo de l'existence du nouveau
   noyau. Ce systme prsente une stabilit et des performances
   suffisamment bonnes pour qu'il me serve depuis de station de
   travail principale. Pour rsumer, le SMP sous Linux, a
   fonctionne !

   La question qui se prsente alors est : existe-t-il suffisamment
   d'API de haut niveau permettant d'crire et d'excuter des
   programmes en parallle et utilisant la mmoire partage sous
   Linux SMP ? Courant 1996, il n'y en avait pas beaucoup. Les choses
   ont chang. Par exemple, il existe dsormais une bibliothque
   POSIX de gestion des threads^[2] trs complte.

   Bien que les performances soient moins leves que celles des
   mcanismes de mmoire partage natifs, un systme Linux sur SMP
   peut aussi utiliser la plupart des logiciels de traitement en
   parallle initialement dvelopps pour des clusters de stations de
   travail en utilisant la communication par socket. Les sockets
   (voir section 3.3) fonctionnent  l'intrieur d'une machine en
   SMP, et mme dans un cluster de machines SMP relies en rseau.
   Cependant, les sockets engendrent beaucoup de pertes en temps
   inutiles pour du SMP. Cela complique le problme car Linux SMP
   n'autorise en gnral qu'un seul processeur  la fois  se trouver
   dans le noyau et le contrleur d'interruption est rgl de faon 
   ce que seul le processeur de boot^[3] puisse traiter les
   interruptions. En dpit de cela, l'lectronique de communication
   typique des systmes SMP est tellement meilleure que la plupart
   des clusters en rseau que les logiciels pour cluster
   fonctionneront souvent mieux sur du SMP que sur le cluster pour
   lequel ils ont t conus.

   Le reste de cette section traite de l'lectronique contrlant le
   SMP, passe en revue les mcanismes Linux de base partageant de la
   mmoire  travers les diffrents processus d'un programme en
   parallle, fait quelques remarques concernant l'atomicit, la
   volatilit, les verrous et les lignes de cache, et donne enfin des
   rfrences vers d'autres ressources de traitement en parallle 
   mmoire partage.

  2.1. L'lectronique SMP

   Bien que les systmes SMP soit rpandus depuis de nombreuses
   annes, jusque trs rcemment, chaque machine tendait 
   implmenter les fonctions de base d'une manire suffisamment
   diffrente des autres pour que leur gestion par le systme
   d'exploitation ne soit pas portable. Les choses ont chang avec la
   Intel's MultiProcessor Specification (Spcification
   MultiProcesseurs d'Intel) souvent dsigne par MPS. La
   spcification MPS 1.4 est actuellement disponible sous forme de
   document PDF sur
   http://www.intel.com/design/intarch/MANUALS/242016.htm
   [http://www.intel.com/design/intarch/MANUALS/242016.htm]^[4], mais
   gardez  l'esprit qu'Intel rorganise souvent son site web. Un
   large panel de constructeurs fabrique des systmes conformes  MPS
   pouvant recevoir jusqu' quatre processeurs, mais en thorie, MPS
   admet bien plus de processeurs.

   Les seuls systmes non MPS et non IA32 reconnus par Linux SMP sont
   les machines SPARC multiprocesseurs de Sun4m. Linux SMP prend
   aussi en charge la plupart des machines Intel conformes  MPS 1.1
   ou 1.4, comptant jusqu' 16 processeurs 486DX, Pentium, Pentium
   MMX, Pentium Pro ou Pentium II. Parmi les processeurs IA32 non
   pris en charge (N.D.T. : par le SMP), on trouve les Intel 386 et
   486SX/SLC (l'absence de coprocesseur mathmatique interfre sur
   les mcanismes du SMP) et les processeurs AMD et Cyrix (qui
   ncessitent des circuits de gestion du SMP diffrents et qui ne
   semblent pas tre disponibles  l'heure o ce document est crit).

   Il est important de bien comprendre que les performances de
   diffrents systmes conformes  MPS peuvent fortement varier.
   Comme l'on peut s'y attendre, une des causes de diffrence de
   performance est la vitesse du processeur : Une horloge plus rapide
   tend  rendre les systmes plus rapides, et un processeur Pentium
   Pro est plus rapide qu'un Pentium. En revanche, MPS ne spcifie
   pas vraiment comment le matriel doit mettre en uvre la mmoire
   partage, mais seulement comment cette implmentation doit
   fonctionner d'un point de vue logiciel. Cela signifie que les
   performances dpendent aussi de la faon dont l'implmentation de
   la mmoire partage interagit avec les caractristiques de Linux
   SMP et de vos applications en particulier.

   La principale diffrence entre les systmes conformes  MPS rside
   dans la manire dont ils implmentent l'accs  la mmoire
   physiquement partage.

    2.1.1. Chaque processeur possde-t-il sa propre mmoire cache de
    niveau 2 (L2) ?

   Certains systmes MPS  base de Pentium, et tous les systmes MPS
   Pentium Pro et Pentium II ont des mmoires cache L2 indpendantes
   (le cache L2 est embarqu dans le module des Pentium Pro et
   Pentium II). Les mmoires caches L2 dissocies sont gnralement
   rputes augmenter les performances de l'ordinateur, mais les
   choses ne sont pas si videntes sous Linux. La principale
   complication provient du fait que l'ordonnanceur de Linux SMP
   n'essaie pas de maintenir chaque processus sur le mme processeur,
   concept connu sous le nom d'affinit processeur. Cela pourrait
   bientt changer. Un dbat a rcemment eu lieu sur ce sujet dans la
   communaut des dveloppeurs Linux SMP, sous le titre  processor
   bindings  ( associations de processeurs ). Sans affinit
   processeur, des caches L2 spars peuvent introduire des dlais
   non ngligeables lorsqu'un processus se voit allouer une tranche
   de temps d'excution sur un processeur qui n'est pas le mme que
   celui sur lequel il s'excutait juste avant.

   Plusieurs systmes relativement bon march sont organiss de
   manire  ce que deux processeurs Pentium puissent partager la
   mme mmoire cache L2. La mauvaise nouvelle, c'est que cela cre
   des conflits  l'utilisation de ce cache, qui dgradent
   srieusement les performances lorsque plusieurs programmes
   squentiels indpendants s'excutent simultanment. La bonne
   nouvelle, c'est que bon nombre de programmes parallles pourraient
   tirer profit de la mmoire cache partage, car si les deux
   processeurs veulent accder  la mme ligne de mmoire partage,
   seul un processeur doit aller la rapatrier dans le cache, et l'on
   vite des conflits de bus. Le manque d'affinit processeur peut
   aussi s'avrer moins dsastreux avec un cache L2 partag. Ainsi,
   pour les programmes parallles, il n'est pas vraiment certain que
   partager la mmoire cache L2 soit si prjudiciable que l'on
   pourrait le penser.

    l'usage, notre bi-Pentium  mmoire cache partage de 256Ko
   prsente une vaste chelle de performances, dpendantes du niveau
   d'activit noyau requis. Au pire, le gain en vitesse n'atteint
   qu'un facteur de 1,2. En revanche, nous avons aussi constat une
   acclration de 2,1 fois la vitesse d'origine, ce qui suggre que
   les calculs intensifs  base de SPMD tirent vraiment profit de
   l'effet d' acquisition partage  ( shared fetch ).

    2.1.2. Configuration du bus ?

   La premire chose  dire est que la plupart des systmes modernes
   relient le processeur  un ou plusieurs bus PCI qui  leur tour
   sont  ponts  vers un ou plusieurs bus ISA ou EISA. Ces ponts
   engendrent des temps de latence, et l'ISA comme l'EISA offrent
   gnralement des bandes passantes plus rduites que le PCI (ISA
   tant le plus lent). C'est pourquoi les disques, cartes vidos et
   autres priphriques de haute performance devraient en principe
   tre connects sur un bus PCI.

   Bien qu'un systme MPS puisse apporter un gain en vitesse
   honorable  plusieurs programmes parallles de calcul intensif
   mme avec un seul bus PCI, les oprations d'entres/sorties,
   elles, ne sont pas meilleures que sur un systme monoprocesseur.
   Elles sont peut-tre mme un peu moins bonnes  cause des conflits
   de bus entre les processeurs. Ainsi, si votre objectif est
   d'acclrer les entres/sorties, prenez soin de choisir un systme
   MPS comportant plusieurs bus PCI indpendants et plusieurs
   contrleurs d'entres/sorties (par exemple : plusieurs chanes
   SCSI). Il vous faudra tre prudent, et sr que Linux reconnat
   tout votre matriel. Gardez aussi  l'esprit le fait que Linux
   n'autorise qu'un seul processeur  la fois  entrer en mode noyau,
   aussi devrez-vous choisir des contrleurs qui rduisent au minimum
   le temps noyau ncessaire  leurs oprations. Pour atteindre des
   performances vraiment trs leves, il se pourrait mme qu'il vous
   faille envisager d'effectuer vous-mme les oprations
   d'entre/sortie de bas niveau directement depuis les processus
   utilisateurs, sans appel systme... ce n'est pas forcment aussi
   difficile que cela en a l'air, et cela permet d'viter de
   compromettre la scurit du systme (voir la section 3.3 pour une
   description des techniques de base).

   Il est important de remarquer que la relation entre vitesse du bus
   et vitesse du processeur est devenue trs floue ces dernires
   annes. Bien que la plupart des systmes utilisent maintenant la
   mme frquence de bus PCI, il n'est pas rare de trouver un
   processeur rapide appari avec un bus lent. L'exemple classique
   est celui du Pentium 133 qui utilise en gnral un bus plus rapide
   que celui du Pentium 150, produisant des rsultats tranges sur
   les logiciels bancs de tests ( benchmarks ). Ces effets sont
   amplifis sur les systmes SMP, o il est encore plus important
   d'utiliser un bus rapide.

    2.1.3. Interfoliage de la mmoire et technologie DRAM

   L'interfoliage de la mmoire n'a en fait absolument rien  voir
   avec le MPS, mais vous verrez souvent cette mention accompagner
   les systmes MPS car ceux-ci sont typiquement gourmands en bande
   passante mmoire. Concrtement, l'interfoliage en deux ou en
   quatre voies organise la RAM de faon  ce que l'accs  un bloc
   de mmoire se fasse au travers de plusieurs bancs de RAM plutt
   qu'un seul. Ceci acclre grandement les accs  la mmoire,
   particulirement en ce qui concerne le chargement et
   l'enregistrement du contenu des lignes de cache.

   Il faut toutefois souligner que ce fait n'est pas aussi vident
   qu'il y parait, car la DRAM EDO et les diffrentes technologies
   mmoire tendent  optimiser ce genre d'oprations. Un excellent
   aperu des diffrentes technologies DRAM est disponible sur
   http://www.pcguide.com/ref/ram/tech.htm
   [http://www.pcguide.com/ref/ram/tech.htm].

   Ainsi, par exemple, mieux vaut-il avoir de la mmoire DRAM EDO
   interfolie  2 voies, ou de la mmoire SDRAM non interfolie ?
   C'est une trs bonne question et la rponse n'est pas simple, car
   la mmoire interfolie comme les technologies DRAM exotiques ont
   tendance  tre coteuses. Le mme investissement en mmoire plus
   ordinaire vous apporte en gnral une mmoire centrale bien plus
   vaste. Mme la plus lente des mmoire DRAM reste autrement plus
   rapide que la mmoire virtuelle par fichier d'change...

  2.2. Introduction  la programmation en mmoire partage

   Okay, donc vous avez dcid que le traitement en parallle sur
   SMP, c'est gnial... Par quoi allez-vous commencer ? Eh bien, la
   premire tape consiste  en apprendre un peu plus sur le
   fonctionnement rel de la communication par mmoire partage.

   A premire vue, il suffit qu'un processeur range une valeur en
   mmoire et qu'un autre la lise. Malheureusement, ce n'est pas
   aussi simple. Par exemple, les relations entre processus et
   processeurs sont trs floues. En revanche, si nous n'avons pas
   plus de processus actifs que de processeurs, les termes sont  peu
   prs interchangeables. Le reste de cette section rsume brivement
   les cas de figure typiques qui peuvent poser de srieux problmes,
   si vous ne les connaissiez pas dj : les deux diffrents modles
   utiliss pour dterminer ce qui est partag, les problmes
   d'atomicit, le concept de volatilit, les instructions de
   verrouillage matriel, les effets de la ligne de cache, et les
   problmes poss par l'ordonnanceur de Linux.

    2.2.1. Partage Intgral contre Partage Partiel

   Il existe deux modles fondamentaux couramment utiliss en
   programmation en mmoire partage : le partage intgral et le
   partage partiel. Ces modles permettent tous deux aux processeurs
   de communiquer en chargeant et rangeant des donnes depuis et dans
   la mmoire. La diffrence rside dans le fait que le partage
   intgral place toutes les structures en mmoire partage, quand le
   partage partiel, lui, distingue les structures qui sont
   potentiellement partageables et celles qui sont prives, propres 
   un seul processeur (et oblige l'utilisateur  classer
   explicitement ses structures dans l'une de ces catgories).

   Alors quel modle de partage mmoire faut-il utiliser ? C'est
   surtout une affaire de chapelle. Beaucoup de gens aiment le
   partage intgral car ils n'ont pas spcialement besoin
   d'identifier les structures qui doivent tre partages au moment
   de leur dclaration. On place simplement des verrous sur les
   objets auxquels l'accs peut crer des conflits, pour s'assurer
   qu'un seul processeur (ou processus) y accde  un moment donn.
   Mais l encore, ce n'est pas aussi simple... aussi beaucoup
   d'autres gens prfrent, eux, le modle relativement sr du
   partage partiel.

      2.2.1.1. Partage intgral

   Le bon cot du partage intgral est que l'on peut aisment
   reprendre un programme squentiel existant et le convertir
   progressivement en programme parallle en partage intgral. Vous
   n'avez pas  dterminer au pralable les donnes qui doivent tre
   accessibles aux autres processeurs.

   Pos simplement, le principal problme avec le partage intgral
   vient du fait qu'une action effectue par un processeur peut
   affecter les autres processeurs. Ce problme ressurgit de deux
   manires :

     o Plusieurs bibliothques utilisent des structures de donnes
       qui ne sont tout simplement pas partageables. Par exemple, la
       convention UNIX stipule que la plupart des fonctions peuvent
       renvoyer un code d'erreur dans une variable appele errno. Si
       deux processus en partage intgral font des appels divers, ils
       vont interfrer l'un sur l'autre car ils partagent la mme
       variable errno. Bien qu'il existe dsormais une bibliothque
       qui rgle le problme de cette variable, ce problme se
       prsente toujours dans la plupart des bibliothques comme par
       exemple X-Window qui,  moins de prendre des prcautions trs
       spciales, ne fonctionnera pas si diffrents appels sont
       passs depuis diffrents processus en partage intgral.

     o En temps normal, un programme qui utilise un pointeur ou un
       index dfaillant provoque au pire l'arrt du processus qui
       contient le code corrompu. Il peut mme gnrer un fichier
       core vous renseignant sur les conditions dans lesquelles se
       sont drouls les vnements. En programmation parallle 
       partage intgral, il est fort probable que les accs illgaux
       provoquent la fin d'un processus qui n'est pas le fautif,
       rendant la localisation et la correction de l'erreur quasiment
       impossibles.

   Aucun de ces deux problmes n'est courant dans le cas du partage
   partiel, car seules sont partages les structures explicitement
   marques comme telles. De plus, il est trivial que le partage
   intgral ne peut fonctionner que si les processeurs excutent
   exactement la mme image en mmoire. On ne peut pas utiliser le
   partage intgral entre des images de code diffrentes
   (c'est--dire que vous pourrez travailler en SPMD, mais pas d'une
   manire gnrale en MIMD).

   Les supports de programmation en partage intgral existent le plus
   couramment sous la forme de bibliothques de threads. Les threads
   [http://liinwww.ira.uka.de/bibliography/Os/threads.html] sont
   essentiellement des processus  allgs  dont l'excution peut ne
   pas tre planifie comme celle des processus UNIX normaux et qui,
   c'est le plus important, partagent tous la mme page mmoire.
   L'adaptation des Pthreads
   [http://www.mit.edu:8001/people/proven/IAP_2000/index.html] POSIX
   a fait l'objet de nombreux efforts. La grande question est : ces
   adaptations paralllisent-elles les threads d'un programme en
   environnement Linux SMP (idalement, en attribuant un processeur 
   chaque thread) ?. L'API POSIX ne l'impose pas, et certaines
   versions comme PCthreads semblent ne pas implmenter une excution
   en parallle des threads : tous les threads d'un programme sont
   conservs  l'intrieur d'un seul processus Linux.

   La premire bibliothque de threads  avoir pris en charge le
   paralllisme sous Linux SMP fut la dsormais quelque peu obsolte
   bibliothque bb_thread, une toute petite bibliothque qui
   utilisait l'appel Linux clone() pour donner naissance  de
   nouveaux processus Linux, planifis indpendamment les uns des
   autres, tous partageant un mme espace d'adressage. Les machines
   Linux SMP peuvent lancer plusieurs de ces  threads  car chaque
    thread  est un processus Linux  part entire. L'inconvnient,
   c'est que l'on ne peut obtenir l'ordonnancement  poids-plume 
   apporte par les bibliothques de threads d'autres systmes
   d'exploitation. La bibliothque utilisait un peu de code
   assembleur intgr dans un code source en langage C pour mettre en
   place un bloc de mmoire pour la pile de chaque thread et fournir
   des fonctions d'accs atomiques  un tableau de verrous (les
   mutex). Sa documentation se rsumait  un fichier LISEZMOI et  un
   court programme d'exemple.

   Plus rcemment, une version de threads POSIX utilisant clone() a
   t dveloppe. Cette bibliothque, LinuxThreads
   [http://pauillac.inria.fr/~xleroy/linuxthreads/], est clairement
   la bibliothque en partage intgral favorite pour l'utilisation
   sous Linux SMP. Les threads POSIX sont bien documents, et les
   documents LinuxThreads README
   [http://pauillac.inria.fr/~xleroy/linuxthreads/README] et
   LinuxThreads FAQ
   [http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html] sont
   vraiment trs bien raliss. A prsent, le principal problme est
   que les threads POSIX ont encore beaucoup de dtails  rgler, et
   que LinuxThread est toujours un projet en cours d'volution.
   D'autre part, les threads POSIX ont volu pendant dans leur phase
   de standardisation, aussi devrez-vous tre prudent pour ne pas
   dvelopper en suivant une version obsolte du standard.

      2.2.1.2. Partage Partiel

   Le Partage Partiel consiste rellement   ne partager que ce qui
   doit tre partag . Cette approche est valable pour le MIMD en
   gnral (et pas simplement le SPMD)  condition de prendre soin
   d'allouer les objets partags aux mmes endroits dans le plan
   mmoire de chaque processeur. Plus important encore, le partage
   partiel facilite l'estimation et l'ajustage des performances, le
   dbogage des sources, et ctera. Les seuls problmes sont :

     o Dterminer  l'avance ce qui doit tre partag peut s'avrer
       difficile.

     o L'allocation d'objets dans la mmoire partage peut en fait se
       rvler malais, spcialement en ce qui concerne tout ce qui
       aurait du tre dclar dans la pile. Par exemple, il peut tre
       ncessaire d'allouer explicitement des objets partags dans
       des segments de mmoire spars, ncessitant des routines
       d'allocation mmoire spares, et impliquant l'ajout de
       pointeurs et d'indirections supplmentaires  chaque
       rfrence.

   Actuellement, il existe deux mcanismes similaires permettant aux
   groupes de processus sous Linux de possder des espaces mmoire
   indpendants, mais de tous partager un unique et relativement
   troit segment de mmoire. En supposant que vous n'ayez pas
   btement exclu l'option  System V IPC  lorsque que vous avez
   configur votre systme Linux (N.D.T. : ici  la recompilation du
   noyau), Linux gre un mcanisme trs portable devenu clbre sous
   le nom de  mmoire partage System V . L'autre alternative est
   une fonction de projection en mmoire dont l'implmentation varie
   grandement selon le systme UNIX utilis : L'appel systme mmap.
   Vous pouvez -- et devriez -- apprendre le fonctionnement de ces
   primitives au travers des pages du manuel (man pages)... mais vous
   trouverez quand mme un rapide aperu de chacune d'elles dans les
   sections 2.5 et 2.6 pour vous aider  dmarrer.

    2.2.2. Atomicit et ordonnancement

   Que vous utilisiez l'un ou l'autre des modles cits ci-dessus, le
   rsultat est  peu prs le mme : vous obtenez un pointeur sur un
   bloc de mmoire en lecture/criture accessible par tous les
   processus de votre programme en parallle. Cela signifie-t-il que
   je peux laisser mes programmes accder aux objets partags comme
   s'ils se trouvaient en mmoire locale ordinaire ? Pas tout 
   fait...

   L'atomicit dsigne une opration sur un objet effectue en une
   squence indivisible et ininterruptible. Malheureusement, les
   accs  la mmoire partage n'impliquent pas que les toutes les
   oprations sur les donnes de cette mmoire se fassent de manire
   atomique. A moins de prendre des prcautions spciales, seules les
   oprations de lecture ou d'criture s'accomplissant en une seule
   transaction sur le bus (c'est--dire alignes sur une adresse
   multiple de 8, 16 ou 32 bits,  l'exclusion des oprations 64 bits
   ou mal alignes) sont atomiques. Pire encore, les compilateurs
    intelligents  comme GCC font souvent des optimisations qui
   peuvent liminer les oprations mmoire ncessaires pour s'assurer
   que les autres processeurs puissent voir ce que le processeur
   concern a fait. Heureusement, ces problmes ont tous deux une
   solution... en acceptant seulement de ne pas se soucier de la
   relation entre l'efficacit des accs mmoire et la taille de la
   ligne de cache.

   En revanche, avant de traiter de ces diffrents cas de figure, il
   est utile de prciser que tout ceci part du principe que les
   rfrences  la mmoire pour chaque processeur se produisent dans
   l'ordre o elles ont t programmes. Le Pentium fonctionne de
   cette manire, mais les futurs processeurs d'Intel pourraient ne
   pas le faire. Aussi, quand vous dvelopperez sur les processeurs 
   venir, gardez  l'esprit qu'il pourrait tre ncessaire d'encadrer
   les accs  la mmoire avec des instructions provoquant
   l'achvement de toutes les accs  la mmoire en suspens,
   provoquant ainsi leur mise en ordre. L'instruction CPUID semble
   provoquer cet effet.

    2.2.3. Volatilit

   Pour viter que l'optimiseur du GCC ne conserve les valeurs de la
   mmoire partage dans les registres de processeur, tous les objets
   en mmoire partage doivent tre dclars avec l'attribut
   volatile. Tous les accs en lecture ou criture ne ncessitant
   l'accs qu' un seul mot se feront alors de manire atomique. Par
   exemple, en supposant que p est un pointeur sur un entier, et que
   ce pointeur comme l'entier qu'il pointe se trouvent en mmoire
   partage, la dclaration en C ANSI ressemblera  :

 volatile int * volatile p;

   Dans ce code, le premier volatile concerne l'int que p pointe
   ventuellement, quand le second volatile s'applique au pointeur
   lui-mme. Oui, c'est ennuyeux, mais c'est le prix  payer pour que
   GCC puisse faire des optimisations vraiment puissantes. En
   thorie, l'option -traditional devrait suffire  produire du code
   correct au prix de quelques optimisations, car le standard C K&R
   (N.D.T. : Kernigan & Ritchie) pr norme ANSI tablit que toutes
   les variables sont volatiles si elles ne sont pas explicitement
   dclares comme register. Ceci tant dit, si vos compilations GCC
   ressemblent  cc -O6 ..., vous n'aurez rellement besoin de
   dclarer les choses comme tant volatiles qu'aux endroits o c'est
   ncessaire.

   Un rumeur a circul  propos du fait que les verrous crits en
   assembleur signals comme modifiant tous les registres du
   processeur provoquaient de la part du compilateur GCC
   l'enregistrement adquat de toutes les variables en suspens,
   vitant ainsi le code compil  inutile  associ aux objets
   dclars volatile. Cette astuce semble fonctionner pour les
   variables globales statiques avec la version 2.7.0 de GCC... En
   revanche, ce comportement n'est pas une recommandation du standard
   C ANSI. Pire encore, d'autres processus n'effectuant que des accs
   en lecture pourraient conserver ternellement les valeurs dans des
   registres, et ainsi ne jamais s'apercevoir que la vraie valeur
   stocke en mmoire partage a en fait chang. En rsum,
   dveloppez comme vous l'entendez, mais seules les variables
   dclares volatile offrent un fonctionnement normal garanti.

   Notez qu'il est possible de provoquer un accs volatile  une
   variable ordinaire en utilisant un transtypage ( casting )
   imposant l'attribut volatile. Par exemple, un int i; ordinaire
   peut tre rfrenc en tant que volatile par *((volatile int *)
   &i); . Ainsi, vous pouvez forcer la volatilit et les cots
   supplmentaires qu'elle engendre seulement aux endroits o elle
   est critique.

    2.2.4. Verrous (Locks)

   Si vous pensiez que ++i; aurait toujours incrment une variable i
   sans problme, vous allez avoir une mauvaise surprise : mme
   codes en une seule instruction, le chargement et l'enregistrement
   du rsultat sont deux transactions mmoire spares, et d'autres
   processeurs peuvent accder  i entre ces deux transactions. Par
   exemple, deux processus effectuant chacun l'instruction ++i;
   pourraient n'incrmenter la variable i que d'une unit et non
   deux. Selon le  Manuel de l'Architecture et de la Programmation 
   du Pentium d'Intel, le prfixe LOCK peut tre employ pour
   s'assurer que chacune des instructions suivantes soit atomique par
   rapport  l'adresse mmoire  laquelle elles accdent :

 BTS, BTR, BTC                     mem, reg/imm
 XCHG                              reg, mem
 XCHG                              mem, reg
 ADD, OR, ADC, SBB, AND, SUB, XOR  mem, reg/imm
 NOT, NEG, INC, DEC                mem
 CMPXCHG, XADD

   En revanche, il n'est pas conseill d'utiliser toutes ces
   oprations. Par exemple, XADD n'existait mme pas sur 386, aussi
   l'employer en programmation peut poser des problmes de
   portabilit.

   L'instruction XCHG engendre toujours un verrou, mme sans le
   prfixe LOCK, et est ainsi et indiscutablement l'opration
   atomique favorite pour construire d'autres oprations atomiques de
   plus haut niveau comme les smaphores et les files d'attente
   partages. Bien sr, on ne peut pas demander  GCC de gnrer
   cette instruction en crivant simplement du code C. Il vous faudra
    la place crire un peu de code assembleur en ligne^[5]. En
   prenant un objet volatile obj et un registre du processeur reg,
   tous deux de type word (longs de 16 bits), le code assembleur GCC
   sera :

 __asm__ __volatile__ ("xchgl %1,%0"
                       :"=r" (reg), "=m" (obj)
                       :"r" (reg), "m" (obj));

   Quelques exemples de programmes assembleur en ligne utilisant des
   oprations bit--bit pour raliser des verrous sont disponibles
   dans le code source de la bibliothque bb_threads.

   Il est toutefois important de se souvenir que faire des
   transactions mmoire atomiques a un cot. Une opration de
   verrouillage engendre des dlais supplmentaires assez importants
   et peut retarder l'activit mmoire d'autres processeurs, quand
   des rfrences ordinaires auraient utilis le cache local. Les
   meilleures performances s'obtiennent en utilisant les oprations
   atomiques aussi peu souvent que possible. De plus, ces
   instructions atomiques IA32 ne sont videment pas portables vers
   d'autres systmes.

   Il existe plusieurs alternatives permettant aux instructions
   ordinaires d'tre utilises pour mettre en uvre diffrents types
   de synchronisation, y compris l'exclusion mutuelle, qui garantit
   qu'au plus un seul processeur met  jour un objet partag donn 
   un moment prcis. La plupart des manuels des diffrents systmes
   d'exploitation traitent d'au moins une de ces techniques. On
   trouve un trs bon expos sur le sujet dans la quatrime dition
   des Operating System Concepts (Principes des Systmes
   d'Exploitation), par Abraham Silberschatz et Peter B. Galvin, ISBN
   0-201-50480-4.

    2.2.5. Taille de la ligne de cache

   Encore une chose fondamentale concernant l'atomicit et qui peut
   avoir des consquence dramatiques sur les performances d'un SMP :
   la taille de la ligne de cache. Mme si le standard MPS impose que
   les rfrences soient cohrentes quelque soit le cache utilis, il
   n'en reste pas moins que lorsque qu'un processeur crit sur une
   ligne particulire de la mmoire, chaque copie en cache de
   l'ancienne ligne doit tre invalide ou mise  jour. Ceci implique
   que si au moins deux processeurs crivent chacun sur des portions
   diffrentes de la ligne de cache, cela peut provoquer un trafic
   important sur le bus et le cache, pour au final transfrer la
   ligne depuis le cache vers le cache. Ce problme est connu sous le
   nom de faux partage ( false sharing ). La solution consiste
   uniquement  organiser les donnes de telle manire que ce que les
   objets auxquels on accde en parallle proviennent globalement de
   diffrentes lignes de cache pour chaque processus.

   Vous pourriez penser que le faux partage n'est pas un problme
   quand on utilise un cache de niveau 2 partag, mais souvenez-vous
   qu'il existe toujours des caches de niveau 1 spars.
   L'organisation du cache et le nombre de niveaux spars peut
   varier, mais la ligne de cache de premier niveau d'un Pentium est
   longue de 32 octets, et le cache externe typique tourne autour de
   256 octets. Supposons que les adresses (physiques ou logiques) de
   deux objets soient a et b, et que la taille de la ligne de cache
   soit c, que nous admettrons tre une puissance de 2. Pour tre
   trs prcis, si ((int) a) & ~(c-1) est gal  ((int) b) & ~(c-1),
   alors les deux rfrences se trouvent dans la mme ligne de cache.
   Une rgle plus simple consiste  dire que si deux objets
   rfrencs en parallle sont loigns d'au moins c octets, ils
   devraient se trouver dans des lignes de cache diffrentes.

    2.2.6. Les problmes de l'ordonnanceur de Linux

   Bien que tout l'intrt d'utiliser de la mmoire partage pour les
   traitements en parallle consiste  viter les dlais dus au
   systme d'exploitation, ces dlais peuvent parfois provenir
   d'autres choses que les communications en elles-mmes. Nous avons
   dj remarqu que le nombre de processus que l'on devrait crer
   doit tre infrieur ou gal au nombre de processeurs de la
   machine. Mais comment dcide-t-on exactement du nombre de
   processus  crer ?

   Pour obtenir les meilleures performances, le nombre de processus
   de votre programme en parallle doit tre gal au nombre de
   processus qui peuvent tre excuts simultanment, chacun sur son
   processeur. Par exemple, si un systme SMP  quatre processeurs
   hberge un processus trs actif pour un autre usage (par exemple
   un serveur web), alors votre programme en parallle ne devra
   utiliser que trois processus. Vous pouvez vous faire une ide
   gnrale du nombre de processus actifs excuts sur votre systme
   en consultant la  charge systme moyenne  ( load average )
   mise en vidence par la commande uptime.

   Vous pouvez en outre  pousser  la priorit de vos processus de
   votre programme parallle en utilisant, par exemple, la commande
   renice ou l'appel systme nice(). Vous devez tre privilgi^[6]
   pour augmenter la priorit d'un processus. L'ide consiste
   simplement  jecter les autres programmes des autres processeurs
   pour que votre programme puisse tre excut sur tous les
   processeurs simultanment. Ceci peut tre effectu de manire un
   peu plus explicite en utilisant la version prototype de Linux SMP
   disponible sur http://www.fsmlabs.com/products/openrtlinux/
   [http://www.fsmlabs.com/products/openrtlinux/] et qui propose un
   ordonnanceur en temps rel (N.D.T. : il existe dsormais un guide
   consacr  RTLinux, accessible en ligne : RTLinux HOWTO
   [http://www.traduc.org/docs/howto/lecture/RTLinux-HOWTO.html]).

   Si vous n'tes pas le seul utilisateur employant votre systme SMP
   comme une machine en parallle, il se peut que vous entriez en
   conflit avec les autres programmes en parallle essayant de
   s'excuter simultanment. La solution standard est
   l'ordonnancement de groupe ( gang scheduling ), c'est--dire la
   manipulation de la priorit d'ordonnancement de faon  ce que
   seuls les processus d'un seul programme en parallle s'excutent 
   un moment donn. Il est bon de rappeler, en revanche, que
   multiplier les paralllismes tend  rduire les retours et que
   l'activit de l'ordonnanceur introduit des dlais supplmentaires.
   Ainsi, par exemple, il sera srement prfrable, pour une machine
    quatre processeurs, d'excuter deux programmes contenant chacun
   deux processus, plutt que d'ordonnancer en groupe deux programmes
   de quatre processus chacun.

   Il y a encore une chose dont il faut tenir compte. Supposons que
   vous dveloppiez un programme sur une machine trs sollicite le
   jour, mais disponible  cent pour cent pendant la nuit pour le
   traitement en parallle. Il vous faudra crire et tester votre
   code dans les conditions relles, donc avec tous ses processus
   lancs, mme en sachant que des tests de jour risquent d'tre
   lents. Ils seront en fait trs lents si certains de vos processus
   sont en tat d'attente active ( busy waiting )^[7], guettant le
   changement de certaines valeurs en mmoire partage, changement
   cens tre provoqu par d'autres processus qui ne sont pas
   excuts (sur d'autres processeurs) au mme moment. Ce mme
   problme apparat lorsque l'on dveloppe et que l'on teste un
   programme sur un systme monoprocesseur.

   La solution consiste  intgrer des appels systme  votre code l
   o il peut se mettre en boucle en attendant une action d'un autre
   processeur, pour que Linux puisse donner une chance de s'excuter
    un autre processus. J'utilise pour cela une macro en langage C,
   appelons-la IDLE_ME (N.D.T. : MetsMoiEnAttente) : pour faire un
   simple test, compilez votre programme par  cc
   -DIDLE_ME=usleep(1);... . Pour produire un excutable dfinitif,
   utilisez  cc -DIDLE_ME={}... . L'appel usleep(1) rclame une
   pause d'une microseconde, qui a pour effet de permettre 
   l'ordonnanceur de Linux de choisir un nouveau processus  excuter
   sur ce processeur. Si le nombre de processus dpasse le nombre de
   processeurs disponibles, il n'est pas rare de voir des programmes
   s'excuter dix fois plus rapidement avec usleep(1) que sans.

  2.3. bb_threads

   La bibliothque bb_threads ("Bare Bones" threads) est une
   bibliothque remarquablement simple qui fait la dmonstration de
   l'utilisation de l'appel systme Linux clone(). Le fichier tar.gz
   n'occupe que 7 ko ! Bien que cette bibliothque ait t rendue
   pour l'essentiel obsolte par la bibliothque LinuxThreads,
   traite dans la section 2.4, bb_threads reste utilisable, et est
   suffisamment simple et peu encombrante pour former une bonne
   introduction  la gestion des threads sous Linux. Il est beaucoup
   moins effrayant de se lancer dans la lecture de ce code source que
   dans celui de LinuxThreads. En rsum, la bibliothque bb_threads
   forme un bon point de dpart, mais n'est pas vraiment adapte  la
   ralisation de grands projets.

   La structure de base des programmes utilisant la bibliothque
   bb_threads est la suivante :

    1. Lancez le programme en tant que processus unique.

    2. Il vous faudra estimer l'espace maximum dans la pile qui sera
       ncessaire  chaque thread. Prvoir large est relativement
       sage (c'est   que sert la mmoire virtuelle ;-), mais
       souvenez-vous que toutes les piles proviennent d'un seul
       espace d'adressage virtuel, aussi voir trop grand n'est pas
       une ide formidable. La dmo suggre 64Ko. Cette taille est
       fixe  b octets par bb_threads_stacksize(b).

    3. L'tape suivante consiste  initialiser tous les verrous dont
       vous aurez besoin. Le mcanisme de verrouillage intgr 
       cette bibliothque numrote les verrous de 0  MAX_MUTEXES, et
       initialise un verrou i par bb_threads_mutexcreate(i).

    4. La cration d'un nouveau thread s'effectue en appelant une
       routine de la bibliothque recevant en arguments la fonction
       que le nouveau thread doit excuter, et les arguments qui
       doivent lui tre transmis. Pour dmarrer un nouveau thread
       excutant la fonction f de type void et attendant un argument
       arg, l'appel ressemblera  bb_threads_newthread (f, &arg), o
       f devra tre dclar comme suit :

 void f (void *arg, size_t dummy)

       Si vous avez besoin de passer plus d'un argument  votre
       fonction, utilisez un pointeur sur une structure contenant les
       valeurs  transmettre.

    5. Lancement du code en parallle, en prenant soin d'utiliser
       bb_threads_lock(n) et bb_threads_unlock(n) o n est un entier
       indiquant le verrou  utiliser. Notez que les oprations de
       verrouillage et dverrouillage sont des oprations de
       blocage^[8] trs primaires et utilisant des instructions
       atomiques de verrouillage du bus, lesquelles peuvent causer
       des interfrences d'accs  la mmoire, et qui n'essaient en
       aucun cas d'agir  proprement . Le programme de dmonstration
       fourni avec bb_threads n'utilisait pas correctement les
       verrous pour empcher printf() d'tre excut depuis les
       fonctions fnn et main, et  cause de cela, la dmo ne
       fonctionne pas toujours. Je ne dis pas cela pour dmolir la
       dmo, mais plutt pour bien mettre en vidence le fait que ce
       travail comporte beaucoup de piges. Ceci dit, utiliser
       LinuxThreads ne se rvle que lgrement plus facile.

    6. Lorsqu'un thread excute return, il dtruit le processus...
       mais la pile locale n'est pas automatiquement dsalloue. Pour
       tre plus prcis, Linux ne gre pas la dsallocation, et
       l'espace mmoire n'est pas automatiquement rendu  la liste
       d'espace libre de malloc(). Aussi, le processus parent doit-il
       rcuprer l'espace mmoire de chaque processus fils mort par
       bb_threads_cleanup(wait(NULL)).

   Le programme suivant, crit en langage C, utilise l'algorithme
   trait dans la section 1.3 pour calculer la valeur de Pi en
   utilisant deux threads bb_threads.

 #include <stdio.h>
 #include <stdlib.h>
 #include <unistd.h>
 #include <sys/types.h>
 #include <sys/wait.h>
 #include "bb_threads.h"

 volatile double pi = 0.0;
 volatile int intervalles;
 volatile int pids[2];      /* Numros de processus Unix des threads */

 void
 do_pi(void *data, size_t len)
 {
   register double largeur, sommelocale;
   register int i;
   register int iproc = (getpid() != pids[0]);

   /* Fixe la largeur des intervalles */
   largeur = 1.0 / intervalles;

   /* Effectue les calculs locaux */
   sommelocale = 0;
   for (i=iproc; i<intervalles; i+=2) {
     register double x = (i + 0.5) * largeur;
     sommelocale += 4.0 / (1.0 + x * x);
   }
   sommelocale *= largeur;

   /* Obtention des permissions, mise  jour de Pi, et dverrouillage */
   bb_threads_lock(0);
   pi += sommelocale;
   bb_threads_unlock(0);
 }

 int
 main(int argc, char **argv)
 {
   /* Rcupre le nombre d'intervalles */
   intervalles = atoi(argv[1]);

   /* Fixe la taille de la pile, et cre le verrou */
   bb_threads_stacksize(65536);
   bb_threads_mutexcreate(0);

   /* cre deux threads ... */
   pids[0] = bb_threads_newthread(do_pi, NULL);
   pids[1] = bb_threads_newthread(do_pi, NULL);

   /* nettoie derrire les deux threads */
   /* (forme ainsi une barrire de synchro) */

   bb_threads_cleanup(wait(NULL));
   bb_threads_cleanup(wait(NULL));

   /* Affiche le rsultat */
   printf("Estimation de la valeur de Pi: %f\n", pi);

   /* Sortie avec code de SUCCES */
   exit(0);
 }

  2.4. LinuxThreads

   LinuxThreads (http://pauillac.inria.fr/~xleroy/linuxthreads/
   [http://pauillac.inria.fr/~xleroy/linuxthreads/]) est une
   implmentation assez complte et bien construite en accord avec le
   standard de threads POSIX 1003.1c. Contrairement aux autres
   adaptations d'implmentations de threads POSIX, LinuxThreads
   utilise galement l'appel clone() du noyau Linux, dj employ par
   bb_threads. La compatibilit POSIX implique qu'il est relativement
   ais de faire l'adaptation de certaines applications provenant
   d'autres systmes, et diffrents tutoriels et leur support sont
   disponibles. Bref, c'est incontestablement la bibliothque 
   utiliser pour dvelopper des applications multi-threads  grande
   chelle sous Linux.

   La structure de base d'un programme utilisant LinuxThreads suit ce
   modle :

    1. Lancement du programme en tant que processus unique.

    2. Initialisation de tous les verrous dont vous aurez besoin.
       Contrairement aux verrous de bb_threads qui sont identifis
       par des numros, les verrous POSIX sont dclars comme des
       variables de type pthread_mutex_t lock. Utilisez
       pthread_mutex_init(&lock,val) pour initialiser chacun des
       verrous que vous utiliserez.

    3. Comme avec bb_threads, la cration d'un nouveau thread se fait
       par l'appel d'une fonction de la bibliothque admettant des
       arguments spcifiant  leur tour la fonction que le nouveau
       thread doit excuter et les arguments que celle-ci reoit.
       Cependant, POSIX impose  l'utilisateur la dclaration d'une
       variable de type pthread_t pour identifier chaque thread. Pour
       crer un thread pthread_t thread excutant la fonction f(), on
       appelle pthread_create(&thread,NULL,f,&arg).

    4. Lancement de la partie parallle du programme, en prenant soin
       d'utiliser pthread_mutex_lock(&lock) et
       pthread_mutex_unlock(&lock) comme il se doit.

    5. Utilisation de pthread_join(thread,&retval) aprs chaque
       thread pour tout nettoyer.

    6. Utilisation de -D_REENTRANT  la compilation de votre
       programme en C.

   Voici l'exemple du calcul de Pi en parallle, s'appuyant sur
   LinuxThreads. L'algorithme de la section 1.3 est utilis et, comme
   pour l'exemple de bb_threads, deux threads s'excutent en
   parallle.

 #include <stdio.h>
 #include <stdlib.h>
 #include "pthread.h"

 volatile double pi = 0.0;    /* Approximation de pi (partage) */
 pthread_mutex_t pi_lock;     /* Verrou de la variable ci-dessous */
 volatile double intervalles; /* Combien d'intervalles ? */

 void *
 process(void *arg)
 {
   register double largeur, sommelocale;
   register int i;
   register int iproc = (*((char *) arg) - '0');

   /* Fixe la largeur */
   largeur = 1.0 / intervalles;

   /* Fais les calculs locaux */
   sommelocale = 0;
   for (i=iproc; i<intervalles; i+=2) {
     register double x = (i + 0.5) * largeur;
     sommelocale += 4.0 / (1.0 + x * x);
   }
   sommelocale *= largeur;

   /* Verrouille la variable pi en vue d'une mise  jour,
      effectue la mise  jour, puis dverrouille Pi. */

   pthread_mutex_lock(&pi_lock);
   pi += sommelocale;
   pthread_mutex_unlock(&pi_lock);

   return(NULL);
 }

 int
 main(int argc, char **argv)
 {
   pthread_t thread0, thread1;
   void * retval;

   /* Rcupre le nombre d'intervalles */
   intervalles = atoi(argv[1]);

   /* Initialise un verrou sur pi */
   pthread_mutex_init(&pi_lock, NULL);

   /* Cre les deux threads */
   if (pthread_create(&thread0, NULL, process, "0") ||
       pthread_create(&thread1, NULL, process, "1")) {
     fprintf(stderr, "%s: Cration des threads impossible\n", argv[0]);
     exit(1);
   }

   /*  Joint  (dtruit) les deux threads */
   if (pthread_join(thread0, &retval) ||
       pthread_join(thread1, &retval)) {
     fprintf(stderr, "%s: Erreur  la fusion des threads\n", argv[0]);
     exit(1);
   }

   /* Affiche le rsultat */
   printf("Estimation de la valeur de Pi: %f\n", pi);

   /* Sortie */
   exit(0);
 }

  2.5. La mmoire partage de System V

   La gestion des IPC (Inter-Process Communication) System V
   s'effectue au travers d'un certain nombre d'appels systme
   fournissant les mcanismes des files de message, des smaphores et
   de la mmoire partage. Bien sr, ces mcanismes ont t
   initialement conus pour permettre  plusieurs processus de
   communiquer au sein d'un systme monoprocesseur. Cela signifie
   nanmoins que ces mcanismes devraient aussi fonctionner dans un
   systme Linux SMP, quelque soit le nombre de processeurs.

   Avant d'aller plus loin dans l'utilisation de ces appels, il est
   important de comprendre que mme s'il existe des appels IPC System
   V pour des choses comme les smaphores et la transmission de
   messages, vous ne les utiliserez probablement pas. Pourquoi ?
   Parce ces fonctions sont gnralement lentes et srialises sous
   Linux SMP. Inutile de s'tendre.

   La marche  suivre standard pour crer un groupe de processus
   partageant l'accs  un segment de mmoire partage est la
   suivante.

    1. Lancement du programme en tant que processus unique.

    2. En temps normal, chaque instance de votre programme en
       parallle devra avoir son propre segment de mmoire partage,
       aussi vous faudra-t-il appeler shmget() pour crer un nouveau
       segment de la taille souhaite. Mais d'autre part, cet appel
       peut tre utilis pour rcuprer l'identifiant d'un segment de
       mmoire partage dj existant. Dans les deux cas, la valeur
       de retour est soit l'identifiant du segment de mmoire
       partage, soit -1 en cas d'erreur. Par exemple, pour crer un
       segment de mmoire partage long de b octets, on passe un
       appel ressemblant  shmid = shmget(IPC_PRIVATE, b, (IPC_CREAT
       | 0666)).

    3. L'tape suivante consiste  attacher ce segment de mmoire
       partage au processus, c'est--dire l'ajouter  son plan
       mmoire. Mme si l'appel shmat() permet au programmeur de
       spcifier l'adresse virtuelle  laquelle le segment doit
       apparatre, cette adresse doit tre aligne sur une page (plus
       prcisment tre un multiple de la taille d'une page renvoye
       par getpagesize(), correspondant  4096 octets), et recouvrera
       (prendra le pas sur) tout segment de mmoire s'y trouvant
       dj. Ainsi est-il plus sage de laisser le systme choisir une
       adresse. Dans les deux cas, la valeur de retour est un
       pointeur sur l'adresse virtuelle de base du segment
       frachement install dans le plan mmoire. L'instruction
       correspondante est la suivante : shmptr = shmat(shmid, 0, 0).
       Remarquez que vous pouvez allouer toutes vos variables
       statiques dans ce segment de mmoire partage en dclarant
       simplement vos variables partages comme tant les membres
       d'une structure de type struct, et en dclarant shmptr comme
       tant un pointeur vers ce type de donnes. Avec cette
       technique, une variable partage x serait accessible par
       shmptr->x.

    4. Comme ce segment de mmoire partage doit tre dtruit quand
       le dernier processus  y accder prend fin ou s'en dtache, il
       nous faut appeler shmctl() pour configurer cette action par
       dfaut. Le code correspondant ressemble  shmctl(shmid,
       IPC_RMID, 0).

    5. Utiliser l'appel Linux fork()^[9] pour crer le nombre dsir
       de processus. Chacun d'eux hritera du segment de mmoire
       partage.

    6. Lorsqu'un processus a fini d'utiliser un segment de mmoire
       partage, il doit s'en dtacher. On accomplit cela par un
       shmdt(shmptr).

   Mme avec si peu d'appels systme, une fois le segment de mmoire
   partage tabli, tout changement effectu par un processeur sur
   une valeur se trouvant dans cet espace sera automatiquement
   visible par les autres processus. Plus important, chaque opration
   de communication sera exonre du cot d'un appel systme.

   Ci-aprs, un exemple de programme en langage C utilisant les
   segments de mmoire partage System V. Il calcule Pi, en utilisant
   les algorithmes de la section 1.3.

 #include <stdio.h>
 #include <stdlib.h>
 #include <unistd.h>
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <fcntl.h>
 #include <sys/ipc.h>
 #include <sys/shm.h>

 volatile struct shared { double pi; int lock; } * partage;

 inline extern int xchg(register int reg,
 volatile int * volatile obj)
 {
   /* Instruction atomique d'change */
 __asm__ __volatile__ ("xchgl %1,%0"
                       :"=r" (reg), "=m" (*obj)
                       :"r" (reg), "m" (*obj));
   return(reg);
 }

 main(int argc, char **argv)
 {
   register double largeur, sommelocale;
   register int intervalles, i;
   register int shmid;
   register int iproc = 0;;

   /* Alloue de la mmoire partage */
   shmid = shmget(IPC_PRIVATE,
                  sizeof(struct shared),
                  (IPC_CREAT | 0600));
   partage = ((volatile struct shared *) shmat(shmid, 0, 0));
   shmctl(shmid, IPC_RMID, 0);

   /* Fais les inits ... */
   partage->pi = 0.0;
   partage->lock = 0;

   /* Cre un fils */
   if (!fork()) ++iproc;

   /* Rcupre le nombre d'intervalles */
   intervalles = atoi(argv[1]);
   largeur = 1.0 / intervalles;

   /* Fais les calculs locaux */
   sommelocale = 0;
   for (i=iproc; i<intervalles; i+=2) {
     register double x = (i + 0.5) * largeur;
     sommelocale += 4.0 / (1.0 + x * x);
   }
   sommelocale *= largeur;

   /* Verrou d'attente atomique, ajout, et dverrouillage ... */
   while (xchg((iproc + 1), &(shared->lock))) ;
   shared->pi += sommelocale;
   shared->lock = 0;

   /* Fin du processus fils (barrire de synchro) */
   if (iproc == 0) {
     wait(NULL);
     printf("Estimation de pi: %f\n", partage->pi);
   }

   /* Sortie en bonne et due forme */
   return(0);
 }

   Dans cet exemple, j'ai utilis l'instruction atomique d'change
   pour mettre le verrouillage en uvre. Pour de meilleures
   performances, prfrez-lui une technique de synchronisation
   vitant les intructions verrouillant le bus.

   Pendant les phases de dbogage, il est utile de se souvenir que la
   commande ipcs renvoie la liste des facilits des IPC System V en
   cours d'utilisation.

  2.6. Projection mmoire (Memory Map Call)

   L'utilisation des appels systme pour accder aux fichiers (les
   entres/sorties) peut revenir cher. En fait, c'est la raison pour
   laquelle il existe une bibliothque de gestion des entres/sorties
   grant un tampon dans l'espace utilisateur (getchar(), fwrite(),
   et ctera). Mais les tampons utilisateur ne remplissent pas leur
   fonction si plusieurs processus accdent au mme fichier ouvert en
   criture. La solution Unix BSD  ce problme fut l'ajout d'un
   appel systme permettant  une portion d'un fichier d'tre
   projete en mmoire utilisateur, en utilisant principalement les
   mcanismes de la mmoire virtuelle pour provoquer les mises 
   jour. Le mme mcanisme a t utilis pendant plusieurs annes
   dans les systmes de Sequent comme base de leur gestion du
   traitement parallle en mmoire partage. En dpit de commentaires
   trs ngatifs dans la page de manuel (assez ancienne), Linux
   semble correctement effectuer au moins quelques unes des fonctions
   de base, et sait prendre en charge l'usage driv de cet appel
   pour projeter un segment anonyme de mmoire pouvant tre partag
   par plusieurs processus.

   L'implmentation Linux de l'appel mmap() est en elle-mme une
   solution intgre de remplacement des tapes 2, 3 et 4 du schma
   classique de mmoire partage System V, mis en vidence dans la
   section 2.5. Pour crer un segment de mmoire partage anonyme :

 shmptr =
     mmap(0,                        /* Le systme choisit l'adresse */
          b,                        /* Taille du segment de mmoire partage */
          (PROT_READ | PROT_WRITE), /* droits d'accs, peuvent tre rwx */
          (MAP_ANON | MAP_SHARED),  /* anonyme, partag */
          0,                        /* descripteur de fichier (inutilis) */
          0);                       /* offset fichier (inutilis) */

   L'quivalent de l'appel de mmoire partage System V shmdt() est
   munmap() :

 munmap(shmptr, b);

    mon avis, on ne gagne pas grand chose  utiliser mmap() plutt
   que les mcanismes de gestion de la mmoire partage de System V.

3. Clusters de systmes Linux

   Cette section tente de donner un aperu de ce qu'est le traitement
   parallle en cluster sous Linux. Les clusters sont, actuellement,
    la fois l'approche la plus populaire et la plus varie, en
   s'tendant du simple rseau de stations de travail (Network Of
   Workstations : NOW) aux machines en parallle essentiellement
   construites sur mesure, et dans lesquelles il arrive que l'on
   trouve comme lments des PC sous Linux. Il existe galement un
   grand nombre de logiciels pouvant prendre en charge le calcul en
   parallle dans des clusters de machines Linux.

  3.1. Pourquoi un cluster ?

   Le traitement en parallle au travers d'un cluster offre plusieurs
   avantages majeurs :

     o Chacune des machines d'un cluster peut tre un systme
       complet, utilisable avec une large gamme d'applications de
       calcul. Cela conduit beaucoup de gens  suggrer l'ide que ce
       type de cluster pourrait faire usage de tous les  cycles
       machine perdus  sur les ordinateurs tournant  ne rien faire
       dans les bureaux. Il n'est pas si facile de rcuprer ces
       cycles, et cela risque de ralentir l'cran de veille de votre
       collgue, mais cela peut tre fait.

     o L'explosion actuelle des systmes en rseau signifie que la
       plupart du matriel ncessaire  la construction d'un cluster
       se vend dj en grande quantit et aux prix rduits inhrents
        la  grande distribution . On peut conomiser encore un peu
       plus en partant du principe qu'une seule carte vido, un seul
       moniteur et un seul clavier soient ncessaires pour chaque
       cluster (bien qu'il vous faille tout de mme les passer d'une
       machine  une autre pour faire l'installation initiale de
       Linux, une fois lanc, un PC sous Linux typique n'a pas besoin
       de  console ). En comparaison, les systmes SMP et
       processeurs auxiliaires reprsentent des marchs plus rduits,
       tendant  proposer des prix plus levs par performances 
       l'unit.

     o Les calculateurs en cluster peuvent voluer en de trs grands
       systmes. Alors qu'il est actuellement difficile de trouver un
       ordinateur SMP  plus de quatre processeurs qui soit
       compatible avec Linux, la plupart du matriel rseau
       disponible permet de btir facilement un cluster incluant
       jusqu' 16 machines. Avec un peu d'huile de coude, on peut
       mettre en rseau des centaines voire des milliers de machines.
       En fait, Internet tout entier pourrait tre assimil  un seul
       immense cluster.

     o Le fait que remplacer une  mauvaise machine  au sein d'un
       cluster soit une opration triviale compar  la rparation
       d'un ordinateur SMP partiellement dfaillant garantit une
       disponibilit bien plus leve aux configurations de cluster
       soignes. Cela devient important non seulement pour les
       applications qui ne peuvent tolrer des interruptions de
       service trop importantes, mais aussi dans l'utilisation en
       gnral de systmes qui contiennent un nombre suffisant de
       processeurs pour que la panne d'une machine en particulier
       soit assez courante (par exemple, mme si la dure moyenne
       avant la premire panne d'un PC est environ deux ans, dans un
       cluster de 32 machines, la probabilit qu'au moins une machine
       tombe en panne dans les six premiers mois est assez leve).

   Trs bien. Si les clusters sont gratuits ou trs peu onreux,
   peuvent devenir trs grands et offrir une haute disponibilit...
   pourquoi tout le monde n'utilise pas un cluster ? Eh bien, parce
   qu'il y a aussi des problmes :

     o  quelques exceptions prs, le matriel rseau n'est pas conu
       pour le traitement en parallle. Typiquement, les temps de
       latence sont levs et la bande passante rduite compars aux
       systmes SMP et processeurs auxiliaires. Par exemple, si les
       temps de latence d'un SMP n'excdent gnralement pas plus de
       quelques microsecondes, ils atteignent couramment des
       centaines, voire des milliers de microsecondes dans un
       cluster. La bande passante des communications dans un systme
       SMP dpasse souvent 100 mgaoctets par seconde. Bien que le
       matriel rseau le plus rapide (c'est--dire le  Gigabit
       Ethernet ) prsente une vitesse comparable, la plupart des
       rseaux sont de 10  1000 fois plus lents. La performance d'un
       matriel rseau est dj suffisamment mdiocre dans un cluster
       isol. Si le rseau n'est pas isol du reste du trafic, ce qui
       est souvent le cas lorsque l'on utilise des  machines qui
       sont en rseau  plutt qu'un systme conu pour tre un
       cluster, les performances peuvent tre bien pires encore.

     o La gestion logicielle des clusters en tant que systme unique
       est trs mince. Par exemple, la commande ps ne fait tat que
       des processus s'excutant sur un seul systme Linux, pas des
       processus s'excutant  travers le cluster Linux entier.

   Moralit, les clusters ont un trs grand potentiel, mais ce
   potentiel risque d'tre trs difficile  concrtiser pour la
   plupart des applications. La bonne nouvelle, c'est qu'il existe un
   soutien logiciel trs dvelopp pour vous aider  obtenir de
   bonnes performances avec les programmes adapts  cet
   environnement, et qu'il existe galement des rseaux conus
   spcialement pour largir la palette de programmes pouvant avoir
   de bonnes performances.

  3.2. Le matriel rseau

   Les rseaux informatiques sont en pleine explosion... mais vous le
   savez dj. Un nombre toujours grandissant de technologies et
   produits rseau a t dvelopp, et la plupart d'entre eux sont
   disponibles sous une forme qui peut tre utilise pour faire d'un
   groupe de machines (des PC fonctionnant chacun sous Linux) un
   cluster de traitement en parallle.

   Malheureusement, aucune technologie rseau ne rsout compltement
   tous les problmes.  vrai dire, le nombre d'approches
   diffrentes, en cot et en performances, est  premire vue assez
   difficile  croire. Par exemple, le cot par machine mise en
   rseau s'tend de moins de 5 dollars jusqu' plus de 4000. La
   bande passante et les temps de latence varient aussi selon quatre
   ordres de grandeur.

   Avant d'en apprendre plus sur les spcificits de certains
   rseaux, il est important de remarquer que ces choses voluent
   trs frquemment (voir http://www.linux.org.uk/NetNews.html
   [http://www.linux.org.uk/NetNews.html] pour avoir des nouvelles
   fraches concernant les rseaux sous Linux), et qu'il est trs
   difficile d'obtenir des infos prcises concernant certains
   rseaux.

   J'ai plac un  ?  aux endroits incertains. J'ai aussi pass
   beaucoup de temps  faire des recherches sur ce sujet, mais je
   reste sr que ce rsum est plein d'erreurs et d'omissions
   importantes. Si vous avez des corrections ou des ajouts  y
   apporter, merci de m'envoyer un courrier lectronique en anglais 
   l'adresse suivante : <hankd CHEZ engr POINT uky POINT edu>.

   Les rsums comme le LAN Technology Scorecard
   [http://www.mcgeoch.com/other/lan-technology.html]^[10] donnent
   les caractristiques de nombreux et diffrents types de rseaux et
   de standards de rseaux locaux (LAN). Cependant, l'essentiel de ce
   guide pratique est centr sur les proprits les plus indiques 
   la construction d'un cluster Linux. Chaque section dcrivant un
   type de rseau dbute par une courte liste de caractristiques. Ci
   dessous, la dfinition de chaque entre.

   Prise en charge sous Linux :

           Si la rponse est non, la signification est claire. Les
           autres rponses tentent de dcrire l'interface de base
           utilise pour accder au rseau. La plupart du matriel
           rseau est interfac via un pilote de priphrique du
           noyau, sachant typiquement grer les communications
           TCP/UDP. D'autres rseaux utilisent des interfaces plus
           directes (par exemple des bibliothques) pour rduire les
           temps de latence en vitant d'avoir  passer par le noyau.

           Il y a quelques annes, il tait considr comme
           parfaitement acceptable d'accder au coprocesseur
           mathmatique ( floating point unit ) par un appel
           systme mais aujourd'hui, c'est clairement ridicule.  mon
           avis, ncessiter un appel systme pour chaque
           communication entre les processeurs excutant un programme
           en parallle est peu commode. Le problme est que les
           ordinateurs n'ont pas encore intgr ces mcanismes de
           communication, et que les approches non  orientes
           noyau  tendent  prsenter des problmes de portabilit.
           Vous allez entendre beaucoup parler de ce sujet dans un
           avenir proche, principalement sous la forme de la nouvelle
           Virtual Interface (VI) Architecture
           (http://www.intel.com/intelpress/sum_via.htm
           [http://www.intel.com/intelpress/sum_via.htm]) mthode
           standardise pour les oprations des interfaces rseau et
           servant  contourner les couches des systmes
           d'exploitation usuels. Le standard VI est appuy par
           Compaq, Intel et Microsoft, et aura assurment un impact
           important sur la conception des SAN (System Area Network)
           dans les prochaines annes.

   Bande passante maximum :

           C'est le chiffre dont tout le monde se soucie. J'ai
           gnralement repris les dbits maximum thoriques. Votre
           moyenne, elle, va varier.

   Temps de latence minimum :

            mon avis, c'est le chiffre dont tout le monde devrait se
           soucier, plus encore que de la bande passante. L encore,
           j'ai utilis les (irralistes) valeurs thoriques idales,
           mais au moins ces nombres prennent en compte toutes les
           sources de latence, tant logicielles que matrielles. Dans
           la plupart des cas, les temps de latence rseau ne durent
           que quelques microsecondes. Des nombres beaucoup plus
           grands refltent les couches des matriels et logiciels
           inefficaces.

   Disponibilit :

           Reprise telle quelle, cette ligne dcrit la forme sous
           laquelle vous pouvez acqurir ce type de matriel. Le
           matriel de la grande distribution est disponible
           largement et de plusieurs fabricants, le prix tant alors
           le premier critre de choix. Les choses proposes par
            diffrents fabricants  sont disponibles chez plus d'un
           seul concurrent, mais il existe des diffrences
           significatives, et des problmes potentiels
           d'interoprabilit. Les rseaux produits par un
            fabricant exclusif  vous laissent  la merci de ce
           fournisseur, aussi bienveillant soit-il.  Domaine
           public  signifie que mme si vous ne pouvez trouver
           quelqu'un pour vous vendre ce type de matriel, vous ou
           n'importe qui d'autre pouvez acheter les composants et en
           fabriquer un exemplaire. C'est typiquement le cas des
           prototypes de recherche. Ils ne sont en gnral ni prts 
           tre utiliss par le public, ni disponibles  celui-ci.

   Port ou bus utilis :

           La manire dont on relie l'interface rseau 
           l'ordinateur. Les meilleures performances (et dsormais
           les plus courantes) s'obtiennent avec le bus PCI. Il
           existe aussi des cartes pour bus EISA, VESA local bus
           (VLB), et ISA. ISA fut le premier, et il est toujours
           utilis par les cartes aux basses performances. On trouve
           toujours l'EISA comme bus secondaire dans les machines
           PCI. Ces derniers temps, on ne trouve plus beaucoup de
           matriel  base de VLB (mme si la Video Electronics
           Standards Association [http://www.vesa.org] voit les
           choses autrement).

           Bien sr, toute interface que vous pouvez utiliser sans
           avoir  ouvrir le botier de votre PC est plus
           qu'attrayante. les interfaces IrDA (N.D.T. : port
           infrarouge) et USB font leur apparition de plus en plus
           frquemment. Le Port Parallle Standard (SPP) est
           longtemps rest  ce sur quoi vous branchiez votre
           imprimante , mais s'est avr dernirement tre trs
           utile comme extension du bus ISA. Cette nouvelle fonction
           est amliore par le standard IEEE 1284, qui spcifie les
           optimisations EPP et ECP. Il y a aussi le bon vieux port
           srie RS232, lent mais fiable. Je n'ai eu vent d'aucun
           tmoignage concernant l'interconnexion de machines par le
           biais des connecteurs vido (VGA), clavier, souris ou
           joystick...

   Structure du rseau :

           Un bus est un fil, un ensemble de fils, ou une fibre
           (optique). Un hub ( concentrateur  ou  plaque
           tournante ) est une petite boite qui peut recevoir
           diffrents types de fils ou de fibres. Les commutateurs
           ( switched hubs ) permettent  plusieurs connexions de
           transmettre activement et simultanment leurs donnes.

   Cot par machine relie :

           Voici comment lire ces nombres. Supposons que, en dehors
           des connexions rseau, acheter un PC comme unit de votre
           cluster vous cote 2000 dollars. L'ajout de Fast Ethernet
           porte le prix  l'unit  environ 2400 dollars. L'ajout de
           Myrinet mne ce prix  3800 dollars environ. Si vous avez
           20 000 dollars  dpenser, vous pouvez alors avoir soit 8
           machines relies par du Fast Ethernet, soit 5 machines
           relies par du Myrinet. Il est galement trs raisonnable
           d'utiliser plusieurs types de rseaux. Par exemple, avec
           20 000 dollars, vous pouvez vous offrir 8 machines relies
           entre elles par Fast Ethernet et TTL_PAPERS. Choisissez un
           rseau -- ou un ensemble de rseaux -- qui permettra 
           votre cluster d'excuter votre application le plus
           rapidement possible.

           Au moment o vous lirez ces lignes, ces chiffres seront
           faux... En fait, ils le sont srement dj. Il peut aussi
           y avoir un grand nombre de rductions, d'offres spciales,
           et ctera. Mais en tout cas, les prix cits ici ne seront
           jamais suffisamment errons pour vous conduire  faire un
           choix totalement inappropri. Nul besoin d'avoir un
           doctorat (mme si c'est mon cas ;-) pour constater que
           l'utilisation de rseaux onreux n'a de sens que si votre
           application a rellement besoin de leurs proprits ou si
           les PC utiliss dans votre cluster sont eux aussi
           relativement chers.

   Maintenant que vous tes avertis, place au spectacle...

    3.2.1. ArcNet

     o Prise en charge par Linux : pilotes du noyau

     o Bande passante maximum : 2,5 Mbits/s

     o Temps de latence minimum : 1000 microsecondes ?

     o Disponibilit : diffrents fabricants

     o Port ou bus utilis : ISA

     o Structure du rseau : Hub ou bus non commuts (anneau logique)

     o Cot par machine relie : 200 dollars

   ARCNET est un rseau local principalement destin  tre utilis
   dans les systmes de contrle temps rel embarqus. Comme
   Ethernet, le rseau est physiquement organis en prises le long
   d'un bus d'un ou plusieurs hubs. En revanche, et contrairement 
   Ethernet, il utilise un protocole  base de jetons qui structure
   de manire logique le rseau comme un anneau. Les enttes des
   paquets sont rduites (3 ou 4 octets) et les messages peuvent tre
   trs courts (jusqu' un seul octet). De fait, ARCNET est plus
   efficace qu'Ethernet. Malheureusement, il est aussi plus lent, et
   moins populaire ce qui le rend plus cher. Vous trouvez plus
   d'informations sur le site de l'ARCNET Trade Association
   [http://www.arcnet.com/].

    3.2.2. ATM

     o Prise en charge par Linux : pilotes du noyau, bibliothques
       AAL*

     o Bande passante maximum : 155 Mbits/s (bientt, 1200 Mbits/s)

     o Temps de latence minimum : 120 microsecondes

     o Disponibilit : diffrents fabricants

     o Port ou bus utilis : PCI

     o Structure du rseau : hubs commuts

     o Cot par machine relie : 3000 dollars

   A moins d'avoir t dans le coma ces dernires annes, vous avez
   srement beaucoup entendu dire qu'ATM ( Asynchronous Transfer
   Mode ) est l'avenir... Eh bien, en quelque sorte. ATM est
   meilleur march que HiPPI et plus rapide que Fast Ethernet, et il
   peut tre utilis sur de trs longues distances, ce qui intresse
   beaucoup les oprateurs tlphoniques. Le protocole du rseau ATM
   est galement conu pour fournir une interface logicielle aux
   temps d'accs rduits et grant plus efficacement les messages
   courts et les communications en temps rel (c'est--dire les
   transmissions audio et vido numriques). C'est aussi l'un des
   rseaux aux plus hauts dbits que Linux prenne actuellement en
   charge. La mauvaise nouvelle, c'est qu'ATM n'est pas vraiment bon
   march, et qu'il demeure encore des problmes de compatibilit
   entre fabricants. Un aperu du dveloppement ATM sous Linux est
   disponible sur http://linux-atm.sourceforge.net/
   [http://linux-atm.sourceforge.net/].

    3.2.3. CAPERS

     o Prise en charge par Linux : bibliothque AFAPI

     o Bande passante maximum : 1,2 Mbit/s

     o Temps de latence maximum : 3 microsecondes

     o Disponibilit : grande distribution

     o Port ou bus utilis : SPP (port parallle)

     o Structure du rseau : cble entre 2 machines

     o Cot par machine relie : 2 dollars

   CAPERS ( Cable Adapter for Parallel Execution and Rapid
   Synchronisation  :  Adaptateur par Cble pour l'Excution en
   Parallle et la Synchronisation Rapide ) est un produit driv du
   projet PAPERS, de l'University School of Electrical and Computer
   Engineering de Purdue. En substance, ce projet dfinit un
   protocole logiciel permettant d'utiliser une simple liaison
   point--point par le port parallle, type  LapLink , pour
   implmenter la bibliothque PAPERS sur deux PC sous Linux. L'ide
   n'est exploitable  grande chelle, mais le prix est imbattable.
   Tout comme avec TTL_PAPERS, pour amliorer la scurit du systme,
   il est recommand, mais pas ncessaire, d'appliquer un correctif
   mineur au noyau.

    3.2.4. Ethernet

     o Prise en charge par Linux : pilotes du noyau

     o Bande passante maximum : 10 Mbits/s

     o Latence minimum : 100 microsecondes

     o Disponibilit : grande distribution

     o Port ou bus utilis : PCI

     o Structure du rseau : commutateurs ou concentrateurs, ou mme
       bus simple

     o Cot par machine connecte : 100 dollars (sans concentrateur,
       50 dollars)

   Depuis plusieurs annes maintenant, l'Ethernet  10Mbits/s est le
   standard des technologies rseau. Une bonne carte Ethernet
   s'achte pour moins de 50 dollars, et bon nombre de PC en sont
   aujourd'hui quips de srie, l'interface tant intgre  la
   carte-mre. Les rseaux  base Ethernet dont la charge n'est pas
   trs leve peuvent tre organiss comme un long bus  prises
   multiples sans concentrateur ( hub ). Une telle configuration
   peut servir jusqu' 200 machines pour un cot minimal, mais n'est
   pas approprie au traitement en parallle. Ajouter un
   concentrateur non commut n'amliore pas beaucoup les
   performances. En revanche, les commutateurs ( switches ), qui
   peuvent offrir une bande passante maximum  plusieurs connexions
   simultanment ne cotent qu'aux alentours de 100 dollars par port.
   Linux prend en charge un nombre impressionnant d'interfaces
   Ethernet diffrentes, mais il est important de garder  l'esprit
   que les variations entre ces matriels peuvent engendrer de
   grandes diffrences de performance. Consultez le Guide pratique de
   la compatibilit matrielle avec Linux
   [http://www.traduc.org/docs/howto/lecture/Hardware-HOWTO.html]
   (N.D.T. : version franaise du Hardware Compatibility HOWTO
   [http://www.tldp.org/HOWTO/Hardware-HOWTO/]) pour plus
   d'informations concernant les diffrents quipements fonctionnant
   sous Linux, et pour avoir une ide de leur qualit.

   Le cluster Linux  16 machines ralis dans le cadre du projet
    Beowulf [http://www.beowulf.org]  (initialement dvelopp au
   CESDIS de la NASA) est une manire intressante d'augmenter ses
   performances. C'est  Donald Becker, auteur de plusieurs pilotes
   de cartes Ethernet, que l'on doit la prise en charge de la
   rpartition du trafic au travers de plusieurs cartes rseau
   s'clipsant mutuellement (autrement dit, partageant les mmes
   adresses rseau). Cette fonction est intgre en standard dans
   Linux, et s'effectue de manire invisible en dessous du niveau des
   oprations sur les sockets. Le cot d'un hub n'tant pas
   ngligeable, relier chaque machine  deux (ou plus) rseaux
   Ethernet, sans hubs ni switches, pour amliorer les performances
   peut s'avrer financirement trs rentable. D'une manire
   gnrale, dans les situations o une machine est le goulet
   d'tranglement d'un rseau, la rpartition de charge  travers
   plusieurs rseaux ( shadow networks ) se rvle bien plus
   efficace que l'usage d'un rseau quip d'un commutateur seul.

    3.2.5. Ethernet (Fast Ethernet)

     o Prise en charge par Linux : pilotes du noyau

     o Bande passante maximum : 100 Mbits/s

     o Temps de latence minimum : 80 microsecondes

     o Disponibilit : grande distribution

     o Port ou bus utilis : PCI

     o Structure du rseau : concentrateurs ou commutateurs (hubs ou
       switches)

     o Cot par machine connecte : 400 dollars (?)

   Bien qu'il existe un certain nombre de technologies diffrentes
   nommes  Fast Ethernet , elles se rfrent souvent  un rseau
   Ethernet 100 Mbits/s en grande partie compatible avec les anciens
   cbles et priphriques 10 Mbits/s type  10 BaseT . Comme on
   peut s'y attendre, tout ce qui s'appelle Ethernet bnficie des
   prix de la vente de masse, et ces interfaces ne cotent
   gnralement qu'une fraction du prix des cartes ATM  155 Mbits/s.
   Le problme est qu'une collection de machines partageant tous le
   mme  bus   100 Mbits/s ( l'aide d'un hub non commut) peut
   prsenter des performances n'atteignant en moyenne mme pas celles
   d'un rseau 10 Mbits/s utilisant un commutateur fournissant 
   chaque machine une connexion 10 Mbits/s complte.

   Les commutateurs pouvant fournir une connexion 100 Mbits  chaque
   machine simultanment sont chers, mais les prix chutent chaque
   jour, et ces commutateurs offrent une bande passante autrement
   plus leve que de simples hubs non commuts. Ce qui rend les
   commutateurs ATM si onreux est la ncessit de commuter chaque
   cellule ATM, cellule relativement courte. Certains commutateurs
   Ethernet parient sur une frquence de commutation attendue
   relativement lente et en tirent profit en utilisant des techniques
   aux temps de latence rduits  l'intrieur du commutateur, mais
   ncessitant quelques millisecondes pour changer de voie. Si
   l'itinraire de votre trafic rseau change frquemment, vitez ce
   type d'quipement.

   Notez aussi que, comme pour Ethernet, le projet Beowulf
   (http://www.beowulf.org [http://www.beowulf.org]) de la NASA
   dveloppe des pilotes aux performances suprieures car utilisant
   la rpartition de charge entre plusieurs cartes Fast Ethernet.

    3.2.6. Ethernet (Gigabit Ethernet)

     o Prise en charge par Linux : pilotes du noyau

     o Bande passante maximum : 1000 Mb/s

     o Temps de latence minimum : 300 microsecondes (?)

     o Disponibilit : diffrents fabricants

     o Port ou bus utilis : PCI

     o Structure rseau : commutateurs ou FDR

     o Cot par machine connecte : 2500 dollars (?)

   Je ne suis pas sr que Gigabit Ethernet
   [http://www.gigabit-ethernet.org/] ait une raison technologique
   valable de s'appeler Ethernet... mais son nom inspire le fait que
   Gigabit Ethernet est conu pour tre une technologie rseau bon
   march et de grande distribution, avec une prise en charge native
   de l'IP. En revanche, les prix actuels refltent le fait que cela
   reste un produit difficile  fabriquer.

   Contrairement aux autres technologies Ethernet, Gigabit Ethernet
   apporte un contrle du flux, ce qui devrait en faire un rseau
   plus fiable. Les FDR, ou  Full-Duplex Repeaters  ( rpteurs
   bidirectionnels simultans ), se contentent de multiplexer les
   lignes, en utilisant des mmoires tampons et des contrles de flux
   localiss pour amliorer les performances. La plupart des
   commutateurs sont construits comme de nouveaux modules pour les
   diffrents modles de commutateurs compatible Gigabit dj
   existants. Les commutateurs ou FDR sont distribus ou annoncs par
   au moins Acacianet, Bay networks [http://www.baynetworks.com/],
   Cabletron [http://www.cabletron.com/] (dsormais Enterasys. Page
   franaise : http://www.enterasys.com/fr/
   [http://www.enterasys.com/fr/]), Networks digital, Extreme
   networks [http://www.extremenetworks.com/homepage_french.asp],
   Foundry networks [http://www.foundrynet.com/], Gigalabs.com,
   Packet engines, Plaintree systems [http://www.plaintree.com/],
   Prominet [http://www.prominet.com/], Sun microsystems
   [http://fr.sun.com/], et Xlnt.

   Il existe un pilote pour Linux pour les  Yellowfin  G-NIC de
   Packet Engines^[11]. Les premiers essais sous Linux ont fait tat
   d'un taux de transfert environ 2,5 fois suprieur  la plus rapide
   des cartes Fast Ethernet  100 Mbits/s. Avec les rseaux Gigabit,
   une configuration soigneuse du bus PCI est un facteur critique. Il
   reste toujours un doute quant  la poursuite des amliorations de
   ce pilote, et du dveloppement des pilotes Linux des autres cartes
   rseau.

    3.2.7. FC ( Fibre Channel )

     o Prise en charge par Linux : non^[12]

     o Bande passante maximum : 1062 Mbits/s

     o Temps de latence minimum : ?

     o Disponibilit : diffrents fabricants

     o Interface ou bus utilis : PCI (?)

     o Structure du rseau : ?

     o Cot par machine connecte : ?

   L'objectif du FC ( Fibre Channel ) est de fournir un mdium
   d'entre/sortie de type bloc aux performances leves (une trame
   FC transporte un bloc de donnes d'une longueur forfaitaire de
   2048 octets), particulirement adapt aux partages de disques et
   autres priphriques de stockage, qui peuvent alors tre relis
   directement au rseau FC plutt qu' travers un ordinateur. Niveau
   bande passante, le FC est prsent comme tant relativement
   rapide, avec un taux s'tendant de 133  1062 Mbits/s. Si le FC
   tend  devenir populaire en tant que solution haut-de-gamme de
   remplacement du SCSI, il pourrait rapidement devenir une
   technologie trs abordable. Pour le moment, ce n'est pas
   abordable, et ce n'est pas pris en charge par Linux. La Fibre
   Channel Association tient une importante collection de rfrences
   au FC, sur http://www.fibrechannel.org
   [http://www.fibrechannel.org]^[13].

    3.2.8. FireWire (IEEE 1394)

     o Prise en charge par Linux : non^[14]

     o Bande passante maximum : 196,608 Mbits/s (bientt, 393,216
       Mbits/s)

     o Temps de latence minimum : ?

     o Disponibilit : diffrents fabricants

     o Interface ou bus utilis : PCI

     o Structure du rseau : alatoire, sans cycles (auto-configur)

     o Cot par machine connecte : 600 dollars

   FireWire, ou standard IEEE 1394-1995, est vou  tre le rseau
   numrique  grande vitesse et  prix rduit des appareils
   lectroniques domestiques. Son application-phare est la connexion
   des camscopes numriques aux ordinateurs, mais FireWire est
   destin  tre utilis dans des domaines s'tendant de
   l'alternative au SCSI jusqu' l'interconnexion des diffrents
   composants de votre  Home Cinma . Il vous permet de relier plus
   de 64000 priphriques dans une topologie utilisant des bus et des
   ponts mais ne formant pas de boucle, et dtecte automatiquement la
   configuration des priphriques lorsqu'ils sont ajouts ou
   retirs. Les messages courts (les  quadlets , longs de quatre
   octets) sont galement pris en charge, de mme que les
   transmissions isochrones sur le modle de l'ATM (utilises pour
   prserver le synchronisme des messages multimdia). Adaptec
   propose des produits FireWire permettant de relier jusqu' 63
   priphriques  une seule carte PCI, et tient aussi un bon site
   d'information gnrale concernant le FireWire sur
   http://www.adaptec.com
   [http://www.adaptec.com/worldwide/product/prodtechindex.html?cat=%2fTechnology%2fFireWire-1394&prodkey=1394_summary].

   Bien que le FireWire ne soit pas le rseau le plus rapide
   disponible actuellement, le march de la grande distribution (qui
   tire les prix vers le bas) et les temps de latence rduits
   pourraient en faire d'ici l'an prochain la meilleure interface
   rseau pour le message passing dans un cluster de PC sous Linux.

    3.2.9. HiPPI et Serial HiPPI

     o Prise en charge par Linux : non^[15]

     o Bande passante maximum : 1600 Mbits/s (1200 Mb/s pour Serial
       HiPPI)

     o Temps de latence minimum : ?

     o Disponibilit : diffrents fabricants

     o Interface ou bus utilis : EISA, PCI

     o Structure du rseau : commutateurs

     o Cot par machine connecte : 3500 dollars (4,500 dollars pour
       Serial HiPPI)

   HiPPI ( High Performance Parallel Interface , soit  Interface
   Parallle aux Performances leves ) tait initialement cense
   fournir un taux de transfert lev pour l'change d'immenses blocs
   de donnes entre un supercalculateur et une autre machine (un
   autre supercalculateur, un  frame buffer , une batterie de
   disques, et ctera), et est devenu le standard dominant dans le
   monde des supercalculateurs. Bien que ce soit un oxymoron, Serial
   HiPPI devient galement trs populaire en utilisant typiquement de
   la fibre optique  la place des cbles HiPPI standard de 32 bits
   de large (donc parallles). Ces dernires annes, les commutateurs
   HiPPI en croix sont devenus courants et les prix ont srieusement
   chut. Malheureusement, les quipement HiPPI Srie, eux, sont
   encore trs onreux, et sont en gnral les seuls pris en charge
   par le bus PCI. Pire, Linux ne gre pas encore HiPPI. Le CERN
   tient une bonne prsentation d'HiPPI sur
   http://www.cern.ch/HSI/hippi/ [http://www.cern.ch/HSI/hippi/]. Ils
   tiennent aussi une liste assez longue de distributeurs proposant
   le HiPPI sur http://www.cern.ch/HSI/hippi/procintf/manufact.htm
   [http://www.cern.ch/HSI/hippi/procintf/manufact.htm].

    3.2.10. IrDA ( Infrared Data Association )

     o Prise en charge par Linux : non (?)^[16]

     o Bande passante maximum : 1,15 Mbits/s et 4 Mbits/s

     o Temps de latence minimum : ?

     o Disponibilit : Diffrents fabricants

     o Interface ou bus utilis : IrDA

     o Structure rseau : Air libre ;-)

     o Cot par machine connecte : 0

   L'IrDA ( Infrared Data Association  ou  Association de Donnes
   par Infrarouges , sur http://www.irda.org [http://www.irda.org]),
   c'est ce petit appareil  infrarouges sur le cot des ordinateurs
   portables. Il reste assez difficile, par conception, de relier
   plus de deux ordinateurs par ce biais, aussi l'IrDA ne se
   prte-t-il gure  la  clusterisation , ou mise en parallle
   massive de nombreuses machines. Don Becker est toutefois l'auteur
   de quelques travaux prliminaires sur l'IrDA.

    3.2.11. Myrinet

     o Prise en charge par Linux : bibliothques

     o Bande passante maximum : 1280 Mbits/s

     o Temps de latence minimum : 9 microsecondes

     o Disponibilit : matriel propritaire.

     o Interface ou bus utiliss : PCI

     o Structure du rseau : commutateurs

     o Cot par machine connecte : 1800 dollars

   Myrinet [http://www.myri.com] est un rseau local (LAN :  Local
   Area Network ) conu pour servir galement de rseau systme
   ^[17]. Les versions LAN et SAN utilisent des mdias physiques
   distincts et leur caractristiques sont sensiblement diffrentes.
   La version SAN est gnralement utilise au sein d'un cluster.

   La structure de Myrinet est trs conventionnelle, mais a la
   rputation d'tre trs bien implmente. Les pilotes pour Linux
   sont connus pour donner de trs bons rsultats, bien qu'il et t
   fait tat de frappantes diffrences de performances d'une
   implmentation du bus PCI  l'autre.

   Actuellement, Myrinet est assurment le rseau favori des
   responsables de clusters n'tant pas trop svrement limit au
   niveau budgtaire. Si, pour vous, un PC Linux typique est un
   Pentium Pro dernier cri ou un Pentium II avec au moins 256 Mo de
   mmoire vive, et un disque RAID et SCSI, alors le cot de Myrinet
   apparat raisonnable. En revanche, avec des machines plus
   conventionnelles, il vous faudra probablement choisir entre relier
   N machines avec Myrinet, ou 2N machines avec plusieurs quipements
   de type  Fast Ethernet  ou  TTL_PAPERS . Tout cela dpend
   rellement de votre budget et du type de calcul qui vous importe
   le plus.

    3.2.12. Parastation

     o Prise en charge par Linux : couches d'abstraction ( HAL ) ou
       bibliothques rseau

     o Bande passante maximum : 125 Mbits/s

     o Temps de latence minimum : 2 microsecondes

     o Disponibilit : fabricant exclusif

     o Interface ou bus utilis : PCI

     o Structure du rseau : maillage, sans concentrateur

     o Cot par machine connecte : plus de 1000 dollars

   Le projet ParaStation (http://wwwipd.ira.uka.de/parastation
   [http://wwwipd.ira.uka.de/parastation]) de la section informatique
   de l'Universit de Karlsruhe est en train de mettre sur pieds un
   rseau  maison  compatible PVM et aux temps de latence rduits.
   Ils ont d'abord construit un prototype de ParaPC biprocesseur en
   utilisant une carte EISA conue sur mesure et des PC fonctionnant
   sous Unix BSD, puis ont bti de plus grands clusters composs de
   machines Alpha DEC. Depuis Janvier 1997, Parastation est
   disponible sous Linux. Les cartes PCI sont produites en
   coopration avec une socit nomme Hitex [http://www.hitex.com].
   Le matriel de Parastation implmente  la fois un systme de
   transmission de messages rapide et fiable, et des barrires de
   synchronisation simples.

    3.2.13. PLIP

     o Prise en charge par Linux : pilotes du noyau

     o Bande passante maximum : 1,2 Mbits/s

     o Temps de latence minimum : 1000 microsecondes ?

     o Disponibilit : grande distribution

     o Interface ou bus utilis : SPP

     o Structure du rseau : cble entre 2 machines

     o Cot par machine connecte : 2 dollars

   Pour le seul cot d'un cble  LapLink  (N.D.T. : cble parallle
   crois), PLIP ( Parallel Line Interface Protocol , soit
    Protocole d'Interface par Ligne Parallle ) permet  deux
   machines Linux de communiquer par le port parallle en utilisant
   les couches logicielles standard bases sur la communication par
    sockets . En termes de bande passante, de temps de latence et
   d'volutivit, il ne s'agit pas d'une technologie rseau srieuse.
   En revanche, le cot de revient quasi-nul et la compatibilit
   logicielle s'avrent tre trs utiles. Le pilote est partie
   intgrante du noyau Linux standard.

    3.2.14. SCI

     o Prise en charge par Linux : non

     o Bande passante maximum : 4000 Mbit/s

     o Temps de latence minimum : 2,7 microsecondes

     o Disponibilit : diffrents fabricants.

     o Interface ou bus utilis : PCI et propritaire

     o Structure rseau : ?

     o Cot par machine connecte : + de 1000 dollars

   L'objectif de SCI (Scalable Coherent Interconnect, ANSI/IEEE
   1596-1992) consiste essentiellement  fournir un mcanisme de
   haute performance pouvant assurer des accs cohrents  la mmoire
   partage au travers d'un grand nombre de machines. On peut dire
   sans se mouiller que la bande passante et les temps de latences de
   SCI sont  trs impressionnants  compars  la plupart des autres
   technologies rseau. Le problme est que SCI n'est pas trs
   rpandu et reste donc assez onreux, et que ce matriel n'est pas
   pris en charge par Linux.

   SCI est principalement utilis dans diverses implmentations
   propritaires pour des machines  mmoire partage logiquement et
   distribue physiquement, comme le HP/Convex Exemplar SPP et le
   Sequent NUMA-Q 2000 (voir http://www.sequent.com
   [http://www.sequent.com]^[18]). Ceci dit, SCI est disponible sous
   forme de carte PCI et de commutateurs quatre ports de Dolphin (on
   peut relier ainsi jusqu' 16 machines en montant ces commutateurs
   en cascade), http://www.dolphinics.com
   [http://www.dolphinics.com], sous la srie "Clustar". Le CERN
   tient  jour une bonne collection de liens concernant SCI sur
   http://www.cern.ch/HSI/sci/sci.html
   [http://www.cern.ch/HSI/sci/sci.html].

    3.2.15. SCSI

     o Prise en charge par Linux : pilotes du noyau

     o Bande passante maximum : de 5 Mbits/s  plus de 20 Mbits/s

     o Temps de latence minimum : ?

     o Disponibilit : diffrents fabricants

     o Interface ou bus utilis : cartes PCI, EISA ou ISA

     o Structure du rseau : bus inter-machines partageant des
       priphriques SCSI

     o Cot par machine connecte : ?

   Le SCSI (Small Computer Systems Interconnect) consiste
   essentiellement en un bus d'entre/sortie utilis par les disques
   durs, les lecteurs de CD-ROM, les numriseurs ( scanners ), et
   ctera. Il existe trois standards distincts : SCSI-1, SCSI-2 et
   SCSI-3, en vitesses "Fast" et "Ultra" et en largeur de bus de 8,
   16 ou 32 bits (avec compatibilit FireWire annonce pour SCSI-3).
   Tout cela est plutt confus, mais nous savons tous qu'un bon SCSI
   est bien plus rapide que l'EIDE, et peut grer plus de
   priphriques, plus efficacement.

   Ce que beaucoup de gens ne ralisent pas, c'est qu'il est trs
   simple de partager le mme bus SCSI entre deux ordinateurs. Ce
   type de configuration est trs utile pour partager des disques
   entre deux machines et mettre en place un systme de fail-over, de
   faon  ce qu'une machine prenne  sa charge les requtes  une
   base de donnes lorsque l'autre machine tombe en panne. C'est
   actuellement le seul mcanisme reconnu par le cluster PC de
   Microsoft : WolfPack. En revanche, l'incapacit du SCSI  voluer
   vers de plus grands systmes le rend en gnral inintressant pour
   le traitement en parallle.

    3.2.16. ServerNet

     o Prise en charge par Linux : non

     o Maximum bandwidth : 400 Mbits/s

     o Temps de latence minimum : 3 microsecondes

     o Disponibilit : fabricant exclusif

     o Interface ou bus utilis : PCI

     o Structure du rseau : arbre hexagonal / concentrateurs en
       mailles ttradriques

     o Cot par machine connecte : ?

   ServerNet est la solution rseau de haute performance propose par
   Tandem (http://www.tandem.com [http://www.tandem.com]). Dans le
   monde du traitement des transactions en ligne ( OnLine Transation
   Processing , ou  OLTP ) en particulier, Tandem est rput tre
   l'un des premiers fabricants de systmes de haute fiabilit, aussi
   n'est-il pas surprenant que leurs rseaux ne revendiquent pas
   simplement la haute performance, mais aussi la  haute fiabilit
   et intgrit des donnes . Une autre facette intressante de
   ServerNet : ce matriel serait capable de transfrer des donnes
   directement de priphrique  priphrique, pas simplement entre
   processeurs, mais galement entre disques durs, et ctera, dans un
   style unilatral similaire  ce qui a t suggr pour les
   mcanismes d'accs  distance  la mmoire du MPI, dcrits dans la
   section 3.5. Un dernier mot  propos de Servernet : Bien qu'il n'y
   ait qu'un seul fabricant, celui-ci est suffisamment puissant pour
   faire tablir potentiellement Servernet en tant que standard
   majeur : Tandem appartient  Compaq^[19].

    3.2.17. SHRIMP

     o Prise en charge par Linux : interface utilisateur  mmoire
       mappe

     o Bande passante maximum : 180 Mbits/s

     o Temps de latence minimum : 5 microsecondes

     o Disponibilit : prototype exprimental

     o Interface ou bus utilis : EISA

     o Structure du rseau : Fond de panier en maille (comme pour le
       Paragon d'Intel)

     o Cot par machine connecte : ?

   Le projet SHRIMP [http://www.cs.princeton.edu/shrimp/] de la
   section des sciences des ordinateurs de l'Universit de Princeton,
   met sur pieds un ordinateur parallle en utilisant dont les
   lments de traitement sont des ordinateurs PC sous Linux. Le
   premier SHRIMP ( Scalable, High-Performance, Really Inexpensive
   Multi-Processor , soit  multiprocesseur volutif et de hautes
   performances vraiment bon march ) tait un simple prototype
   biprocesseur utilisant une mmoire partage sur une carte EISA
   dveloppe pour l'occasion. Il existe dsormais un prototype
   pouvant voluer vers de plus larges configurations en utilisant
   une interface  maison  pour se connecter  une sorte de
   concentrateur, essentiellement conu comme le rseau de routage en
   mailles utilis dans le Paragon d'Intel. Des efforts considrables
   ont t faits pour dvelopper une lectronique de  communication
   mappe en mmoire virtuelle  aux overheads rduits, avec sa
   couche logicielle.

    3.2.18. SLIP

     o Prise en charge par Linux : pilotes du noyau

     o Bande passante maximum : 0,1 Mbits/s

     o Temps de latence minimum : 1000 microsecondes ?

     o Disponibilit : grande distribution

     o Interface ou bus utilis : RS232C

     o Structure du rseau : cble entre deux machines

     o Cot par machine connecte : 2 dollars

   Mme si SLIP ( Serial Line Interface Protocol ) se situe
   dfinitivement au pied de l'chelle des performances, ce protocole
   (tout comme CSLIP ou PPP) permet  deux machines de communiquer en
   utilisant les  sockets  et ce au travers d'un cble RS232
   ordinaire. Les ports RS232 peuvent tre relis  l'aide d'un cble
   srie type NULL-MODEM, ou mme au travers d'une ligne tlphonique
   en utilisant des modems. Dans tous les cas, les temps de latence
   sont levs, et la bande passante rduite. Aussi, SLIP ne devrait
   tre utilis qu'en dernier recours. En revanche, la plupart des PC
   sont dots de deux ports RS232. Il doit donc tre possible de
   relier un groupe de machines sous forme de rseau linaire ou
   d'anneau. Il existe mme un logiciel de rpartition de la charge
   appel EQL.

    3.2.19. TTL_PAPERS

     o Prise en charge par Linux : bibliothque AFAPI

     o Bande passante maximum : 1,6 Mbits/s

     o Temps de latence minimum : 3 microsecondes

     o Disponibilit : conception dans le domaine public, fabricant
       exclusif

     o Interface ou bus utilis : SPP (port parallle)

     o Structure du rseau : arbre de concentrateurs

     o Cot par machine connecte : 100 dollars

   Le projet PAPERS ( Purdue's Adapter for Parallel Execution and
   Rapid Synchronization , soit  Adaptateur pour l'Excution en
   Parallle et la Synchronisation Rapide de l'universit de
   Purdue ), men par la Purdue University School of Electrical and
   Computer Engineering ( cole Suprieure d'lectricit et
   d'Ingnierie en Informatique ), dveloppe un ensemble logiciel et
   matriel volutif et aux temps de latence rduits pour les
   communications des fonctions d'agrgation, permettant de mettre
   sur pieds un supercalculateur en parallle utilisant comme nuds
   des PC d'origine, non modifis.

   Plus d'une douzaine de versions de cartes  PAPERS , relies au
   PC  la station de travail via le port parallle standard (SPP :
    Standard Parallel Port ), ont t construites, en suivant
   globalement deux grands axes. Les versions estampilles  PAPERS 
   visent les hautes performances, quelle que soit la technologie la
   plus indique, la version actuelle utilisant des FPGA (N.D.T. :
   famille de rseaux logiques programmables), et des modles
   d'interfaces PCI  haut dbit sont actuellement  l'tude. Par
   opposition, les versions nommes  TTL_PAPERS  sont conues pour
   tre facilement reproduites hors de l'universit de Purdue, et
   s'appuient sur des modles du domaine public remarquablement
   simples et qui peuvent tre mis en place en utilisant de la
   logique TTL ordinaire. L'une de ces versions est produite
   commercialement.

   Contrairement au matriel sur mesure conu par d'autres
   universits, des clusters TTL_PAPERS ont t assembls dans
   plusieurs coles depuis les tats-Unis jusqu'en Core du Sud. La
   bande passante est svrement limite par la connectivit du port
   parallle, mais PAPERS met en uvre des fonctions d'agrgation aux
   temps de latence trs rduits. Mme les systmes orients messages
   les plus rapides ne peuvent offrir de telles performances sur ces
   fonctions d'agrgation. Ainsi, PAPERS est particulirement
   performant dans la synchronisation des diffrents crans d'un mur
   vido ( dbattre dans le Video-Wall-HOWTO actuellement en
   prparation), pour planifier les accs  un rseau  haut dbit,
   pour valuer les probabilits en recherche gntique, et ctera.
   Mme si des clusters PAPERS ont t construits en utilisant AIX
   d'IBM sur PowerPC, des DEC Alpha OSF/1, ou HP-UX sur HP PA-RISC,
   le PC sous Linux reste la plate-forme la mieux prise en charge.

   Les programmes utilisateur utilisant l'AFAPI de TTL_PAPERS
   attaquent directement les registres matriels du port parallle
   sous Linux, sans effectuer d'appel systme  chaque accs. Pour ce
   faire, l'AFAPI demande d'abord les droits d'accs au port
   parallle en utilisant soit iopl(), soit ioperm(). Le problme est
   que, l'un comme l'autre, ces appels obligent le programme appelant
    tre privilgi, ce qui introduit une faille de scurit
   potentielle. La solution rside en un correctif optionnel 
   appliquer au noyau Linux et permettant  un processus privilgi
   de contrler les permissions d'accs aux ports d'entre/sortie
   pour n'importe quel autre processus.

    3.2.20. USB ( Universal Serial Bus )

     o Prise en charge par Linux : pilotes du noyau

     o Bande passante maximum : 12 Mbits/s

     o Temps de latence minimum : ?

     o Disponibilit : dans le commerce

     o Interface ou bus utilis : USB

     o Structure du rseau : bus

     o Cot par machine connecte : 5 dollars

   USB ( Universal Serial Bus , http://www.usb.org
   [http://www.usb.org]) est un bus fonctionnant  la vitesse de
   l'Ethernet conventionnel, dont les priphriques qui s'y
   rattachent peuvent tre connects  chaud ( Hot-Plug  : sans
   imposer la mise hors tension pralable du bus) et pouvant
   accueillir simultanment jusqu' 127 de ces priphriques pouvant
   s'tendre du clavier  la camra de vido-confrence. La manire
   dont on relie plusieurs ordinateurs par le biais de l'USB n'est
   pas clairement dfinie. Quoi qu'il en soit, les ports USB sont en
   train de s'tablir trs rapidement en standard sur les
   cartes-mres, au mme titre que le port srie RS232 ou le port
   parallle, aussi ne soyez pas surpris si vous voyez apparatre un
   ou deux ports USB ^[20] sur votre prochain PC.

   D'une certaine manire, l'USB est pratiquement la version basse
   performance  prix nul du FireWire que l'on peut se procurer
   aujourd'hui.

    3.2.21. WAPERS

     o Prise en charge par Linux : bibliothque AFAPI

     o Bande passante maximum : 0,4 Mbits/s

     o Temps de latence : 3 microsecondes

     o Disponibilit : modle dans le domaine public

     o Interface ou bus utilis : SPP (Port Parallle Standard)

     o Structure du rseau : modle de cblage entre 2  64 machines

     o Cot par machine connecte : 5 dollars

   WAPERS ( Wired-AND Adapter for Parallel Execution and Rapid
   Synchronization , soit  Adaptateur par ET Cbl pour l'Excution
   en Parallle et la Synchronisation Rapide ) est une des facettes
   du projet PAPERS, de la Purdue University School of Electrical and
   Computer Engineering ( cole Suprieure d'lectricit et
   d'Ingnierie en Informatique ). S'il est construit proprement, le
   port parallle possde quatre bits de sortie  collecteur ouvert
   qui peuvent tre cbls entre eux pour former un ET cbl de 4
   bits de large. Ce ET cbl est assez sensible lectriquement, et
   le nombre maximum de machines qui peuvent y tre relies dpend de
   faon critique des proprits analogiques des ports (les limites
   maximum des puits de courant et les valeurs des rsistances de
   pull-up). On peut typiquement relier 7  8 machines en rseau de
   cette faon, avec WAPERS. Bien que les cots et les temps de
   latences soient trs rduits, la bande passante l'est aussi.
   WAPERS est donc bien plus indiqu comme rseau secondaire ddi
   aux fonctions d'agrgations que comme unique rseau d'un cluster.
   Comme pour TTL_PAPERS, il existe un correctif noyau visant 
   amliorer la scurit, recommand mais non requis.

  3.3. Interface Logicielle Rseau

   Avant d'explorer les ressources logicielles existantes en matire
   de traitement en parallle, il est utile de couvrir rapidement les
   bases de l'interface logicielle de bas niveau grant
   l'lectronique du rseau. Il n'existe en ralit que trois options
   de base : les sockets, les pilotes de priphriques et les
   bibliothques utilisateur.

    3.3.1. Les sockets

   Le socket est de loin la plus courante des interfaces rseau de
   bas niveau. Les sockets sont partie intgrante d'Unix depuis plus
   d'une dcennie et la plupart des standards dans le domaine du
   matriel lectronique de rseau est conue pour prendre en charge
   au moins deux types de protocoles de socket : TCP et UDP. Ces deux
   types de sockets vous permettent d'envoyer des blocs de donnes
   d'une longueur arbitraire d'une machine  l'autre, mais il existe
   plusieurs diffrences importantes. Typiquement, ils engendrent
   tous deux un temps de latence minimum d'environ 1000
   microsecondes, mme si les performances peuvent bien pires encore
   en fonction du trafic.

   Ces types de sockets constituent l'interface logicielle rseau de
   base pour la majorit des logiciels de traitement en parallle
   portables et de plus haut niveau. Par exemple, PVM utilise une
   combinaison de l'UDP et du TCP, aussi en connatre les diffrences
   vous aidera  affiner les performances de votre systme. Ce qui
   suit n'est qu'un aperu de TCP et UDP. Rfrez-vous aux pages du
   manuel et  un bon livre de programmation pour plus de dtails.

      3.3.1.1. Le protocole UDP (SOCK_DGRAM)

   UDP signifie  User Datagram Protocol  ou  Protocole de
   Datagrammes Utilisateur  mais il est plus facile de se souvenir
   des proprits d'UDP en tant que  Unreliable Datagram
   Processing , ou  Traitement des Datagrammes Peu fiable . En
   d'autres termes, UDP permet  chaque bloc d'tre mis comme un
   message individuel, mais un message peut tre perdu pendant la
   transmission. De fait, selon l'tat du trafic sur le rseau,
   certains messages UDP peuvent tre perdus, arriver plusieurs fois,
   ou arriver dans un ordre diffrent de celui dans lequel ils ont
   t mis. L'expditeur d'un message UDP ne reoit pas
   systmatiquement d'accus de rception, et c'est donc au programme
   crit par l'utilisateur qu'il appartient de dtecter et compenser
   ces problmes. Heureusement, le protocole UDP garantit que si un
   message arrive, son contenu sera intact (c'est--dire que vous ne
   recevrez jamais un message incomplet).

   Le bon cot de l'UDP est qu'il tend  tre le plus rapide des
   protocoles des socket. En outre, UDP est  orient hors
   connexion  ( connectionless ), ce qui signifie que chaque
   message est essentiellement indpendant des autres. On peut
   comparer chaque message  une lettre  La Poste. Vous pouvez
   envoyer plusieurs lettres  la mme adresse, mais chacune d'entre
   elles est indpendante des autres, et vous n'tes pas limit quant
   aux nombre de personnes  qui vous pouvez en envoyer.

      3.3.1.2. Le protocole TCP (SOCK_STREAM)

   Contrairement  l'UDP, le TCP est un protocole fiable et orient
   connexion. Chaque bloc est considr non pas comme un message,
   mais comme un bloc de donnes appartenant  un flot d'octets
   voyageant au travers d'une connexion tablie entre l'expditeur et
   le destinataire. Ce principe est trs diffrent du systme de
   messages de l'UDP car chaque bloc n'est qu'une partie du flot
   d'octets, et il appartient au programme utilisateur de trouver le
   moyen de les isoler car il n'y a aucune marque de sparation pour
   les distinguer. De plus, les connexions sont plus vulnrables aux
   perturbations du rseau, et seul un nombre limit de connexions
   simultanes peut exister au sein d'un mme processus. Parce qu'il
   est fiable, le TCP engendre souvent des overheads plus importants
   que l'UDP.

   Le TCP rserve en revanche quelques bonnes surprises. Par exemple,
   si plusieurs messages sont envoys  travers une connexion, TCP
   est capable de les rassembler dans une mmoire tampon pour mieux
   correspondre aux tailles standard des paquets de l'lectronique du
   rseau, ce qui peut donner de meilleurs rsultats que l'UDP dans
   le cas de groupes de messages courts ou de taille inhabituelle. Un
   autre avantage : Les rseaux btis sur des connexions physiques
   directes entre deux machines peuvent facilement et efficacement
   tre assimils  des connexions TCP. Ce fut le cas pour la
    Socket Library  ( bibliothque de gestion de Sockets ),
   prsentant une gestion compatible TCP au niveau de l'utilisateur
   qui ne diffrait des appels systmes TCP standard que par le
   prfixe PSS, que l'on rajoutait au dbut du nom des fonctions 
   invoquer.

    3.3.2. Les pilotes de priphriques

   Lorsque l'on en arrive au stade o il faut effectivement injecter
   des donnes sur le rseau ou les y en extraire, l'interface
   logicielle des Unix standard fait partie du noyau et s'appelle
    pilote  ( driver ). UDP et TCP ne se contentent pas de
   transporter des donnes, ils s'accompagnent galement d'importants
   overheads dus  la gestion des sockets. Par exemple, il faut que
   quelque chose s'occupe du fait que plusieurs connexions TCP
   peuvent partager la mme interface rseau physique. Par
   opposition, un pilote de priphrique ddi  une interface rseau
   n'a besoin de mettre en uvre qu'un petit nombre de fonctions de
   transport lmentaires. Ces pilotes peuvent alors tre invoqus 
   l'aide de l'appel open() pour identifier le priphrique adquat,
   puis en utilisant par exemple read() et write() sur le  fichier 
   ouvert. Ainsi, chaque opration peut transporter un bloc de
   donnes en cotant  peine plus cher qu'un appel systme, ce qui
   permet d'atteindre des dlais de l'ordre de quelques dizaines de
   microsecondes.

   crire un pilote de priphrique pour Linux n'est pas difficile...
   pourvu que vous sachiez parfaitement comme fonctionne votre
   priphrique. Si vous n'en tes pas sr, n'essayez pas de le
   deviner. Dboguer un pilote de priphrique n'est pas une chose
   amusante, et faire des erreurs peut coter la vie  votre
   matriel. En revanche, si ces risques ne vous effraient pas, il
   est possible d'crire un pilote pour, par exemple, utiliser des
   cartes Ethernet ddies comme des connexions machine-vers-machine
    btes  mais trs rapides car exonres du protocole Ethernet
   habituel. Pour tre exact, c'est pratiquement la technique
   utilise par les premiers supercalculateurs Intel. Rfrez-vous au
   Device-Driver-HOWTO pour plus d'informations.

    3.3.3. Bibliothques utilisateurs

   Si vous avez pris des cours de programmation systme, on a d vous
   y apprendre qu'accder directement aux registres matriels des
   priphriques  partir d'un programme utilisateur tait l'exemple
   typique de ce qu'il ne faut pas faire, parce que l'un des
   principes mme d'un systme d'exploitation est de contrler
   l'accs aux priphriques. Cependant, le simple fait de passer un
   appel systme cote au minimum quelques dizaines de microsecondes.
   Dans le cas d'interfaces rseau bties sur mesure comme
   TTL_PAPERS, qui peut effectuer des oprations de base sur un
   rseau en seulement 3 microsecondes, un tel surcot pour un appel
   systme est intolrable. Le seul moyen d'viter ce temps d'attente
   est de faire en sorte que du code s'excutant au niveau de
   l'utilisateur, donc une  bibliothque au niveau de
   l'utilisateur  ^[21], puisse accder directement au matriel,
   mais sans remettre en cause la souverainet du systme
   d'exploitation sur la gestion des droits d'accs aux ressources
   matrielles.

   Sur un systme typique, les seuls moyens, pour une bibliothque
   utilisateur, d'accder directement aux registres du matriel sont
   les suivants :

    1. Au lancement du programme utilisateur, faire un appel systme
       pour mapper l'espace d'adressage qui contient les registres du
       priphrique dans le plan mmoire du processus utilisateur.
       Sur certains systmes, l'appel systme mmap() (trait pour la
       premire fois dans la section 2.6) peut tre utilis pour
       mapper un fichier spcial reprsentant les adresses de la page
       de mmoire physique du priphrique. Il est en mme temps
       relativement simple d'crire un pilote de priphrique
       effectuant cette opration. De plus, ce pilote peut obtenir
       l'accs en ne mappant que la ou les pages qui contiennent les
       registres ncessaires, en maintenant ainsi le contrle des
       droits d'accs sous la coupe du systme d'exploitation.

    2. Accder ensuite aux registres du priphrique sans passer par
       un appel systme en se contentant de charger ou de ranger des
       valeurs sur la plage d'adressage mappe. Par exemple, un
       *((char *) 0x1234) = 5; dposera un octet de valeur 5 
       l'adresse mmoire 1234 en hexadcimal.

   Par bonheur, il se trouve que Linux pour Intel 386 et compatibles
   offre une solution meilleure encore :

    1. En invoquant l'appel systme ioperm() depuis un processus
       privilgi, obtenir la permission d'accder aux ports
       d'entre/sortie correspondant prcisment aux registres du
       priphrique. Paralllement, ces permissions peuvent tre
       gres par un processus utilisateur privilgi et indpendant
       (autrement dit : un  mta-systme d'exploitation ) en
       utilisant l'appel systme giveioperm(), disponible sous la
       forme d'un correctif  appliquer au noyau Linux.

    2. Accder aux registres du priphrique sans appel systme en
       utilisant les instructions assembleur d'accs aux ports
       d'entre/sortie du 386.

   Cette seconde solution est prfrable car il arrive souvent que
   les registres de plusieurs priphriques soient runis sur une
   mme page, auquel cas la premire mthode ne pourrait offrir de
   protection contre l'accs aux autres registres rsidant dans la
   mme page que ceux appartenant au priphrique concern.
   L'inconvnient est que ces instructions ne peuvent bien sr pas
   tre crites en langage C. Il vous faudra  la place utiliser un
   peu d'assembleur. La fonction utilisant l'assembleur en ligne
   intgr  GCC (donc utilisable dans les programmes C) permettant
   de lire un octet depuis un port est la suivante :

 extern inline unsigned char
 inb(unsigned short port)
 {
     unsigned char _v;
 __asm__ __volatile__ ("inb %w1,%b0"
                       :"=a" (_v)
                       :"d" (port), "0" (0));
     return _v;
 }

   La fonction symtrique permettant l'mission d'un octet est :

 extern inline void
 outb(unsigned char value,
 unsigned short port)
 {
 __asm__ __volatile__ ("outb %b0,%w1"
                       :/* pas de valeur retourne */
                       :"a" (value), "d" (port));
 }

  3.4. PVM ( Parallel Virtual Machine )

   PVM (pour  Parallel Virtual Machine , soit  Machine Virtuelle
   en Parallle ) est une bibliothque de message-passing portable
   et disponible gratuitement, s'appuyant gnralement directement
   sur les sockets. Cette bibliothque s'est incontestablement
   tablie comme le standard de facto dans le domaine du traitement
   en parallle  l'aide de clusters  transmission de messages.

   PVM prend en charge les machines Linux monoprocesseur et SMP,
   comme les clusters de machines Linux relies entre elles  l'aide
   par des rseaux reconnaissant les sockets (donc SLIP, PLIP,
   Ethernet, ATM). En fait, PVM fonctionnera mme  travers un groupe
   de machines utilisant diffrents types de processeurs, de
   configurations et de rseaux physiques -- Un cluster htrogne --
   mme si l'envergure de ce cluster est de l'ordre de la mise en
   parallle de machines en utilisant Internet pour les relier entre
   elles. PVM offre mme des facilits de contrles de tches
   ( jobs ) en parallle au travers d'un cluster. Cerise sur le
   gteau, PVM est disponible gratuitement et depuis longtemps
   (actuellement sur http://www.epm.ornl.gov/pvm/pvm_home.html
   [http://www.epm.ornl.gov/pvm/pvm_home.html]), ce qui a conduit bon
   nombre de langages de programmation, de compilateurs, et d'outils
   de dbogage ou autres  l'adopter comme leur  bibliothque cible
   portable de message-passing . Il existe galement un groupe de
   discussion : [1]news:comp.parallel.pvm.

   Il est important de remarquer, en revanche, que les appels PVM
   ajoutent gnralement aux oprations socket un overhead non
   ngligeable alors que les temps de latence de celles-ci sont dj
   importants. En outre, les appels eux-mmes ne sont pas aiss 
   manipuler.

   Applique au mme exemple de calcul de Pi dcrit en section 1.3,
   la version PVM du programme en langage C est la suivante :

 #include <stdlib.h>
 #include <stdio.h>
 #include <pvm3.h>

 #define NPROC   4

 main(int argc, char **argv)
 {
   register double sommelocale, largeur;
   double somme;
   register int intervalles, i;
   int mytid, iproc, msgtag = 4;
   int tids[NPROC];  /* Tableau des numros des tches */

   /* Dbut du traitement avec PVM */
   mytid = pvm_mytid();

   /*  Je rejoins le groupe et, si je suis la premire instance,
      iproc=0, je cre plusieurs copies de moi-mme. 
   */
   iproc = pvm_joingroup("pi");

   if (iproc == 0) {
     tids[0] = pvm_mytid();
     pvm_spawn("pvm_pi", &argv[1], 0, NULL, NPROC-1, &tids[1]);
   }
   /* On s'assure que tous les processus sont prts  */
   pvm_barrier("pi", NPROC);

   /* Rcupre le nombre d'intervalles */
   intervalles = atoi(argv[1]);
   largeur = 1.0 / intervalles;

   sommelocale = 0.0;
   for (i = iproc; i<intervalles; i+=NPROC) {
     register double x = (i + 0.5) * largeur;
     sommelocale += 4.0 / (1.0 + x * x);
   }

   /* On ajuste les rsultats locaux en fonction de la largeur */
   somme = sommlocale * largeur;
   pvm_reduce(PvmSum, &sum, 1, PVM_DOUBLE, msgtag, "pi", 0);

   /* Seul le processus rattach  la console renvoie le rsultat */
   if (iproc == 0) {
     printf("Estimation de la valeur de pi: %f\n", somme);
   }

   /* On attend que le programme soit termin,
      on quitte le groupe et
          on sort de PVM. */
   pvm_barrier("pi", NPROC);
   pvm_lvgroup("pi");
   pvm_exit();
   return(0);
 }

  3.5. MPI ( Message Passing Interface )

   Bien que PVM soit le standard de fait en matire de bibliothque
   de message-passing, MPI ( Message Passing Interface ) tend 
   devenir le nouveau standard officiel. Le site du standard MPI se
   trouve sur http://www.mcs.anl.gov:80/mpi/
   [http://www.mcs.anl.gov:80/mpi/] et le groupe de discussion
   correspondant sur [2]news:comp.parallel.mpi.

   En revanche, avant d'explorer MPI, je me sens oblig de parler
   rapidement de la guerre de religion qui oppose PVM  MPI et qui
   dure depuis quelques annes. Je ne penche ni pour l'un ni pour
   l'autre. Voici un rsum aussi impartial que possible des
   diffrences entre les deux interfaces :

   Environnement de contrle de l'excution

           Pour faire simple, PVM en a un, et MPI ne prcise pas s'il
           existe, ni comment il doit tre implment. Cela signifie
           que certaines choses comme lancer l'excution d'un
           programme PVM se fait de la mme manire partout, alors
           que pour MPI, cela dpend de l'implmentation utilise.

   Prise en charge des clusters htrognes.

           PVM a grandi dans le monde de la collecte des cycles
           machines inutiliss sur les stations de travail, et sait
           donc grer donc directement les mlanges htrognes de
           machines et de systmes d'exploitation. A contrario, MPI
           part du principe gnral que la cible est un MPP
           ( Massively Parallel Processor , soit  Processeur
           Massivement Parallle ) ou un cluster ddi de stations
           de travail pratiquement toutes identiques.

   Syndrome de l'vier.

           PVM se rvle tre conu pour une catgorie d'utilisation
           bien dfinie, ce que MPI 2.0 ne fait pas. Le nouveau
           standard MPI 2.0 inclut une varit de fonctionnalits qui
           s'tendent bien au del du simple modle de
           message-passing, comme le RMA ( Remote Memory Access ,
           soit  Accs Mmoire  Distance ) ou les oprations
           d'entre/sortie en parallle sur les fichiers. Toutes ces
           choses sont-elles bien utiles ? Assurment... mais
           assimiler MPI 2.0 est comparable  rapprendre depuis zro
           un langage de programmation totalement nouveau.

   Conception de l'interface utilisateur.

           MPI a t conu aprs PVM, et en a incontestablement tir
           les leons. MPI offre une gestion des tampons plus simple
           et plus efficace et une couche d'abstraction de
           haut-niveau permettant de transmettre des donnes dfinies
           par l'utilisateur comme des messages.

   Force de loi.

           Pour ce que j'ai pu en voir, il existe toujours plus
           d'applications conues autour de PVM qu'autour de MPI.
           Nanmoins, porter celles-ci vers MPI est chose facile, et
           le fait que MPI soit soutenu par un standard formel trs
           rpandu signifie que MPI est, pour un certain nombre
           d'institutions, une question de vision des choses.

   Conclusion ? Disons qu'il existe au moins trois versions de MPI
   dveloppes de faon indpendante et disponibles gratuitement
   pouvant fonctionner sur des clusters de machines Linux (et j'ai
   crit l'un d'eux) :

     o LAM ( Local Area Multicomputer , soit  MultiOrdinateur
       Local ) est une mise en uvre complte du standard 1.1. Il
       permet aux programmes MPI de s'excuter sur un systme Linux
       individuel ou au travers d'un cluster de systmes Linux
       communiquant par le biais de sockets TCP/UDP. Le systme
       inclut des facilits de base de contrle de l'excution, ainsi
       que toute une gamme d'outils de dveloppement et de dbogage
       de programmes.

     o MPICH ( MPI CHameleon ) est conu pour tre une
       implmentation complte et hautement portable du standard MPI
       1.1. Tout comme LAM, il permet aux programmes MPI d'tre
       excuts sur des systmes Linux individuels ou en clusters via
       une communication par socket TCP/UDP. En revanche, l'accent
       est port sur la promotion de MPI en fournissant une
       implmentation efficace et facilement repositionnable. Pour
       porter cette implmentation, il faut rimplmenter soit les
       cinq fonctions de la  channel interface , soit, pour de
       meilleures performances, la totalit de l'ADI ( Abstract
       Device Interface , soit  Interface Priphrique
       Abstraite ). MPICH, et beaucoup d'informations concernant ce
       sujet et la faon de le porter, sont disponibles sur
       http://www.mcs.anl.gov/mpi/mpich/
       [http://www.mcs.anl.gov/mpi/mpich/].

     o AFMPI ( Aggregate Function MPI ) est une sous-implmentation
       du standard MPI 2.0. C'est celle que j'ai crite. S'appuyant
       sur AFAPI, elle est conue pour tre la vitrine des RMA et des
       fonctions de communications collectives, et n'offre donc qu'un
       soutien minimal des types MPI, de ses systmes de
       communication, et ctera. Elle permet  des programmes C
       utilisant MPI d'tre excuts sur un systme Linux individuel
       ou au travers d'un cluster mis en rseau par du matriel
       pouvant prendre en charge l'AFAPI.

   Quelque soit l'implmentation MPI utilise, il est toujours trs
   simple d'effectuer la plupart des types de communication.

   En revanche, MPI 2.0 incorpore plusieurs paradigmes de
   communication suffisamment diffrents entre eux fondamentalement
   pour qu'un programmeur utilisant l'un d'entre eux puisse ne mme
   pas reconnatre les autres comme tant des styles de programmation
   MPI. Aussi, plutt que d'explorer un seul exemple de programme, il
   est utile de passer en revue un exemple de chacun des (diffrents)
   paradigmes de communication de MPI. Tous les programmes qui
   suivent emploient le mme algorithme (celui de la section 1.3)
   utilis pour calculer Pi.

   Le premier programme MPI utilise les appels de message-passing MPI
   sur chaque processeur pour que celui-ci renvoie son rsultat
   partiel au processeur 0, qui fait la somme de tous ces rsultats
   et la renvoie  l'cran :

 #include <stdlib.h>
 #include <stdio.h>
 #include <mpi.h>

 main(int argc, char **argv)
 {
   register double largeur;
   double somme, sommelocale;
   register int intervalles, i;
   int nproc, iproc;
   MPI_Status status;

   if (MPI_Init(&argc, &argv) != MPI_SUCCESS) exit(1);
   MPI_Comm_size(MPI_COMM_WORLD, &nproc);
   MPI_Comm_rank(MPI_COMM_WORLD, &iproc);
   intervalles = atoi(argv[1]);
   largeur = 1.0 / intervalles;
   sommelocale = 0;
   for (i=iproc; i<intervalles; i+=nproc) {
     register double x = (i + 0.5) * largeur;
     sommelocale += 4.0 / (1.0 + x * x);
   }
   sommelocale *= largeur;
   if (iproc != 0) {
     MPI_Send(&lbuf, 1, MPI_DOUBLE, 0, 0, MPI_COMM_WORLD);
   } else {
     somme = sommelocale;
     for (i=1; i<nproc; ++i) {
       MPI_Recv(&lbuf, 1, MPI_DOUBLE, MPI_ANY_SOURCE,
                MPI_ANY_TAG, MPI_COMM_WORLD, &status);
       somme += sommelocale;
     }
     printf("Estimation de la valeur de pi: %f\n", somme);
   }
   MPI_Finalize();
   return(0);
 }

   Le second programme MPI utilise les communications collectives
   (qui, pour ce cas prcis, sont incontestablement les plus
   appropries) :

 #include <stdlib.h>
 #include <stdio.h>
 #include <mpi.h>

 main(int argc, char **argv)
 {
   register double largeur;
   double somme, sommelocale;
   register int intervalles, i;
   int nproc, iproc;

   if (MPI_Init(&argc, &argv) != MPI_SUCCESS) exit(1);
   MPI_Comm_size(MPI_COMM_WORLD, &nproc);
   MPI_Comm_rank(MPI_COMM_WORLD, &iproc);
   intervalles = atoi(argv[1]);
   largeur = 1.0 / intervalles;
   sommelocale = 0;
   for (i=iproc; i<intervalles; i+=nproc) {
     register double x = (i + 0.5) * largeur;
     sommelocale += 4.0 / (1.0 + x * x);
   }
   sommelocale *= largeur;
   MPI_Reduce(&sommelocale, &somme, 1, MPI_DOUBLE,
              MPI_SUM, 0, MPI_COMM_WORLD);
   if (iproc == 0) {
     printf("Estimation de la valeur de pi: %f\n", somme);
   }
   MPI_Finalize();
   return(0);
 }

   La troisime version MPI utilise le mcanisme RMA de MPI 2.0 sur
   chaque processeur pour ajouter la valeur locale de la variable
   sommelocale de ce dernier  la variable somme du processeur 0 :

 #include <stdlib.h>
 #include <stdio.h>
 #include <mpi.h>

 main(int argc, char **argv)
 {
   register double largeur;
   double somme = 0, sommelocale;
   register int intervalles, i;
   int nproc, iproc;
   MPI_Win somme_fen;

   if (MPI_Init(&argc, &argv) != MPI_SUCCESS) exit(1);
   MPI_Comm_size(MPI_COMM_WORLD, &nproc);
   MPI_Comm_rank(MPI_COMM_WORLD, &iproc);
   MPI_Win_create(&somme, sizeof(somme), sizeof(somme),
                  0, MPI_COMM_WORLD, &somme_fen);
   MPI_Win_fence(0, somme_fen);
   intervalles = atoi(argv[1]);
   largeur = 1.0 / intervalles;
   sommelocale = 0;
   for (i=iproc; i<intervalles; i+=nproc) {
     register double x = (i + 0.5) * largeur;
     sommelocale += 4.0 / (1.0 + x * x);
   }
   sommelocale *= largeur;
   MPI_Accumulate(&sommelocale, 1, MPI_DOUBLE, 0, 0,
                  1, MPI_DOUBLE, MPI_SUM, somme_fen);
   MPI_Win_fence(0, somme_fen);
   if (iproc == 0) {
     printf("Estimation de la valeur de pi: %f\n", somme);
   }
   MPI_Finalize();
   return(0);
 }

   Il est utile de prciser que le mcanisme RMA de MPI 2.0 prvient
   de faon remarquable tout problme de structures de donnes se
   trouvant  des adresses mmoires diffrentes selon les
   processeurs, en se rfrant  une "fentre" incluant l'adresse de
   base, une protection contre les accs mmoire hors de porte, et
   mme le rchelonnement d'adresse.  une implmentation efficace,
   s'ajoute le fait qu'un traitement RMA peut-tre report jusqu' la
   prochaine MPI__Win_fence. Pour faire simple, le mcanisme RMA est
   un trange croisement entre mmoire partage distribue et message
   passing, mais reste une interface trs propre pouvant gnrer des
   communications trs efficaces.

  3.6. AFAPI ( Aggregate Function API )

   Contrairement  PVM, MPI, et ctera, l'interface AFAPI
   ( Aggregate Function API , ou  Interface  Fonctions
   d'Agrgation ) n'a pas dbut sa vie en tant que couche
   d'abstraction portable s'appuyant sur un rseau matriel ou
   logiciel existant. AFAPI tait plutt la bibliothque de gestion
   bas niveau d'un matriel spcifique pour PAPERS ( Purdue's
   Adapter for Parallel Execution and Rapid Synchronization , soit
    Adaptateur pour l'Excution en Parallle et la Synchronisation
   Rapide de l'universit de Purdue ).

   PAPERS a t rapidement prsent dans la section 3.2. Il s'agit
   d'un rseau  fonction d'agrgations conu sur mesure dont le
   modle est dans domaine public et qui prsente des temps de
   latence infrieurs  quelques microsecondes. Mais surtout, il
   s'agit de la tentative de construction d'un supercalculateur
   formant une meilleure cible pour la technologie des compilateurs
   que les supercalculateurs dj existants. Il se distingue en
   qualit de la plupart des efforts en matire de clusters Linux et
   de PVM/MPI, qui s'attachent gnralement  essayer d'exploiter les
   rseaux standard au profit des rares applications en parallle
   prsentant une granularit suffisante. Le fait que les lments de
   PAPERS soient des machines PC sous Linux ne sert qu' permettre
   l'implmentation de prototypes  des cots les plus avantageux
   possibles.

   La ncessit d'avoir une interface logicielle de bas niveau
   commune  plus d'une douzaine d'implmentations diffrentes d'un
   prototype a conduit la bibliothque PAPERS  tre standardise
   sous le nom d'AFAPI. Mais le modle utilis par AFAPI est simple
   en lui-mme et bien plus adapt aux interactions  la granularit
   plus fine, typiquement du code compil par des compilateurs
   parallliss, ou crit pour des architectures SIMD. Non seulement
   la simplicit du modle rend les machines PAPERS aises 
   construire, mais elle apporte galement une efficacit surprenante
   aux ports d'AFAPI sur diffrents types de systme, tels que les
   SMP.

   AFAPI fonctionne actuellement sur des clusters Linux utilisant
   TTL_PAPERS, CAPERS ou WAPERS. Elle fonctionne galement (sans
   appel systme ni mme instruction de verrouillage de bus, voir la
   section 2.2) sur les machines SMP utilisant une bibliothque de
   gestion de mmoire partage type System V ( System V Shared
   Memory ) appele SHMAPERS. Une version fonctionnant sur des
   clusters Linux utilisant la diffusion UDP sur des rseaux
   conventionnels (Ex : Ethernet) est en cours de dveloppement.
   Toutes les versions d'AFAPI sont crites pour tre appeles 
   partir des langages C ou C++.

   L'exemple suivant est la version AFAPI du programme de calcul de
   Pi dcrit dans la section 1.3.

 #include <stdlib.h>
 #include <stdio.h>
 #include "afapi.h"

 main(int argc, char **argv)
 {
   register double largeur, somme;
   register int intervalles, i;

   if (p_init()) exit(1);

   intervalles = atoi(argv[1]);
   largeur = 1.0 / intervalles;

   sum = 0;
   for (i=IPROC; i<intervalles; i+=NPROC) {
     register double x = (i + 0.5) * largeur;
     somme += 4.0 / (1.0 + x * x);
   }

   somme = p_reduceAdd64f(somme) * largeur;

   if (IPROC == CPROC) {
     printf("Estimation de la valeur de pi: %f\n", somme);
   }

   p_exit();
   return(0);
 }

  3.7. Autres bibliothques de gestion de clusters

   Outre PVM, MPI et AFAPI, les bibliothques suivantes proposent des
   services qui peuvent s'avrer utiles au travers de grappes de
   machines Linux. Ces systmes sont traits ici de manire moins
   approfondie simplement parce que, contrairement  PVM, MPI et
   AFAPI, je n'ai que peu, voire aucune exprience pratique de
   l'utilisation de ceux-ci sur des clusters Linux. Si l'une de ces
   bibliothques (ou mme d'autres) vous est particulirement utile,
   merci de m'envoyer un courrier lectronique en anglais  <hankd
   CHEZ engr POINT uky POINT edu> en me dtaillant vos dcouvertes.
   J'envisagerai alors d'ajouter une section plus complte  son
   sujet.

    3.7.1. Condor (migration de processus)

   Condor est un systme de gestion de ressources distribues qui
   peut diriger de vastes clusters de stations de travail
   htrognes. Sa conception a t motive par les besoins des
   utilisateurs souhaitant utiliser la puissance inexploite de tels
   clusters au profit de leurs tches aux temps d'excution prolongs
   et aux calculs intensifs. Condor reproduit dans une large mesure
   l'environnement de la machine initiale sur celle qui excute le
   processus, mme si ces deux machines ne partagent pas un systme
   de fichier ou un mcanisme de mot de passe communs. Les tches
   sous Condor qui se rsument  un processus unique sont
   automatiquement interceptes et dplaces entre les diffrentes
   stations en fonctions des besoins pour les mener  terme.

   Condor est disponible sur http://www.cs.wisc.edu/condor/
   [http://www.cs.wisc.edu/condor/]. Une version Linux existe
   galement. Contactez l'administrateur du site, <condor TIRET admin
   CHEZ cs POINT wisc POINT edu>, pour plus de dtails.

    3.7.2. DFN-RPC (Rseau Allemand de la Recherche --  Remote
    Procedure Call )

   Le DFN-RPC (un outil du Rseau Allemand de la Recherche --
    Remote Procedure Call ) a t dvelopp pour distribuer et
   parallliser des applications d'intret scientifique ou technique
   entre une station de travail et un serveur de calcul ou un
   cluster. L'interface est optimise pour les applications crites
   en Fortran, mais le DFN-RPC peut aussi tre utilis dans un
   environnement de langage C. Une version Linux a t crite. Plus
   d'information sur
   [3]ftp://ftp.uni-stuttgart.de/pub/rus/dfn_rpc/README_dfnrpc.html.

    3.7.3. DQS ( Distributed Queueing System )

   Pas vraiment une bibliothque, DQS 3.0 ( Distributed Queueing
   System , soit  Systme de Files d'attente Distribues ) est un
   systme de mise en file d'attente des tches qui a t dvelopp
   et test sous Linux. Ce systme a t conu pour permettre  la
   fois l'utilisation et l'administration d'un cluster de machines
   htrognes comme une seule entit. Disponible sur
   http://www.scri.fsu.edu/~pasko/dqs.html
   [http://www.scri.fsu.edu/~pasko/dqs.html].

   Il existe aussi une version commerciale nomme CODINE 4.1.1
   ( COmputing in DIstributed Network Environments , soit  CAlcul
   en Environnement Rseau Distribu ).

  3.8. Rfrences gnrales aux clusters

   Les clusters peuvent tre construits et utiliss de tellement de
   manires diffrentes que certains groupes ont apport des
   contributions particulirement intressantes. Ce qui suit fait
   rfrence aux diffrents projets lis  la mise en place de
   clusters pouvant avoir un intrt d'ordre gnral. Ceci inclut un
   mlange de rfrences  des clusters spcifiques  Linux et  des
   clusters gnriques. Cette liste est prsente dans l'ordre
   alphabtique.

    3.8.1. Beowulf

   Le projet Beowulf [http://www.beowulf.org/], se focalise sur la
   production de logiciels pour une utilisation de stations de
   travail immdiatement disponibles base sur du matriel PC de
   grande distribution, un rseau  haut dbit interne au cluster, et
   le systme d'exploitation Linux.

   Thomas Sterling a t le principal acteur de Beowulf, et continue
   d'tre un promoteur franc et loquent de l'utilisation de clusters
   Linux dans le domaine du calcul scientifique en gnral.  vrai
   dire, plusieurs groupes parlent  prsent de leur cluster comme de
   systme de  classe Beowulf , et ce mme si la conception de ce
   cluster s'loigne du modle Beowulf officiel.

   Don Becker, apportant son appui au projet Beowulf, a produit
   nombre des pilotes rseau utiliss par Linux en gnral. Plusieurs
   de ces pilotes ont mme t adapts pour tre utiliss sous BSD.
   C'est galement  Don que l'on doit la possibilit, pour certains
   pilotes, de rpartir le trafic rseau  travers plusieurs
   connexions parallles pour augmenter les taux de transfert sans
   utiliser d'onreux commutateurs. Ce type de rpartition de la
   charge rseau tait le principal atout des clusters Beowulf.

    3.8.2. Linux/AP+

   Le projet Linux/AP+ [http://cap.anu.edu.au/cap/projects/linux] ne
   concerne pas exactement le clustering sous Linux, mais s'attache 
   faire fonctionner Linux sur l'AP1000+ de Fujitsu, et  y apporter
   les amliorations appropries en matire de traitement en
   parallle. L'AP1000+ est une machine en parallle  base de SPARC
   et disponible dans le commerce, utilisant un rseau spcifique
   avec une topologie en tore, un taux de transfert de 25Mo/s et un
   temps de latence de 10 microsecondes... Pour faire court, cela
   ressemble beaucoup  un cluster Linux SPARC.

    3.8.3. Locust

   Le projet Locust est en train de mettre au point un systme de
   mmoire partage virtuelle qui utilise les informations obtenues 
   la compilation pour masquer les temps de latence des messages et
   rduire le trafic rseau lors de l'excution.  Pupa  forme la
   base du systme de communication de Locust, et est implment 
   l'aide d'un rseau Ethernet reliant des machines PC 486 sous
   FreeBSD. Et Linux ?

    3.8.4. Midway DSM ( Distributed Shared Memory )

   Midway
   [http://www.cs.cmu.edu/afs/cs.cmu.edu/project/midway/WWW/HomePage.html]
   est une DSM ( Distributed Shared Memory , soit  Mmoire
   Partage Distribue ) logicielle, similaire  TreadMarks. Le bon
   cot rside en l'utilisation d'indications  la compilation plutt
   que de relativement lents mcanismes d'erreur de page, et en sa
   gratuit. Le mauvais cot est cela ne fonctionne pas sur des
   clusters Linux.

    3.8.5. Mosix

   MOSIX apporte des modifications au systme d'exploitation BSD
    BSDI  pour proposer une rpartition de charge rseau ( load
   balancing ) dynamique et une migration de processus premptive au
   travers d'un groupe de PC mis en rseau. C'est un systme trs
   utile non seulement pour le traitement en parallle, mais d'une
   manire gnrale pour utiliser un cluster comme une machine SMP
   volutive. Y aura-t-il une version Linux ? Voyez
   http://www.mosix.org [http://www.mosix.org] pour plus
   d'informations^[22].

    3.8.6. NOW ( Network Of Workstations )

   Le projet NOW ( Network Of Workstations , ou  Rseau de
   Stations de Travail ) de l'universit de Berkeley
   (http://now.cs.berkeley.edu [http://now.cs.berkeley.edu/]) a
   conduit dans une large mesure l'effort pour le calcul en parallle
   en utilisant des rseaux de stations de travail. Bon nombre de
   travaux sont mens l-bas, tous tourns vers la  dmonstration en
   pratique d'un systme  100 processeurs dans les prochaines
   annes . Hlas, ils n'utilisent pas Linux.

    3.8.7. Traitement en parallle avec Linux

   Le site web du  Traitement en parallle avec Linux  ( Parallel
   processing using Linux ), sur http://yara.ecn.purdue.edu/~pplinux
   [http://yara.ecn.purdue.edu/~pplinux]>, est le site officiel de ce
   guide pratique et de plusieurs documents en rapport avec ce thme,
   y compris des prsentations en ligne. Paralllement aux travaux du
   projet PAPERS, l'cole Suprieure d'lectricit et d'Informatique
   de Purdue ( Purdue University School of Electrical and Computer
   Engineering ) reste un leader en matire de traitement en
   parallle. Ce site a t mis en place pour aider les autres 
   utiliser des PC sous Linux pour faire du traitement en parallle.

   Depuis l'assemblage du premier cluster de PC Linux en fvrier
   1994, bien d'autres furent galement assembls  Purdue, dont
   plusieurs quips de murs vidos. Bien que ces clusters
   s'appuyaient sur des machines  base de microprocesseurs 386, 486
   ou Pentium (mais pas de Pentium Pro), Intel a rcemment accord 
   Purdue une donation qui lui permettra de construire plusieurs
   grands clusters de systmes  Pentium II (avec pas moins de 165
   machines par cluster). Mme si tous ces clusters sont ou seront
   quips de rseaux PAPERS, la plupart sont galement dots de
   rseaux conventionnels.

    3.8.8. Pentium Pro Cluster Workshop

   Les 10 et 11 avril 1997, le laboratoire AMES a tenu  Des Moines,
   dans l'tat de l'Iowa aux tats-Unis, le  Pentium Pro Cluster
   Workshop  ( Atelier de clusters Pentium Pro ). Le site web de
   cet atelier, http://www.scl.ameslab.gov
   [http://www.scl.ameslab.gov], renferme une mine d'informations
   concernant les clusters PC, glanes auprs de tous les
   participants.

    3.8.9. TreadMarks DSM ( Distributed Shared Memory )

   La DSM ( Distributed Shared Memory , ou  Mmoire Partage
   Distribue ) est une technique avec laquelle un systme de
   message-passing peut se prsenter et agir comme un SMP. Il existe
   quelques systmes de ce genre, la plupart utilisant les mcanismes
   d'erreur de page du systme d'exploitation pour dclencher la
   transmission des messages. TreadMarks
   [http://www.cs.rice.edu/~willy/TreadMarks/overview.html] est l'un
   des plus efficaces, et fonctionne sur les clusters Linux. La
   mauvaise nouvelle est que  TreadMarks est distribu  un cot
   rduit aux universits et organisations  but non lucratif . Pour
   plus d'informations concernant le logiciel, prenez contact (en
   anglais) avec <tmk CHEZ cs POINT rice POINT edu>.

    3.8.10. U-Net ( User-level NETwork interface architecture )

   Le projet U-Net ( User-level NETwork interface architecture , ou
    Architecture d'interface Rseau au Niveau Utilisateur ),
   accessible sur http://www.eecs.harvard.edu/~mdw/proj/old/unet
   [http://www.eecs.harvard.edu/~mdw/proj/old/unet], tente d'apporter
   temps de latence rduits et taux de transfert levs sur du
   matriel rseau du commerce en virtualisant les interfaces rseau
   de manire  ce que les applications puissent envoyer et recevoir
   des messages sans passer par un appel systme. U-Net fonctionne
   sur des PC Linux en utilisant du matriel Fast Ethernet bas sur
   une puce DEC DC21140, ou une carte ATM Fore Systems PCA-200 (mais
   pas PCA-200E).

    3.8.11. WWT ( Wisconsin Wind Tunnel )

   On trouve bon nombre de projets relatifs  l'utilisation de
   clusters dans le Wisconsin. Le projet WWT ( Wisconsin Wind
   Tunnel , ou  Soufflerie du Wisconsin ), sur
   http://www.cs.wisc.edu/~wwt/ [http://www.cs.wisc.edu/~wwt/], mne
   toutes sortes de travaux orients vers le dveloppement d'une
   interface  standard  entre les compilateurs et le matriel
   rseau sur lequel ils s'appuient. Il existe le  Wisconsin COW 
   (pour  Cluster Of Workstation ),  Cooperative Shared Memory 
   et  Tempest , le  Paradyn Parallel Performance Tools , et
   ctera. Malheureusement, il n'y a pas grand chose concernant
   Linux.

4. SIMD Within A Register : SWAR (Ex : utilisation de MMX)

   Le SIMD ( Single Instruction stream, Multiple Data stream  ou
    Un seul flux d'instruction, plusieurs flux de donnes ) 
   l'Intrieur d'Un Registre (ou  SIMD Within A Register  : SWAR)
   n'est pas un concept rcent. En considrant une machine dote de
   registres, bus de donnes et units de fonctions de k bits, il est
   connu depuis longtemps que les oprations sur les registres
   ordinaires peuvent se comporter comme des oprations parallles
   SIMD sur n champs de k/n bits chacun. Ce n'est en revanche qu'avec
   les efforts rcents en matire de multimdia que l'acclration
   d'un facteur deux  huit apporte par les techniques SWAR a
   commenc  concerner l'informatique gnrale. Les versions de 1997
   de la plupart des microprocesseurs incorporent une prise en charge
   matrielle du SWAR^[23] :

     o AMD K6 MMX ( MultiMedia eXtensions )
       [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/20726.pdf]

     o Sun SPARC V9 VIS ( Visual Instruction Set )
       [http://www.sun.com/sparc/vis/index.html]

   Il existe quelques lacunes dans la prise en charge matrielle
   apporte par les nouveaux microprocesseurs, des caprices comme par
   exemple la prise en charge d'un nombre limit d'instructions pour
   certaines tailles de champ. Il est toutefois important de garder 
   l'esprit que bon nombre d'oprations SWAR peuvent se passer
   d'acclration matrielle. Par exemple, les oprations au niveau
   du bit sont insensibles au partitionnement logique d'un registre.

  4.1. Quels usages pour le SWAR ?

   Bien que tout processeur moderne soit capable d'excuter un
   programme en effectuant un minimum de paralllisme SWAR, il est de
   fait que mme le plus optimis des jeux d'instructions SWAR ne
   peut grer un paralllisme d'intrt vraiment gnral. A dire
   vrai, de nombreuses personnes ont remarqu que les diffrences de
   performance entre un Pentium ordinaire et un Pentium  avec
   technologie MMX  taient surtout des  certains dtails, comme
   le fait que l'augmentation de la taille du cache L1 concide avec
   l'apparition du MMX. Alors, concrtement,  quoi le SWAR (ou le
   MMX) est-il utile ?

     o Dans le traitement des entiers, les plus courts tant les
       meilleurs. Deux valeurs 32 bits tiennent dans un registre MMX
       64 bits, mais forment aussi une chane de huit caractres, ou
       encore permettent de reprsenter un chiquier complet, 
       raison d'un bit par case. Note : il existera une version
        virgule flottante  du MMX, bien que trs peu de choses
       aient t dites  ce sujet. Cyrix a dpos une prsentation,
       [4]ftp://ftp.cyrix.com/developr/mpf97rm.pdf, qui contient
       quelques commentaires concernant MMFP. Apparemment, MMFP
       pourra prendre en charge le chargement de nombres 32 bits en
       virgule flottante dans des registres MMX 64 bits. Ceci combin
        deux pipelines MMFP fournirait quatre FLOP ^[24] en simple
       prcision par cycle d'horloge.

     o Pour le SIMD, ou paralllisme vectoris. La mme opration
       s'applique  tous les champs, simultanment. Il existe des
       moyens d'annihiler ses effets sur des champs slectionns
       (l'quivalent du  SIMD enable masking , ou  activation du
       masquage ), mais ils sont compliqus  mettre en uvre et
       grvent les performances.

     o Pour les cas o la rfrence  la mmoire se fait de manire
       localise et rgulire (et de prfrence regroupe). Le SWAR
       en gnral, et le MMX en particulier se rvlent dsastreux
       sur les accs alatoires. Rassembler le contenu d'un vecteur
       x[y] (o y est l'index d'un tableau) est extrmement coteux.

   Il existe donc d'importantes limitations, mais ce type de
   paralllisme intervient dans un certain nombre d'algorithmes, et
   pas seulement dans les applications multimdia. Lorsque
   l'algorithme est adapt, le SWAR est plus efficace que le SMP ou
   le paralllisme en clusters... et son utilisation ne cote rien !

  4.2. Introduction  la programmation SWAR

   Le concept de base du SWAR ( SIMD Within A Register , ou  SIMD
    l'intrieur d'un registre ) rside dans le fait que l'on peut
   utiliser des oprations sur des registres de la taille d'un mot
   pour acclrer les calculs en effectuant des oprations parallles
   SIMD sur n champs de k/n bits. En revanche, employer les
   techniques du SWAR peut parfois s'avrer maladroit, et certaines
   de leurs oprations peuvent au final tre plus coteuses que leurs
   homologues en srie car elles ncessitent des instructions
   supplmentaires pour forcer le partitionnement des champs.

   Pour illustrer ce point, prenons l'exemple d'un mcanisme SWAR
   grandement simplifi grant quatre champs de 8 bits dans chaque
   registre de 32 bits. Les valeurs de ces deux registres pourraient
   tre reprsentes comme suit :

          PE3     PE2     PE1     PE0
       +-------+-------+-------+-------+
 Reg0  | D 7:0 | C 7:0 | B 7:0 | A 7:0 |
       +-------+-------+-------+-------+
 Reg1  | H 7:0 | G 7:0 | F 7:0 | E 7:0 |
       +-------+-------+-------+-------+

   Ceci indique simplement que chaque registre est vu essentiellement
   comme un vecteur de quatre valeurs entires 8 bits indpendantes.
   Alternativement, les valeurs A et E peuvent tre vues comme les
   valeurs, dans Reg0 et Reg1, de l'lment de traitement 0 (ou
    PE0  pour  Processing Element 0 ), B et F comme celles de
   l'lment 1, et ainsi de suite.

   Le reste de ce document passe rapidement en revue les classes de
   base des oprations parallles SIMD sur ces vecteurs d'entiers et
   la faon dont ces fonctions peuvent tre implmentes.

    4.2.1. Oprations polymorphiques

   Certaines oprations SWAR peuvent tre effectues de faon
   triviale en utilisant des oprations ordinaires sur des entiers 32
   bits, sans avoir  se demander si l'opration est rellement faite
   pour agir en parallle et indpendemment sur ces champs de 8 bits.
   On qualifie ce genre d'opration SWAR de polymorphique, parce que
   la fonction est insensible aux types des champs (et  leur
   taille).

   Tester si un champ quelconque est non-nul est une opration
   polymorphique, tout comme les oprations logiques au niveau du
   bit. Par exemple, un  ET  logique bit--bit ordinaire
   (l'oprateur  &  du registre C) effectue son calcul bit--bit,
   quelque soit la taille des champs. Un  ET  logique simple des
   registres ci-dessus donnerait :

           PE3       PE2       PE1       PE0
       +---------+---------+---------+---------+
 Reg2  | D&H 7:0 | C&G 7:0 | B&F 7:0 | A&E 7:0 |
       +---------+---------+---------+---------+

   Puisque le bit de rsultat k de l'opration  ET  logique n'est
   affect que par les valeurs des bits d'oprande k, toutes les
   tailles de champs peuvent tre prises en charge par une mme
   instruction.

    4.2.2. Oprations partitionnes

   Malheureusement, de nombreuses et importantes oprations SWAR ne
   sont pas polymorphiques. Les oprations arithmtiques comme
   l'addition, la soustraction, la multiplication et la division sont
   sujettes aux interactions de la  retenue  entre les champs. Ces
   oprations sont dites partitionnes car chacune d'elles doit
   cloisonner effectivement les oprandes et le rsultat pour viter
   les interactions entre champs. Il existe toutefois trois mthodes
   diffrentes pouvant tre employes pour parvenir  ces fins :

      4.2.2.1. Instructions partitionnes

   L'approche la plus vidente pour implmenter les oprations
   partitionnes consiste peut-tre  proposer une prise en charge
   matrielle des  instructions parallles partitionnes  coupant
   le systme de retenue entre les champs. Cette approche peut offrir
   les performances les plus leves, mais elle ncessite la
   modification du jeu d'instruction du processeur et implique en
   gnral des limitations sur la taille des champs (Ex : ces
   instructions pourraient prendre en charge des champs larges de 8
   bits, mais pas de 12).

   Le MMX des processeurs AMD, Cyrix et Intel, Le MAX de Digital,
   celui d'HP, et le VIS de Sun implmentent tous des versions
   restreintes des instructions partitionnes. Malheureusement, ces
   diffrents jeux d'instructions posent des restrictions assez
   diffrentes entre elles, ce qui rend les algorithmes difficilement
   portables. tudions  titre d'exemple l'chantillon d'oprations
   partitionnes suivant :

   Instruction           AMD/Cyrix/Intel MMX   DEC MAX   HP MAX   Sun VIS
 +---------------------+---------------------+---------+--------+---------+
 | Diffrence Absolue  |                     |       8 |        |       8 |
 +---------------------+---------------------+---------+--------+---------+
 | Maximum             |                     |   8, 16 |        |         |
 +---------------------+---------------------+---------+--------+---------+
 | Comparaison         |           8, 16, 32 |         |        |  16, 32 |
 +---------------------+---------------------+---------+--------+---------+
 | Multiplication      |                  16 |         |        |    8x16 |
 +---------------------+---------------------+---------+--------+---------+
 | Addition            |           8, 16, 32 |         |     16 |  16, 32 |
 +---------------------+---------------------+---------+--------+---------+

   Dans cette table, les chiffres indiquent les tailles de champ
   reconnues par chaque opration. Mme si la table exclut un certain
   nombre d'instructions dont les plus exotiques, il est clair qu'il
   y a des diffrences. Cela a pour effet direct de rendre
   inefficaces les modles de programmation en langages de haut
   niveau, et de svrement restreindre la portabilit.

      4.2.2.2. Oprations non partitionnes avec code de correction

   Implmenter des oprations partitionnes en utilisant des
   instructions partitionnes est certainement trs efficace, mais
   comment faire lorsque l'opration dont vous avez besoin n'est pas
   prise en charge par le matriel ? Rponse : utiliser une srie
   d'instructions ordinaires pour effectuer l'opration malgr les
   effets de la retenue entre les champs, puis effectuer la
   correction de ces effets indsirs.

   C'est une approche purement logicielle, et les corrections
   apportent bien entendu un surcot en temps, mais elle fonctionne
   pleinement avec le partitionnement en gnral. Cette approche est
   galement  gnrale  dans le sens o elle peut tre utilise
   soit pour combler les lacunes du matriel dans le domaine des
   instructions partitionnes, soit pour apporter un soutien logiciel
   complet aux machines qui ne sont pas du tout dotes d'une prise en
   charge matrielle.  dire vrai, en exprimant ces squences de code
   dans un langage comme le C, on permet au SWAR d'tre totalement
   portable.

   Ceci soulve immdiatement une question : quelle est prcisment
   l'inefficacit des oprations SWAR partitionnes simules  l'aide
   d'oprations non partitionnes ? Eh bien c'est trs certainement
   la question  65536 dollars, mais certaines oprations ne sont pas
   aussi difficiles  mettre en uvre que l'on pourrait le croire.

   Prenons en exemple le cas de l'implmentation de l'addition d'un
   vecteur de quatre lments 8 bits contenant des valeurs entires,
   soit x+y, en utilisant des oprations 32 bits ordinaires.

   Une addition 32 bits ordinaire pourrait en fait rendre un rsultat
   correct, mais pas si la retenue d'un champ de 8 bits se reporte
   sur le champ suivant. Aussi, notre but consiste simplement  faire
   en sorte qu'un tel report ne se produise pas. Comme l'on est sr
   qu'additionner deux champs de k bits ne peut gnrer qu'un
   rsultat large d'au plus k+1 bits, on peut garantir qu'aucun
   report ne va se produire en  masquant  simplement le bit de
   poids fort de chaque champs. On fait cela en appliquant un  ET 
   logique  chaque oprande avec la valeur 0x7f7f7f7f, puis en
   effectuant un addition 32 bits habituelle.

 t = ((x & 0x7f7f7f7f) + (y & 0x7f7f7f7f));

   Ce rsultat est correct... sauf pour le bit de poids fort de
   chacun des champs. Il n'est question, pour calculer la valeur
   correcte, que d'effectuer deux additions 1-bit partitionnes,
   depuis x et y vers le rsultat  7 bits calcul pour t.
   Heureusement, une addition partitionne sur 1 bit peut tre
   implmente  l'aide d'une opration  OU Exclusif  logique
   ordinaire. Ainsi, le rsultat est tout simplement :

 (t ^ ((x ^ y) & 0x80808080))

   D'accord. Peut-tre n'est-ce pas si simple, en fin de compte.
   Aprs tout, cela fait six oprations pour seulement quatre
   additions. En revanche, on remarquera que ce nombre d'oprations
   n'est pas fonction du nombre de champs. Donc, avec plus de champs,
   on gagne en rapidit.  dire vrai, il se peut que l'on gagne quand
   mme en vitesse simplement parce que les champs sont chargs et
   redposs en une seule opration (vectorise sur des entiers), que
   la disponibilit des registres est optimise, et parce qu'il y a
   moins de code dynamique engendrant des dpendances (parce que l'on
   vite les rfrences  des mots incomplets).

      4.2.2.3. Contrler les valeurs des champs

   Alors que les deux autres approches de l'implmentation des
   oprations partitionnes se centrent sur l'exploitation du maximum
   d'espace possible dans les registres, il peut tre, au niveau du
   calcul, plus efficace de contrler les valeurs des champs de faon
    ce que l'interaction de la retenue entre ceux-ci ne se produise
   jamais. Par exemple, si l'on sait que toutes les valeurs de champs
   additionnes sont telles qu'aucun dpassement ne peut avoir lieu,
   une addition partitionne peut tre implmente  l'aide d'une
   instruction ordinaire. Cette contrainte pose, une addition
   ordinaire pourrait en fin de compte apparatre polymorphique, et
   tre utilisable avec n'importe quelle taille de champ sans
   programme de correction. Ce qui nous amne ainsi  la question
   suivante : Comment s'assurer que les valeurs des champs ne vont
   pas provoquer d'vnements dus  la retenue ?

   Une manire de faire cela consiste  implmenter des instructions
   partitionnes capables de restreindre la porte des valeurs des
   champs. Les instructions vectorises de maximum et de minimum du
   MAX de Digital peuvent tre assimiles  une prise en charge
   matrielle de l'crtage des valeurs des champs pour viter les
   interactions de la retenue entre les champs.

   En revanche, si l'on ne dispose pas d'instructions partitionnes 
   mme de restreindre efficacement la porte des valeurs des champs,
   existe-t-il une condition qui puisse tre impose  un cot
   raisonnable et qui soit suffisante pour garantir le fait que les
   effets de la retenue n'iront pas perturber les champs adjacents ?
   La rponse se trouve dans l'analyse des proprits arithmtiques.
   Additionner deux nombres de k bits renvoie un rsultat large d'au
   plus k+1 bits. Ainsi, un champ de k+1 bits peut recevoir en toute
   scurit le rsultat d'une telle opration, mme s'il est produit
   par une instruction ordinaire.

   Supposons donc que les champs de 8 bits de nos prcdents exemples
   soient dsormais des champs de 7 bits avec  espaces de sparation
   pour retenue  d'un bit chacun :

               PE3          PE2          PE1          PE0
       +----+-------+----+-------+----+-------+----+-------+
 Reg0  | D' | D 6:0 | C' | C 6:0 | B' | B 6:0 | A' | A 6:0 |
       +----+-------+----+-------+----+-------+----+-------+

   Mettre en place un vecteur d'additions 7 bits se fait de la
   manire suivante : On part du principe qu'avant l'excution de
   toute instruction partitionne, les bits des sparateurs de
   retenue (A', B', C', et D') sont nuls. En effectuant simplement
   une addition ordinaire, tous les champs reoivent une valeur
   correcte sur 7 bits. En revanche, certains bits de sparation
   peuvent passer  1. On peut remdier  cela en appliquant une
   seule opration supplmentaire conventionnelle et masquant les
   bits de sparation. Notre vecteur d'additions entires sur 7 bits,
   x+y, devient ainsi :

 ((x + y) & 0x7f7f7f7f)

   Ceci ncessite seulement deux oprations pour effectuer quatre
   additions. Le gain en vitesse est vident.

   Les lecteurs avertis auront remarqu que forcer les bits de
   sparation  zro ne convient pas pour les soustractions. La
   solution est toutefois remarquablement simple : Pour calculer x-y,
   on garantira simplement la condition initiale, qui veut que tous
   les bits de sparation de x valent 1 et que tous ceux de y soient
   nuls. Dans le pire des cas, nous obtiendrons :

 (((x | 0x80808080) - y) & 0x7f7f7f7f)

   On peut toutefois souvent se passer du  OU  logique en
   s'assurant que l'opration qui gnre la valeur de x utilise |
   0x80808080 plutt que & 0x7f7f7f7f en dernire tape.

   Laquelle de ces mthodes doit-on appliquer aux oprations
   partitionnes du SWAR ? La rponse est simple :  celle qui offre
   le gain en rapidit le plus important . Ce qui est intressant,
   c'est que la mthode idale peut tre diffrente selon chaque
   taille de champ, et ce  l'intrieur d'un mme programme,
   s'excutant sur une mme machine.

    4.2.3. Oprations de communication et de conversion de type

   Bien que certains calculs en parallle, incluant les oprations
   sur les pixels d'une image, ont pour proprit le fait que la
   nime valeur d'un vecteur soit une fonction des valeurs se
   trouvant  la nime position des vecteurs des oprandes, ce n'est
   gnralement pas le cas. Par exemple, mme les oprations sur les
   pixels telles que l'adoucissement ou le flou rclament en oprande
   les valeurs des pixels adjacents, et les transformations comme la
   transforme de Fourrier (FFT) ncessitent des schmas de
   communications plus complexes (et moins localiss).

   Il est relativement facile de mettre efficacement en place un
   systme de communication  une dimension entre les valeurs du
   voisinage immdiat pour effectuer du SWAR, en utilisant des
   oprations de dcalage non partitionnes. Par exemple, pour
   dplacer une valeur depuis PE vers PE(n+1), un simple dcalage
   logique suffit. Si les champs sont larges de 8 bits, on
   utilisera :

 (x << 8)

   Pourtant, ce n'est pas toujours aussi simple. Par exemple, pour
   dplacer une valeur depuis PEn vers PE(n-1), un simple dcalage
   vers la droite devrait suffire... mais le langage C ne prcise pas
   si le dcalage vers la droite conserve le bit de signe, et
   certaines machines ne proposent, vers la droite, qu'un dcalage
   sign. Aussi, d'une manire gnrale, devons-nous mettre
   explicitement  zro les bits de signe pouvant tre rpliqus.

 ((x >> 8) & 0x00ffffff)

   L'ajout de connexions   enroulement  ( wrap-around )  l'aide
   de dcalages non partitionns ^[25] est aussi raisonnablement
   efficace. Par exemple, pour dplacer une valeur depuis PEi vers
   PE(i+1) avec enroulement :

 ((x << 8) | ((x >> 24) & 0x000000ff))

   Les problmes srieux apparaissent lorsque des schmas de
   communications plus gnraux doivent tre mis en uvre. Seul le
   jeu d'instructions du MAX de HP permet le rarrangement arbitraire
   des champs en une seule instruction, nomme Permute. Cette
   instruction Permute porte vraiment mal son nom : Non seulement
   elle effectue une permutation arbitraire des champs, mais elle
   autorise galement les rptitions. En bref, elle met en place une
   opration arbitraire de x[y].

   Il reste malheureusement trs difficile d'implmenter x[y] sans le
   concours d'une telle instruction. La squence de code est
   gnralement  la fois longue et inefficace, parce qu'en fait, il
   s'agit d'un programme squentiel. Ceci est trs dcevant. La
   vitesse relativement leve des oprations de type x[y] sur les
   les supercalculateurs SIMD MasPar MP1/MP2 et Thinking Machines
   CM1/CM2/CM200 tait une des cls majeures de leur succs.
   Toutefois, un x[y] reste plus lent qu'une communication de
   proximit, mme sur ces supercalculateurs. Beaucoup d'algorithmes
   ont donc t conus pour rduire ces besoins en oprations de type
   x[y]. Pour simplifier, disons que sans soutien matriel, le
   meilleur est encore trs certainement de dvelopper des
   algorithmes SWAR en considrant x[y] comme tant interdit, ou au
   moins trs coteux.

    4.2.4. Oprations rcurrentes (rductions, balayages, et ctera)

   Une rcurrence est un calcul dans lequel il existe une relation
   squentielle apparente entre les valeurs  traiter. Si toutefois
   des oprations associatives sont impliques dans ces rcurrences,
   il peut tre possible de recoder ces calculs en utilisant un
   algorithme parallle  structure organise en arbre.

   Le type de rcurrence paralllisable le plus courant est
   probablement la classe connue sous le nom de rduction
   associative. Par exemple, pour calculer la somme des valeurs d'un
   vecteur, on crit du code C purement squentiel, comme :

 t = 0;
 for (i=0; i<MAX; ++i) t += x[i];

   Cependant, l'ordre des additions est rarement important. Les
   oprations en virgule flottante et les saturations peuvent rendre
   diffrents rsultats si l'ordre des additions est modifi, mais
   les additions ordinaires sur les entiers (et qui reviennent au
   dbut aprs avoir atteint la valeur maximum) renverront exactement
   les mmes rsultats, indpendemment de l'ordre dans lequel elles
   sont effectues. Nous pouvons ainsi rcrire cette squence sous
   la forme d'une somme parallle structure en arbre, dans laquelle
   nous additionnons d'abord des paires de valeurs, puis des paires
   de ces sous-totaux, et ainsi de suite jusqu' l'unique somme
   finale. Pour un vecteur de quatre valeurs 8 bits, seulement deux
   additions sont ncessaires. La premire effectue deux additions de
   8 bits et retourne en rsultat deux champs de 16 bits, contenant
   chacun un rsultat sur 9 bits :

 t = ((x & 0x00ff00ff) + ((x >> 8) & 0x00ff00ff));

   La deuxime fait la somme de ces deux valeurs de 9 bits dans un
   champs de 16 bits, et renvoie un rsultat sur 10 bits :

 ((t + (t >> 16)) & 0x000003ff)

   En ralit, la seconde opration effectue l'addition de deux
   champs de 16 bits... mais les 16 bits de poids fort n'ont pas de
   signification. C'est pourquoi le rsultat est masqu en une valeur
   de 10 bits.

   Les balayages ( scans ), aussi connus sous le nom d'oprations
     prfixe parallle  sont un peu plus difficile  mettre en
   uvre efficacement. Ceci est d au fait que contrairement aux
   rductions, les balayages peuvent produire des rsultats
   partitionnes.

  4.3. SWAR MMX sous Linux

   Pour Linux, nous nous soucierons principalement des processeurs
   IA32. La bonne nouvelle, c'est qu'AMD, Cyrix et Intel implmentent
   tous le mme jeu d'instructions MMX. En revanche, les performances
   de ces diffrents MMX sont variables. Le K6, par exemple, n'est
   dot que d'un seul pipeline l o le Pentium MMX en a deux. La
   seule nouvelle vraiment mauvaise, c'est qu'Intel diffuse toujours
   ces stupides films publicitaires sur le MMX... ;-)

   Il existe trois approches srieuses du SWAR par le MMX :

    1. L'utilisation des fonctions d'une bibliothque ddie au MMX.
       Intel, en particulier, a dvelopp plusieurs  bibliothques
       de performances , offrant toute une gamme de fonctions
       optimises  la main et destines aux tches multimdia
       courantes. Avec un petit effort, bon nombre d'algorithmes
       non-multimdia peuvent tre retravaills pour permettre 
       quelques unes des zones de calcul intensif de s'appuyer sur
       une ou plusieurs de ces bibliothques. Ces bibliothques ne
       sont pas disponibles sous Linux, mais pourraient tre adaptes
       pour le devenir.

    2. L'utilisation directe des instructions MMX. C'est assez
       compliqu, pour deux raisons : D'abord, le MMX peut ne pas
       tre disponible sur le processeur concern, ce qui oblige 
       fournir une alternative. Ensuite, l'assembleur IA32 utilis en
       gnral sous Linux ne reconnat actuellement pas les
       instructions MMX.

    3. L'utilisation d'un langage de haut niveau ou d'un module du
       compilateur qui puisse directement gnrer des instructions
       MMX appropries. Quelques outils de ce type sont actuellement
       en cours de dveloppement, mais aucun n'est encore pleinement
       fonctionnel sous Linux. Par exemple,  l'Universit de Purdue
       (http://dynamo.ecn.purdue.edu/~hankd/SWAR/
       [http://dynamo.ecn.purdue.edu/~hankd/SWAR/]), nous dveloppons
       actuellement un compilateur qui admettra des fonctions crites
       dans un  dialecte  explicite parallle au langage C et qui
       gnrera des modules SWAR accessibles comme des fonctions C
       ordinaires, et qui feront usage de tous les supports SWAR
       disponibles, y compris le MMX. Les premiers prototypes de
       compilateurs  modules ont t gnrs  Fall, en 1996. Amener
       cette technologie vers un tat rellement utilisable prend
       cependant beaucoup plus de temps que prvu initialement.

   En rsum, le SWAR par MMX est toujours d'un usage malais.
   Toutefois, avec quelques efforts supplmentaires, la seconde
   approche dcrite ci-dessus peut tre utilise ds  prsent. En
   voici les bases :

    1. Vous ne pourrez pas utiliser le MMX si votre processeur ne le
       prend pas en charge. Le code GCC suivant vous permettra de
       savoir si votre processeur est quip de l'extension MMX. Si
       c'est le cas, la valeur renvoye sera diffrente de zro,
       sinon nulle.

 inline extern
 int mmx_init(void)
 {
         int mmx_disponible;

         __asm__ __volatile__ (
                 /* Rcupre la version du CPU */
                 "movl $1, %%eax\n\t"
                 "cpuid\n\t"
                 "andl $0x800000, %%edx\n\t"
                 "movl %%edx, %0"
                 : "=q" (mmx_disponible)
                 : /* pas d'entre */
         );
         return mmx_disponible;
 }

    2. Un registre MMX contient essentiellement ce que GCC
       appellerait un unsigned long long. Ainsi, ce sont des
       variables de ce type et rsidant en mmoire qui vont former le
       mcanisme de communication entre les modules MMX et le
       programme C qui les appelle. Vous pouvez aussi dclarer vos
       donnes MMX comme tant des structures de donnes alignes sur
       des adresses multiples de 64 bits (il convient de garantir
       l'alignement sur 64 bits en dclarant votre type de donnes
       comme tant membre d'une union comportant un champ unsigned
       long long).

    3. Si le MMX est disponible, vous pouvez crire votre code MMX en
       utilisant la directive assemble .byte pour coder chaque
       instruction. C'est un travail pnible s'il est abattu  la
       main, mais pour un compilateur, les gnrer n'est pas trs
       difficile. Par exemple, l'instruction MMX PADDB MM0,MM1
       pourrait tre encode par la ligne d'assembleur in-line GCC
       suivante :

 __asm__ __volatile__ (".byte 0x0f, 0xfc, 0xc1\n\t");

       Souvenez-vous que le MMX utilise une partie du matriel
       destin aux oprations en virgule flottante, et donc que le
       code ordinaire mlang au MMX ne doit pas invoquer ces
       dernires. La pile en virgule flottante doit galement tre
       vide avant l'excution de tout code MMX. Cette pile est
       normalement vide  l'entre d'une fonction C ne faisant pas
       usage de la virgule flottante.
    4. Clturez votre code MMX par l'excution de l'instruction EMMS,
       qui peut tre encode par :

 __asm__ __volatile__ (".byte 0x0f, 0x77\n\t");

   Tout ce qui prcde parat rbarbatif, et l'est. Ceci dit, le MMX
   est encore assez jeune... de futures versions de ce document
   proposeront de meilleures techniques pour programmer le SWAR MMX.

5. Processeurs auxiliaires des machines Linux

   Mme si cette approche n'est plus  la mode depuis quelques temps,
   il reste virtuellement impossible aux autres mthodes de maintenir
    la fois prix bas et performances leves, chose habituellement
   rendue possible par l'utilisation d'un systme Linux, lorsqu'il
   s'agit d'hberger dans la machine une unit de calcul ddie. Le
   problme est que la prise en charge logicielle de ces outils est
   trs limite. Nous serons plus ou moins livrs  nous mmes.

  5.1. Un PC Linux est une bonne station d'accueil

   En gnral, les processeurs secondaires tendent  se spcialiser
   dans l'excution de fonctions bien spcifiques.

   Avant de se sentir dcourags parce que livrs  nous-mmes, il
   est utile de comprendre que, bien qu'il puisse tre difficile de
   le prparer  recevoir un systme particulier, un PC sous Linux
   reste l'une des rares plate-formes qui se prtent convenablement 
   cet usage.

   Un PC forme un bon systme d'accueil pour deux raisons : La
   premire est sa capacit  voluer aisment et de faon peu
   onreuse. Les ressources telles que la mmoire, les disques, le
   rseau et autres peuvent tre ajoutes vraiment trs facilement 
   un PC. La seconde est sa facilit d'interfaage. Non seulement les
   prototypes de cartes ISA et PCI sont largement rpandus et
   disponibles, mais le port parallle fournit galement des
   performances raisonnables dans une interface discrte. L'adressage
   spar des entres / sorties de l'architecture IA32 facilite
   galement l'interfaage en offrant une protection de ces adresses
   au niveau du port individuel.

   Linux est galement un bon systme d'exploitation pour
   l'hbergement de systmes ddis. La libre et complte
   disponibilit du code source, et les nombreux manuels de
   programmation avance constituent videment une aide trs
   prcieuse. Mais Linux apporte galement une gestion des tches
   pratiquement temps-rel. Il existe mme une version fonctionnant
   en vrai temps-rel. Mais une chose peut-tre plus importante
   encore est le fait que, mme dans un environnement Unix complet,
   Linux sait prendre en charge des outils de dveloppement crits
   pour fonctionner sous MS-DOS ou Windows. Les programmes DOS
   peuvent tre excuts dans un processus Unix en utilisant dosemu,
   qui dresse une machine virtuelle protge qui peut littralement
   excuter du code MS-DOS. La prise en charge des programmes Windows
   3.xx sous Linux est encore plus directe : certains logiciels
   libres comme wine [http://www.winehq.org] simulent Windows
   3.11^[26] suffisamment bien pour permettre  la plupart des
   programmes Windows d'tre excuts correctement sur une machine
   Unix quipe de X-Window.

   Les deux sections suivantes donnent des exemples de systmes
   parallles auxiliaires que j'aimerais voir tre exploits sous
   Linux :

  5.2. Avez-vous essay le DSP ?

   Un march prospre s'est dvelopp autour des puces DSP ( Digital
   Signal Processing , ou  Traitement Numrique du Signal ) 
   hautes performances. Bien qu'elles soient en gnral conues pour
   tre embarques dans des systmes ddis  des usages bien
   spcifiques, elles peuvent aussi tre utilises comme de trs bons
   ordinateurs parallles annexes. Voici pourquoi :

     o Plusieurs d'entre elles, comme le TMS320 de Texas Instruments
       [http://www.ti.com] et la famille SHARC d'Analog Devices
       [http://www.analog.com] sont conues pour permettre
       l'assemblage de machines parallles en n'utilisant que trs
       peu, voire aucun circuit logique intermdiaire.

     o Ces puces sont bon march, spcialement au niveau du cot par
       MIP ou par MFLOP. Prix des circuits de gestion logique de base
       compris, on peut trouver un processeur DSP pour le dixime du
       prix du processeur d'un PC,  performances comparables.

     o Elle ne ncessitent que peu de puissance et ne dissipent pas
       beaucoup de chaleur. Cela signifie qu'il est possible
       d'alimenter toute une poigne de processeurs de ce type avec
       une simple alimentation PC conventionnelle, et de les enfermer
       dans le botier d'un PC sans transformer celui-ci en
       haut-fourneau.

     o La plupart des jeux d'instructions des DSP contiennent des
       choses assez exotiques et que les langages de haut niveau
       (c'est--dire : comme le C) ne sont pas  mme d'utiliser
       correctement. Par exemple, l' adressage de bit invers . En
       utilisant des systmes parallles inclus dans une machine, il
       est possible de compiler et d'excuter directement la plupart
       du code sur cette machine, tout en confiant l'excution des
       quelques algorithmes consommant la plupart du temps systme
       aux DSP, par l'entremise d'un code particulirement soign et
       optimis  la main.

     o Ces DSP ne sont pas vraiment conus pour faire fonctionner un
       systme d'exploitation UNIX ou assimil, et ne sont
       gnralement pas non plus adapts  une utilisation autonome
       comme processeur gnral d'un ordinateur. Le systme de
       gestion de la mmoire, par exemple, est insuffisant pour
       beaucoup d'entre eux. En d'autres mots, ils sont bien plus
       efficaces lorsqu'ils sont intgrs au sein d'une machine hte
       plus polyvalente ... telle qu'un PC sous Linux.

   Bien que de nombreux modems et cartes son contiennent des
   processeurs DSP accessibles par des pilotes Linux, les grands
   profits arrivent avec l'utilisation de systmes parallles
   intgrs comprenant au moins quatre processeurs DSP.

   Mme si la srie TMS320 de Texas Instruments, sur
   http://dspvillage.ti.com [http://dspvillage.ti.com], est populaire
   depuis un bon moment, les systmes de ce type tant disponibles
   sont encore peu nombreux. Il existe  la fois une version
   uniquement entire et une version virgule flottante du TMS320. Les
   anciens modles utilisaient un format de virgule flottante en
   simple prcision assez inhabituel, mais les nouveaux grent 
   prsent les formats IEEE. Les anciens TMS320C4x (ou simplement
    C4x ), accomplissaient jusqu' 80 MFLOP en utilisant le format
   de nombre en virgule flottante simple prcision spcifique  TI.
   En comparaison, un seul  C67x  apportera jusqu' 1 GFLOP en
   simple prcision et 420 MFLOP en double prcision au format IEEE,
   en utilisant une architecture  base de VLIW nomme VelociTI. Non
   seulement il est ais de configurer un groupe de circuits de ce
   type pour en faire un multiprocesseur, mais un de ces circuits, le
   multiprocesseur  'C8x , formera  lui seul un processeur
   principal  technologie RISC accusant 100 MFLOP au format IEEE, et
   dot soit de deux, soit de quatre DSP esclaves intgrs.

   L'autre famille de processeurs DSP qui ne soit pas simplement
   utilise ces temps-ci par quelques rares systmes en parallle est
   SHARC (ou  ADSP-2106x ), d'Analog Devices
   [http://www.analog.com/]. Ces circuits peuvent tre configurs en
   un multiprocesseur  mmoire partage form par 6 processeurs sans
   ncessiter de logique externe pour les associer, et peuvent aussi
   former de plus grands systmes grce  des circuits de liaison de
   4 bits. Les systmes au-del de celui-ci sont essentiellement
   destins aux applications militaires, et reviennent assez cher.
   Toutefois, Integrated Computing Engines, Inc.
   [http://www.iced.com/] produit un petit jeu de deux cartes PCI
   assez intressant, nomm GreenICE. Cette unit contient un rseau
   de 16 processeurs SHARC, et affiche une vitesse de pointe d'1.9
   GFLOP au format IEEE simple prcision. GreenICE cote moins de
   5000 dollars.

    mon avis, les circuits DSP parallles intgrs mriteraient une
   plus grande attention de la part du petit monde du calcul en
   parallle sous Linux...

  5.3. Calcul  l'aide des FPGA et circuits logiques reconfigurables

   Si l'objectif final du traitement en parallle reste l'atteinte
   des plus hautes vitesses possibles, et bien pourquoi ne pas
   fabriquer du matriel sur mesure ? Nous connaissons tous la
   rponse : Trop cher, trop long  dvelopper, le matriel ainsi
   conu devient inutile lorsque l'algorithme change mme de faon
   minime, et ctera. Cependant, les rcentes avances faites dans le
   domaine des FPGA ( Field Programmable Gate Array , ou  Rseaux
   Logiques Programmables  effet de Champ ) ont rduit  nant la
   plupart de ces objections. Aujourd'hui, la densit des portes
   logiques est suffisamment leve pour qu'un processeur entier
   puisse tre intgr dans un seul FPGA, et le temps de
   reconfiguration (ou de reprogrammation) d'un de ces FPGA a
   galement chut  un niveau o l'on peut raisonnablement
   reconfigurer le circuit mme entre deux phases d'un mme
   algorithme.

   Il ne faut pas avoir froid aux yeux pour utiliser ces techniques :
   Il faudra travailler avec des langages de description matrielle
   tels que le VHDL pour configurer les FPGA, tout comme crire du
   code de bas niveau pour programmer les interfaces avec le systme
   d'accueil Linux. En revanche, le cot des FPGA est assez bas,
   spcialement pour les algorithmes oprant sur des donnes entires
   et de prcision normale (ce qui ne reprsente en fait qu'un
   surensemble restreint de tout ce  quoi le SWAR s'applique bien),
   ces FPGA peuvent effectuer des oprations complexes  peu prs
   aussi vite qu'on peut les leur transmettre. Par exemple, de
   simples systmes  base de FPGA ont accus des performances
   suprieures  celles des supercalculateurs lors de recherches sur
   des bases de donnes gntiques.

   Il existe plusieurs compagnies produisant du matriel appropri 
   base de FPGA, mais les deux suivantes en sont un bon exemple :

   Virtual Computer Company propose toute une gamme de produits
   utilisant des FPGA Xilinx  base de SRAM et reconfigurables
   dynamiquement. Leur  Virtual ISA Proto Board  8/16 bits cote
   moins de 2000 dollars.

   L'ARC-PCI d'Altera ( Altera Reconfigurable Computer , sur bus
   PCI), sur http://www.altera.com/html/new/pressrel/pr_arc-pci.html
   [http://www.altera.com/html/new/pressrel/pr_arc-pci.html], est un
   type de carte similaire, mais utilisant les FPGA d'Altera et un
   bus PCI comme interface plutt qu'un bus ISA.

   Bon nombre de ces outils de conception, langages de description
   matrielle, compilateurs, routeurs, et ctera, sont livrs sous
   forme d'un code objet qui ne fonctionne que sous DOS ou Windows.
   Nous pourrions simplement conserver une partition DOS/Windows sur
   notre PC d'accueil et redmarrer lorsque nous en avons besoin.
   Toutefois, la plupart de ces outils peuvent probablement
   fonctionner sous Linux en utilisant dosemu ou des mulateurs
   Windows tels que wine.

6. D'intrt gnral

   Les sujets couverts dans cette section s'appliquent aux quatre
   modles de traitement en parallle sous Linux.

  6.1. Compilateurs et langages de programmation

   Je suis principalement un  chercheur en compilateurs . Je
   devrais donc tre capable de dire s'il y a beaucoup de
   compilateurs vraiment performants, gnrant du code parallle
   efficace pour les systmes Linux. Malheureusement, et pour dire la
   vrit, il est difficile de battre les performances obtenues en
   exprimant votre programme en parallle avec des communications et
   autres oprations parallles, le tout dans un code en langage C,
   compil par GCC.

   Les projets de compilateurs ou de langages suivants reprsentent
   une partie des meilleurs efforts produits pour la gnration d'un
   code raisonnablement efficace depuis les langages de haut niveau.
   Gnralement, chacun d'eux est raisonnablement efficace pour les
   tches qu'il vise, mais aucun ne correspond aux langages et aux
   compilateurs puissants et tout-terrain qui vous feront abandonner
   dfinitivement l'criture de programmes C compils par GCC... ce
   qui est trs bien comme . Utilisez ces langages et compilateurs
    ce pour quoi ils ont t conus, et vous serez rcompenss par
   des dures de dveloppement plus courtes, des oprations de
   maintenance et de dbogages rduites, et ctera.

   Il existe un grand nombre de langages et de compilateurs en dehors
   de ceux lists ici (dans l'ordre alphabtique). Une liste de
   compilateurs librement disponibles (la plupart n'ayant rien  voir
   avec le traitement en parallle sous Linux) est accessible ici :
   http://www.idiom.com/free-compilers
   [http://www.idiom.com/free-compilers].

    6.1.1. Fortran 66/77/PCF/90/HPF/95

   Au moins dans la communaut de l'informatique scientifique, le
   Fortran sera toujours prsent. Bien sr, le Fortran d'aujourd'hui
   n'a plus la mme signification que celle dfinie par le standard
   ANSI de 1966. En quelques mots, le Fortran 66 tait trs limit.
   Le Fortran 77 a ajout des nuances dans ses fonctions, la plus
   intressante tant la prise en charge amliore des donnes de
   type caractre et la modification de la smantique des boucles DO.
   Le Fortran PCF ( Parallel Computing Forum ) a tent d'ajouter
   diverses fonctions de gestion de traitement en parallle au
   Fortran 77. Le Fortran 90 est un langage moderne et pleinement
   fonctionnel, qui apporte essentiellement des facilits de
   programmation oriente objet ressemblant au C++ et une syntaxe de
   tableaux en parallle au langage du Fortran 77. HPF
   ( High-Performance Fortran , lui-mme propos en deux versions
   (HPF-1 et HPF-2), est essentiellement la version standardise et
   amliore de ce que beaucoup d'entre nous ont connu sous les noms
   de CM Fortran, MasPar Fortran, ou Fortran D. Il tend le Fortran
   90 avec diverses amliorations ddies au traitement en parallle,
   trs centres sur la spcification d'agencements de donnes.
   Citons enfin le Fortran 95, version quelque peu amliore et
   raffine du Fortran 90.

   Ce qui fonctionne avec le C peut en gnral fonctionner aussi avec
   f2c, g77, ou les produits Fortran 90/95 commerciaux de NAG. Ceci
   est d au fait que tous ces compilateurs peuvent au final produire
   le mme code que celui utilis en arrire-boutique par GCC.

   Les parallliseurs Fortran commerciaux pouvant gnrer du code
   pour SMP sont disponibles sur http://www.kai.com
   [http://www.kai.com] et http://www.crescentbaysoftware.com
   [http://www.crescentbaysoftware.com]. Il n'est pas clairement
   indiqu si ces compilateurs sont utilisables pour des machines SMP
   Linux, mais ils devraient l'tre tant donn que les threads POSIX
   standards (soit les LinuxThreads) fonctionnent sur des systmes
   SMP sous Linux.

   Le Portlan Group [http://www.pgroup.com/] propose des compilateurs
   Fortran HPF (et C/C++) parallles commerciaux gnrant du code
   Linux SMP. Il existe aussi une version ciblant les clusters
   s'appuyant sur MPI ou PVM. Les produits de http://www.apri.com
   [http://www.apri.com] pourraient aussi tre utiles sur des
   clusters ou des machines SMP.

   Parmi les Fortran parallliss disponibles librement et qui
   pourraient fonctionner sur des systmes Linux en parallle,
   citons :

     o ADAPTOR ( Automatic DAta Parallelism TranslaTOR ,
       http://www.gmd.de/SCAI/lab/adaptor/adaptor_home.html
       [http://www.gmd.de/SCAI/lab/adaptor/adaptor_home.html], qui
       peut traduire du Fortran HPF en Fortran 77/90 avec appels MPI
       ou PVM, mais qui ne mentionne pas Linux.

     o Fx, de l'Universit Carnegie Mellon (N.D.T. : Pittsburgh),
       vise certains clusters de stations de travail, mais Linux ?

     o HPFC (un prototype de Compilateur HPF) gnre du code Fortran
       77 avec appels PVM. Est-il utilisable sur un cluster Linux ?

     o PARADIGM ( PARAllelizing compiler for DIstributed-memory
       General-purpose Multicomputers ,
       http://www.crhc.uiuc.edu/Paradigm
       [http://www.crhc.uiuc.edu/Paradigm]) peut-il lui aussi tre
       utilis avec Linux ?

     o Le compilateur Polaris gnre du code Fortran pour
       multiprocesseurs  mmoire partage, et pourrait bientt tre
       recibl vers les clusters Linux PAPERS.

     o PREPARE,
       http://www.irisa.fr/EXTERNE/projet/pampa/PREPARE/prepare.html
       [http://www.irisa.fr/EXTERNE/projet/pampa/PREPARE/prepare.html],
       vise les clusters MPI... On ne sait pas vraiment s'il sait
       gnrer du code pour processeurs IA32.

     o Combinant ADAPT et ADLIB,  shpf  ( Subset High Performance
       Fortran compilation system ) est dans le domaine public et
       gnre du code Fortran 90 avec appels MPI. Donc, si vous avez
       un compilateur Fortran 90 sous Linux...

     o SUIF ( Stanford University Intermediate Form , voir
       http://suif.stanford.edu [http://suif.stanford.edu]) propose
       des compilateurs parallliss pour le C et le Fortran. C'est
       aussi l'objectif du National Compiler Infrastructure
       Project...  Quelqu'un s'occupe-t-il des systmes parallles
       sous Linux ? 

   Je suis sr d'avoir omis plusieurs compilateurs potentiellement
   utiles dans les diffrents dialectes du Fortran, mais ils sont si
   nombreux qu'il est difficile d'en garder la trace. A l'avenir, je
   prfrerais ne lister que ceux qui sont rputs fonctionner sous
   Linux. Merci de m'envoyer commentaires et corrections en anglais
   par courrier lectronique  <hankd CHEZ engr POINT uky POINT edu>.

    6.1.2. GLU ( Granular Lucid )

   GLU ( Granular Lucid ) est un systme de programmation de trs
   haut niveau bas sur un modle hybride combinant les modles
   intentionnel ( Lucid ) et impratif. Il reconnat  la fois les
   sockets PVM et TCP. Fonctionne-t-il sous Linux ? (Le site du
    Computer Science Laboratory  se trouve sur
   http://www.csl.sri.com [http://www.csl.sri.com].

    6.1.3. Jade et SAM

   Jade est un langage de programmation en parallle sous forme
   d'extension au langage C et exploitant les concurrences de la
   granularit des programmes squentiels et impratifs. Il s'appuie
   sur un modle de mmoire partage distribue, modle implment
   par SAM dans les clusters de stations de travail utilisant PVM.
   Plus d'informations sur http://suif.stanford.edu/~scales/sam.html
   [http://suif.stanford.edu/~scales/sam.html].

    6.1.4. Mentat et Legion

   Mentat est un systme de traitement en parallle orient objet qui
   fonctionne avec des clusters de stations de travail et qui a t
   port vers Linux. Le  Mentat Programming Language  (MPL) est un
   langage de programmation orient objet bas sur le C++. Le systme
   temps-rel de Mentat utilise quelque chose qui ressemble vaguement
    des appels de procdures  distance ( remote procdure
   calls  : RPC) non bloquantes. Plus d'informations sur
   http://www.cs.virginia.edu/~mentat
   [http://www.cs.virginia.edu/~mentat].

   Legion http://www.cs.virginia.edu/~legion
   [http://www.cs.virginia.edu/~legion/] est construit au dessus de
   Mentat, et simule une machine virtuelle unique au travers des
   machines d'un rseau large zone.

    6.1.5. MPL ( MasPar Programming Language )

    ne pas confondre avec le MPL de Mentat, ce langage tait
   initialement dvelopp pour tre le dialecte C parallle natif des
   supercalculateurs SIMD MasPar. MasPar ne se situe plus vraiment
   sur ce segment (ils s'appellent maintenant NeoVista Solutions
   [http://www.neovista.com] et se spcialisent dans le data
   mining^[27], mais leur compilateur MPL a t construit en
   utilisant GCC. Il est donc librement disponible. Dans un effort
   concert entre les universit de l'Alabama,  Huntsville, et celle
   de Purdue, le MPL MasPar a t recibl pour gnrer du code C avec
   appels AFAPI (voir la section 3.6), et fonctionne ainsi  la fois
   sur des machines Linux de type SMP et sur des clusters. Le
   compilateur est, nanmoins, quelque peu bogu... voir
   http://www.math.luc.edu/~laufer/mspls/papers/cohen.ps
   [http://www.math.luc.edu/~laufer/mspls/papers/cohen.ps].

    6.1.6. PAMS ( Parallel Application Management System )

   Myrias est une compagnie qui vend un logiciel nomm PAMS
   ( Parallel Application Management System ). PAMS fournit des
   directives trs simples destines au traitement en parallle
   utilisant de la mmoire partage virtuelle. Les rseaux de
   machines Linux ne sont pas encore pris en charge.

    6.1.7. Parallaxis-III

   Parallaxis-III est un langage de programmation structure qui
   reprend Modula-2, en ajoutant des  processeurs et connexions
   virtuels  pour le paralllisme des donnes (un modle SIMD). La
   suite Parallaxis comprend des compilateurs pour ordinateurs
   squentiels et parallles, un dbogueur (extension des dbogueurs
   gdb et xgdb), et une vaste gamme d'algorithmes d'exemple de
   diffrents domaines, en particulier dans le traitement des images.
   Il fonctionne sur les systmes Linux squentiels. Une ancienne
   version prenait dj en charge diverses plate-formes parallles,
   et une prochaine version le fera  nouveau (comprendre : ciblera
   les clusters PVM). Plus d'informations sur
   http://www.informatik.uni-stuttgart.de/ipvr/bv/p3/p3.html
   [http://www.informatik.uni-stuttgart.de/ipvr/bv/p3/p3.html].

    6.1.8. pC++/Sage++

   pC++/Sage++ est une extension au langage C autorisant les
   oprations de type  donnes en parallle , en utilisant des
    collections d'objets  formes  partir de classes  lments 
   de base. Il s'agit d'un prprocesseur gnrant du code C++ pouvant
   fonctionner en environnement PVM. Est-ce que cela fonctionne sous
   Linux ? Plus d'informations ici :
   http://www.extreme.indiana.edu/sage
   [http://www.extreme.indiana.edu/sage/].

    6.1.9. SR ( Synchronizing Resources )

   SR ( Synchronizing Resources , ou  ressources synchronises )
   est un langage de programmation de situations concurrentes et dans
   lequel les ressources encapsulent les processus et les variables
   qu'ils partagent. Les  oprations  forment le principal
   mcanisme d'interactions entre processus. SR propose une
   intgration novatrice des mcanismes utilises pour invoquer et
   traiter les oprations. En consquence, les appels de procdures
   locaux ou  distance, les rendez-vous, le message passing, la
   cration dynamique de processus, la multi-diffusion et les
   smaphores sont tous pris en charge. SR gre galement les
   variables et oprations globales partages.

   Il existe une adaptation Linux, mais le type de paralllisme que
   SR peut y faire fonctionner n'est pas clairement dfini. Plus
   d'informations sur http://www.cs.arizona.edu/sr/www/index.html
   [http://www.cs.arizona.edu/sr/www/index.html].

    6.1.10. ZPL et IronMan

   ZPL est un langage de programmation par matrices conu pour grer
   les applications scientifiques et d'ingnierie. Il gnre des
   appels  une interface de message-passing assez simple nomme
   IronMan, et les quelques fonctions qui constituent cette interface
   peuvent facilement tre implmentes  l'aide de pratiquement
   n'importe quel systme de message-passing. Il est toutefois
   principalement tourn vers PVM et MPI sur des clusters de stations
   de travail, et peut fonctionner sous Linux. Plus d'informations
   sur http://www.cs.washington.edu/research/zpl/home/index.html
   [http://www.cs.washington.edu/research/zpl/home/index.html].

  6.2. Question de performance

   Beaucoup de gens passent beaucoup de temps  faire des mesures de
   performances  au banc d'essai  de cartes-mres particulires, de
   carte rseau, et ctera, pour dterminer laquelle d'entre elles
   est la meilleure. Le problme de cette approche est que, le temps
   d'arriver  des rsultats probants, le matriel test peut ne plus
   tre le meilleur. Il peut mme tre retir du march et remplac
   par un modle rvis et aux proprits radicalement diffrentes.

   Acheter du matriel pour PC, c'est un peu comme acheter du jus
   d'orange. Il est gnralement fabriqu  partir de produits de
   bonne qualit, et ce quelque soit le nom de la compagnie qui le
   distribue. Peu de gens connaissent ou se soucient de la provenance
   de ces composant (ou du concentr de jus d'orange). Ceci dit, il
   existe quelques diffrences auxquelles on devrait tre attentif.
   Mon conseil est simple : Soyez simplement conscients de ce que
   vous pouvez attendre de votre matriel lorsqu'il fonctionne sous
   Linux, puis portez votre attention sur la rapidit de livraison,
   un prix raisonnable et une garantie convenable.

   Il existe un excellent aperu des diffrents processeurs pour PC
   sur http://www.pcguide.com/ref/cpu/fam/
   [http://www.pcguide.com/ref/cpu/fam/]; En fait, le site PC Guide
   [http://www.pcguide.com/] entier est rempli de bonnes
   prsentations techniques de l'lectronique d'un PC. Il est
   galement utile d'en savoir un peu sur les performances et la
   configuration d'un matriel spcifique, et le
   Linux Benchmarking HOWTO
   [http://www.traduc.org/docs/howto/lecture/Benchmarking-HOWTO.html]
   est un bon document pour commencer.

   Les processeurs Intel IA32 sont dots de plusieurs registres
   spciaux qui peuvent tre utiliss pour mesurer les performances
   d'un systme en fonction dans ses moindres dtails. Le VTune
   d'Intel, sur http://developer.intel.com/design/perftool/vtune
   [http://developer.intel.com/design/perftool/vtune], fait un usage
   pouss de ces registres de performances, dans un systme
   d'optimisation du code vraiment trs complet... qui
   malheureusement ne fonctionne pas sous Linux. Un pilote sous forme
   de module chargeable et une bibliothque de fonctions servant 
   accder aux registres de performances du Pentium sont disponibles
   et ont t crits par Cuneyt Akinlar. Souvenez-vous que ces
   registres de performance sont diffrents selon les processeurs
   IA32. Ce code ne fonctionnera donc que sur un Pentium, pas sur un
   486, ni sur un Pentium Pro, un Pentium II, un K6, et ctera.

   Il y a encore un commentaire  faire  propos des performances,
   destin spcialement  ceux qui veulent monter de grands clusters
   dans de petits espaces. Les processeurs modernes incorporent pour
   certains des capteurs de temprature, et utilisent des circuits
   ralentissant la cadence du processeur lorsque cette temprature
   dpasse un certain seuil (tentative de rduction des missions de
   chaleur et d'amlioration de la fiabilit). Je ne suis pas en
   train de dire que tout le monde devrait sortir s'acheter un module
    effet Peltier (ou  pompe  chaleur ) pour refroidir chaque
   CPU, mais que nous devrions tre conscients du fait qu'une
   temprature trop lev ne se contente pas de raccourcir la dure
   de vie des composants, mais agit aussi directement sur les
   performances d'un systme. Ne placez vos ordinateurs dans des
   configurations pouvant bloquer le flux d'air, pigeant la chaleur
   dans des zones confines, et ctera.

   Enfin, les performances ne sont pas seulement une question de
   vitesse, mais galement de fiabilit et de disponibilit. Une
   haute fiabilit signifie que votre systme ne plantera
   pratiquement jamais, mme si un composant vient  tomber en
   panne... ce qui ncessite gnralement un matriel spcial comme
   une alimentation redondante et une carte-mre autorisant le
   remplacement   chaud  des quipements qui y sont connects.
   Tout cela est en gnral assez cher. Une haute disponibilit
   signifie que votre systme sera prt  tre utilis pratiquement
   tout le temps. Le systme peut planter si l'un des composants
   tombe en panne, mais il pourra tre rpar et redmarr trs
   rapidement. Le High-Availability HOWTO traite plusieurs des cas de
   base de la haute disponibilit. En revanche, dans le cas des
   clusters, une haute disponibilit peut tre assure en prvoyant
   simplement quelques pices de rechange. liminer le matriel
   dfectueux et le remplacer par une de ces pices de rechange peut
   apporter une plus grande disponibilit pour un cot d'entretien
   moins lev que celui d'un contrat de maintenance.

  6.3. Conclusion -- C'est fini !

   Alors, y a-t-il quelqu'un dans l'assemble qui fasse du traitement
   en parallle sous Linux ? Oui !

   Il y a encore peu de temps, beaucoup de gens se demandaient si la
   mort de plusieurs compagnies fabricant des supercalculateurs
   parallles n'annonait pas la fin du traitement en parallle. Ce
   n'tait alors pas mon opinion (voir
   http://dynamo.ecn.purdue.edu/~hankd/Opinions/pardead.html
   [http://dynamo.ecn.purdue.edu/~hankd/Opinions/pardead.html] pour
   un aperu assez amusant de ce qui,  mon avis, s'est vraiment
   pass), et il semble assez clair qu'aujourd'hui le traitement en
   parallle est  nouveau sur une pente ascendante. Mme Intel, qui
   n'a cess que rcemment de produire des supercalculateurs
   parallles, est fier du soutien apport au traitement en parallle
   par des choses comme le MMX, et l'EPIC ( Explicitly Parallel
   Instruction Computer , ou  Ordinateur  jeu d'Instructions
   Parallles Explicites ) de l'IA64.

   Si vous faites une recherche sur les mots  Linux  et
    Parallle  dans votre moteur de recherche favori, vous
   trouverez un certain nombre d'endroits impliqus dans le
   traitement en parallle sous Linux. Les clusters de PC sous Linux,
   en particulier, font leur apparition un peu partout. Le fait que
   Linux se prte particulirement bien  ce genre de tche combin
   aux cots rduits et aux hautes performances du matriel pour PC
   ont fait du traitement en parallle sous Linux une approche
   populaire, tant pour les groupes au budget restreint que pour les
   vastes laboratoires de recherche nationaux confortablement
   subventionns.

   Certains projets numrs dans ce document tiennent une liste de
   sites de recherche  apparents  utilisant des configurations
   Linux parallles similaires. Vous trouvez cependant sur
   http://yara.ecn.purdue.edu/~pplinux/Sites
   [http://yara.ecn.purdue.edu/~pplinux/Sites] un document hypertexte
   dont le but est d'apporter photographies, descriptions et contacts
   vers les sites de tous les projets utilisant Linux pour effectuer
   des traitement en parallle. Si vous voulez voir votre propre site
   y figurer :

     o Vous devez avoir un site  permanent  prsentant le
       fonctionnement d'un systme Linux en parallle : Une machine
       SMP, un systme SWAR, ou un PC quip de processeurs ddis,
       configur pour permettre aux utilisateurs d'excuter des
       programmes parallles sous Linux. Un environnement logiciel
       bas sur Linux et prenant directement en charge la gestion du
       traitement en parallle (tel que PVM, MPI ou AFAPI) doit tre
       install sur le systme. En revanche, le matriel ne doit pas
       ncessairement tre ddi au traitement en parallle sous
       Linux et peut tre employ  des tches compltement
       diffrentes lorsque les programmes parallles ne sont pas en
       cours d'excution.

     o Vous devez formuler une demande pour que votre site apparaisse
       sur cette liste. Envoyez vos informations en anglais  <hankd
       CHEZ engr POINT uky POINT edu>. Merci de respecter le format
       utilis par les autres entres pour les informations
       concernant votre site. Aucun site ne sera rpertori sans
       demande explicite de la part du responsable de ce site.

   Quatorze clusters sont actuellement rpertoris dans cette liste,
   mais nous avons t informs de l'existence de plusieurs douzaines
   de clusters Linux  travers le monde. Bien sr, cette inscription
   n'implique aucun engagement. Notre objectif est simplement de
   favoriser le dveloppement des connaissances, de la recherche et
   de la collaboration impliquant le traitement en parallle sous
   Linux.

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

   ^[1] N.D.T. :  flat memory model , dans lequel toute la mmoire
   se trouve dans le mme plan mmoire, par opposition aux segments,
   mmoire pagine, et tout autre modle compos.

   ^[2] N.D.T. : dcomposition d'un programme en plusieurs processus
   distincts, mais travaillant simultanment et de concert.

   ^[3] N.D.T. : qui a dmarr la machine avant de passer en mode
   SMP.

   ^[4] N.D.T. : le lien vers l'ancienne version 1.1, lui, n'existe
   plus. La documentation la plus rcente se trouve  ce jour sur
   http://www.intel.com/design/Pentium4/documentation.htm
   [http://www.intel.com/design/Pentium4/documentation.htm].

   ^[5] N.D.T. : insr au sein du code source, ici en C.

   ^[6] N.D.T. : soit, sous Unix, tre sous le compte root.

   ^[7] N.D.T. : temporisations introduites au sein d'un programme en
   utilisant par exemple des boucles et en consommant ainsi tout le
   temps machine allou au processus plutt qu'en rendant la main au
   systme.

   ^[8] N.D.T. :  spin locks  : mise en tat d'attente jusqu' ce
   qu'une condition soit remplie.

   ^[9] N.D.T. : Il s'agit en fait d'un appel Unix standard.

   ^[10] N.D.T. : il semble que ce panel ne soit plus mis  jour
   depuis un certain temps. Le site suggr proposait  la date de
   rdaction de la version franaise le bulletin le plus rcent, mais
   n'est pas officiel.

   ^[11] N.D.T. : dsormais intgr aux sources du noyau.

   ^[12] N.D.T. : les pilotes FC pour le noyau Linux ont en fait t
   crits en 1999.

   ^[13] N.D.T. : La Fibre Channel Association (FCA) et la Fibre
   Channel Loop Community (FCLC) ont fusionn en 2000 pour former la
   Fibre Channel Industry Association.

   ^[14] N.D.T. : les premiers pilotes FireWire pour Linux ont t
   crits en 1999 mais, bien que disponibles en standard, sont
   toujours considrs comme exprimentaux.

   ^[15] N.D.T. : HiPPI est aujourd'hui pris en charge par Linux,
   mais de faon restreinte et exprimentale.

   ^[16] N.D.T. : l'IrDA est pris en charge par le noyau depuis 2000.

   ^[17] SAN :  System Area Network .

   N.D.T. :  ne pas confondre avec  Storage Area Network , qui
   partage le mme acronyme.

   ^[18] N.D.T. : Sequent a t absorb par IBM en septembre 1999.

   ^[19] N.D.T. : et donc dsormais  Hewlett-Packard.

   ^[20] N.D.T. : les ports et le standard USB sont aujourd'hui
   parfaitement reconnus par Linux.

   ^[21] N.D.T. : par opposition  un  appel systme , donc sans
   franchir la barrire du passage en mode noyau.

   ^[22] N.D.T. : MOSIX fonctionne aujourd'hui sous Linux.

   ^[23] N.D.T. : initialement, huit liens taient proposs  cet
   endroit, devenus pour la plupart obsoltes.

   ^[24] N.D.T. : FLOP =  FLoating point OPeration , ou  OPration
   en Virgule Flottante .

   ^[25] N.D.T. : il s'agit en fait de simuler la r-entre par le
   cot oppos des donnes jectes par le dcalage. L'exemple qui
   suit permet d'implmenter ce cas en langage C, mais la plupart des
   microprocesseurs sont quips d'instructions de rotation
   effectuant cela en une seule opration.

   ^[26] N.D.T. : WINE a volu avec le temps et reconnat
   naturellement les versions plus rcentes de ce systme
   d'exploitation.

   ^[27] N.D.T. : le data mining consiste  tudier et mettre au
   point des techniques efficaces de recherche d'une information au
   travers d'une immense quantit de donnes.

