/usr/share/doc/HOWTO/fr-html/Beowulf-HOWTO.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for HTML5 for Linux version 5.2.0">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.72">
<title>Beowulf HOWTO</title>
</head>
<body>
<h1>Beowulf HOWTO</h1>
<h2>Jacek Radajewski and Douglas Eadline (traduction&nbsp;:
Emmanuel PIERRE, epierre@e-nef.com&nbsp;)</h2>
v1.1.1, 22 Novembre 1998
<hr>
<em>Ce document est une introduction à l'architecture Beowulf
Supercomputeur. Il fournit les informations de base sur la
programmation parallèle, et inclut des liens vers des documents
plus spécifiques et des pages web.</em>
<hr>
<h2><a name="s1">1. Préambule</a></h2>
<h2><a name="ss1.1">1.1 Mise en garde</a></h2>
<p>Nous n'accepterons aucune responsabilité pour toute information
incorrecte présente dans ce document, ni pour aucun des dommages
qui pourraient en résulter.</p>
<h2><a name="ss1.2">1.2 Copyright</a></h2>
<p>Copyright © 1997 - 1998 Jacek Radajewski et Douglas Eadline. Le
droit de distribuer et de modifier ce document est autorisé sous la
licence GNU General Public License.</p>
<h2><a name="ss1.3">1.3 Au sujet de ce HOWTO</a></h2>
<p>Jacek Radajewski a commencé à travailler sur ce document en
novembre 1997 et a été ensuite rejoint par Douglas Eadline. En
quelques mois, le HOWTO Beowulf est devenu un document consistant,
et en août 1998, il a été découpé en trois: Beowulf HOWTO, Beowulf
Architecture Design HOWTO, the Beowulf Installation and
Administration HOWTO. La Version 1.0.0 de ce document a été soumise
au Linux Documentation Project le 11 novembre 1998. Nous espérons
que ce ne soit que le début de ce qui deviendra une documentation
complète du Projet de Documentation Beowulf (Beowulf Documentation
Project).</p>
<h2><a name="ss1.4">1.4 Au sujet des auteurs</a></h2>
<ul>
<li>Jacek Radajewski est Administrateur Réseau, et prépare un degré
honorifique en Informatique à l'Université du Southern Queensland,
Australie. Le premier contact de Jacek avec Linux eut lieu en 1995
et il en tomba amoureux du premier coup. Jacek construisit son
premier cluster Beowulf en Mai 1997 et a joué avec cette
technologie depuis, toujours à la recherche de la meilleure manière
de tout organiser. Vous pouvez joindre Jacek par courriel à
<a href="mailto:jacek@usq.edu.au">jacek@usq.edu.au</a></li>
<li>Douglas Eadline, Ph.D. est le President et le Principal
Scientifique (Principal Scientist) à Paralogic, Inc., Bethlehem,
PA, USA. Formé en tant que Chimiste Physique/Analytique, il s'est
investi dans les ordinateurs depuis 1978, année où il a construit
sa première machine pour l'utiliser avec l'instrumentation
chimique. A ujourd'hui, le Dr. Eadline s'intéresse à Linux, aux
clusters Beowulf, et aux algorithmes parallèles. Le Dr. Eadline
peut être joint par courriel à <a href=
"mailto:deadline@plogic.com">deadline@plogic.com</a></li>
</ul>
<h2><a name="ss1.5">1.5 Remerciements</a></h2>
<p>L'écriture du HOWTO Beowulf a été longue, et il est finalement
complet grâce à de nombreuses personnes. Nous voudrions remercier
celles qui suivent pour leur aide et leurs contributions à ce
HOWTO:</p>
<ul>
<li>Becky pour son amour, son soutien, et sa compréhension.</li>
<li>Tom Sterling, Don Becker, et les autres personnes de la NASA
qui furent à l'origine du projet Beowulf.</li>
<li>Thanh Tran-Cong et la Faculty of Engineering and Surveying pour
avoir donné la machine Beowulf <i>topcat</i> pour les tests de
Beowulf.</li>
<li>Mon supérieur Christopher Vance pour de nombreuses bonnes
idées.</li>
<li>Mon ami Russell Waldron pour de grandes idées de programmation,
son intérêt général pour le projet, et son soutien.</li>
<li>Mon ami David Smith pour la relecture de ce document.</li>
<li>Et de nombreuses autres personnes sur la liste de diffusion
Beowulf qui nous ont fournis beaucoup de retour et d'idées.</li>
<li>Toutes les personnes qui sont responsables du système
d'exploitation Linux et de tous les autres outils gratuits utilisés
sur <i>topcat</i> et les diverses machines Beowulf.</li>
</ul>
<h2><a name="s2">2. Introduction</a></h2>
<p>Au fur et à mesure que les niveaux de performance et de
commodité des ordinateurs et des réseaux augmentent, il devient de
plus en plus facile de construire des systèmes informatiques
parallèles à partir de composants facilement disponibles, plutôt
que de construire des processeurs sur de très coûteux
Superordinateurs. En fait, le rapport prix/performances d'une
machine de type Beowulf est de trois à dix fois meilleur que celui
des superordinateurs traditionnels. L'architecture Beowulf
s'échelonne bien, elle est facile à construire et vous ne payez que
pour le matériel, puisque la pluspart des logiciels sont
gratuits.</p>
<h2><a name="ss2.1">2.1 A qui s'adresse ce HOWTO ?</a></h2>
<p>Ce HOWTO s'adresse aux personnes qui ont déjà eu au moins des
contacts avec le système d'exploitation Linux. La connaissance de
la technologie Beowulf ou d'un système d'exploitation plus complexe
et de concepts réseaux n'est pas essentielle, mais des aperçus de
la programmation parallèle sont bienvenus (après tout, vous devez
avoir de bonnes raisons de lire ce document). Ce HOWTO ne répondra
pas à toutes les questions que vous pourriez vous poser au sujet de
Beowulf, mais, espérons-le, vous donnera des idées et vous guidera
dans la bonne direction. Le but de ce HOWTO est de fournir des
informations de base, des liens et des références vers des
documents plus approfondis.</p>
<h2><a name="ss2.2">2.2 Qu'est-ce que Beowulf ?</a></h2>
<p><i>Famed was this Beowulf: far flew the boast of him, son of
Scyld, in the Scandian lands. So becomes it a youth to quit him
well with his father's friends, by fee and gift, that to aid him,
aged, in after days, come warriors willing, should war draw nigh,
liegemen loyal: by lauded deeds shall an earl have honor in every
clan.</i> Beowulf est le poème épique le plus ancien en Anglais qui
ait été conservé. C'est l'histoire d'un héros d'une grande force et
d'un grand courage qui a défait un monstre appelé Grendel. Voir l'
<a href="#history">Historique</a> pour en savoir plus sur le héros
Beowulf.</p>
<p>Il y a peut-être de nombreuses définitions de Beowulf, autant
que de personnes qui construisent ou utilisent des Superordinateurs
Beowulf. Certains disent qu'ils peuvent appeler leur système
Beowulf seulement s'il est construit de la même façon que la
machine d'origine de la NASA. D'autres vont à l'extrême inverse et
appellent ainsi n'importe quel système de stations qui exécutent du
code parallèle. Ma définition d'un Beowulf se situe entre ces deux
avis, et est fondée sur de nombreuses contributions dans la liste
de diffusion Beowulf.</p>
<p>Beowulf est une architecture multi-ordinateurs qui peut être
utilisée pour la programmation parallèle. Ce système comporte
habituellement un noeud serveur, et un ou plusieurs noeuds clients
connectés entre eux à travers Ethernet ou tout autre réseau. C'est
un système construit en utilisant des composants matériels
existants, comme tout PC capable de faire tourner Linux, des
adaptateurs Ethernet standards, et des switches. Il ne contient
aucun composant matériel propre et est aisément reproductible.
Beowulf utilise aussi des éléments comme le système d'exploitation
Linux, Parallel VirtualMachine (PVM) et Message Passing Interface
(MPI). Le noeud serveur contrôle l'ensemble du cluster et sert de
serveur de fichiers pour les noeuds clients. Il est aussi la
console du cluster et la passerelle (gateway) vers le monde
extérieur. De grandes machines Beowulf peuvent avoir plus d'un
noeud serveur, et éventuellement aussi d'autres noeuds dédiés à des
tâches particulières, par exemple comme consoles ou stations de
surveillance. Dans de nombreux cas, les noeuds clients d'un système
Beowulf sont idiots (dumb): plus ils sont idiots, mieux ils sont.
Les noeuds sont configurés et contrôlés par le noeud serveur, et ne
font que ce qu'on leur demande de faire. Dans une configuration
client sans disque (diskless), les noeuds clients ne connaissent
même pas leur adresse IP ou leur nom jusqu'à ce que le serveur leur
dise qui ils sont. Une des principales différences entre Beowulf et
un Cluster de Stations de travail (COW) est le fait que Beowulf se
comporte plus comme une simple machine plutôt que comme plusieurs
stations de travail. Dans de nombreux cas, les noeuds clients n'ont
pas de claviers ni de moniteurs, et on n'y accède que par une
connection distante ou par un terminal série. Les noeux Beowulf
peuvent être envisagés comme un CPU + des ensembles de mémoires qui
peuvent être branchés dans le cluster, exactement comme un CPU ou
un module mémoire peut être branché dans une carte mère.</p>
<p>Beowulf n'est pas un ensemble de matériels spécialisés, une
nouvelle topologie réseau ou le dernier hack du kernel. Beowulf est
une technologie de clustering d'ordinateurs Linux pour former un
superordinateur parallèle, virtuel. Même s'il y a de nombreux
paquetages comme des patches du noyau, PVM, les librairies MPI, et
des outils de configuration qui rendent l'architecture Beowulf plus
rapide, plus facile à configurer, et plus facilement utilisable, on
peut construire une machine de classe Beowulf en utilisant une
distribution Standard de Linux sans ajouter d'autres logiciels. Si
vous avez deux Linux en réseau qui partagent au moins le même
système de fichier <code>racine</code> via NFS, et qui se font
confiance pour exécuter des sessions distantes (rsh), alors on peut
dire que vous avez un simple Beowulf de deux noeuds.</p>
<h2><a name="ss2.3">2.3 Classification</a></h2>
<p>Les systèmes Beowulf ont été construits à partir de nombreux
constituants. Pour des considérations de performances, des
composants moins communs (i.e. produits par un seul fabricant) ont
été utilisés. Afin de recenser les différents types de systèmes et
de rendre les discussions au sujet des machines un peu plus
faciles, nous proposons la méthode simple de classification
suivante:</p>
<p>CLASSE I BEOWULF:</p>
<p>Cette classe concerne des machines faites d'éléments globalement
disponibles. Nous devrons utiliser les tests de certification
"Computer Shopper" pour définir les composants d'assemblage.
("Computer Shopper" est un mensuel sur les PC et leurs composants.)
[NdT: US seulement ; pour un équivalent, on peut évoquer par
exemple "PC Direct".] Le test est le suivant:</p>
<p>Un Beowulf CLASSE I est une machine qui peut être assemblée à
partir de pièces trouvées dans au moins quatre journaux de
publicité de grande diffusion.</p>
<p>Les avantages des systèmes de CLASS I sont:</p>
<ul>
<li>le matériel est disponible de noubreuses sources (faible coût,
maintenance facile)</li>
<li>ne dépendant pas d'un seul vendeur de matériel</li>
<li>support des drivers par les commodités Linux</li>
<li>basé habituellement sur des standards (SCSI, Ethernet,
etc.)</li>
</ul>
<p>Les désavantages d'un système de CLASSE I sont:</p>
<ul>
<li>de meilleures performances peuvent nécessiter du matériel de
CLASSE II</li>
</ul>
<p>CLASSE II BEOWULF</p>
<p>Un Beowulf CLASSE II Beowulf est simplement une machine qui ne
passe pas le test de certification "Computer Shopper". Ce n'est pas
une mauvaise chose. D'autre part, il s'agit plutôt d'une
classification de la machine.</p>
<p>Les avantages d'un système de CLASSE II sont:</p>
<ul>
<li>les performances peuvent être assez bonnes !</li>
</ul>
<p>Les désavantages des systèmes de CLASSE II sont:</p>
<ul>
<li>le support des drivers peut varier</li>
<li>reposent sur un seul vendeur de matériel</li>
<li>peuvent être plus chers que les systèmes de CLASSE I.</li>
</ul>
<p>Une CLASSE n'est pas nécessairement meilleure qu'une autre. Cela
dépend surtout de vos besoins et de votre budget. Cette
classification des systèmes sert seulement à rendre les discussions
sur les systèmes Beowulf un peu plus succintes. La "Conception du
Système" peut aider à déterminer quelle sorte de système est le
plus approprié à vos besoins.</p>
<h2><a name="s3">3. Aperçu de l'Architecture</a></h2>
<h2><a name="ss3.1">3.1 A quoi cela ressemble-t-il ?</a></h2>
<p>Je pense que la meilleure façon de décrire l'architecture d'un
superordinateur Beowulf est d'utiliser un exemple qui est très
proche du vrai Beowulf, mais aussi familier à beaucoup
d'administrateurs systèmes. L'exemple le plus proche d'une machine
Beowulf est un Unix de laboratoire avec un serveur et un certain
nombre de clients. Pour être plus spécifique, j'utiliserai le DEC
Alpha au laboratoire d'informatique de la Faculté des Sciences de
l'USQ comme exemple. Le serveur est appelé <i>beldin</i> et les
machines clientes sont <i>scilab01</i>, <i>scilab02</i>,
<i>scilab03</i>, jusqu'à <i>scilab20</i>. Tous les clients ont une
copie locale du système d'exploitation Digital Unix 4.0 installé,
mais ont l'espace disque utilisateur (<code>/home</code>) et
<code>/usr/local</code> du serveur via NFS (Network File System).
Chaque client a une entrée pour le serveur et tous les autres
clients dans son fichier <code>/etc/hosts.equiv</code>: ainsi tous
les clients peuvent exécuter une cession distante (rsh) vers tout
autre. La machine serveur est un serveur NIS pour tout le
laboratoire, ainsi les informations des comptes sont les mêmes sur
toutes les machines. Une personne peut s'asseoir à la console de
<i>scilab02</i>, se logue, et a le même environnement que s'il
était logué sur le serveur, ou <i>scilab15</i>. La raison pour
laquelle les clients ont la même présentation est que le système
d'exploitation est installé et configuré de la même façon sur
toutes les machines, les espaces <code>/home</code> et
<code>/usr/local</code> sont physiquement sur le même serveur et
les clients y accèdent via NFS. Pour plus d'informations sur NIS et
NFS, reportez-vous à <a href=
"http://sunsite.unc.edu/LDP/HOWTO/NIS-HOWTO.html">NIS</a> et
<a href=
"http://sunsite.unc.edu/LDP/HOWTO/NFS-HOWTO.html">NFS</a>.</p>
<h2><a name="ss3.2">3.2 Comment utiliser les autres noeuds
?</a></h2>
<p>Maintenant que nous avons une vision correcte de l'architecture
du système, regardons comment nous pouvons utiliser les cycles CPU
des machines dans le laboratoire. Toute personne peut se loguer sur
n'importe laquelle des machines, et lancer un programme dans son
répertoire de base, mais peut aussi éclater la même tâche sur
différentes machines simplement en exécutant un shell distant. Par
exemple, si nous voulons calculer la somme des racines carrées de
tous les entiers inclus strictement entre 1 et 10, nous écrivons un
simple programme appelé <code>sigmasqrt</code> (voir <a href=
"#sigmasqrt">code source</a>) qui fait cela exactement. Pour
calculer la somme des racines carrées des nombres de 1 à 10, nous
exécutons :</p>
<pre>
[jacek@beldin sigmasqrt]$ time ./sigmasqrt 1 10
22.468278

