LaseriX et les FPGAs

Olivier, qui travaille sur l’expérience LaseriX, se présente. Il est personnel du LPGP et a une activité répartie entre le LPGP et LaseriX. Il explique qu’il travaille sur les FPGAs (Field Programmable Gate Arrays, ou réseaux de portes logiques programmables), et présente cette technologie ainsi que l’utilisation qui en est faite dans le contrôle-commande et l’acquisition de LaseriX.

Ces FPGA sont une forme d’électronique reprogrammable différente des microprocesseurs.
Il s’agit d’un réseau programmable de portes logiques, qui peut également effectuer des traitement séquentiels via des bascules. Cela permet par exemple de créer un diviseur de fréquence d’horloge précis à la nanoseconde.
Les FPGA sont principalement programmés avec deux langages : VHDL et Verilog.

La synthèse d’un circuit FPGA est l’équivalent d’une compilation : elle crée la structure logique du circuit intégrant les connexions et optimise ce schéma. Pour des circuits simples, la synthèse n’est pas si lente (de l’ordre de quelques minutes).

Les FPGA peuvent intégrer des circuits ASIC tout faits pour remplir des fonctionnalités courantes, par exemple la communication RS-232.
On peut aussi acheter des fonctionnalités toutes faites, précâblées (nommée IP, pour « intellectual property »), qui ne sont pas forcément payantes.

Deux entreprises mastodontes vendent des FPGA : Altera et Xilinx. Intel a dernièrement racheté Altera
Il est possible que Intel y voit un moyen de faire des coprocesseurs de calcul rapides et reprogrammables pour faire concurrence aux GPU.
Ces FPGA ne sont pas si impressionnant en FLOPs (nombre d’opérations réelles par secondes effectué), car un GPU est un ASIC de calcul flottant dédié donc performant. Cependant, le FPGA s’aventure plus facilement en dehors du domaine du calcul sur nombres réels et surtout, il a une bande passante E/S gigantesque (les modèles haut de gamme montent à plusieurs Tb/s de débit réseau).
En revanche, la contrainte d’espace occupé est nouvelle pour les collègues faisant du calcul informatisé. Le FPGA est naturellement parallélisable, puisqu’il est géographiquement divisible en unités logiques distinctes qui occuperont un emplacement défini.
Intel se dirige actuellement vers des architectures comportant un processeur et un FPGA, avec une interconnexion très rapide (QPI) entre les deux.
Des prototypes de puces sont disponibles à OpenLab au CERN, la date de la commercialisation n’est pas connue.
Une autre idée d’Intel à plus long terme pourrait être de mettre au point des réseaux d’unités arithmétiques et logiques (plutôt que de portes logiques) programmables.

