Le traitement en parallèle sous Linux

Bien que l'emploi de multiples processeurs puisse accélérer nombre d'opérations, la plupart des applications ne peuvent encore tirer profit du traitement en parallèle. A la base, le traitement en parallèle est approprié si :

Bien que le traitement en parallèle ait été utilisé pendant de nombreuses années par de nombreux systèmes, il reste étranger à la plupart des utilisateurs. Aussi, avant de traiter des différentes alternatives, il est important de se familiariser avec une poignée de termes usuels :

Afin de bien comprendre l'usage des différentes approches de programmation en parallèle mises en évidence dans ce guide, il est utile d'étudier cet exemple. Bien qu'un algorithme simple de traitement en parallèle eût suffi, si l'on en choisit un qui a déjà été utilisé pour faire la démonstration d'autres systèmes de programmation parallèle, il devient un peu plus facile de comparer et mettre en évidence les caractéristiques de ces différentes approches. le livre de M. J. Quinn, Parallel Computing Theory And Practice (« Théorie et Pratique du Calcul en Parallèle »), seconde édition, édité par McGraw Hill, New York en 1994, utilise un algorithme parallèle qui calcule la valeur de Pi pour présenter différents environnements de programmation sur supercalculateurs parallèles (par exemple, le message passing du nCube ou la mémoire partagée des Sequent). Dans ce guide, nous utiliserons le même algorithme.

Cet algorithme calcule la valeur approchée de Pi en faisant la somme de l'aire située sous x au carré. En tant que programme C purement séquentiel, 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 désiré */
  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);
}

Le reste de ce document est divisé en cinq parties. Les sections 2, 3, 4 et 5 correspondent aux trois différents types de configuration matérielle pouvant assumer le traitement en parallèle en utilisant Linux.

La section finale de ce document couvre les aspects d'intérêt général concernant le traitement en parallèle sous Linux, non spécifique à l'une des approches listées ci-dessus.

En lisant ce document, gardez à l'esprit que nous n'avons pas tout testé, et que beaucoup de choses rapportées dans ce document ont toujours « un caractère expérimental » (une jolie manière de dire que cela ne fonctionne pas tout à fait comme espéré ;-) ). Cela dit, le traitement en parallèle sous Linux est désormais 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 propriétaire des droits sur ce document, conformément aux règles du Linux Documentation Project (LDP). Bien qu'un effort ait été fait pour assurer l'exactitude de cette présentation, ni Dietz ni l'Université de Purdue ne peuvent être tenus responsables d'éventuels problèmes ou erreurs, et l'Université de Purdue n'endosse la responsabilité d'aucun produit ou travaux traités dans ce document.

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 française, sur plusieurs points :

Malgré toutes ces réserves, les techniques couvertes par ce document sont suffisament générales pour rester valables au cours du temps et au travers des différents modèles de machines, et son contenu présente toujours un intérêt à la fois pédagogique et historique, qui restera encore longtemps profitable au lecteur. Tout ceci justifie une publication même tardive.

Enfin, le traducteur s'est efforcé de rendre le présent document aussi correct et fidèle à son original que possible, mais n'est pas infaillible. Tout signalement d'un contresens, d'une erreur technique, ou tout autre défaut de traduction sera apprécié à sa juste valeur à l'adresse suivante : <dvandenbroeck CHEZ free POINT fr>.

Bonne lecture !

Bien que les systèmes SMP soit répandus depuis de nombreuses années, jusque très récemment, chaque machine tendait à implémenter les fonctions de base d'une manière suffisamment différente des autres pour que leur gestion par le système d'exploitation ne soit pas portable. Les choses ont changé avec la Intel's MultiProcessor Specification (Spécification MultiProcesseurs d'Intel) souvent désignée par MPS. La spécification MPS 1.4 est actuellement disponible sous forme de document PDF sur http://www.intel.com/design/intarch/MANUALS/242016.htm^[4], mais gardez à l'esprit qu'Intel réorganise souvent son site web. Un large panel de constructeurs fabrique des systèmes conformes à MPS pouvant recevoir jusqu'à quatre processeurs, mais en théorie, MPS admet bien plus de processeurs.

