Retrouvez cet article dans : Linux Magazine 84

Uqbar était un cluster composé de trois supercalculateurs vectoriels NEC SX-5, installés à partir de 1999 au centre de calcul du CNRS du plateau d’Orsay. Il a servi aux scientifiques pour des calculs de climatologie mais, à bout de souffle, il est aujourd’hui décommissionné. Sa vente aux enchères est prévue pour le 26 avril 2006 et tout passionné d’informatique voudrait au moins lui rendre visite, avant son départ pour la ferraille...

Au moment où ce magazine deviendra disponible en kiosque, le sort de ce sumo aura probablement été décidé, mais pour l’instant personne n’a d’idée sur un éventuel acheteur.
Gigantesque, obsolète, cher à entretenir, il est improbable qu’il joue encore son rôle de calculatrice programmable surpuissante. Pourtant, au-delà de cette annonce, il y a beaucoup de choses à apprendre sur son environnement informatique et scientifique.
Parti en reportage sur le lieu du décès, à la recherche d’images et de témoignages pour ces colonnes, j’ai aussi collecté de nombreuses informations et découvert le rôle des différents acteurs (scientifiques, industriels, administrations), ainsi que d’innombrables éléments dont j’ignorais encore l’existence.

Fig. 1 : L’incroyable annonce (Source : [1])

Fig. 2 : Les ressources informatiques de l’IDRIS (Source : IDRIS)

Une vente domaniale pas comme les autres

C’est sur Usenet, grâce au groupe news:fr.comp.ordinosaure, que j’ai appris la nouvelle le 4 avril. Au sortir d’un thread sur les serveurs de récupération (" My HP9000 is sexier than your SUN "), un message de Willpot nous renvoie vers un site d’annonces des ventes domaniales [1].
Au milieu des voitures, meubles, photocopieuses et autres lots de PC dont l’administration française se débarrasse en continu (sans oublier quelques SUN et HP9000), le lot 67 propose un ordinateur qui laisse rêveur :
J’avais vu des très gros ordinateurs, mais là je reste rêveur, sans parler du rapport performance/prix incroyable. Que ce soit dans la catégorie sasfépu ou non, c’est même la plus étonnante annonce que j’ai pu lire.
En particulier, la surface au sol est hors de portée de l’amateur, même motivé ! Et elle passe aussi sous silence l’infrastructure indispensable au fonctionnement correct : climatisation, alimentation électrique, câblages, tous à une échelle gargantuesque. Rien que la note d’électricité doit être décourageante et la prise de courant ne se trouve pas dans un magasin de bricolage.
Impossible, même si le prix est intéressant (dans l’absolu) pour une telle machine, d’envisager sa reprise par un passionné. Malgré son âge modeste (j’utilise couramment des ordinateurs plus vieux et qui ne prétendent pas appartenir à la catégorie sasfépu), la vie est dure pour les supercalculateurs : fleurons un jour, tas de ferraille encombrants quelques années plus tard.
La marche forcée de l’industrie pour " coller à la Loi de Moore " apporte un flot continu d’ordinateurs toujours plus rapides, moins chers et plus petits, qui remplacent à chaque génération le parc précédent.
Étant inutilisable sans une infrastructure suffisamment dimensionnée, et n’étant plus rentable (son rapport MFLOPS/Watt est dépassé par d’autres ordinateurs plus récents), Uqbar est destiné à la casse. Pour quel prix et qui remportera l’enchère, personne ne le sait encore, ni ne s’en préoccupe. En revanche, Uqbar est un calculateur assez particulier qui mérite quelques explications.

Uqbar à l’IDRIS

Le site Internet de l’IDRIS [2] fournit de nombreuses informations sur les équipements disponibles et leur utilisation. Depuis 1993, l’IDRIS gère les moyens de " calcul haute performance " des laboratoires du CNRS, quand les ordinateurs de ces derniers ne sont pas assez puissants.
La figure 2, extraite du manuel d’initiation à l’utilisation des ordinateurs, montre l’organisation et l’importance des différentes ressources.

Note:

Caractéristiques principales d’Uqbar :
3 nœuds vectoriels NEC SX-5 à 250MHz

• 1 nÅ“ud à 16 CPU et 128GO
• 1 nÅ“ud à 16 CPU et 64GO
• 1 nÅ“ud à 8 CPU et 32GO

Taille mémoire totale : 224GO
CPU : 64 bits, 64 pipelines (dont 32 en virgule flottante) pour traiter 8 registres vectoriels de 256 nombres
Classement : 81ème place au top500 en juin 2001
Système d’exploitation : Super-UX (UNIX de NEC)
Masse totale : 20 tonnes ?
Performance crête totale : 320GFLOPS
Bande passante vers la mémoire (par nœud) : 64GO/s
Puissance électrique nécessaire : 60KW (par nœud ?)
Refroidissement : air froid
Combien de nœuds Opteron d’aujourd’hui faut-il pour obtenir la même performance, pour quelle consommation électrique et à quel prix ?

Pour mettre en perspective les performances réelles d’Uqbar, les archives du classement top500.org [3] indiquent qu’il était le 81ème ordinateur le plus puissant du monde en juin 2001. Il a très vite sombré et a disparu sans laisser de trace. Pourtant, c’est une ressource très prisée par les scientifiques, car Uqbar possède certaines qualités que ne peuvent remplacer les " clusters scalaires " qui ont envahi le paysage, malgré leurs performances théoriques supérieures.

La structure du supercluster

Uqbar se démarque des installations classiques, car il est composé de trois supercalculateurs vectoriels, ce qui exploite un parallélisme à trois niveaux.

Parallélisme des données