real    0m0.029s
user    0m0.001s
sys     0m0.024s
</pre>
La commande <code>time</code> nous permet de vérifier le temps mis
en exécutant cette tâche. Comme nous pouvons le voir, cet exemple a
pris seulement une petite fraction de seconde (0.029 sec) pour
s'exécuter, mais que se passe-t-il si je veux ajouter la racine
carrée des entiers de 1 à 1 000 000 000 ? Essayons ceci, et
calculons le temps écoulé:
<pre>
[jacek@beldin sigmasqrt]$ time ./sigmasqrt 1 1000000000
21081851083600.559000

real    16m45.937s
user    16m43.527s
sys     0m0.108s
</pre>
<p>Cette fois, le temps d'exécution de ce programme est
considérablement supérieur. La question évidente qui se pose est:
est-il possible de diminuer le temps d'exécution de cette tâche et
comment ? La réponse évidente est de découper la tâche en un
ensemble de sous-tâches et d'exécuter ces sous-tâches en parallèle
sur tous les ordinateurs. Nous pouvons séparer la grande tâche
d'addition en 20 parties en calculant un intervalle de racines
carrées et en les additionnant sur un seul noeud. Quand tous les
noeuds ont fini les calculs et retournent leurs résultats, les 20
nombres peuvent être additionnés ensemble et fournir la solution
finale. Avant de lancer ce processus, nous allons créer un "named
pipe" qui sera utilisé par tous les processus pour écrire leurs
résultats:</p>
<pre>
[jacek@beldin sigmasqrt]$ mkfifo output
[jacek@beldin sigmasqrt]$ ./prun.sh &amp; time cat output | ./sum
[1] 5085
21081851083600.941000
[1]+  Done                    ./prun.sh