Les seuls systèmes 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 mathématique interfère sur les mécanismes du SMP) et les processeurs AMD et Cyrix (qui nécessitent des circuits de gestion du SMP différents et qui ne semblent pas être disponibles à l'heure où ce document est écrit).

Il est important de bien comprendre que les performances de différents systèmes conformes à MPS peuvent fortement varier. Comme l'on peut s'y attendre, une des causes de différence de performance est la vitesse du processeur : Une horloge plus rapide tend à rendre les systèmes plus rapides, et un processeur Pentium Pro est plus rapide qu'un Pentium. En revanche, MPS ne spécifie pas vraiment comment le matériel doit mettre en œuvre la mémoire partagée, mais seulement comment cette implémentation doit fonctionner d'un point de vue logiciel. Cela signifie que les performances dépendent aussi de la façon dont l'implémentation de la mémoire partagée interagit avec les caractéristiques de Linux SMP et de vos applications en particulier.

La principale différence entre les systèmes conformes à MPS réside dans la manière dont ils implémentent l'accès à la mémoire physiquement partagée.

Okay, donc vous avez décidé que le traitement en parallèle sur SMP, c'est génial… Par quoi allez-vous commencer ? Eh bien, la première étape consiste à en apprendre un peu plus sur le fonctionnement réel de la communication par mémoire partagée.

A première vue, il suffit qu'un processeur range une valeur en mémoire et qu'un autre la lise. Malheureusement, ce n'est pas aussi simple. Par exemple, les relations entre processus et processeurs sont très floues. En revanche, si nous n'avons pas plus de processus actifs que de processeurs, les termes sont à peu près interchangeables. Le reste de cette section résume brièvement les cas de figure typiques qui peuvent poser de sérieux problèmes, si vous ne les connaissiez pas déjà : les deux différents modèles utilisés pour déterminer ce qui est partagé, les problèmes d'atomicité, le concept de volatilité, les instructions de verrouillage matériel, les effets de la ligne de cache, et les problèmes posés par l'ordonnanceur de Linux.

volatile int * volatile p;

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

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

La bibliothèque bb_threads ("Bare Bones" threads) est une bibliothèque remarquablement simple qui fait la démonstration de l'utilisation de l'appel système Linux clone(). Le fichier tar.gz n'occupe que 7 ko ! Bien que cette bibliothèque ait été rendue pour l'essentiel obsolète par la bibliothèque LinuxThreads, traitée 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 résumé, la bibliothèque bb_threads forme un bon point de départ, mais n'est pas vraiment adaptée à la réalisation de grands projets.

La structure de base des programmes utilisant la bibliothèque bb_threads est la suivante :

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];      /* Numéros 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 déverrouillage */
  bb_threads_lock(0);
  pi += sommelocale;
  bb_threads_unlock(0);
}

int
main(int argc, char **argv)
{
  /* Récupère le nombre d'intervalles */
  intervalles = atoi(argv[1]);

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

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

  /* nettoie derrière les deux threads */
  /* (forme ainsi une barrière de synchro) */

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

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

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

LinuxThreads (http://pauillac.inria.fr/~xleroy/linuxthreads/) est une implémentation assez complète et bien construite en accord avec le standard de threads POSIX 1003.1c. Contrairement aux autres adaptations d'implémentations de threads POSIX, LinuxThreads utilise également l'appel clone() du noyau Linux, déjà employé par bb_threads. La compatibilité POSIX implique qu'il est relativement aisé de faire l'adaptation de certaines applications provenant d'autres systèmes, et différents tutoriels et leur support sont disponibles. Bref, c'est incontestablement la bibliothèque à utiliser pour développer des applications multi-threads à grande échelle sous Linux.

La structure de base d'un programme utilisant LinuxThreads suit ce modèle :

Voici l'exemple du calcul de Pi en parallèle, s'appuyant sur LinuxThreads. L'algorithme de la section 1.3 est utilisé et, comme pour l'exemple de bb_threads, deux threads s'exécutent en parallèle.

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

volatile double pi = 0.0;    /* Approximation de pi (partagée) */
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 déverrouille 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;

  /* Récupère le nombre d'intervalles */
  intervalles = atoi(argv[1]);

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

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

  /* « Joint » (détruit) 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 résultat */
  printf("Estimation de la valeur de Pi: %f\n", pi);

  /* Sortie */
  exit(0);
}

La gestion des IPC (Inter-Process Communication) System V s'effectue au travers d'un certain nombre d'appels système fournissant les mécanismes des files de message, des sémaphores et de la mémoire partagée. Bien sûr, ces mécanismes ont été initialement conçus pour permettre à plusieurs processus de communiquer au sein d'un système monoprocesseur. Cela signifie néanmoins que ces mécanismes devraient aussi fonctionner dans un système 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 même s'il existe des appels IPC System V pour des choses comme les sémaphores et la transmission de messages, vous ne les utiliserez probablement pas. Pourquoi ? Parce ces fonctions sont généralement lentes et sérialisées sous Linux SMP. Inutile de s'étendre.

La marche à suivre standard pour créer un groupe de processus partageant l'accès à un segment de mémoire partagée est la suivante.

Même avec si peu d'appels système, une fois le segment de mémoire partagée é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 opération de communication sera exonérée du coût d'un appel système.

Ci-après, un exemple de programme en langage C utilisant les segments de mémoire partagée 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 mémoire partagée */
  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;

  /* Crée un fils */
  if (!fork()) ++iproc;

  /* Récupère 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 déverrouillage ... */
  while (xchg((iproc + 1), &(shared->lock))) ;
  shared->pi += sommelocale;
  shared->lock = 0;

  /* Fin du processus fils (barrière 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, préférez-lui une technique de synchronisation évitant les intructions verrouillant le bus.

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

L'utilisation des appels système pour accéder aux fichiers (les entrées/sorties) peut revenir cher. En fait, c'est la raison pour laquelle il existe une bibliothèque de gestion des entrées/sorties gérant un tampon dans l'espace utilisateur (getchar(), fwrite(), et cætera). Mais les tampons utilisateur ne remplissent pas leur fonction si plusieurs processus accèdent au même fichier ouvert en écriture. La solution Unix BSD à ce problème fut l'ajout d'un appel système permettant à une portion d'un fichier d'être projetée en mémoire utilisateur, en utilisant principalement les mécanismes de la mémoire virtuelle pour provoquer les mises à jour. Le même mécanisme a été utilisé pendant plusieurs années dans les systèmes de Sequent comme base de leur gestion du traitement parallèle en mémoire partagée. En dépit de commentaires très négatifs 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 dérivé de cet appel pour projeter un segment anonyme de mémoire pouvant être partagé par plusieurs processus.

L'implémentation Linux de l'appel mmap() est en elle-même une solution intégrée de remplacement des étapes 2, 3 et 4 du schéma classique de mémoire partagée System V, mis en évidence dans la section 2.5. Pour créer un segment de mémoire partagée anonyme :

shmptr =
    mmap(0,                        /* Le système choisit l'adresse */
         b,                        /* Taille du segment de mémoire partagée */
         (PROT_READ | PROT_WRITE), /* droits d'accès, peuvent être rwx */
         (MAP_ANON | MAP_SHARED),  /* anonyme, partagé */
         0,                        /* descripteur de fichier (inutilisé) */
         0);                       /* offset fichier (inutilisé) */