Un " vecteur " est l’équivalent d’un tableau et un ordinateur vectoriel dispose de registres extrêmement larges contenant des données indépendantes (64 nombres en virgule flottante de 64 bits pour les CRAY, 256 nombres pour une SX-5). Une opération vectorielle consiste habituellement à effectuer, avec une seule instruction, des opérations identiques sur tous les nombres du registre.

/* Comparaison du fonctionnement interne
   de différents types de processeurs */

// Fonctionnement d’une addition scalaire (i386 par exemple) :
int a, b, c;
a = b + c;

// Fonctionnement d’une addition SIMD 32 bits avec MMX :
int a1, a2, b1, b2, c1, c2;
a1 = b1 + c1, a2 = b2 + c2;

// Fonctionnement d’une addition vectorielle (Cray1-style) :
#define LongueurRegistre 64
 double[LongueurRegistre] a, b, c;
 // nb: les nombres flottants Cray n’étaient pas IEEE754
 int i=0, longueur; // < à LongueurRegistre

  while (i < longueur) {
    a[i] = b[i] + c[i];
    i++;
  }

// Fonctionnement d’une addition vectorielle (NEC-style) :
#define LongueurRegistre 256
 double[LongueurRegistre] a, b, c;
 int i, j, longueur; // < à LongueurRegistre

  while (i < longueur) {
    j=longueur-i;
               a[i   ] = b[i   ] + c[i   ];
    if (j>=1)  a[i+ 1] = b[i+ 1] + c[i+ 1];
    if (j>=2)  a[i+ 2] = b[i+ 2] + c[i+ 2];
    if (j>=3)  a[i+ 3] = b[i+ 3] + c[i+ 3];
    ......................................
    if (j>=13) a[i+13] = b[i+13] + c[i+13];
    if (j>=14) a[i+14] = b[i+14] + c[i+14];
    if (j>=15) a[i+15] = b[i+15] + c[i+15];
    i+=16;
  }

/* Vectorisation : le but du compilateur est de transformer le code pour adapter les registres du CPU à la longueur des
vecteurs du code source. Par exemple : */

void code_original() {
 int i=0, j=0, taille_vecteur, stride;
 double *a, *b, *c;

 while (j<taille_vecteur)
   a[j++] = b[i] + c[i];
   i+=stride; // une opération usuelle en maths...
}

void code_vectorisé() {
  int i, taille_vecteur, stride;
  double *a, *b, *c;
  VECTEUR A, B, C;
 // réserve 3 registres vectoriels internes

  longueur = LongueurRegistre;
 // travailler avec tout le registre

  while (taille_vecteur > LongueurRegistre) {
    VECT_load (B, b, 8*stride);
  // charge tout le registre vectoriel,
    VECT_load (C, c, 8*stride);
  // avec auto-incrémentation du pointeur
  VECT_add  (A, B, C);
  // de stride*sizeof(double)
    VECT_store (A, a, 8*stride);
    // Note : grâce au "chaînage interne", pas besoin
    // d’attendre la fin des load pour commencer le store
    taille_vecteur -= LongueurRegistre;
  }

  // Traiter le petit bout qui dépasse à la fin de la boucle :
  longueur = taille_vecteur;

  // travailler avec une partie du registre
  VECT_load (B, b, 8);
  VECT_load (C, c, 8);
  VECT_add  (A, B, C);
  VECT_store (A, a, 8);
}

/* Exemple d’opération "scatter-gather" : */
*double[LongueurRegistre] registre_ptr;
 double[LongueurRegistre] registre_double;

void ScatterGather(int longueur) {
  int i=0;
  while (i < longueur) {
    registre_double[i] = *registre_ptr[i]; // les lectures
      //  sont effectuée en parallèle si c’est possible
    i++; // le compteur est géré en matériel
  }
}

Aujourd’hui, on parle souvent de " processeur SIMD ", avec des registres de 64 ou 128 bits pour les plus répandus (Altivec ou SSE par exemple).

Mais pour la virgule flottante 64 bits (les vendeurs préfèrent donner les performances en 32 bits, car elles sont plus flatteuses), ils peuvent seulement effectuer 2 opérations par cycle (4 dans certains cas). Avec un processeur vectoriel, c’est comme si on travaillait avec 8 registres de 4096 ou 16384 bits !

En pratique, sur les SX-5, le contenu du registre est traité séquentiellement, mais profite de multiples pipelines parallèles : 16 pour l’addition, 16 pour la multiplication, 16 pour la division et 16 pour les opérations booléennes [6][7]. Cela permet d’obtenir 8GFLOPS à 250MHz seulement, soit 32 FLOP/cycle, et de traiter tout un registre vectoriel en 16 cycles (si on oublie la latence d’amorçage de l’opération).

L’annonce n’était pas très précise, il y a bien de 8GFLOPS par processeur, mais cette performance crête est disponible uniquement pour certains types de calculs. Par exemple, l’algorithme doit avoir besoin à la fois de la multiplication et de l’addition. Et si le code source ne peut pas être vectorisé, ou si le compilateur ne reconnaît pas une structure vectorisable, on sent tout de suite que le processeur ne tourne qu’à 250MHz...

Le portage de bibliothèques de calcul standard (comme blas) permet de faciliter le développement en réutilisant du code déjà vectorisé, du moins pour les parties utilisant des mathématiques classiques. Mais ces bibliothèques ne peuvent compenser la faiblesse des SX-5 pour l’adressage indirect (" scatter-gather "), lorsqu’un vecteur contient des pointeurs et doit lire ou écrire simultanément la mémoire avec ces adresses. Les formations et les équipes de support de l’IDRIS aident les scientifiques utilisateurs à améliorer leurs programmes pour atténuer ces défauts.

Parallélisme de contrôle :

