n°4
Janvier
2009
Le projet PetaQCD

L’étude d’une très ambitieuse machine pétaflopique consacrée à la simulation QCD sur réseau a débuté depuis quelques mois. Elle est le fruit de plusieurs années de recherches collaboratives dans ce domaine, et regroupe, au sein du projet ANR intitulé PetaQCD, un consortium pluridisciplinaire de 9 partenaires issus de l’IN2P3, du CNRS, de l’INRIA plus 2 petites entreprises privées. Ce projet devrait, sur la période 2009-2011, faire la preuve qu’une machine de ce type, capable de simuler des réseaux de l’ordre de 256x1283 à l’aide des logiciels de la famille HMC, est réalisable à un coût raisonnable avec un nombre limité de processeurs (entre 1000 et 4000). Cette preuve prendra la forme d’une maquette basée autant que faire se peut sur des éléments standards, et 2 axes particulièrement prometteurs seront explorés en priorité : l’utilisation des processeurs Cell (IBM) et celle des cartes GP-GPU (Nvidia). La machine sera donc massivement parallèle, et très probablement hétérogène, et les problèmes de communication entre processeurs, intrinsèques au problème traité plus encore qu’à l’algorithme utilisé, seront certainement l’une des clefs de l’étude.

Les solutions historiques

Il est maintenant traditionnel d’étudier et d’utiliser des machines spécifiques (par exemple les machines apeNEXT ou QCDOC) pour réaliser les calculs nécessités par la simulation de QCD sur réseau (LQCD pour Lattice QCD). Ces études ont parfois permis de déboucher sur des machines d’intérêt commercial, comme le super-calculateur IBM BlueGene, rejeton de la filière QCDOC (QCD On Chip). L’explosion du HPC (High Performance Computing), tant du côté des constructeurs que des utilisateurs – qui ont découvert depuis une dizaine d’années les économies qu’ils pouvaient réaliser en basant la conception des produits complexes sur la simulation (avionique, études pharmaceutiques …) met actuellement à notre portée plusieurs gammes de processeurs très attirants par leur capacité et leurs performances : calculs flottants en Double Précision (64 bits) rapides, multi-cœurs mieux adaptés au traitement parallèle.

Or les simulations LQCD sont de plus en plus gourmandes en temps de calcul, et la taille des réseaux à traiter ne cesse de croître. En effet, il faut que ce réseau couvre le volume géométrique dans lequel évoluent les quarks dans le noyau (c.à.d. quelques fermis) avec une granularité suffisamment fine pour ne pas trop moyenner les effets des fluctuations qui contiennent la physique, et on pense à une maille de 0,02 à 0,05 fm. D’où des réseaux qui atteignent 229 à 230 cellules.

Des programmes de plus en plus exigeant

Cependant, les gros calculateurs existants se plient mal aux exigences de nos programmes de simulation et à leur structure. Bien qu’ils réunissent souvent quelques-unes des caractéristiques requises, les études récentes montrent que pour l’instant aucun ne répond à toutes les conditions nécessaires qui sont :
- Une puissance de traitement en calculs flottants Double Précision élevée – on cherche à atteindre le pétaflop pour éviter qu’une simulation donnée dure plus de quelques semaines, par exemple.
- Un parallélisme massif pour pouvoir décomposer le réseau à traiter en unités suffisamment petites pour pouvoir tenir sur un processeur - on cherche à limiter le nombre total de processeurs à mettre en œuvre à quelques milliers.
- Des communications très rapides entre ces processeurs , car l’algorithme de base requiert que les données décrivant les sites du réseau à la frontière entre chaque domaine de la décomposition soient échangées au cœur de chaque itération de la boucle de calcul, et ceci même pour le noyau de calcul qui sera le meilleur candidat pour la vectorisation de l’algorithme. Ce problème des échanges est relativement classique dans les simulations qui doivent procéder à une décomposition du domaine pour en paralléliser le traitement, comme dans les simulations météorologiques ou l’exploration sismique.
- Une mémoire physique suffisante pour contenir les données à traiter au cœur de l’algorithme, et ceci pour les coprocesseurs vectoriels les plus aptes à nous fournir la puissance de calcul requise – si cette condition n’est pas remplie, le flux de données qui doivent être lues ou écrites pour alimenter le CPU devient alors trop élevé. Il est rare que les 3 paramètres (puissance CPU, taille mémoire du coprocesseur, bande passante pour les accès mémoire) soient harmonieusement équilibrés, surtout quand la puissance CPU délivrée est élevée.
- Avoir un cluster qui soit le moins gourmand possible en énergie (électricité, refroidissement) et qui occupe le plus petit volume possible. Ce dernier paramètre est aussi essentiel pour la vitesse des communications par le réseau, et il est intimement lié au nombre de processeurs à mettre en œuvre ;
- On ne serait sûrement pas exhaustif si l’on mettait sous le tapis les problèmes de fiabilité, car on s’attend à ce qu’une machine (probablement hétérogène) comportant plusieurs milliers de processeurs présente au moins une panne par jour sur l’un de ses constituants. Et il est peu probable que l’un des constructeurs soit capable de nous procurer un système de checkpointing capable de faire face à ces pannes simplement et à faible coût.

Des solutions non satisfaisantes

Banc de test ’Coyotte’Plusieurs types de processeurs sont actuellement candidats pour cette machine un peu spéciale, mais on ne tient pas encore le bon candidat, et il sera probablement nécessaire de revoir de fond en comble l’algorithme de simulation pour espérer obtenir les performances souhaitées. Citons pour le moment :
- Le processeur IBM Cell, qui a été initialement conçu essentiellement pour les besoins graphiques de la console de jeux Sony PS3, et qui offre une puissance CPU confortable. Cependant, son avenir n’est actuellement pas garanti (cf SC’08 à Austin-Texas). C’est un modèle avec co-processeurs embarqués (on-chip). Un banc de test, baptisé ‘Coyote’, financé par le CC-IN2P3, a été installé à Lyon pour y étudier en détails un petit cluster à base de Cell. Il regroupe au total 16 de ces processeurs, reliés par un réseau du type Infiniband.
- Les cartes GP-GPU du type Tesla (NVIDIA), qui sont aussi à classer dans la gamme des co-processeurs graphiques, mais cette fois off-chip, car il faut absolument les associer à un processeur maître (de type multi-cœur par exemple). Ils tiennent le haut du pavé dans le domaine du HPC ces derniers temps.
- Les processeurs multi-cœurs – on connaît déjà les quadri-cœurs qui ont tendance à devenir le standard dans nos ordinateurs de bureau un peu musclés – mais la gamme 64-cœurs de chez Intel prévue dans un ou deux ans commencerait à devenir particulièrement attirante.
- La machine IBM BlueGene (dont le modèle P à l’Idris est aussi sous notre microscope), qui reste tout de même coûteuse, et dont certaines performances, au regard de notre application fétiche, nous laissent un peu sur notre faim.

Problématique à résoudre

En guise de conclusion, il n’est guère possible de détailler tous les aspects délicats de chacun des systèmes mentionnés : dans la mesure où il s’agit d’un problème d’optimisation globale sur l’ensemble des paramètres (application – vitesse CPU – énergie – bande passante réseau – mémoire – prix – bande passante mémoire – fiabilité…), il nous faut concevoir des outils d’approche communs à tous ces systèmes – éventuellement en les modélisant – notamment pour l’optimisation du software (réorganisation des données et des flux de données, des boucles et des algorithmes…), pour ne pas répéter 4 fois la même étude. Et c’est bien le but du projet PetaQCD.

Gilbert Grosdidier (LAL)