L'équivalent de l'appel de mémoire partagée System V shmdt() est munmap() :

munmap(shmptr, b);

À mon avis, on ne gagne pas grand chose à utiliser mmap() plutôt que les mécanismes de gestion de la mémoire partagée de System V.

Le traitement en parallèle au travers d'un cluster offre plusieurs avantages majeurs :

Très bien. Si les clusters sont gratuits ou très peu onéreux, peuvent devenir très grands et offrir une haute disponibilité… pourquoi tout le monde n'utilise pas un cluster ? Eh bien, parce qu'il y a aussi des problèmes :

Moralité, les clusters ont un très grand potentiel, mais ce potentiel risque d'être très difficile à concrétiser pour la plupart des applications. La bonne nouvelle, c'est qu'il existe un soutien logiciel très développé pour vous aider à obtenir de bonnes performances avec les programmes adaptés à cet environnement, et qu'il existe également des réseaux conçus spécialement pour élargir la palette de programmes pouvant avoir de bonnes performances.

Les réseaux informatiques sont en pleine explosion… mais vous le savez déjà. Un nombre toujours grandissant de technologies et produits réseau a été développé, et la plupart d'entre eux sont disponibles sous une forme qui peut être utilisée pour faire d'un groupe de machines (des PC fonctionnant chacun sous Linux) un cluster de traitement en parallèle.

Malheureusement, aucune technologie réseau ne résout complètement tous les problèmes. À vrai dire, le nombre d'approches différentes, en coût et en performances, est à première vue assez difficile à croire. Par exemple, le coût par machine mise en réseau 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 spécificités de certains réseaux, il est important de remarquer que ces choses évoluent très fréquemment (voir http://www.linux.org.uk/NetNews.html pour avoir des nouvelles fraîches concernant les réseaux sous Linux), et qu'il est très difficile d'obtenir des infos précises concernant certains réseaux.

J'ai placé un « ? » aux endroits incertains. J'ai aussi passé beaucoup de temps à faire des recherches sur ce sujet, mais je reste sûr que ce résumé 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 résumés comme le LAN Technology Scorecard^[10] donnent les caractéristiques de nombreux et différents types de réseaux et de standards de réseaux locaux (LAN). Cependant, l'essentiel de ce guide pratique est centré sur les propriétés les plus indiquées à la construction d'un cluster Linux. Chaque section décrivant un type de réseau débute par une courte liste de caractéristiques. Ci dessous, la définition de chaque entrée.