D’autres exemples existent de projets sur FPGA existent, par exemple en Intelligence Artificielle pour créer des unités de base qui se reproduisent selon l’espace disponible, afin de créer un schéma fonctionnel de calcul et obtenir le résultat attendu (voir par exemple http://blob.lri.fr/ ).

« Flasher » un circuit sur un FPGA est rapide, c’est la synthèse (« câblage » et optimisation) du réseau de portes logiques qui est lent (ce serait a priori un problème NP-complet, analogue au voyageur de commerce).

Les FPGA sont utilisé à LaseriX dans un contexte d’acquisition pour obtenir une synchronisation précise (~10 ns).
Un rappel est fait pour préciser que le temps réel signifie qu’une suite d’opération sera effectuée (ou annulée) dans un délai borné dans le temps et défini à l’avance.
Avec un système d’exploitation habituel, on est au mieux précis à la ms (c’est l’unité de temps de l’ordonnanceur) car plusieurs programmes sont exécutés en parallèle. Même lorsque le programme s’exécute, des interruptions (clavier, souris, autres matériels) peuvent l’interrompre et donc le retarder.
Avec un système d’exploitation pseudo-temps réel qui empêche le code de se faire interrompre par l’ordonnanceur, on arrive à des délais de l’ordre de ~1µs.
Seul un FPGA permet de descendre à la ns.
Exemples de circuits existants :

• le raspberry est un processeur faisant tourner un système d’exploitation ;
• l’arduino est un micro-contrôleur qui initialise les données puis effectue le même programme en boucle.

Pour information, chacun coûtent quelques dizaines d’euros.

En acquisition, Olivier indique qu’il n’a pas rencontré en pratique de limite maximum du nombre de reprogrammation possible sur un FPGA (peu de reprogrammation après développement). Dans les années 80, un FPGA n’était « flashable » qu’une seule fois, il ne fallait pas se tromper !
Des outils existent désormais pour simuler un modèle et vérifier son bon fonctionnement avant de synthétiser le circuit final.

Comment communiquer avec un FPGA depuis l’ordi maître ?

• il n’y a pas toujours besoin, car le FPGA est autonome une fois configuré ;
• on peut communiquer en JTAG, USB, PCI-Express, etc. ;
• des outils de programmation et communication sont fournis par le fabricant ;

Comment on lance un calcul ?

• On peut implémenter sur le FPGA la logique qu’on veut pour communiquer avec l’hôte: RS232, Ethernet…
• Sur les périphériques déportés (PCIe, USB…), on peut avoir un petit CPU à côté du FPGA

Le groupe LASERIX intégrera le LAL (ou plus exactement le laboratoire résultant de la fusion LAL-IPNO-CSNSM-IMNC-LPT) au 1er janvier 2020. Les instruments PHIL et LASERIX seront alors intégré au sein d’une même plate-forme au service de la recherche sur les interactions laser-faisceaux. Même si la sa priorité est pour l’instant LASERIX , Olivier commence donc d’ors et déjà à s’intégrer aux développements TANGO communs entre PhIL et LaseriX, et plus généralement à la vie du service informatique du LAL.

Nouvelles de Spark

Les Journées CAlcul & Données sont en train de se dérouler. Fabio du CCIN2P3 y est intervenu pour parler de LSST. Spark n’a pas été évoqué, l’accent étant mis sur des technologies plus établies.

Quel est le positionnement de Spark dans l’activité de recherche en calcul du LAL ? Pour le comprendre, il nous faut marquer une distinction entre deux échelles différentes d’une infrastructure de calcul : ce qui se passe au sein d’un nœud de calcul (une machine physique possédant une mémoire vive partagée) et au niveau de la distribution du travail entre les noeuds. Ces deux échelles présentent en effet des problématiques assez différentes. Quand on doit coordonner un calcul entre plusieurs nœuds, on doit surtout gérer le coût et la complexité relative de la communication entre ces derniers, ainsi que l’hétérogénéité et la faillibilité du matériel utilisé. Alors qu’au sein d’un nœud, on doit plutôt faire face à la complexité du matériel interne du noeud: hiérarchie mémoire très profonde, nombreux niveaux de parallélisme, coprocesseurs et entrées-sorties indépendantes qu’il faut synchroniser avec le reste…

Si Spark est en principe capable de gérer tous les aspects d’un calcul distribué, ses domaines de prédilection sont la gestion de la hiérarchie mémoire et de la répartition du calcul entre les nœuds. Il serait donc envisageable, sur le long terme, de combiner Spark pour la distribution du travail entre les nœuds avec d’autres technologies plus spécialisée au sein de chaque nœud. De telles approches hybrides sont très largement employées dans d’autres domaines, on peut ainsi penser au duo OpenMP + MPI dans le milieu du calcul haute performance ou à la combinaison d’ordonnanceurs distribués avec des frameworks de traitements de données locaux qui est employée sur la Grille.

Il existe une certaine inertie à approuver et confronter des activités de R&D autour de Spark face à des technologies de distributions de calcul plus établies, mais spécifiques aux communautés de la physique des particules et de l’astronomie. C’est l’éternel dilemme du « build vs buy » : utiliser Spark permet de tirer parti de l’énorme effort de R&D industriel qui s’est monté autour de ce produit, mais comme l’outil n’a pas été développé dans une optique de calcul scientifique, il peut y avoir un questionnement quand à sa capacité à s’adapter à cette tâche aussi bien qu’un outil plus spécialisé.

Un exemple de divergence entre ces deux approches est celle liée aux formats de données. Dans le cadre de son utilisation « Big Data », Spark s’est principalement développé autour du traitement de données peu ou pas structurées, telles que des journaux d’exécution ou des fichiers JSON. Bien qu’il existe aussi des initiatives sur des formats de données complexes et optimisés (citons ici Parquet ou Avro par exemple), le travail à faire pour l’adapter aux formats de données de la physique, qui sont davantage construits autour de formats binaires à base de tableaux de chiffres à N dimensions ou de tables à colonnes hétérogènes (« NTuples »), n’est pas négligeable. Ce n’est pas que le cas d’utilisation n’ait pas été considéré dans la conception initiale de l’outil, c’est plutôt que son utilisation majeure au quotidien ne requiert pas vraiment d’optimisation dans ce sens.

Spark versus Hadoop : 2 produits avec un certain recouvrement. Hadoop c’est à la fois un système de stockage distribué (un file system) et un outil de traitement des données implémentant le paradigme MapReduce (pour simplifier, traitement en // des données découpées en morceaux et consolidation des résultats partiels). Spark est né comme une réimplémentation du moteur MapReduce pour tirer plus efficacement parti des ressources des machines de calcul (en particulier la hierarchie mémoire pour faire un caching le plus efficace possible). Aujourd’hui, du fait des avantages de Spark, la plupart des personnes qui utilisaient Hadoop à l’origine pour le traitement de données sont passés à Spark. Mais les données peuvent rester sans problème dans la couche de stockage Hadoop.

Autres sujets

Christian a assumé son statut de vétéran en racontant comment elle avait assisté aux commencements du Web. A l’époque, Tim Berners-Lee lui avait montré un des premiers navigateur web sur son ordinateur NeXT. Celui-ci était déjà graphique, les navigateurs web textuels comme lynx sont en réalité une invention postérieure, née du fait que tout le monde n’avait pas accès à une machine NeXT, ni à un terminal graphique d’ailleurs.

A ses débuts, Christian a également travaillé sur l’acquisition d’expériences de physique des particules, comme par exemple la chambre à propane liquide Gargamel.

Du côté CNRS, la hiérarchie a encouragé, via la liste de diffusion SFP-HEP, une féminisation… chez les DR. Le question des ingénieures, quand à elle, n’a pas été évoquée.

Enfin, Cyril nous présentera l’application web Coding Pool qu’il développe avec David au cours de la prochaine réunion.