n°37
Juillet
2017
Le Higgs passe au vert avec le calcul haute performance

Infrastructure

Détails au niveau de l’événement des échanges entre l’hôte et un GPU. Pour chaque événement, plusieurs scenarii sous forme d'intégrales sont évalués. Chaque intégrale est calculée plusieurs fois (5 fois) pour effectuer un test de khi-deux.

Une méthode d’analyse pour CMS

L’application CMS-MEM est un outil d’analyse basé sur la Méthode des Éléments de Matrice (MEM) [1]. Elle permet de combiner de manière optimale l’information théorique décrivant des processus physiques avec l’information expérimentale décrivant la résolution d’un détecteur. Elle a été développée dans sa version « Htautau » au LLR, et elle est utilisée dans l’expérience CMS pour caractériser les propriétés du boson de Higgs, produit en association avec des quarks top, et se désintégrant en paires de leptons tau.

A l’opposé des méthodes supervisées (réseau de neurones, arbre de décision, machines à vecteur de support), la MEM permet de définir des discriminants pour la classification d’événements, sans apprentissage, en s’appuyant sur la physique pour calculer les probabilités d’observer les états finaux attendus. Cette nouvelle méthode plus précise est, néanmoins, extrêmement consommatrice de temps CPU.

Dans ce contexte, l’équipe CMS du LLR, par le biais du travail de recherche de T. Strebler sur le canal ttH, a relevé le défi de développer un application dite "HPC" [2]. Dans une première étape, elle a été exploitée sur des plates-formes multi-nœuds / multi-cœurs , puis dans un second temps sur des architectures multi-nœuds / multi-GPUs [3]. L’implémentation multi-nœuds / multi-cœurs a été utilisée avec succès dans les comptes-rendus publics de la collaboration CMS [4].

Contraintes et défis technologiques

Nous avons souhaité dès le début des développements, initialement réalisés sur la plate-forme GridCL [5], relever un certain nombre de défis techniques. Pour traiter de l’analyse du canal ttH par MEM dans des délais raisonnables, nous avons conçu l’application autour des standards portables MPI et OpenCL pour agréger, respectivement, la puissance de calcul des nœuds et celle des GPUs ou autres accélérateurs de calcul rattachés à chaque nœud. L’autre choix de conception consiste à déployer tous les calculs sur les cartes accélératrices ou GPUs pour minimiser les communications « host/devices ». Cette stratégie nous a amené à développer une extension OpenCL/CUDA dans le générateur de code MadGraph [6], qui engendre l’élément de matrice au cœur de la méthode sous la forme d’un code source. Ceci nous a conduit à manipuler des "kernels" [7] allant de 10^4 à 2.10^4 lignes de code, caractéristique peu courante pour ces technologies, permettant ainsi d’éprouver la robustesse des compilateurs pour accélérateurs de calcul.

Plus récemment encore, notre participation à la Cellule de Veille Technologique (CVT) GENCI [8], nous a mis face à un difficulté supplémentaire. Leur plate-forme "pré-"exascale [9] combine des processeurs IBM OpenPOWER à instructions non x86, et des cartes de génération Pascal, pour lesquelles NVIDIA ne fournit pas encore d’implémentation d’OpenCL. Soucieux de profiter des évolutions de CUDA et des outils NVIDIA (non accessibles depuis OpenCL), nous avons construit une passerelle OpenCL 1.1/CUDA, pérennisant ainsi nos développements OpenCL face aux aléas. Cette passerelle a été largement validée et exploitée sur GridCL, sur les GPUs Pascal P100 de l’IDRIS et sur la plate-forme GPU du CC-IN2P3.

Production sur la plate-forme GPUs du CC-IN2P3

Parmi les possibilités de déploiement de CMS-MEM en mode production, l’acquisition d’une plate-forme GPUs par le CC-IN2P3 a été une aubaine pour effectuer les analyses requises. Cette machine dispose d’une puissance de calcul importante, répartie sur 10 nœuds équipés chacun de 4 accélérateurs NVIDIA K80. Le portage de CMS-MEM sur cette plate-forme a été effectué sans difficulté et le mode de soumission a été adapté pour répondre aux contraintes du système de queues.