Maintenant que vous êtes avertis, place au spectacle…

Avant d'explorer les ressources logicielles existantes en matière de traitement en parallèle, il est utile de couvrir rapidement les bases de l'interface logicielle de bas niveau gérant l'électronique du réseau. Il n'existe en réalité que trois options de base : les sockets, les pilotes de périphériques et les bibliothèques utilisateur.

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

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

PVM (pour « Parallel Virtual Machine », soit « Machine Virtuelle en Parallèle ») est une bibliothèque de message-passing portable et disponible gratuitement, s'appuyant généralement directement sur les sockets. Cette bibliothèque s'est incontestablement établie comme le standard de facto dans le domaine du traitement en parallèle à l'aide de clusters à transmission de messages.

PVM prend en charge les machines Linux monoprocesseur et SMP, comme les clusters de machines Linux reliées entre elles à l'aide par des réseaux reconnaissant les sockets (donc SLIP, PLIP, Ethernet, ATM). En fait, PVM fonctionnera même à travers un groupe de machines utilisant différents types de processeurs, de configurations et de réseaux physiques — Un cluster hétérogène — même si l'envergure de ce cluster est de l'ordre de la mise en parallèle de machines en utilisant Internet pour les relier entre elles. PVM offre même des facilités de contrôles de tâches (« jobs ») en parallèle au travers d'un cluster. Cerise sur le gâteau, PVM est disponible gratuitement et depuis longtemps (actuellement sur 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 débogage ou autres à l'adopter comme leur « bibliothèque cible portable de message-passing ». Il existe également un groupe de discussion : news:comp.parallel.pvm.

Il est important de remarquer, en revanche, que les appels PVM ajoutent généralement aux opérations socket un overhead non négligeable alors que les temps de latence de celles-ci sont déjà importants. En outre, les appels eux-mêmes ne sont pas aisés à manipuler.

Appliquée au même exemple de calcul de Pi décrit 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 numéros des tâches */

  /* Début du traitement avec PVM */
  mytid = pvm_mytid();

  /* « Je rejoins le groupe et, si je suis la première instance,
     iproc=0, je crée plusieurs copies de moi-même. »
  */
  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 prêts  */
  pvm_barrier("pi", NPROC);

  /* Récupère 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 résultats 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 résultat */
  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);
}

Bien que PVM soit le standard de fait en matière de bibliothèque 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/ et le groupe de discussion correspondant sur 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 années. Je ne penche ni pour l'un ni pour l'autre. Voici un résumé aussi impartial que possible des différences entre les deux interfaces :

Conclusion ? Disons qu'il existe au moins trois versions de MPI développées de façon indépendante et disponibles gratuitement pouvant fonctionner sur des clusters de machines Linux (et j'ai écrit l'un d'eux) :

Quelque soit l'implémentation MPI utilisée, il est toujours très simple d'effectuer la plupart des types de communication.

En revanche, MPI 2.0 incorpore plusieurs paradigmes de communication suffisamment différents entre eux fondamentalement pour qu'un programmeur utilisant l'un d'entre eux puisse ne même pas reconnaître les autres comme étant des styles de programmation MPI. Aussi, plutôt que d'explorer un seul exemple de programme, il est utile de passer en revue un exemple de chacun des (différents) paradigmes de communication de MPI. Tous les programmes qui suivent emploient le même 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 résultat partiel au processeur 0, qui fait la somme de tous ces résultats 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 précis, sont incontestablement les plus appropriées) :

#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 troisième version MPI utilise le mécanisme 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 préciser que le mécanisme RMA de MPI 2.0 prévient de façon remarquable tout problème de structures de données se trouvant à des adresses mémoires différentes selon les processeurs, en se référant à une "fenêtre" incluant l'adresse de base, une protection contre les accès mémoire hors de portée, et même le rééchelonnement d'adresse. À une implémentation efficace, s'ajoute le fait qu'un traitement RMA peut-être reporté jusqu'à la prochaine MPI__Win_fence. Pour faire simple, le mécanisme RMA est un étrange croisement entre mémoire partagée distribuée et message passing, mais reste une interface très propre pouvant générer des communications très efficaces.