Chaque nœud SX-5 dispose de plusieurs processeurs 64 bits vectoriels identiques (16, 16 et 8, soit 40 processeurs au total) et d’une mémoire globale pour tous ses processeurs (128G octets, 64G et 32 respectivement), ce qui rend la programmation facile (aucun partitionnement à gérer), mais augmente la latence d’accès (masquée par un gros pipeline) et la facture (mais un superordinateur sans super-mémoire est juste une grosse Playstation).

Un calculateur ordinaire développant une telle puissance est composé de centaines de PC disposant chacun d’une mémoire locale ; il faut donc partitionner le logiciel, c’est-à-dire le fractionner judicieusement en morceaux qui doivent communiquer entre eux. Allouer à chaque PC une partie du calcul est une tâche souvent difficile et la vitesse comme la latence des communications sont critiques. Elles peuvent effondrer les performances générales. Les ordinateurs comme les SX-5 n’ont pas besoin de transmettre de données entre processeurs d’un même nœud, car il leur suffit d’échanger localement un simple pointeur. La programmation UNIX/POSIX (avec des zones de mémoire partagée) et les mécanismes de sécurité matériels ajoutent un léger surcoût, mais négligeable par rapport à un transfert par réseau.

Parallélisme des ordinateurs :

Quand un ordinateur ne suffit pas, on en couple plusieurs entre eux. Uqbar est constitué de 3 nœuds que les codeurs utilisent avec un modèle de programmation parallèle standard, à base de threads POSIX, OpenMP et MPI. En plus des liaisons par Ethernet et HIPPI (pour GFS et NFS), les nœuds ont un réseau privé d’interconnexion bidirectionnel (IXS, voir sur la figure 3) à 8GO/s (1/8 de la bande passante vers la mémoire !).
" Les jobs (rares) spécialisés qui l’utilisent sont monstrueux de puissance ! ", m’affirme M. Guigon, ingénieur chez NEC High Performance Computing Europe. Et pour faire bonne mesure, le stockage attaché aux nœuds cumule 3TO de disques en distribué, plus 1,5TO en partagé, le tout en Fiber Channel. Cela met en lumière certaines imprécisions de l’annonce de vente...

Fig. 3 : Les trois super nœuds sont reliés par un super-réseau. (Source : IDRIS [7])

Le portage d’un code existant ne nécessite pas de réécriture majeure grâce aux bibliothèques standards, mais il y a souvent une étape d’adaptation en raison des structures et des chaînes de compilation différentes. De plus, comme un ordinateur vectoriel n’est pas adapté aux " basses tâches de base " comme la compilation, une organisation en trois étapes est prévue :

• Compilation : le compilateur est logé dans un ordinateur frontal, une SGI Origin 2100, ce qui évite de " plomber " les performances d’Uqbar lorsque d’autres utilisateurs calculent.
• Tests, validations et mesures de performances : le nÅ“ud le plus petit (8 CPU et 32 GB) sert à vérifier que le code se comporte comme prévu, un peu comme un (grand) " bac à sable ".
• Exécution par lot : le code validé est mis en attente dans une liste de tâches (NQS), pour tourner plusieurs dizaines d’heures en moyenne, principalement sur les deux autres machines à 16 processeurs (128GB et 64GB de RAM).

Actuellement, presque tous les centres de calcul utilisent un parallélisme à deux niveaux (" cluster de SMP "), un peu moins foudroyants en puissance utile mais plus économique (économie d’échelle grâce à des processeurs répandus) et plus flexibles (moins de pénalité de performances lors d’opérations scatter-gather dans le même nœud). La réduction à deux niveaux affranchit des contraintes de la vectorisation, mais les performances reposent alors entièrement sur les liens de communication qui doivent être très, très performants. La programmation est aussi plus difficile car la mémoire est un peu moins spacieuse sur un nœud (elle est divisée par le nombre de processeurs).

Visite guidée à l’IDRIS

Les recherches sur Internet sont intéressantes, mais rien ne vaut un déplacement pour voir par soi-même. Équipé d’un dictaphone et d’un appareil photo numérique, je me suis rendu, le mercredi 19 avril 2006, sur le plateau surplombant l’Université d’Orsay.

Fig. 4 : Pas de panique ! Le bâtiment 506 est ici :-)

C’est un endroit reculé, où quelques laboratoires de physique des particules ont poussé au milieu des champs et de la forêt, loin des habitations (juste au cas où...).
De fil en aiguille, les mathématiciens sont arrivés, puis l’analyse numérique, les écoles d’ingénieurs... Le paysage s’est ainsi rempli, au cours des dernières décennies, de bâtiments de toutes formes et tous styles.
Si on oublie les avions décollant de l’aéroport d’Orly, tout y est tranquille. Le printemps a redonné des couleurs aux arbres et les oiseaux remplissent l’air de leurs chants. La desserte est assurée par bus toutes les vingt minutes, ce qui contribue à l’atmosphère de patience... Les chercheurs sont rarement dérangés.
J’ai été accueilli par M. Thierry Goldmann, qui assiste les utilisateurs des outils de visualisation graphique, et qui est aussi chargé de la communication externe.
Ce n’est donc pas à un communiqué de presse que j’ai eu droit, mais à un vrai exposé passionné sur le travail de l’IDRIS, et sur les supercalculateurs en général, tout cela en m’ouvrant les portes des salles climatisées...

Fig. 5 : Bienvenue à l’IDRIS

Uqbar venait d’être arrêté le lundi, et le démontage avait commencé le mardi (la veille du rendez-vous). Je suis donc arrivé au bon moment, puisque seulement un des nœuds avait été retiré de la salle des machines.
Il faut normalement une semaine environ pour déplacer un nœud de grande taille, mais comme la machine ne servirait certainement plus, certains câbles ont simplement été sectionnés et la procédure raccourcie à deux jours.
De plus, j’ai appris plus tard qu’un seul nœud avait été arrêté pour ne pas interrompre totalement le fonctionnement de l’IDRIS. J’ai donc eu beaucoup de chance d’arriver à l’instant où c’était presque terminé ! Les derniers cabinets (figure 6) étaient encore visibles dans un des couloirs et les ingénieurs de NEC m’ont expliqué, en toute décontraction, quelques détails.