real    0m58.539s
user    0m0.061s
sys     0m0.206s
</pre>
<p>Cette fois, cela prend 58.5 secondes. C'est le temps qui a été
nécessaire entre le démarrage du processus et le moment où les
noeuds ont fini leurs calculs et écrit leurs résultats dans la
pipe. Ce temps n'inclut pas l'addition finale des 20 nombres, mais
il représente une petite fraction de seconde et peut être ignoré.
Nous pouvons voir qu'il y a un avantage significatif à exécuter une
tâche en parallèle. En fait la tâche en parallèle s'est exécutée 17
fois plus vite, ce qui est très raisonnable pour un facteur 20
d'augmentation du nombre de CPU. Le but de l'exemple précédent est
d'illustrer la méthode la plus simple de paralléliser du code
concurrent. En pratique, des exemples aussi simples sont rares et
différentes techniques (les API de PVM et PMI) sont utilisées pour
obtenir le parallélisme.</p>
<h2><a name="ss3.3">3.3 En quoi un Beowulf diffère-t-il d'un COW
?</a></h2>
<p>Le laboraroire d'informatique décrit plus haut est un exemple
parfait d'un cluster de stations (COW). Qu'est-ce qui rend donc
Beowulf si spécial et en quoi diffère-t-il d'un COW ? En réalité il
n'y a pas beaucoup de différence, mais un Beowulf a quelques
caractéristiques uniques. La première est que dans la plupart des
cas, les noeuds clients dans un cluster Beowulf n'ont pas de
clavier, de souris, de carte graphique ni de moniteur. Tous les
accès aux noeuds clients sont faits par une connection distante du
noeud serveur, un noeud dédié à une console, ou une console série.
Cela parce qu'il n'y a aucun besoin pour un noeud client d'accéder
à des machines en dehors du cluster, ni pour des machines en dehors
du cluster d'accéder à des noeuds clients directement; c'est une
pratique habituelle que les noeuds clients utilisent des adresses
IP privées comme les plages d'adresses 10.0.0.0/8 ou 192.168.0.0/16
(RFC 1918 <a href=
"http://www.alternic.net/rfcs/1900/rfc1918.txt.html">http://www.alternic.net/rfcs/1900/rfc1918.txt.html</a>).
D'habitude la seule machine qui est aussi connectée au monde
externe en utilisant une seconde carte réseau est le noeud serveur.
La façon la plus habituelle d'accéder au système est soit
d'utiliser la console du serveur directement, soit de faire un
telnet ou un login distant (rlogin) sur le noeud serveur d'une
station personnelle. Une fois sur celui-ci, les utilisateurs
peuvent éditer et compiler leur code, et aussi distribuer les
tâches sur tous les noeuds du cluster. Dans la plupart des cas, les
COW sont utilisées pour des calculs parallèles la nuit et les
week-ends, quand les stations ne sont pas utilisées pendant les
journées de travail, utilisant ainsi les périodes de cycles libres
des CPU. D'autre part, le Beowulf est une machine dédiée au calcul
parallèle, et optimisée pour cette tâche. Il donne aussi un
meilleur rapport prix/performance puisqu'il est constitué de
composants grand public et qu'il tourne principalement à partir de
logiciels libres. Beowulf donne aussi davantage l'image d'une seule
machine, ce qui permet aux utilisateurs de voir le cluster Beowulf
comme une seule station de calcul.</p>
<h2><a name="s4">4. Conception du Système</a></h2>
<p>Avant d'acheter du matériel, il serait de bon aloi de considérer
le design de votre système. Il y a deux approches matérielles qui
sont impliquées dans le design d'un système Beowulf: le type de
noeuds ou d'ordinateurs que vous allez utiliser, et la méthode que
vous allez utiliser pour vous connecter aux noeuds d'ordinateurs.
Il n'y a qu'une seule approche logicielle qui puisse affecter votre
choix matériel: la librairie de communication ou API. Une
discussion plus détaillée sur le matériel et les logiciels de
communication est fournie plus loin dans ce document.</p>
<p>Alors que le nombre de choix n'est pas grand, il y a des
considérations de conception qui doivent être prises pour la
construction d'un cluster Beowulf. La science (ou art) de la
"programmation parallèle" étant l'objet de nombreuses
interprétations, une introduction est fournie plus bas. Si vous ne
voulez pas lire les connaissances de base, vous pouvez survoler
cette section, mais nous vous conseillons de lire la section
<a href="#suitability">Convenance</a> avant tout choix défninitif
de matériel.</p>
<h2><a name="ss4.1">4.1 Brefs rappels sur la programmation
parallèle</a></h2>
<p>Cette section fournit des informations générales sur les
concepts de la programmation parallèle. Ceci n'est PAS exhaustif,
ce n'est pas une description complète de la programmation parallèle
ou de sa technologie. C'est une brève description des enjeux qui
peuvent influer fortement sur le concepteur d'un Beowulf, ou sur
son utilisateur.</p>
<p>Lorsque vous déciderez de construire votre Beowulf, de nombreux
points décrits plus bas deviendront importants dans votre processus
de choix. A cause de la nature de ses "composants", un
Superordinateur Beowulf nécessite de prendre de nombreux facteurs
en compte, car maintenant ils dépendent de nous. En général, il
n'est pas du tout difficile de comprendre les objectifs impliqués
dans la programmation parallèle. D'ailleurs, une fois que ces
objectifs sont compris, vos attentes seront plus réalistes, et le
succès plus probable. Contrairement au "monde séquentiel", où la
vitesse du processeur est considérée comme le seul facteur
important, la vitesse des processeurs dans le "monde parallèle"
n'est que l'un des paramètres qui détermineront les performances et
l'efficacité du système dans son ensemble.</p>
<h2><a name="ss4.2">4.2 Les méthodes de programmation
parallèle</a></h2>
<p>La programmation parallèle peut prendre plusieurs formes. Du
point de vue de l'utilisateur, il est important de tenir compte des
avantages et inconvénients de chaque méthodologie. La section
suivante tente de fournir quelques aperçus sur les méthodes de
programmation parallèle et indique où la machine Beowulf fait
défaut dans ce continuum.</p>
<h3>Pourquoi plus d'un CPU ?</h3>
<p>Répondre à cette question est important. Utiliser 8 CPU pour
lancer un traitement de texte sonne comme "trop inutile" -- et ce
l'est. Et qu'en est-il pour un serveur web, une base de données, un
programme de ray-tracing, ou un planificateur de projets ?
Peut-être plus de CPU peuvent-ils améliorer les performances. Mais
qu'en est-il de simulations plus complexes, de la dynamique des
fluides, ou d'une application de Fouille de Données (Data Mining) ?
Des CPU supplémentaires sont absolument nécessaires dans ces
situations. D'ailleurs, de multiples CPU sont utilisés pour
résoudre de plus en plus de problèmes.</p>
<p>La question suivante est habituellement: "Pourquoi ai-je besoin
de deux ou quatre CPU ? Je n'ai qu'à attendre le méga super rapide
processeur 986." Il y a de nombreuses raisons:</p>
<ol>
<li>Avec l'utilisation de systèmes d'exploitations multi-tâches, il
est possible de faire plusieurs choses en même temps. Cela est un
"parallélisme" naturel qui est exploité par plus d'un CPU de bas
prix.</li>
<li>La vitesse des processeurs double tous les 18 mois mais qu'en
est-il de la vitesse de la mémoire ? Malheureusement, celle-ci
n'augmente pas aussi vite que celle des processeurs. Gardez à
l'esprit que beaucoup d'applications ont besoin de mémoire autre
que celle du cache processeur et de l'accès disque. Faire les
choses en parallèle est une façon de contourner ces
limitations.</li>
<li>Les prédictions indiquent que la vitesse des processeurs ne
continuera pas à doubler tous les 18 mois après l'an 2005. Il y a
divers obstacles à surmonter pour maintenir ce rythme.</li>
<li>Suivant l'application, la programmation parallèle peut
accélérer les choses de 2 à 500 fois (et même plus dans certains
cas). De telles performances ne sont pas disponibles sur un seul
processeur. Même les Superordinateurs qui utilisaient à un moment
un seul processeur spécialisé très rapide sont maintenant
constitués de nombreux CPU plus banals.</li>
</ol>
<p>Si vous avez besoin de vitesse -- à cause d'un problème lié au
calcul et/ou aux entrées/sorties --, il vaut la peine de considérer
l'approche parallèle. Comme le calcul parallèle est implémenté
selon de nombreuses voies, résoudre votre problème en parallèle
nécessitera de prendre quelques décisions importantes. Ces
décisions peuvent affecter dramatiquement la protabilité, la
performance, et le coût de votre application.</p>
<p>Avant d'être par trop technique, regardons un vrai "problème de
calcul parallèle" en utilisant un exemple qui nous est familier:
faire la queue à une caisse.</p>
<h3>La "caisse" en programmation parallèle</h3>
<p>Considérons un grand magasin avec 8 caisses regroupées devant le
magasin. Imaginons que chaque caisse est un CPU et chaque client un
programme informatique. La taille du programme (quantité de calcul)
est la taille de la commande de chaque client. Les analogies
suivantes peuvent être utilisées pour illustrer les concepts de la
programmation parallèle:</p>
<h3>Systèmes d'exploitation Mono-Tâche:</h3>
<p>Une caisse ouverte (et en service) qui ne peut traiter qu'un
client à la fois.</p>
<p>Exemple en Informatique : MS DOS</p>
<h3>Systèmes d'exploitation Multi-Tâches:</h3>
<p>Une caisse ouverte, mais maintenant nous pouvons traiter une
partie de chaque commande à un instant donné, aller à la personne
suivante et traiter une partie de sa commande. Tout le monde
"semble" avancer dans la queue en même temps, mais s'il n'y a
personne dans la queue, vous serez servi plus vite.</p>
<p>Exemple en Informatique : UNIX, NT avec un seul CPU</p>
<h3>Systèmes d'exploitation Multi-Tâches avec plusieurs CPU:</h3>
<p>Maintenant on ouvre plusieurs caisses dans le magasin. Chaque
commande peut être traitée par une caisse différente et la queue
peut avancer plus vite. Ceci est appelé SMP - Gestion Multiple
Symétrique (Symmetric Multi-processing). Même s'il y a plus de
caisses ouvertes, vous n'avancerez pas plus vite dans la queue que
s'il n'y avait qu'une seule caisse.</p>
<p>Exemple en Informatique : UNIX, NT avec plusieurs CPU</p>
<h3>Sous-tâches (Threads) sur les autres CPU d'un Système
d'exploitation Multi-Tâches:</h3>
<p>Si vous "séparez" les objets de votre commande, vous pouvez être
capable d'avancer plus vite en utilisant plusieurs caisses en même
temps. D'abord, nous postulons que vous achetez une grande quantité
d'objets, parce que le temps que vous investirez pour "séparer"
votre commande doit être regagné en utilisant plusieurs caisses. En
théorie, vous devriez être capables de vous déplacer dans la queue
"n" fois plus vite qu'avant, où "n" est le nombre de caisses. Quand
les caissiers ont besoin de faire des sous-totaux, ils peuvent
échanger rapidement les informations visuellement et en discutant
avec toutes les autres caisses "locales". Ils peuvent aussi aller
chercher directement dans les registres des autres caisses pour
trouver les informations dont ils ont besoin pour travailler plus
vite. La limite étant le nombre de caisses qu'un magasin peut
effectivement installer.</p>
<p>La loi de Amdals montre que l'accélération de l'application est
liée à la portion séquentielle la plus lente exécutée par le
programme (NdT: i.e. majorée par la tâche la plus lente).</p>
<p>Exemple en Informatique : UNIX ou NT avec plusieurs CPU sur la
même carte-mère avec des programmes multi-threads.</p>
<h3>Envoyer des messages sur des Systèmes d'exploitation
Multi-Tâches avec plusieurs CPU:</h3>
<p>De façon à améliorer la performance, la Direction ajoute 8
caisses à l'arrière du magasin. Puisque les nouvelles caisses sont
loin du devant du magasin, les caissiers doivent téléphoner pour
envoyer leurs sous-totaux vers celui-ci. La distance ajoute un
délai supplémentaire (en temps) dans la communication entre
caissiers, mais si la communication est minimisée, cela ne pose pas
de problème. Si vous avez vraiment une grosse commande, une qui
nécessite toutes les caisses, alors comme avant votre vitesse peut
être améliorée en utilisant toutes les caisses en même temps, le
temps sopplémentaire devant être pris en compte. Dans certains cas,
le magasin peut n'avoir que des caisses (ou des îlots de caisses)
localisés dans tout le magasin : chaque caisse (ou îlot) doit
communiquer par téléphone. Puisque tous les caissiers peuvent
discutter par téléphone, leur emplacement importe peu.</p>
<p>Exemple en Informatique : Une ou plusieurs copies d'UNIX ou NT
avec plusieurs CPU sur la même, ou différentes cartes-mères
communiquant par messages.</p>
<p>Les scénarios précédents, même s'ils ne sont pas exacts, sont
une bonne représentation des contraintes qui agissent sur les
systèmes parallèles. Contrairement aux machines avec un seul CPU
(ou caisse), la communication est importante.</p>
<h2><a name="ss4.3">4.3 Architectures pour le calcul
parallèle</a></h2>
<p>Les méthodes et architectures habituelles de la programmation
parallèle sont représentées ci-dessous. Même si cette description
n'est en aucun cas exhaustive, elle est suffisante pour comprendre
les impératifs de base dans la conception d'un Beowulf.</p>
<h3>Architectures Matérielles</h3>
<p>Il y a typiquement deux façons d'assembler un ordinateur
parallèle:</p>
<ol>
<li>La mémoire locale des machines qui communiquent par messages
(Clusters Beowulf)</li>
<li>Les machines à mémoire partagée qui communiquent à travers la
mémoire (machines SMP)</li>
</ol>
<p>Un Beowulf typique est une collection de machines
mono-processeurs connectées utilisant un réseau Ethernet rapide, et
qui est ainsi une machine à mémoire locale. Une machine à 4 voies
SMP est une machine à mémoire partagée et peut être utilisée pour
du calcul parallèle -- les applications parallèles communiquant via
la mémoire partagée. Comme pour l'analogie du grand magasin, les
machines à mémoire locale (donc à caisse individuelle) peuvent être
scalairisées jusqu'à un grand nombre de CPU ; en revanche, le
nombre de CPU que les machines à mémoire partagée peuvent avoir (le
nombre de caisses que vous pouvez placer en un seul endroit) peut
se trouver limité à cause de l'utilisation (et/ou de la vitesse) de
la mémoire.</p>
<p>Il est toutefois possible de connecter des machines à mémoire
partagée pour créer une machine à mémoire partagée "hybride". Ces
machines hybrides "ressemblent" à une grosse machine SMP pour
l'utilisateur et sont souvent appelées des machines NUMA (accès
mémoire non uniforme) parce que la mémoire globale vue par le
programmeur et partagée par tous les CPU peut avoir différents
temps d'accès. A un certain niveau d'ailleurs, une machine NUMA
doit "passer des messages" entre les groupes de mémoires
partagées.</p>
<p>Il est aussi possible de connecter des machines SMP en tant que
noeuds de mémoire locale. Typiquement, les cartes-mères de CLASSE I
ont soit 2 ou 4 CPU et sont souvent utilisées comme moyens pour
réduire le coût global du système. L'arrangeur (scheduler) interne
de Linux détermine combien de ces CPU sont partagés. L'utilisateur
ne peut (à ce jour) affecter une tâche à un processeur SMP
spécifique. Cet utilisateur peut quand même démarrer deux processus
indépendants ou un programme multi-threads et s'attendre à voir une
amélioration de performance par rapport à un système à simple
CPU.</p>
<h3>Architectures Logicielles et API</h3>
<p>Il y a basiquement deux façons d'"exprimer" la concurrence dans
un programme:</p>
<ol>
<li>En envoyant des Messages entre les processeurs</li>
<li>En utilisant les threads du système d'exploitation
(natives)</li>
</ol>
<p>D'autres méthodes existent, mais celles-là sont le plus
généralement employées. Il est important de se souvenir que
l'expression de concurrence n'est pas nécessairement contrôlée par
la couche matérielle. Les Messages et les Threads peuvent être
implémentés sur des SMPn NUMA-SMP, et clusters -- même si, comme
expliqué ci-dessous, l'efficacité et la portabilité sont des
facteurs importants.</p>
<h3>Messages</h3>
<p>Historiquement, la technologie de passage de messages reflétait
les débuts des ordinateurs parallèles à mémoire locale. Les
messages nécessitent la copie des données tandis que les Threads
utilisent des données à la place. Le temps de latence et la vitesse
à laquelle les messages peuvent être copiés sont les facteurs
limitants des modèles de passage de messages. Un message est assez
simple: des données et un processeur de destination. Des API de
passage de messages répandues sont entre autres <a href=
"http://www.epm.ornl.gov/pvm">PVM</a> ou <a href=
"http://www.mcs.anl.gov/Projects/mpi/index.html">MPI</a>. Le
passage de Messages peut être implémenté avec efficacité en
utilisant ensemble des Threads et des Messages entre SMP et
machines en cluster. L'avantage d'utiliser les messages sur une
machine SMP, par rapport aux Threads, est que si vous décidez
d'utiliser des clusters dans le futur, il est facile d'ajouter des
machines ou de scalairiser vos applications.</p>
<h3>Threads</h3>
<p>Les Threads ont été développés sur les systèmes d'exploitation
parce que la mémoire partagée des SMP (moutiprocessorage
symmétrique) permettait une communication très rapide et une
synchronisation de la mémoire partagée entre les parties d'un
programme. Les Threads marchent bien sur les systèmes SMP parce que
la communication a lieu à travers la mémoire partagée. Pour cette
raison, l'utilisateur doit isoler les données locales des données
globales, sinon les programmes ne fonctionneront pas correctement.
Cela est en contraste avec les messages: une grande quantité de
copie peut être éliminée avec les threads car les données sont
partagées entre les processus (threads). Linux implémente les
Threads POSIX. Le problème avec les Threads vient du fait qu'il est
difficile de les étendre au-delà d'une machine SMP, et, comme les
données sont partagées entre les CPU, la gestion de la cohérence du
cache peut contribuer à le charger. Etendre les Threads au-delà des
limites des performances des SMP nécessite la technologie NUMA qui
est chère et n'est pas nativement supportée par Linux. Implémenter
des Threads par dessus les messages a été fait ( <a href=
"http://syntron.com/ptools/ptools_pg.htm">(http://syntron.com/ptools/ptools_pg.htm)</a>),
mais les Threads sont souvent inefficients une fois implémentés en
utilisant des messages.</p>
<p>On peut résumer ainsi les performances:</p>
<pre>
          performance        performance
          machine SMP     cluster de machines  scalabilité
          -----------     -------------------  -----------
messages     bonne             meilleure        meilleure

threads    meilleure           mauvaise*        mauvaise*

* nécessite une technologie NUMA coûteuse.
</pre>
<h3>Architecture des Applications</h3>
<p>Pour exécuter une application en parallèle sur des CPU
multiples, celle-ci doit être explicitement découpée en parties
concurrentes. Une application standard mono-CPU ne s'exécutera pas
plus rapidement même si elle est exécutée sur une machine
multi-processeurs. Certains outils et compilateurs peuvent découper
les programmesn mais la parallélisation n'est pas une opération
"plug and play". Suivant l'application, la parallélisation peut
être facile, extrêmement difficile, voire impossible suivant les
contraintes de l'algorithme.</p>
<p>Avant de parler des besoins applicatifs, il nous faut introduire
le concept de Convenance (Suitability).</p>
<h2><a name="suitability"></a> <a name="ss4.4">4.4
Convenance</a></h2>
<p>Beaucoup de questions au sujet du calcul parallèle ont la même
réponse:</p>
<p>"Cela dépend entièrement de l'application."</p>
<p>Avant de passer directement aux opportunités, il y a une
distinction très importante qui doit être faite: la différence
entre CONCURRENT et PARALLELE. Pour clarifier cette discussion,
nous allons définir ces deux termes ainsi:</p>
<p>les parties CONCURRENTES d'un programme sont celles qui peuvent
être calculées indépendamment.</p>
<p>Les parties PARALLELES d'un programme sont celles qui sont
exécutées sur des éléments de calculs au même moment.</p>
<p>La distinction est très importante, parce que la CONCURRENCE est
une propriété d'un programme et l'efficacité en PARALLELISME est
une propriété de la machine. Idéalement, l'exécution en parallèle
doit produire des performances plus grandes. Le facteur limitant
les performances en parallèle est la vitesse de communication et le
temps de latence entre les noeuds de calcul. (Le temps de latence
existe aussi dans les applications TMP threadées à cause de la
cohérence du cache). De nombreux tests de performances communs sont
hautement parallèles, et ainsi la communication et le temps de
latence ne sont pas les points importants. Ce type de problème peut
être appelé "évidemment parallèle". D'autres applications ne sont
pas si simples et exécuter des parties CONCURRENTES du programme en
PARALLELE peut faire en sorte que le programme fonctionne plus
lentement, et ainsi décaler toute performance de gain dans d'autres
parties CONCURRENTES du programme. En termes plus simples, le coût
en temps de communication doit en pâtir au profit de celui gagné en
temps de calcul, sinon l'exécution PARALLELE des parties
CONCURRENTES est inefficace.</p>
<p>La tâche du programmeur est de déterminer quelles parties
CONCURRENTES le programmeur DOIT exécuter en PARALLELE et pour
quelles parties il NE DOIT PAS le faire. Sa réponse déterminera
l'EFFICACITE de l'application. Le graphe suivant résume la
situation pour le programmeur:</p>
<pre>



         | *
         | *
         | *
 % des   | *
 appli-  |  *
 cations |  *
         |  *
         |  *
         |    *
         |     *
         |      *
         |        ****
         |            ****
         |                ********************
         +-----------------------------------
          temps de communication/temps de calcul
</pre>
<p>Dans un ordinateur parallèle parfait, le rapport
communication/calcul devrait être égal et tout ce qui est
CONCURRENT pourrait être implémenté en PARALLELE. Malheureusement,
les vrais ordinateurs parallèles, incluant les machines à mémoire
partagée, sont sujets aux effets décrits dans ce graphe. En
concevant un Beowulf, l'utilisateur devrait garder celui-ci en tête
parce que la performance dépend du rapport entre le temps de
communication et le temps de calcul pour un ORDINATEUR PARALLELE
SPECIFIQUE. Les applications peuvent être portables entre les
ordinateurs parallèles, mais il n'y a aucune garantie qu'elles
seront efficaces sur une plateforme différente.</p>
<p>EN GENERAL, IL N'EXISTE PAS DE PROGRAMME PORTABLE EFFICACE EN
PARALLELE</p>
<p>Il y a encore une autre conséquence au graphe précédent. Puisque
l'efficacité dépend du rapport communication/calcul, changer juste
un composant du rapport ne signifie pas nécessairement qu'une
application s'exécutera plus rapidement. Un changement de vitesse
processeur, en gardant la même vitesse de communication, peut avoir
des effets inattendus sur votre programme. Par exemple, doubler ou
tripler la vitesse du processeur, en gardant la même vitesse de
communication, peut maintenant rendre des parties de votre
programme qui sont efficaces en PARALLELE, plus efficaces si elles
étaient exécutées SEQUENTIELLEMENT. Cela dit, il se peut qu'il soit
plus rapide maintenant d'exécuter les parties qui étaient avant
PARALLELES en tant que SEQUENTIELLES. D'autant plus qu'exécuter des
parties inefficaces en PARALLELE empêchera votre application
d'atteindre sa vitesse maximale. Ainsi, en ajoutant un processeur
plus rapide, vous avez peut-être ralenti votre application (vous
enpêchez votre nouveau CPU de fonctionner à sa vitesse maximale
pour cette application).</p>
<p>UPGRADER VERS UN CPU PLUS RAPIDE PEUT REELLEMENT RALENTIR VOTRE
APPLICATION</p>
<p>Donc, en conclusion, pour savoir si oui ou non vous pouvez
utiliser un environnement matériel parallèle, vous devez avoir un
bon aperçu des capacités d'une machine particulière pour votre
application. Vous devez tenir compte de beaucoup de facteurs:
vitesse de la CPU, compilateur, API de passage de messages,
réseau... Notez que se contenter d'optimiser une application ne
donne pas toutes les informations. Vous pouvez isoler une lourde
partie de calcul de votre programme, mais ne pas connaître son coût
au niveau de la communication. Il se peut que pour un certain
système, le coût de communication ne rende pas efficace de
paralléliser ce code.</p>
<p>Une note finale sur une erreur commune: on dit souvent qu'"un
programme est PARALLELISE", mais en réalité seules les parties
CONCURRENTES ont été identifiées. Pour toutes les raisons
précédentes, le programme n'est pas PARALLELISE. Une
PARALLELISATION efficace est une propriété de la machine.</p>
<h2><a name="ss4.5">4.5 Ecrire et porter des logiciels
parallèles</a></h2>
<p>A partir du mmoment où vous avez décidé de concevoir et de
construire un Beowulf, considérer un instant votre application en
accord avec les observations précédentes est une bonne idée.</p>
<p>En général, vous pouvez faire deux choses:</p>
<ol>
<li>Y aller et construire un Beowulf CLASSE I et après y ajuster
votre application. Ou exécuter des applications parallèles que vous
savez fonctionner sur votre Beowulf (mais attention à la
portabilité et à l'efficacité en accord avec les informations
citées ci-dessus).</li>
<li>Examiner les applications dont vous avez besoin sur votre
Beowulf, et faire une estimation quant au type de matériel et de
logiciels qu'il vous faut.</li>
</ol>
<p>Dans chaque cas, vous devrez considérer les besoins en
efficacité. En général, il y a trois choses à faire:</p>
<ol>
<li>Déterminer les parties concurrentes de votre programme</li>
<li>Estimer le parallélisme efficacement</li>
<li>Décrire les parties concurrentes de votre programme</li>
</ol>
<p>Examinons-les successivement:</p>
<h3>Déterminer les parties concurrentes de votre programme</h3>
<p>Cette étape est couvent considérée comme "paralléliser votre
programme". Les décisions de parallélisation seront faites à
l'étape 2. Dans cette étape, vous avez besoin de déterminer les
liens et les besoins dans les données.</p>
<p>D'un point de vue pratique, les applications peuvent présenter
deux types de concurrence: calcul (travaux numériques) et E/S
(Bases de Données). Même si dans de nombreux cas, la concurrence
entre calculs et E/S est orthogonale, des applications ont besoin
des deux. Des outils existants peuvent faire l'analyse de la
concurrence sur des applications existantes. La plupart de ces
outils sont conçus pour le FORTRAN. Il y a deux raisons pour
lesquelles le FORTRAN est utilisé: historiquement, la majorité des
applications gourmandes en calculs numériques étaient écrites en
FORTRAN et c'était donc plus facile à analyser. Si aucun de ces
outils n'est disponible, alors cette étape peut être quelque peu
difficile pour des applications existantes.</p>
<h3>Estimer le parallélisme efficacement</h3>
<p>Sans l'aide d'outils, cette étape peut nécessiter un cycle de
tests et erreurs, ou seulement de bons vieux réflexes bien éduqués.
Si vous avez une application spécifique en tête, essayez de
déterminer la limite du CPU (liée au calcul) ou les limites des
disques (liées aux E/S). Les spécifités de votre Beowulf peuvent
beaucoup dépendre de vos besoins. Par exemple, un problème lié au
calcul peut ne nécessiter qu'un petit nombre de CPU très rapides et
un réseau très rapide à faible temps de latence, tandis qu'un
problème lié aux E/S peut mieux travailler avec des CPU plus lents
et un Ethernet rapide.</p>
<p>Cette recommandation arrive souvent comme une surprise pour
beaucoup, la croyance habituelle étant que plus le processeur est
rapide, mieux c'est. Mais cela n'est vrai que si vous avez un
budget illimité: les vrais systèmes peuvent avoir des contraintes
de coûts qui doivent être optimisées. Pour les problèmes liés aux
E/S, il existe une loi peu connue (appelée la loi de
Eadline-Dedkov) qui est assez utile:</p>
<p>Soient deux machines parallèles avec le même index de
performance CPU cumulée, celle qui a les processeurs les plus lents
(et probablement un réseau de communication interprocesseur plus
lent) aura les meilleures performances pour des applications
dominées par les E/S.</p>
<p>Même si les preuves de cette règle vont au-delà de ce document,
vous pouvez trouver intéressant de lire l'article <i>Performance
Considerations for I/O-Dominant Applications on Parallel
Computers</i> (format Postscript 109K) <a href=
"ftp://www.plogic.com/pub/papers/exs-pap6.ps">(ftp://www.plogic.com/pub/papers/exs-pap6.ps)</a></p>
<p>Une fois que vous aurez déterminé quel type de concurrence vous
avez dans votre application, vous devrez estimer à quel point elle
sera efficace en parallèle. Voir la Section <a href=
"#software">Logiciels</a> pour une description des outils
Logiciels.</p>
<p>En l'absence d'outils, il vous faudra peut-être improviser votre
chemin lors de cette étape. Si une boucle liée aux calculs est
mesurée en minutes et que les données peuvent être transférées en
secondes, alors c'est un bon candidat pour la parallélisation. Mais
souvenez-vous que si vous prenez une boucle de 16 minutes et la
coupez en 32 morceaux, et que vos transferts de données ont besoin
de quelques secondes par partie, alors cela devient plus réduit en
termes de performances. Vous atteindrez un point de retours en
diminution.</p>
<h3>Décrire les parties concurrentes de votre programme</h3>
<p>Il y a plusieurs façons de décrire les parties concurrentes de
votre programme:</p>
<ol>
<li>L'exécution parallèle explicite</li>
<li>L'exécution parallèle implicite</li>
</ol>
<p>La différence principale entre les deux est que le parallélisme
explicite est déterminé parl'utilisateur, alors que le parallélisme
implicite est déterminé par le compilateur.</p>
<h3>Les méthodes explicites</h3>
<p>Il y a principalement des méthodes où l'utilisateur peut
modifier le code source spécifique pour une machine parallèle.
L'utilisateur doit soit ajouter des messages en utilisant <a href=
"http://www.epm.ornl.gov/pvm">PVM</a> ou <a href=
"http://www.mcs.anl.gov/Projects/mpi/index.html">MPI</a>, soit
ajouter des threads POSIX. (Souvenez vous que les threads ne
peuvent se déplacer entre les cartes-mères SMP).</p>
<p>Les méthodes explicites tendent à être les plus difficiles à
implémenter et à déboguer. Les utilisateurs ajoutent typiquement
des appels de fonctions dans le code source FORTRAN 77 standard ou
C/C++. La librairie MPI a ajouté des fonctions pour rendre
certaines méthodes parallèles plus faciles à implémenter (i.e. les
fonctions scatter/gather). De plus, il est aussi possible d'ajouter
des librairies standard qui ont été écrites pour des ordinateurs
parallèles. Souvenez-vous quand même du compromis
efficacité/portabilité.</p>
<p>Pour des raisons historiques, beaucoup d'applications gourmandes
en calculs sont écrites en FORTRAN. Pour cette raison, FORTRAN
dispose du plus grand nombres de supports pour le calcul parallèle
(outils, librairies ...). De nombreux programmeurs utilisent
maintenant C ou réécrivent leurs applications FORTRAN existantes en
C, avec l'idée que C permettra une exécution plus rapide. Même si
cela est vrai puisque C est la chose la plus proche du code machine
universel, il a quelques inconvénients majeurs. L'utilisation de
pointeurs en C rend la détermination des dépendances entre données
et l'analyse automatique des pointeurs extrêmement difficiles. Si
vous avez des applications existantes en FORTRAN et que vous
voudrez les paralléliser dans le futur - NE LES CONVERTISSEZ PAS EN
C !</p>
<h3>Méthodes Implicites</h3>
<p>Les méthodes implicites sont celles dans lesquelles
l'utilisateur abandonne quelques décisions de parallélisation (ou
toutes) au compilateur. Par exemple le FORTRAN 90, High Performance
FORTRAN (HPF), Bulk Synchronous Parallel (BSP), et toute une série
de méthodes qui sont en cours de développement.</p>
<p>Les méthodes implicites nécessitent de la part de l'utilisateur
des informations concernant la nature concurrente de leur
application, mais le compilateur prendra quand même beaucoup de
décicions sur la manière d'exécuter cette concurrence en parallèle.
Ces méthodes procurent un niveau de portabilité et d'efficacité,
mais il n'y a pas de "meilleure façon" de décrire un problème
concurrent pour un ordinateur parallèle.</p>
<h2><a name="s5">5. Ressources Beowulf</a></h2>
<h2><a name="ss5.1">5.1 Points de départ</a></h2>
<ul>
<li>Liste de diffusion US Beowulf. Pour s'inscrire, envoyer un
courriel à <a href=
"mailto:beowulf-request@cesdis.gsfc.nasa.gov">beowulf-request@cesdis.gsfc.nasa.gov</a>
avec le mot <i>subscribe</i> dans le corps du message.</li>
<li>Homepage Beowulf <a href=
"http://www.beowulf.org">http://www.beowulf.org</a></li>
<li>Extreme Linux <a href=
"http://www.extremelinux.org">http://www.extremelinux.org</a></li>
<li>Extreme Linux Software pour Red Hat <a href=
"http://www.redhat.com/extreme">http://www.redhat.com/extreme</a></li>
</ul>
<h2><a name="ss5.2">5.2 Documentation</a></h2>
<ul>
<li>La dernière version du Beowulf HOWTO en Anglais <a href=
"http://www.sci.usq.edu.au/staff/jacek/beowulf">http://www.sci.usq.edu.au/staff/jacek/beowulf</a>.</li>
<li>La dernière version du Beowulf HOWTO en Français <a href=
"http://www.e-nef.com/linux//beowulf">http://www.e-nef.com/linux/beowulf</a>.</li>
<li>Construire un système Beowulf <a href=
"http://www.cacr.caltech.edu/beowulf/tutorial/building.html">http://www.cacr.caltech.edu/beowulf/tutorial/building.html</a></li>
<li>Les liens de Jacek sur Beowulf <a href=
"http://www.sci.usq.edu.au/staff/jacek/beowulf">http://www.sci.usq.edu.au/staff/jacek/beowulf</a>.</li>
<li>Beowulf Installation and Administration HOWTO (DRAFT) <a href=
"http://www.sci.usq.edu.au/staff/jacek/beowulf">http://www.sci.usq.edu.au/staff/jacek/beowulf</a>.</li>
<li>Linux Parallel Processing HOWTO <a href=
"http://yara.ecn.purdue.edu/~pplinux/PPHOWTO/pphowto.html">http://yara.ecn.purdue.edu/~pplinux/PPHOWTO/pphowto.html</a></li>
</ul>
<h2><a name="papers"></a> <a name="ss5.3">5.3 Publications</a></h2>
<ul>
<li>Chance Reschke, Thomas Sterling, Daniel Ridge, Daniel Savarese,
Donald Becker, and Phillip Merkey <i>A Design Study of Alternative
Network Topologies for the Beowulf Parallel Workstation</i>.
Proceedings Fifth IEEE International Symposium on High Performance
Distributed Computing, 1996. <a href=
"http://www.beowulf.org/papers/HPDC96/hpdc96.html">http://www.beowulf.org/papers/HPDC96/hpdc96.html</a></li>
<li>Daniel Ridge, Donald Becker, Phillip Merkey, Thomas Sterling
Becker, and Phillip Merkey. <i>Harnessing the Power of Parallelism
in a Pile-of-PCs</i>. Proceedings, IEEE Aerospace, 1997. <a href=
"http://www.beowulf.org/papers/AA97/aa97.ps">http://www.beowulf.org/papers/AA97/aa97.ps</a></li>
<li>Thomas Sterling, Donald J. Becker, Daniel Savarese, Michael R.
Berry, and Chance Res. <i>Achieving a Balanced Low-Cost
Architecture for Mass Storage Management through Multiple Fast
Ethernet Channels on the Beowulf Parallel Workstation</i>.
Proceedings, International Parallel Processing Symposium, 1996.
<a href=
"http://www.beowulf.org/papers/IPPS96/ipps96.html">http://www.beowulf.org/papers/IPPS96/ipps96.html</a></li>
<li>Donald J. Becker, Thomas Sterling, Daniel Savarese, Bruce
Fryxell, Kevin Olson. <i>Communication Overhead for Space Science
Applications on the Beowulf Parallel Workstation</i>.
Proceedings,High Performance and Distributed Computing, 1995.
<a href=
"http://www.beowulf.org/papers/HPDC95/hpdc95.html">http://www.beowulf.org/papers/HPDC95/hpdc95.html</a></li>
<li>Donald J. Becker, Thomas Sterling, Daniel Savarese, John E.
Dorband, Udaya A. Ranawak, Charles V. Packer. <i>BEOWULF: A
PARALLEL WORKSTATION FOR SCIENTIFIC COMPUTATION</i>. Proceedings,
International Conference on Parallel Processing, 95. <a href=
"http://www.beowulf.org/papers/ICPP95/icpp95.html">http://www.beowulf.org/papers/ICPP95/icpp95.html</a></li>
<li>Publications sur le site de Beowulf <a href=
"http://www.beowulf.org/papers/papers.html">http://www.beowulf.org/papers/papers.html</a></li>
</ul>
<h2><a name="software"></a> <a name="ss5.4">5.4 Logiciels</a></h2>
<ul>
<li>PVM - Parallel Virtual Machine/Machine Parallèle Virtuelle
<a href=
"http://www.epm.ornl.gov/pvm/pvm_home.html">http://www.epm.ornl.gov/pvm/pvm_home.html</a></li>
<li>LAM/MPI - Local Area Multicomputer / Message Passing Interface
Multi-Ordinateurs locaux / Interface de Transmission de Messages
<a href=
"http://www.mpi.nd.edu/lam">http://www.mpi.nd.edu/lam</a></li>
<li>BERT77 - outil de conversion FORTRAN <a href=
"http://www.plogic.com/bert.html">http://www.plogic.com/bert.html</a></li>
<li>logiciels Beowulf de la page du Projet Beowulf <a href=
"http://beowulf.gsfc.nasa.gov/software/software.html">http://beowulf.gsfc.nasa.gov/software/software.html</a></li>
<li>Jacek's Beowulf-outils <a href=
"ftp://ftp.sci.usq.edu.au/pub/jacek/beowulf-utils">ftp://ftp.sci.usq.edu.au/pub/jacek/beowulf-utils</a></li>
<li>bWatch - logiciel de surveillance de cluster <a href=
"http://www.sci.usq.edu.au/staff/jacek/bWatch">http://www.sci.usq.edu.au/staff/jacek/bWatch</a></li>
</ul>
<h2><a name="ss5.5">5.5 Machines Beowulf</a></h2>
<ul>
<li>Avalon consiste en 140 processeurs Alpha, 36 Go de RAM, et est
probablement la machine Beowulf la plus rapide, allant à 47.7
Gflops et classée 114ème sur la liste du Top 500. <a href=
"http://swift.lanl.gov/avalon/">http://swift.lanl.gov/avalon/</a></li>
<li>Megalon-A Massively PArallel CompuTer Resource (MPACTR)
consiste en 14 quadri CPU Pentium Pro 200 noeuds, et 14 Go de RAM.
<a href=
"http://megalon.ca.sandia.gov/description.html">http://megalon.ca.sandia.gov/description.html</a></li>
<li>theHIVE - Highly-parallel Integrated Virtual Environment est un
autre Superordinateur Beowulf rapide. theHIVE est de 64 noeuds, une
machine de 128 CPU avec un total de 4 Go de RAM. <a href=
"http://newton.gsfc.nasa.gov/thehive/">http://newton.gsfc.nasa.gov/thehive/</a></li>
<li>Topcat est une machine beaucoup plus petite, constituée de 16
CPU et 1.2 Go de RAM. <a href=
"http://www.sci.usq.edu.au/staff/jacek/topcat">http://www.sci.usq.edu.au/staff/jacek/topcat</a></li>
<li>MAGI cluster -- c'est un très bon site avec de nombreux liens
de qualité. <a href=
"http://noel.feld.cvut.cz/magi/">http://noel.feld.cvut.cz/magi/</a></li>
</ul>
<h2><a name="ss5.6">5.6 D'autres Sites Intéressants</a></h2>
<ul>
<li>Linux SMP <a href=
"http://www.linux.org.uk/SMP/title.html">http://www.linux.org.uk/SMP/title.html</a></li>
<li>Paralogic - Achetez un Beowulf <a href=
"http://www.plogic.com">http://www.plogic.com</a></li>
</ul>
<h2><a name="history"></a> <a name="ss5.7">5.7 Histoire</a></h2>
<ul>
<li>Légendes - Beowulf <a href=
"http://legends.dm.net/beowulf/index.html">http://legends.dm.net/beowulf/index.html</a></li>
<li>Les Aventures de Beowulf <a href=
"http://www.lnstar.com/literature/beowulf/beowulf.html">http://www.lnstar.com/literature/beowulf/beowulf.html</a></li>
</ul>
<h2><a name="s6">6. Code Source</a></h2>
<h2><a name="sum"></a> <a name="ss6.1">6.1 sum.c</a></h2>
<pre>
/* Jacek Radajewski jacek@usq.edu.au */
/* 21/08/1998 */

#include &lt;stdio.h&gt;
#include &lt;math.h&gt;

int main (void) {

  double result = 0.0;
  double number = 0.0;
  char string[80];
  

  while (scanf("%s", string) != EOF) {

    number = atof(string);
    result = result + number;
  }
    
  printf("%lf\n", result);
  
  return 0;
  
}
</pre>
<h2><a name="sigmasqrt"></a> <a name="ss6.2">6.2
sigmasqrt.c</a></h2>
<pre>
/* Jacek Radajewski jacek@usq.edu.au */
/* 21/08/1998 */

#include &lt;stdio.h&gt;
#include &lt;math.h&gt;

int main (int argc, char** argv) {

  long number1, number2, counter;
  double result;
  
  if (argc &lt; 3) {
    printf ("usage : %s number1 number2\n",argv[0]);
    exit(1);
  } else {
    number1 = atol (argv[1]);
    number2 = atol (argv[2]);
    result = 0.0;
  }

  for (counter = number1; counter &lt;= number2; counter++) {
    result = result + sqrt((double)counter);
  }
    
  printf("%lf\n", result);
  
  return 0;
  
}
</pre>
<h2><a name="prun"></a> <a name="ss6.3">6.3 prun.sh</a></h2>
<pre>
#!/bin/bash
# Jacek Radajewski jacek@usq.edu.au
# 21/08/1998

export SIGMASQRT=/home/staff/jacek/beowulf/HOWTO/example1/sigmasqrt

# $OUTPUT doit être un canal nommé (named pipe)
# mkfifo output

export OUTPUT=/home/staff/jacek/beowulf/HOWTO/example1/output

rsh scilab01 $SIGMASQRT         1  50000000 &gt; $OUTPUT &lt; /dev/null&amp;
rsh scilab02 $SIGMASQRT  50000001 100000000 &gt; $OUTPUT &lt; /dev/null&amp;
rsh scilab03 $SIGMASQRT 100000001 150000000 &gt; $OUTPUT &lt; /dev/null&amp;
rsh scilab04 $SIGMASQRT 150000001 200000000 &gt; $OUTPUT &lt; /dev/null&amp;
rsh scilab05 $SIGMASQRT 200000001 250000000 &gt; $OUTPUT &lt; /dev/null&amp;
rsh scilab06 $SIGMASQRT 250000001 300000000 &gt; $OUTPUT &lt; /dev/null&amp;
rsh scilab07 $SIGMASQRT 300000001 350000000 &gt; $OUTPUT &lt; /dev/null&amp;
rsh scilab08 $SIGMASQRT 350000001 400000000 &gt; $OUTPUT &lt; /dev/null&amp;
rsh scilab09 $SIGMASQRT 400000001 450000000 &gt; $OUTPUT &lt; /dev/null&amp;
rsh scilab10 $SIGMASQRT 450000001 500000000 &gt; $OUTPUT &lt; /dev/null&amp;
rsh scilab11 $SIGMASQRT 500000001 550000000 &gt; $OUTPUT &lt; /dev/null&amp;
rsh scilab12 $SIGMASQRT 550000001 600000000 &gt; $OUTPUT &lt; /dev/null&amp;
rsh scilab13 $SIGMASQRT 600000001 650000000 &gt; $OUTPUT &lt; /dev/null&amp;
rsh scilab14 $SIGMASQRT 650000001 700000000 &gt; $OUTPUT &lt; /dev/null&amp;
rsh scilab15 $SIGMASQRT 700000001 750000000 &gt; $OUTPUT &lt; /dev/null&amp;
rsh scilab16 $SIGMASQRT 750000001 800000000 &gt; $OUTPUT &lt; /dev/null&amp;
rsh scilab17 $SIGMASQRT 800000001 850000000 &gt; $OUTPUT &lt; /dev/null&amp;
rsh scilab18 $SIGMASQRT 850000001 900000000 &gt; $OUTPUT &lt; /dev/null&amp;
rsh scilab19 $SIGMASQRT 900000001 950000000 &gt; $OUTPUT &lt; /dev/null&amp;
rsh scilab20 $SIGMASQRT 950000001 1000000000 &gt; $OUTPUT &lt; /dev/null&amp;
</pre>
</body>
</html>
doc-linux-fr-html 2013.01-3ubuntu1 / usr / share / doc / HOWTO / fr-html / Beowulf-HOWTO.html