Comme illustré dans la figure ci-dessous, le taux d’occupation des GPUs est excellent : les kernels calculent la majorité du temps d’exécution et les communications host/devices sont négligeables.

Pour évaluer le gain global en performance de l’application, nous avons pris comme référence l’analyse de 3000 événements. Le temps CPU pour traiter de cette configuration, s’évalue approximativement à 15 heures sur une plate-forme type MPI du CC-IN2P3 comportant 100 cœurs (100 processus MPI). Après quelques difficultés de mise au point des classes (le point délicat étant de coupler des classes « parallèle » avec la réservation des ressources GPUs), nous avons pu lancer nos premières exécutions de production sur 2, 4, puis 6 nœuds. Pour cette dernière configuration, 6 nœuds totalisant 24 GPUs, l’application a requis 1767 secondes. Le facteur d’accélération substantiel obtenu, approximativement 30, n’est pas seulement imputable aux GPUs. La réécriture du calcul des éléments de matrice C++, en kernels C/OpenCL entre dans une part importante de ce gain. Ainsi la puissance de calcul de la configuration avec 6 nœuds est équivalente à une plate-forme MPI comportant 3000 cœurs pour notre application CMS-MEM. Outre le gain en puissance de calcul, l’exploitation des accélérateurs de calcul ou GPU permet de réduire significativement la facture de la consommation électrique des centres de calcul, dans notre cas, cette consommation est réduite d’un facteur 5 [10].

Cette version, première du genre, est en cours d’exploitation sur les nœuds GPUs du CC (prochainement 8 nœuds), et alimente les résultats d’analyse du canal ttH pour la thèse de T.Strebler, libérant ainsi la grille d’une charge significative de travail.

Dans les années à venir, son évolution profitera des axes de réflexion du groupe de travail RI3 « CodeursIntensifs » [11] et des projets IN2P3 en cours de constitution autour des thèmes des conteneurs, de la génération de code, de la précision et de la reproductibilité numérique dans un contexte de calcul parallèle.

Remerciements

Nous adressons nos sincères remerciements au LabEx P2IO pour avoir financé (avec une contribution de l’équipe CMS et du LLR) la plate-forme GridCL, brique indispensable aux développements de CMS-MEM. Nous remercions le Centre de Calcul de l’IN2P3 pour l’élaboration du contexte de production de CMS-MEM, ainsi que la CVT GENCI pour les échanges lors des groupes de travail autour d’experts HPC.

G. GRASSEAU, T. STREBLER, P. PAGANINI et F. BEAUDETTE

[1] A titre d’exemple https://arxiv.org/abs/hep-ex/0406031

[2] High Performance Computing

[3] Graphical Processing Unit

[4] https://cds.cern.ch/record/2257067

[5] Plate-forme de développement, financé principalement par le LabEx P2IO

[6] https://launchpad.net/mg5amcnlo

[7] Terme utilisé pour désigner les codes téléchargés sur l’accélérateur de calcul, une fois compilés

[8] Cellule de Veille Technologique (CVT) GENCI est en charge de préparer les communautés scientifiques françaises à l’émergence des prochaines génération de supercalculateurs

[9] Les architectures dites exascales désignent les futurs supercalculateurs qui disposeront d’une puissance de calcul supérieure à 10^18 opérations en arithmétique flottante par seconde (ExaFlops)

[10] Comparaison effectuée en prenant uniquement en compte la consommation électrique des processeurs (E5-2698 v3 16 cœurs) de 135 W et la consommation par GPU de 150 W

[11] https://gitlab.in2p3.fr/CodeursInte..., accessible sur demande.

Rechercher
     

Directeur de la publication  : Alain FUCHS.
Responsable éditorial : Volker BECKMANN, Pierre-Etienne MACCHI.
Comité de rédaction : David CHAMONT, Frédérique CHOLLET LE FLOUR, Virginie DELEBARRE DUTRUEL, Dirk HOFFMANN et Gaëlle SHIFRIN.

logo CCIN2P3
© CCIN2P3