Fig. 6 : Les derniers cabinets du premier nœud d’Uqbar, boyaux à l’air...

Pour commencer, on peut constater que NEC a très bien compris qu’un bon ordinateur doit aussi être un bel ordinateur. Dans la grande tradition des supercalculateurs, le " look " (figure 7) est très propre et très soigné, ne trahissant pas la sophistication interne. La classe Japonaise :-)

 

Fig. 7 : Le design est très important. S’il faut construire un super-ordinateur, autant qu’il ait l’air super-soigné !

Ensuite, le cabinet des processeurs (figure 8) est imposant. Chaque processeur vectoriel est refroidi par un gros dissipateur à ailettes d’aluminium, que l’on voit dépasser de chaque côté. C’est donc ici un cabinet de 8 CPU, soit une moitié de la machine.
D’innombrables câbles relient chaque processeur à chaque module mémoire, leur séparation physique nécessite des gros moyens pour conserver une synchronisation sans faille. La procédure de connexion doit être interminable... Et le démontage est certainement beaucoup plus rapide.
Cette vue me rappelle le slogan des Allemands du Chaos Computer Club : " Kabelsalat ist gesund " (" La salade de câbles, c’est bon pour la santé ! "). Je vois aussi le chemin accompli, avec les connecteurs étiquetés : un ancien technicien de Cray m’avait expliqué que dans les années 80, chaque fil des supercalculateurs du constructeur américain devait être wrappé à la main, selon un schéma complexe... Il avait gardé un peu de ce fil torsadé, dont il m’a donné une partie ; j’en utilise encore pour des montages électroniques et je confirme que c’est de la bonne qualité :-D
Après avoir déconnecté tous les câbles, le plus dur commence, car pour déplacer une telle quantité de circuits, la procédure est fastidieuse. Les cabinets sont équipés de roulettes (figure 9), mais leurs poids (jusqu’à une tonne et demie pour le cœur) ne permet pas de les sortir de la salle climatisée. Il faut donc démonter tous les modules internes et les transporter sur un chariot séparé afin qu’un cabinet devienne manipulable. Un processeur seul pèse environ 25kg et un tiroir de mémoire (figure 11) environ 10kg. Ces derniers sont disposés sur des rails, que l’on voit sur la figure 10.

Fig. 8 : Les 8 processeurs vectoriels de ce cabinet sont refroidis par air.

La mémoire aussi est impressionnante, et on voit immédiatement qu’il ne s’agit pas d’un ordinateur conventionnel. Les seize modules ont l’air conçus spécifiquement pour être accédés par de multiples processeurs simultanément, comme le montrent les nombreux circuits intégrés de contrôle (que l’on distingue par leur radiateur).
Tous les connecteurs sont aussi à très haute densité. C’est indispensable, car pour transmettre 64GO par seconde (en crête) avec une horloge à 250MHz, il faut (théoriquement) des chemins de données larges de 2048 bits !
Le nœud qui vient d’être démonté contenait 64GO de mémoire répartis dans 2 cabinets. Chaque tiroir contient ainsi 64/(16x2)=2GO et donc un module comprend 128MO. Et si vous êtes toujours assis, sachez qu’il faut (en plus) un tiroir d’alimentation par tiroir de mémoire ainsi que par processeur.
Un technicien a eu la gentillesse de détacher un des modules (figure 12), pour montrer son organisation étonnante. Chaque circuit intégré de mémoire dispose de son propre circuit imprimé, ce qui augmente la densité de stockage par rapport à une barrette habituelle. Sur un tiroir, il y a donc une hiérarchie à trois niveaux : le circuit imprimé principal, les 16 modules perpendiculaires et enfin les mémoires individuelles, parallèles au circuit principal. Et le tout est refroidi par air !
Les présentations faites, je suis ensuite invité à découvrir la salle des machines, où se trouvent encore les deux autres nœuds. Sur la figure 13, on voit toute la façade du deuxième nœud (128GO), attendant le démontage. Il n’aurait pas été visible entièrement sous cet angle si le premier nœud n’avait pas été enlevé. Et malgré cela, mon appareil photo peine à le cadrer dans toute sa largeur ! J’ai dû monter sur une pile de tiroirs d’alimentation, attendant dans un coin leur départ, pour obtenir cette vue. Au fait, ai-je précisé que c’est gigantesque ? Les cabinets ont une hauteur d’environ deux mètres...
La figure 14 montre l’arrière de cette bête, qui distribue ses cabinets à la manière de la lettre H. Plus loin (figure 15), difficile à photographier, on voit le dernier nœud (plus petit) qui jouxte le cluster scalaire (appelé Zahir) fabriqué par IBM.
Je n’ai pas obtenu beaucoup d’informations sur l’infrastructure de toute la salle. Tout est refroidi par air, le vrombissement des climatiseurs comme des ventilateurs dans les machines est très puissant et rend les discussions difficiles. La température est normale, à environ 15 degrés.
La consommation totale est difficile à évaluer, mais je ne voudrais pas payer la note d’électricité ! Si un seul nœud SX-5 consomme 60KW, le cluster et la climatisation devraient pomper 300KW, soit (estimation cavalière) 30 euros par heure.
Si on ajoute la consommation de Zahir et des autres ressources du centre, on comprend pourquoi l’accès n’est pas libre, surtout pour des calculs qui durent des centaines d’heures !
Un coup d’œil à l’escalier de la trappe (figure 17) confirme que le vrai sol est environ 1,60m plus bas. J’avoue ne pas avoir eu le courage de passer la tête sous le faux plancher pour observer les fils...