Contrairement à PVM, MPI, et cætera, l'interface AFAPI (« Aggregate Function API », ou « Interface à Fonctions d'Agrégation ») n'a pas débuté sa vie en tant que couche d'abstraction portable s'appuyant sur un réseau matériel ou logiciel existant. AFAPI était plutôt la bibliothèque de gestion bas niveau d'un matériel spécifique pour PAPERS (« Purdue's Adapter for Parallel Execution and Rapid Synchronization », soit « Adaptateur pour l'Exécution en Parallèle et la Synchronisation Rapide de l'université de Purdue »).

PAPERS a été rapidement présenté dans la section 3.2. Il s'agit d'un réseau à fonction d'agrégations conçu sur mesure dont le modèle est dans domaine public et qui présente des temps de latence inférieurs à 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 déjà existants. Il se distingue en qualité de la plupart des efforts en matière de clusters Linux et de PVM/MPI, qui s'attachent généralement à essayer d'exploiter les réseaux standard au profit des rares applications en parallèle présentant une granularité suffisante. Le fait que les éléments de PAPERS soient des machines PC sous Linux ne sert qu'à permettre l'implémentation de prototypes à des coûts les plus avantageux possibles.

La nécessité d'avoir une interface logicielle de bas niveau commune à plus d'une douzaine d'implémentations différentes d'un prototype a conduit la bibliothèque PAPERS à être standardisée sous le nom d'AFAPI. Mais le modèle utilisé par AFAPI est simple en lui-même et bien plus adapté aux interactions à la granularité plus fine, typiquement du code compilé par des compilateurs parallélisés, ou écrit pour des architectures SIMD. Non seulement la simplicité du modèle rend les machines PAPERS aisées à construire, mais elle apporte également une efficacité surprenante aux ports d'AFAPI sur différents types de système, tels que les SMP.

AFAPI fonctionne actuellement sur des clusters Linux utilisant TTL_PAPERS, CAPERS ou WAPERS. Elle fonctionne également (sans appel système ni même instruction de verrouillage de bus, voir la section 2.2) sur les machines SMP utilisant une bibliothèque de gestion de mémoire partagée type System V (« System V Shared Memory ») appelée SHMAPERS. Une version fonctionnant sur des clusters Linux utilisant la diffusion UDP sur des réseaux conventionnels (Ex : Ethernet) est en cours de développement. Toutes les versions d'AFAPI sont écrites pour être appelées à partir des langages C ou C++.

L'exemple suivant est la version AFAPI du programme de calcul de Pi décrit 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);
}