Fig. 9 : Une fois le cabinet en place, les vérins sont vissés pour décoller les roues du sol et immobiliser le tout.

Le successeur d’Uqbar

Cet entretien était très instructif, car je m’étais imaginé (je ne sais pas pourquoi) qu’Uqbar était la dernière machine vectorielle de l’IDRIS. Je ne pensais pas qu’une autre machine plus puissante de la même lignée reprendrait le flambeau, en raison du déclin général des machines vectorielles depuis dix ans. M. Alessandrini a bien montré qu’elles ont pourtant de l’importance, et M. Goldmann a donné plus d’explications.
Un premier nœud vient d’être enlevé pour laisser la place à une première partie du nouveau cluster SX-8, fin mai. Mais d’abord, NEC doit livrer de nouveaux disques et un ordinateur frontal (aussi de conception NEC) probablement à base d’Opterons et utilisant Linux. Ce dernier sera chargé de la compilation croisée et des sessions interactives avec les utilisateurs. Seul les administrateurs auront un accès direct (en ligne de commande) aux SX-8, alors que toutes les tâches des utilisateurs seront gérées par lots. Comme le remarque M. Goldmann :
" On ne veut plus utiliser de processeurs vectoriels pour exécuter cat ou vi... Ce n’est pas normal. " (voir aussi [9])

Fig. 10 : Le cabinet de mémoire accueille 16 tiroirs, dont certains sont visibles.

Fig. 11 : Vue du dessus d’un tiroir de RAM

Les deux nœuds SX-5 qui restent permettent d’assurer la continuité du service de l’IDRIS, qui doit répondre à une demande croissante d’heures de calcul. La contrainte budgétaire, qui ne permet pas d’acheter l’ensemble du nouveau cluster d’un coup, est compensée par un remplacement graduel. Cela évite l’interruption des calculs vectoriels, même si la puissance disponible est temporairement réduite de moitié.
" Le temps de recouvrement entre la SX-8 et le reste de la SX-5 n’est que d’un mois ! Cela va être une véritable course contre la montre pour tout arranger avec les utilisateurs ! "
Durant les nombreuses validations des SX-8, Uqbar sera encore plus sollicité par les utilisateurs. Une fois les tests terminés, la puissance totale sera supérieure à l’installation précédente. Uqbar sera alors complètement enlevé, laissant définitivement sa place à la deuxième moitié du cluster SX-8, en décembre 2006.
La nouvelle génération de nœuds vectoriels n’apporte pas de gain révolutionnaire, mais c’est une amélioration naturelle, l’équilibre architectural a été modifié pour optimiser l’utilisation des ressources en intégrant les dernières technologies. La quantité de mémoire et bande passante vers la mémoire stagnent respectivement à 64GO et 64GO/s par nœud, un programme peut donc balayer toute la mémoire en une seconde. Par contre, chaque CPU développe 16GFLOPs, ce qui double les besoins de bande passante. Pour compenser l’augmentation de la vitesse de travail, le nombre de processeurs est donc limité à 8.
Pourquoi ne pas augmenter la quantité de mémoire ? Cela ralentirait les programmes car il faudrait plus de temps pour balayer toute la mémoire. Cela ne sert donc à rien si la bande passante n’augmente pas elle aussi, alors que la mémoire est déjà gigantesque (sans parler des bus internes) et représente environ 40% du coût matériel. Au lieu d’augmenter la mémoire, NEC compte sur l’augmentation de la densité des circuits intégrés : la taille a été réduite, les fils racourcis, donc le nœud est plus rapide et moins cher. Au final, l’IDRIS peut donc acheter de nombreux nœuds qui sont aussi efficaces (si ce n’est un peu plus) que les nœuds SX-5 précédents. Il y a moins de CPU mais cela ne change probablement pas la donne, puisqu’un programme exploitant plusieurs CPU est difficile à mettre au point.

Vectoriel contre scalaire

M. Goldmann renchérit :
" On obtient assez facilement 30% de la crête monoprocesseur d’un supercalculateur vectoriel, soit environ 2,5GFLOPs sur Uqbar, pour un code normal. En réalité, les utilisateurs d’Uqbar ont 20 ans d’expérience et atteignent 3,5 à 4GFLOPs. Le maximum obtenu dans des applications réelles est d’environ 6GFLOPs, avec des codes de combustion, résistivité des matériaux, mécanique des fluides, climatologie. Les codes d’astrophysique sont aussi assez bons et presque tout a été codé par le CNRS, il n’y a presque pas de code du commerce. "
Mais tout n’est pas si simple.
" Les codes de climatologie sont très bons en monoprocesseur mais ce domaine n’a pas encore fait son transfert sur machine scalaire. Il n’y a que cinq ans pour le faire (ndla : durée de vie du nouveau cluster), car on ne sait pas s’il y aura un successeur à la SX-8. Les Japonais veulent faire un Earth Simulator II et ils ont décidé de rattraper leur retard par rapport aux Etats-Unis en lançant une grande étude.
L’objectif est d’obtenir une machine " PetaFLOP " pour 2010-2011 mais personne ne sait si elle sera scalaire ou vectorielle. Si NEC remporte le projet, elle sera certainement vectorielle (avec quelques modifications) et les codes de climatologie bénéficieront encore d’années de grâce supplémentaires, avec une SX-9 et une SX-10. Sinon, les architectures scalaires permettent des puissances crête cumulées impressionnantes (des dizaines de Tflops aujourd’hui).

Fig. 12 : Ce n’est pas le type de module mémoire que l’on trouve chez tous les assembleurs...

Fig. 13 : On devine la forme en H et, en arrière-plan, le haut du nœud le moins puissant.

Nous en avons utilisé plusieurs générations (et pas seulement des IBM) mais pour en tirer partie et permettre un temps de restitution rapide des jobs, il faut les utiliser en parallèle. Par défaut on tire entre 8 et 10% seulement de la puissance crête d’une architecture scalaire. Il faut alors des codes parfaitement parallélisés pour soit diminuer le temps de restitution en augmentant le nombre de processeurs alloués, soit faire une autre physique en augmentant la taille du problème par une utilisation d’un nombre plus grand de processeurs (ce que ne permet pas le Vectoriel à une aussi grande échelle). Sur Zahir, un processeur Power4 fournit 5 Gflops théorique, mais, en réalité, on obtient environ 500 Mflops. Si en plus vous faites beaucoup d’entrées/sorties...
Nous avons une communauté d’utilisateurs (1200 scientifiques) très hétérogène et diverse et, curieusement, les machines vectorielles sont devenues les dernières machines " généralistes " en calcul scientifique, car presque n’importe quel code y tourne facilement. "
J’étais déjà impressionné par les cabinets éventrés de la SX-5, l’entretien avec le directeur, l’annonce de Earth Simulator II (Slashdot ne m’avait pas prévenu !) et toutes les armoires de disques durs... Mais cette dernière affirmation m’a achevé. La révolution des Killer micros [4], qui a enterré les machines vectorielles, s’est finalement retournée contre elle-même au bout de quinze ans...
La simplicité architecturale, hors de prix et recluse dans des laboratoires inaccessibles, avait encore le dernier mot et nous, pauvres utilisateurs lambda, devons souffrir l’éternelle agonie du scalaire de bureau... Un ou deux processeurs vectoriels de SX-5 et 16GO de RAM suffiraient pourtant à mes besoins algorithmiques pour de nombreuses années.

Fig. 14 : Vue de l’arrière du nœud SX-5 contenant 16 processeurs et 128GO

" Aujourd’hui, nous avons trois types de machines. D’abord, les machines vectorielles comme Uqbar. Ensuite, les clusters de SMP, (M. Goldmann se tourne alors vers Zahir.) à mémoire partagée, peu de processeurs par nœud (la parallélisation nécessite MPI) et des communications entre les nœuds réduites (théoriquement, mais c’est en fait le goulot d’étranglement).
Enfin, les vraies machines parallèles, comme Blue Gene en ce moment mais leur programmation est plus délicate et toutes les applications scientifiques, ne peuvent pas en tirer parti.
Notre deuxième machine parallèle a été un Cray T3E à 256 processeurs (ndla : Processeurs Alpha avec mémoire distribuée, sur un réseau torique tridimensionnel, année 1994) et c’était excellent, malgré la performance modeste du processeur Alpha : très faible coût des communications (proportionnel à la distance en nombre de nœuds), mémoire distribuée. Mais la programmation d’un code parallèle utilisant de la mémoire distribuée est plus ardue et tous les codes parallèles ne sont pas écrits pour en tirer parti.

Fig. 15 : La même salle héberge Uqbar et Zahir, deux clusters de types très différents.

Il tapote Zahir.
" Les industriels tirent mieux parti des architectures scalaires que nous. Une entreprise achète un nœud à 16 ou 32 processeurs, et qu’une application n’en utilise qu’une partie, ou toute la mémoire, ce n’est pas important pour eux tant que la machine donne le résultat désiré. A l’IDRIS, si un code tournant sur un nœud utilise seulement 8 CPU sur les 32, les 24 autres seront quand même allumés et gâchées. C’est inacceptable, les heures inutilisées sont perdues à jamais pour la communauté.
Les machines vectorielles sont donc, aujourd’hui, plus généralistes pour le calcul scientifique que les architectures scalaires. Et parmi ces dernières, les clusters de SMP, s’ils offrent des performances réelles moins importantes que les vraies machines parallèles, sont encore d’un emploi plus facile et supportent mieux des applications hétérogènes venant de communautés diverses. "

Fig. 16 : " Génial ! Un gros bouton rouge ! Que se passe-t-il si j’y touche ?... "

La gestion des ressources de calcul est délicate. Si un ordinateur est inutilisé ou mal utilisé, c’est une perte d’heures potentielles définitive pour les scientifiques. Le rôle des équipes de l’IDRIS est d’optimiser l’exploitation des machines et la performance des programmes.
" Nous essayons d’y faire cohabiter différents types de codes, avec des profils d’accès à la mémoire différents, pour rentabiliser l’utilisation. Il n’y a pas de time sharing sur les machines scalaires, ou de gestion par lot. Ainsi, une fois qu’on vous y a réservé un certain nombre de tâches, que vous utilisiez les ressources ou non, le processeur est à vous. "

La course au pétaflop