Outre PVM, MPI et AFAPI, les bibliothèques suivantes proposent des services qui peuvent s'avérer utiles au travers de grappes de machines Linux. Ces systèmes sont traités ici de manière moins approfondie simplement parce que, contrairement à PVM, MPI et AFAPI, je n'ai que peu, voire aucune expérience pratique de l'utilisation de ceux-ci sur des clusters Linux. Si l'une de ces bibliothèques (ou même d'autres) vous est particulièrement utile, merci de m'envoyer un courrier électronique en anglais à <hankd CHEZ engr POINT uky POINT edu> en me détaillant vos découvertes. J'envisagerai alors d'ajouter une section plus complète à son sujet.

Les clusters peuvent être construits et utilisés de tellement de manières différentes que certains groupes ont apporté des contributions particulièrement intéressantes. Ce qui suit fait référence aux différents projets liés à la mise en place de clusters pouvant avoir un intérêt d'ordre général. Ceci inclut un mélange de références à des clusters spécifiques à Linux et à des clusters génériques. Cette liste est présentée dans l'ordre alphabétique.

Bien que tout processeur moderne soit capable d'exécuter un programme en effectuant un minimum de parallélisme SWAR, il est de fait que même le plus optimisé des jeux d'instructions SWAR ne peut gérer un parallélisme d'intérêt vraiment général. A dire vrai, de nombreuses personnes ont remarqué que les différences de performance entre un Pentium ordinaire et un Pentium « avec technologie MMX » étaient surtout dûes à certains détails, comme le fait que l'augmentation de la taille du cache L1 coïncide avec l'apparition du MMX. Alors, concrètement, à quoi le SWAR (ou le MMX) est-il utile ?

Il existe donc d'importantes limitations, mais ce type de parallélisme intervient dans un certain nombre d'algorithmes, et pas seulement dans les applications multimédia. Lorsque l'algorithme est adapté, le SWAR est plus efficace que le SMP ou le parallélisme en clusters… et son utilisation ne coûte rien !

Le concept de base du SWAR (« SIMD Within A Register », ou « SIMD à l'intérieur d'un registre ») réside dans le fait que l'on peut utiliser des opérations sur des registres de la taille d'un mot pour accélérer les calculs en effectuant des opérations parallèles SIMD sur n champs de k/n bits. En revanche, employer les techniques du SWAR peut parfois s'avérer maladroit, et certaines de leurs opérations peuvent au final être plus coûteuses que leurs homologues en série car elles nécessitent des instructions supplémentaires pour forcer le partitionnement des champs.

Pour illustrer ce point, prenons l'exemple d'un mécanisme SWAR grandement simplifié gérant quatre champs de 8 bits dans chaque registre de 32 bits. Les valeurs de ces deux registres pourraient être représentées 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 |
      +-------+-------+-------+-------+

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

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

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

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

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

((x + y) & 0x7f7f7f7f)

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

(x << 8)

((x >> 8) & 0x00ffffff)

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

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

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

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

Pour Linux, nous nous soucierons principalement des processeurs IA32. La bonne nouvelle, c'est qu'AMD, Cyrix et Intel implémentent tous le même jeu d'instructions MMX. En revanche, les performances de ces différents 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 sérieuses du SWAR par le MMX :

En résumé, le SWAR par MMX est toujours d'un usage malaisé. Toutefois, avec quelques efforts supplémentaires, la seconde approche décrite ci-dessus peut être utilisée dès à présent. En voici les bases :

Tout ce qui précède paraît rébarbatif, 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.

En général, les processeurs secondaires tendent à se spécialiser dans l'exécution de fonctions bien spécifiques.

Avant de se sentir découragés parce que livrés à nous-mêmes, il est utile de comprendre que, bien qu'il puisse être difficile de le préparer à recevoir un système particulier, un PC sous Linux reste l'une des rares plate-formes qui se prêtent convenablement à cet usage.

Un PC forme un bon système d'accueil pour deux raisons : La première est sa capacité à évoluer aisément et de façon peu onéreuse. Les ressources telles que la mémoire, les disques, le réseau et autres peuvent être ajoutées vraiment très facilement à un PC. La seconde est sa facilité d'interfaçage. Non seulement les prototypes de cartes ISA et PCI sont largement répandus et disponibles, mais le port parallèle fournit également des performances raisonnables dans une interface discrète. L'adressage séparé des entrées / sorties de l'architecture IA32 facilite également l'interfaçage en offrant une protection de ces adresses au niveau du port individuel.

Linux est également un bon système d'exploitation pour l'hébergement de systèmes dédiés. La libre et complète disponibilité du code source, et les nombreux manuels de programmation avancée constituent évidement une aide très précieuse. Mais Linux apporte également une gestion des tâches pratiquement temps-réel. Il existe même une version fonctionnant en vrai temps-réel. Mais une chose peut-être plus importante encore est le fait que, même dans un environnement Unix complet, Linux sait prendre en charge des outils de développement écrits pour fonctionner sous MS-DOS ou Windows. Les programmes DOS peuvent être exécutés dans un processus Unix en utilisant dosemu, qui dresse une machine virtuelle protégée qui peut littéralement exécuter du code MS-DOS. La prise en charge des programmes Windows 3.xx sous Linux est encore plus directe : certains logiciels libres comme wine simulent Windows 3.11^[26] suffisamment bien pour permettre à la plupart des programmes Windows d'être exécutés correctement sur une machine Unix équipée de X-Window.

Les deux sections suivantes donnent des exemples de systèmes parallèles auxiliaires que j'aimerais voir être exploités sous Linux :

Un marché prospère s'est développé autour des puces DSP (« Digital Signal Processing », ou « Traitement Numérique du Signal ») à hautes performances. Bien qu'elles soient en général conçues pour être embarquées dans des systèmes dédiés à des usages bien spécifiques, elles peuvent aussi être utilisées comme de très bons ordinateurs parallèles annexes. Voici pourquoi :

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 systèmes parallèles intégrés comprenant au moins quatre processeurs DSP.

Même si la série TMS320 de Texas Instruments, sur http://dspvillage.ti.com, est populaire depuis un bon moment, les systèmes de ce type étant disponibles sont encore peu nombreux. Il existe à la fois une version uniquement entière et une version virgule flottante du TMS320. Les anciens modèles utilisaient un format de virgule flottante en simple précision assez inhabituel, mais les nouveaux gèrent à présent les formats IEEE. Les anciens TMS320C4x (ou simplement « C4x »), accomplissaient jusqu'à 80 MFLOP en utilisant le format de nombre en virgule flottante simple précision spécifique à TI. En comparaison, un seul « C67x » apportera jusqu'à 1 GFLOP en simple précision et 420 MFLOP en double précision au format IEEE, en utilisant une architecture à base de VLIW nommée 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 intégrés.

L'autre famille de processeurs DSP qui ne soit pas simplement utilisée ces temps-ci par quelques rares systèmes en parallèle est SHARC (ou « ADSP-2106x »), d'Analog Devices. Ces circuits peuvent être configurés en un multiprocesseur à mémoire partagée formé par 6 processeurs sans nécessiter de logique externe pour les associer, et peuvent aussi former de plus grands systèmes grâce à des circuits de liaison de 4 bits. Les systèmes au-delà de celui-ci sont essentiellement destinés aux applications militaires, et reviennent assez cher. Toutefois, Integrated Computing Engines, Inc. produit un petit jeu de deux cartes PCI assez intéressant, nommé GreenICE. Cette unité contient un réseau de 16 processeurs SHARC, et affiche une vitesse de pointe d'1.9 GFLOP au format IEEE simple précision. GreenICE coûte moins de 5000 dollars.

À mon avis, les circuits DSP parallèles intégrés mériteraient une plus grande attention de la part du petit monde du calcul en parallèle sous Linux…

Si l'objectif final du traitement en parallèle reste l'atteinte des plus hautes vitesses possibles, et bien pourquoi ne pas fabriquer du matériel sur mesure ? Nous connaissons tous la réponse : Trop cher, trop long à développer, le matériel ainsi conçu devient inutile lorsque l'algorithme change même de façon minime, et cætera. Cependant, les récentes avancées faites dans le domaine des FPGA (« Field Programmable Gate Array », ou « Réseaux Logiques Programmables à effet de Champ ») ont réduit à néant la plupart de ces objections. Aujourd'hui, la densité des portes logiques est suffisamment élevée pour qu'un processeur entier puisse être intégré 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 même entre deux phases d'un même algorithme.

Il ne faut pas avoir froid aux yeux pour utiliser ces techniques : Il faudra travailler avec des langages de description matérielle tels que le VHDL pour configurer les FPGA, tout comme écrire du code de bas niveau pour programmer les interfaces avec le système d'accueil Linux. En revanche, le coût des FPGA est assez bas, spécialement pour les algorithmes opérant sur des données entières et de précision normale (ce qui ne représente en fait qu'un surensemble restreint de tout ce à quoi le SWAR s'applique bien), ces FPGA peuvent effectuer des opérations complexes à peu près aussi vite qu'on peut les leur transmettre. Par exemple, de simples systèmes à base de FPGA ont accusé des performances supérieures à celles des supercalculateurs lors de recherches sur des bases de données génétiques.

Il existe plusieurs compagnies produisant du matériel 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 coûte 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, est un type de carte similaire, mais utilisant les FPGA d'Altera et un bus PCI comme interface plutôt qu'un bus ISA.

Bon nombre de ces outils de conception, langages de description matérielle, compilateurs, routeurs, et cætera, sont livrés 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 redémarrer 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.

Je suis principalement un « chercheur en compilateurs ». Je devrais donc être capable de dire s'il y a beaucoup de compilateurs vraiment performants, générant du code parallèle efficace pour les systèmes Linux. Malheureusement, et pour dire la vérité, il est difficile de battre les performances obtenues en exprimant votre programme en parallèle avec des communications et autres opérations parallèles, le tout dans un code en langage C, compilé par GCC.

Les projets de compilateurs ou de langages suivants représentent une partie des meilleurs efforts produits pour la génération d'un code raisonnablement efficace depuis les langages de haut niveau. Généralement, chacun d'eux est raisonnablement efficace pour les tâches qu'il vise, mais aucun ne correspond aux langages et aux compilateurs puissants et tout-terrain qui vous feront abandonner définitivement l'écriture de programmes C compilés par GCC… ce qui est très bien comme çà. Utilisez ces langages et compilateurs à ce pour quoi ils ont été conçus, et vous serez récompensés par des durées de développement plus courtes, des opérations de maintenance et de débogages réduites, et cætera.

Il existe un grand nombre de langages et de compilateurs en dehors de ceux listés ici (dans l'ordre alphabétique). Une liste de compilateurs librement disponibles (la plupart n'ayant rien à voir avec le traitement en parallèle sous Linux) est accessible ici : http://www.idiom.com/free-compilers.

Beaucoup de gens passent beaucoup de temps à faire des mesures de performances « au banc d'essai » de cartes-mères particulières, de carte réseau, et cætera, pour déterminer laquelle d'entre elles est la meilleure. Le problème de cette approche est que, le temps d'arriver à des résultats probants, le matériel testé peut ne plus être le meilleur. Il peut même être retiré du marché et remplacé par un modèle révisé et aux propriétés radicalement différentes.

Acheter du matériel pour PC, c'est un peu comme acheter du jus d'orange. Il est généralement 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 différences auxquelles on devrait être attentif. Mon conseil est simple : Soyez simplement conscients de ce que vous pouvez attendre de votre matériel 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 aperçu des différents processeurs pour PC sur http://www.pcguide.com/ref/cpu/fam/; En fait, le site PC Guide entier est rempli de bonnes présentations techniques de l'électronique d'un PC. Il est également utile d'en savoir un peu sur les performances et la configuration d'un matériel spécifique, et le Linux Benchmarking HOWTO est un bon document pour commencer.

Les processeurs Intel IA32 sont dotés de plusieurs registres spéciaux qui peuvent être utilisés pour mesurer les performances d'un système en fonction dans ses moindres détails. Le VTune d'Intel, sur http://developer.intel.com/design/perftool/vtune, fait un usage poussé de ces registres de performances, dans un système d'optimisation du code vraiment très complet… qui malheureusement ne fonctionne pas sous Linux. Un pilote sous forme de module chargeable et une bibliothèque de fonctions servant à accéder aux registres de performances du Pentium sont disponibles et ont été écrits par Cuneyt Akinlar. Souvenez-vous que ces registres de performance sont différents 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 cætera.

Il y a encore un commentaire à faire à propos des performances, destiné spécialement à ceux qui veulent monter de grands clusters dans de petits espaces. Les processeurs modernes incorporent pour certains des capteurs de température, et utilisent des circuits ralentissant la cadence du processeur lorsque cette température dépasse un certain seuil (tentative de réduction des émissions de chaleur et d'amélioration 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 température trop élevé ne se contente pas de raccourcir la durée de vie des composants, mais agit aussi directement sur les performances d'un système. Ne placez vos ordinateurs dans des configurations pouvant bloquer le flux d'air, piégeant la chaleur dans des zones confinées, et cætera.

Enfin, les performances ne sont pas seulement une question de vitesse, mais également de fiabilité et de disponibilité. Une haute fiabilité signifie que votre système ne plantera pratiquement jamais, même si un composant vient à tomber en panne… ce qui nécessite généralement un matériel spécial comme une alimentation redondante et une carte-mère autorisant le remplacement « à chaud » des équipements qui y sont connectés. Tout cela est en général assez cher. Une haute disponibilité signifie que votre système sera prêt à être utilisé pratiquement tout le temps. Le système peut planter si l'un des composants tombe en panne, mais il pourra être réparé et redémarré très 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 assurée en prévoyant simplement quelques pièces de rechange. Éliminer le matériel défectueux et le remplacer par une de ces pièces de rechange peut apporter une plus grande disponibilité pour un coût d'entretien moins élevé que celui d'un contrat de maintenance.

Alors, y a-t-il quelqu'un dans l'assemblée qui fasse du traitement en parallèle sous Linux ? Oui !

Il y a encore peu de temps, beaucoup de gens se demandaient si la mort de plusieurs compagnies fabricant des supercalculateurs parallèles n'annonçait pas la fin du traitement en parallèle. Ce n'était alors pas mon opinion (voir http://dynamo.ecn.purdue.edu/~hankd/Opinions/pardead.html pour un aperçu assez amusant de ce qui, à mon avis, s'est vraiment passé), et il semble assez clair qu'aujourd'hui le traitement en parallèle est à nouveau sur une pente ascendante. Même Intel, qui n'a cessé que récemment de produire des supercalculateurs parallèles, est fier du soutien apporté au traitement en parallèle par des choses comme le MMX, et l'EPIC (« Explicitly Parallel Instruction Computer », ou « Ordinateur à jeu d'Instructions Parallèles Explicites ») de l'IA64.

Si vous faites une recherche sur les mots « Linux » et « Parallèle » dans votre moteur de recherche favori, vous trouverez un certain nombre d'endroits impliqués dans le traitement en parallèle sous Linux. Les clusters de PC sous Linux, en particulier, font leur apparition un peu partout. Le fait que Linux se prête particulièrement bien à ce genre de tâche combiné aux coûts réduits et aux hautes performances du matériel pour PC ont fait du traitement en parallèle sous Linux une approche populaire, tant pour les groupes au budget restreint que pour les vastes laboratoires de recherche nationaux confortablement subventionnés.

Certains projets énumérés dans ce document tiennent une liste de sites de recherche « apparentés » utilisant des configurations Linux parallèles similaires. Vous trouvez cependant sur 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 parallèle. Si vous voulez voir votre propre site y figurer :

Quatorze clusters sont actuellement répertoriés dans cette liste, mais nous avons été informés de l'existence de plusieurs douzaines de clusters Linux à travers le monde. Bien sûr, cette inscription n'implique aucun engagement. Notre objectif est simplement de favoriser le développement des connaissances, de la recherche et de la collaboration impliquant le traitement en parallèle sous Linux.