Je sentais qu’on se rapprochait des questions de noyaux et de systèmes d’exploitation, avec ces histoires de gestion de ressources. Mais l’IDRIS a d’autres préoccupations, puisque chaque fabricant fournit son propre OS optimisé.
" C’est autant une question de système d’exploitation que d’architecture, car ces dernières ne permettent pas le véritable time sharing en scalaire. Il n’y a pas non plus de time sharing sur la mémoire, ce qui joue sur la politique de gestion des clusters par les centres de calcul. Zahir est composé de noeuds à 32 processeurs et 64, 128 ou 256GO de mémoire. L’administrateur doit gérer les ressources CPU et mémoire, nœud par nœud. Mais qu’est-ce qui est le plus important ? Avoir beaucoup de mémoire avec peu de processeurs ou beaucoup de processeurs avec peu de
mémoire ? C’est dépendant du code et difficile à estimer. "
Si l’IDRIS se trompe dans l’allocation, un programme utilisera trop de ressources et d’autres utilisateurs ne pourront pas travailler, leur temps imparti étant amputé.
" Nous incitons donc les utilisateurs à améliorer le parallélisme de leurs programmes pour améliorer le ratio CPU/RAM et ainsi occuper au maximum tous les processeurs d’un ou des nœuds alloués (alors qu’occuper beaucoup de mémoire empêche les programmes des autres utilisateurs de tourner). Cela contribue aussi à réduire le temps total d’exécution ".
Mais c’est une tâche très difficile. Obtenir une efficacité nominale de plus de 10% nécessite un travail à tous les niveaux, en architecture, mathématique, algorithmique et en physique. Prenons un exemple emblématique : le cluster Tera10. C’est un système à base de 1006 processeurs Itanium 2, que le CEA/DAM a acheté à BULL pour les simulations d’explosions nucléaires françaises [10]. Peu de programmes différents tournent dessus, donc on peut mieux optimiser chacun, ce qui occupe des équipes entières de spécialistes.Et pourtant, bien que son nom suggère 10 téraflops, la puissance crête est de 50 téraflops. Cela signifie que le CEA s’attend ou cherche à obtenir 20% d’efficacité... Actuellement, le 26ème classement du site top500.org (novembre 2005) n’indique que 5,829TFLOPs, mais il s’agit du cluster incomplet (beta, à 6,451TFLOPs crête).. A côté d’Uqbar, Zahir dispose de 6,55TFLOPs théoriques et de 3TO de RAM distribuée, c’est donc un proche cousin... Mais il est pourtant déjà considéré comme obsolète et on peut au mieux espérer en tirer 1TFLOPs.
" De plus, les machines ont de plus en plus de processeurs par m², des alimentations de plus en plus gourmandes et un refroidissement qui pose de plus en plus de problèmes. Pour la machine Peta10, il faut donc une surface trois fois plus grande que celle des machines pour l’électricité et pour les générateurs d’eau glacée. A l’IDRIS, tout fonctionne encore avec de la climatisation normale mais nous voyons de plus en plus réapparaitre le refroidissement par eau. La SX-8 aura quatre fois plus de processeurs pour une surface réduite de moitié, il sera très difficile d’augmenter encore cette densité. La capacité de stockage (sur disque et sur bande de sauvegarde) va aussi augmenter d’un facteur 8, mais ce n’est pas un problème comparable. "

Et les Logiciels libres, dans tout ça ?

" Aujourd’hui, Fortran représente peut-être 85% des sources pour la climatologie. C et C++ ont toujours les mêmes problèmes de pointeurs, alors que Fortran évolue bien. La dernière version de ce langage date d’après l’an 2000 et intègre certaines facilités du C, comme les pointeurs et tableaux dynamiques. La SX-8 utilisera Fortran2000. "
Evidemment, j’imagine mal GCC (même le plus récent) capable d’exploiter toute la puissance d’une SX-8, quel que soit le langage. Les constructeurs ont investi pendant des années pour affiner leurs logiciels, et ils ont reporté le coût du développement sur leurs quelques clients. Comment concilier cela avec une démarche scientifique et ouverte ?
" Par défaut, lorsqu’un utilisateur a besoin d’une librairie particulière qui n’est pas disponible à l’IDRIS, nous regardons d’abord si elle est payante ou gratuite. Si elle est chère et qu’elle ne sert qu’à un seul utilisateur, c’est un problème. Mais la fonction de l’IDRIS est de fournir une prestation de service et nous demandons alors l’avis du comité des utilisateurs, pour connaître la pertinence de la requête et savoir si le projet de recherche est suffisamment important pour qu’il bénéficie de l’achat de la librairie.
Pour les logiciels gratuits, c’est le support qui nous pose problème. Donc, nous essayons de limiter les produits du domaine public. "
Sans vouloir jouer au pingouin^Wmanchot de service, la distinction entre gratuit et libre ne me semblait pas avoir fait son chemin à l’IDRIS. Il faut d’abord songer à la dépendance envers les différents vendeurs de matériels, qui fournissent leurs propres versions d’UNIX (propriétaire) avec tout le support auquel un tel client s’attend. L’IDRIS doit aussi gérer d’autre types de logiciels, essentiellement pour la chimie, chers et développés par des universités, fonctionnant comme des boîtes noires et posant toutes sortes de problèmes à cause de leur conception... disons... boiteuse. Mais outre le fait que très peu de Logiciels libres s’intéressent au calcul scientifique ou de haute performance, c’est surtout la fragmentation des distributions GNU/Linux combinée à la " philosophie RTFM " (ou plutôt, il faut toujours se débrouiller soi-même) qui contribue à cette imperméabilité réciproque.
" Nous ne sommes pas anti-Linux, puisque toute notre informatique interne est sous Linux, mais nous ne sommes pas aussi optimistes que la communauté Linux. Linux suit le même chemin qu’Unix, que nous avons vu se développer dans les systèmes propriétaires. Ce développement similaire de Linux est à la fois bien et inquiétant, surtout en ce qui concerne l’uniformité des interfaces. Dans les UNIX propriétaires, on retombait soit dans BSD4.3, soit dans AT&T SysV, et POSIX n’a pas changé beaucoup la situation. Mais vers la fin des années 90, ces systèmes ont fait des grands progrès vers la stabilité et la performance, avec par exemple UNICOS de CRAY, SuperUX de NEC, IRIX de SGI, et même AIX s’est amélioré.
Avec Linux, nous avons eu l’impression de devoir tout reprendre à zéro, dans le monde du calcul scientifique. Nous sommes revenus à un système frustre, avec des restrictions, pas assez stable, pas encore assez développé... Au moins jusqu’en 2001. La situation s’est améliorée, mais nous avons eu beaucoup de problèmes avec de jeunes thésards, qui ne comprenaient pas les contraintes de l’IDRIS, croyant que nous étions réfractaires. Ce qui nous inquiète maintenant, c’est la divergence de tous les Linux. Certains deviennent propriétaires, puisque tous les constructeurs fournissent le noyau Linux (SGI, IBM et même NEC pour le frontal des SX-8) et y greffent le meilleur de leurs outils propriétaires, obtenant ainsi le meilleur des deux mondes. C’est grâce à SGI que Linux a pu tourner pour la première fois sur plus de 256 processeurs, avec une machine Altix (Itanium). SGI a pris le meilleur du scheduling d’IRIX, qui lui-même avait repris ce qu’il y avait de bien dans UNICOS, le meilleur UNIX du marché lorsque SGI a racheté CRAY. Dans le cadre de l’IDRIS, nous utilisons un système de visualisation en temps réel et à distance qui exploite le réseau à haute vitesse Renater2. Nous calculons les images sur une SGI dédiée pour les envoyer, après compression, sur le poste client, qui est équipé d’un logiciel spécifique pour l’interface utilisateur et la décompression. Nous avons acheté le logiciel du serveur, et le logiciel client (pour Windows, Linux, SUN...) est gratuit. Le problème avec le client Linux est qu’il est basé sur la RedHat, qui est le standard aux Etats-Unis. Avec la Mandrake, il manque des liens dynamiques sur certaines librairies C et C++, donc l’installation du RPM du client de visualisation échoue. Ce n’est pas grave, il y a une solution, il faut faire un petit patch, configurer à la main...
Ce n’est pas standard, et ça commence à nous inquiéter énormément. Selon la configuration du poste client, l’installation sera triviale ou il faudra faire une petite rustine. Dans ce cas, nous devrons aider l’utilisateur et ce n’est pas simple. SGI fournit les informations pour installer le client sur SuSE, Debian etc. mais la fragmentation est très inquiétante. Les initiatives d’unification et de standardisation ne font que révéler le malaise. Tous les utilisateurs ne pourront pas régler tous les problèmes de configuration et d’installation sur toutes les variantes de Linux. C’est pour cela que nous sommes dubitatifs, mais l’ordinateur frontal de la SX-8, utilisant un Linux 64 bits avec des Opterons, va nous apprendre plein de choses. "

A la fin de cet entretien fleuve, que j’ai retravaillé plus tard afin de l’éclaircir, j’ai eu du mal à remettre de l’ordre dans mon cerveau. Sur le moment, l’idée d’un Linux propriétaire m’échappait, comme elle échappera aux lecteurs assidus. Pourtant, il faut bien avouer que les Linux installés sur les grosses machines propriétaires ne ressemblent pas à une Fedora, comme le remarque M. Goldmann avec son sens de l’à-propos si aiguisé. Et il ne m’est apparu que plus tard que la collusion entre GNU et Linux, entre Libre et gratuit, n’était pas fortuite ou révélatrice d’une incompréhension, mais due à la mission de l’IDRIS, qui n’est pas de conquérir une liberté, mais d’assister ses différents utilisateurs.

Conclusion

A la sortie de cette visite guidée, la forêt était toujours emplie de chants d’oiseaux et les avions décollaient toujours d’Orly, mais mon appareil photo était lourd d’images et mon dictaphone numérique plein à craquer. Ma tête bourdonnait encore du bruit des climatisations, et j’avais tout mon temps pour repenser à cette visite, en attendant le bus...
Cette courte escapade dans le monde des super-ordinateurs et du calcul scientifique m’a permis de comprendre un peu mieux quelles sont les nouvelles tensions industrielles, et les exigences des chercheurs, qui façonnent le paysage informatique d’aujourd’hui.
De plus, il est rare de pouvoir discuter avec de tels spécialistes, ayant plus de vingt ans d’expérience et un regard historique et pratique sur l’informatique. Sur cette période, il y a eu tellement de bouleversements et de remises en questions qu’on aurait tendance à s’accrocher à quelques mythes ; celui de la disparition définitive des machines vectorielles est donc encore repoussé pour quelques temps.
Non, je ne suis pas reparti avec une pièce du sumo, même minime, puisque j’étais surtout occupé à réunir autant d’images et d’informations que possible. Je n’ai pas pu tout intégrer dans cet article, mais elles valent plus qu’un morceau de circuit qui prendrait la poussière dans un coin...
Le remplaçant d’Uqbar doit bientôt entrer en service, après une période de tests poussés. Sa nouvelle architecture a l’air très intéressante (" une révolution " selon M. Goldmann), mais il est encore trop tôt pour envisager un autre reportage à son sujet. D’ici là, j’aurai probablement eu le temps de visiter d’autres installations scientifiques qui utilisent déjà Linux. J’en ai identifié deux mais rien n’est prévu.
Je tiens à remercier vivement toutes les personnes qui ont participé, directement ou indirectement, à la réalisation de ce reportage, en particulier Messieurs Alessandrini et Goldmann pour m’avoir accueilli et pris le temps de répondre aux questions, ainsi que François Guigon (NEC) qui a fourni des renseignements complémentaires.
Grâce à vous tous, j’ai pu écrire " l’article le plus cool de GLMF " (dixit un relecteur faisant autorité ultime). Je lance donc le défi à d’autres auteurs (confirmés ou débutants) de faire un article encore plus " cool ", par exemple en visitant Earth Simulator ou Tera10 (qui, lui, fonctionnerait avec Linux)... Quoique, pour moi, rien ne vaut des Alphas, donc une installation à base de Cray T3E (les sasfépus sont autorisés), ou bien le cluster de la DAM à 2560 CPU ferait l’affaire. Qui est volontaire ?

Retrouvez cet article dans : Linux Magazine 84