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.

JIs 2018 à Port-Bail

Cette année, il n’y avait pas de sessions parallèles pour développeurs et administrateurs, mais une série de sessions plénières.

Au niveau des avantages, on peut mentionner la mise en contact de ces deux communautés qui se parlent peu et la plus grande visibilité de sujets transverses (packaging, conteneurs, middleware de la Grille). Au niveau des inconvénients, les devs trouvent qu’il y a trop de sujets ASR et vice versa.

Un exposé de la direction IN2P3, présentant les résultats des groupes de travail sur les compétences des informaticiens, a fait polémique. En effet, la classification proposée ne satisfaisait pas tout le monde, et l’objectif poursuivi n’était pas clair. Il semblerait que ces études pourraient affecter le recrutement (en informant des décisions sur les compétences prioritaires à rechercher, ou à l’inverse sur les compétences non prioritaires que l’on peut mettre de côté), et que l’un des buts poursuivis par l’IN2P3 soit d’avoir plus de visibilité sur les compétences présentes pour aider le pilotage.

Un autre exposé intéressant concernait les bandes magnétiques. La fin de celles-ci n’est pas pour demain, mais l’un des deux constructeurs de lecteurs de bande a arrêté cette activité, et celui qui reste est donc désormais en situation de monopole. Ceci place le CCIN2P3 en situation très délicate, étant donné qu’ils ont un grand parc de lecteurs du fabricant qui vient de cesser la production…

L’organisation des ateliers (tutoriels, piscines…) était assez décevante, mais les ateliers en eux-même étaient plutôt satisfaisants.

L’organisation des prochaines journées informatiques sera probablement effectuée par le LAL, qui envisage de les situer à proximité de la vallée d’Orsay. La difficulté est de trouver un lieu qui puisse héberger pour 4 jours à 110€/personne tout compris dans la région. Certains sont déçus par le choix peu attrayant de l’Île de France, mais il faut toutefois rappeler que les soutiens financiers du RI3 ne sont pas forcément disposés à se rendre dans des lieux trop reculés…

Journée LoOPS – conda

Antoine & David sont allés à la journée LoOPS sur conda (`9 octobre 2018 – Journée conda – LoOPS <https://reseau-loops.github.io/journee_2018_10_Conda.html>`_)
Les diapos et les TP sont dispo en ligne (`gouarin/conda_tutorial <https://github.com/gouarin/conda_tutorial>`_). Un article a aussi été écrit sur le projet mené par plusieurs membres de la communauté LoOPS (`article sur les paquets conda <https://medium.com/@lgouarin/conda-smithy-an-easy-way-to-build-and-deploy-your-conda-packages-12216058648f>`_).

La journée se déroulait dans un bel amphi, dans un beau bâtiment (Inria Saclay « Turing »), avec des prises sur chaque siège, c’est notable et pratique.

Les discussions ont porté sur Anaconda, conda, et miniconda.

• Anaconda est une grosse distribution Python (~2 Go) ;
• conda est le gestionnaire de paquet utilisé par cette distribution ;
• miniconda est une distribution minimaliste basée sur conda (~240 Mo avec « seulement » 34 paquets installés).

Il est préférable d’utiliser miniconda qu’Anaconda, car chaque environnement virtuel d’Anaconda hérite de l’environnement de la distribution (et donc de tous les paquets python de celle-ci) et de tout l’environnement système
Cette problématique est plus générale aux environnements système, et existe donc aussi avec d’autres gestionnaires de paquets comme Brew. Tous les gestionnaires de paquets ne se préoccupent pas autant de cette question.
miniconda est idéal pour des images docker minimalistes

Durant la journée, le système de paquetage conda a été présenté, il concerne des langages de programmation au delà de Python.
Anaconda et conda sont gérés par l’entreprise Continuum, sous une licence soit libre. Le dépôt de paquets reste cependant géré par Continuum. La question du risque de changement de gestion par Continuum a été posée, la communauté semble se considérer suffisamment organisée pour y palier le cas échéant. Un problème (de bien plus forte ampleur) s’est cependant posé avec npm il y a quelques années quand une partie importante des sites mondiaux avait cessé de fonctionné durant plusieurs heures suite au retrait d’un paquet (https://www.numerama.com/tech/154759-comment-une-marque-commerciale-et-11-lignes-de-code-retirees-ont-fait-trembler-internet.html ).

Une démonstration du processus de contribution à conda (bug reports, merge requests, tests automatisés…) a aussi été présentée.
La gestion de l’environnement (par exemple disposer de la bonne version de MPI) n’est pas évidente. Loïc Gouarin a proposé une contribution pour simplifier cette gestion.
Un problème général des gestionnaires de paquets est qu’ils veulent tout contrôler, et qu’ils gèrent mal l’interaction avec les systèmes de gestion de paquets du système d’exploitation (pilotes, MPI…).

Le problème de base résolu par conda dans Anaconda est de fournir un gestionnaire de paquets aux utilisateurs Windows et MacOS qui n’en ont pas par défaut sur leur système d’exploitation, tout en étant portable d’un système d’exploitaiton à un autre, ce pour un environnement Python.
L’extension aux langages non-Python émerge naturellement des bibliothèques natives utilisées par Python (ex: numpy, matplotlib)

Loïc a utilisé `doitlive — doitlive 4.0.1 documentation <https://doitlive.readthedocs.io/en/latest/>`_ : on enregistre une série de commandes bash pour faire une démonstration et elles sont rejouées sur les machines clientes (un ou plusieurs caractères enregistrés par frappe clavier, c’est configurable).

Un biologiste a fait la publicité de Nextflow (https://www.nextflow.io/ ), un gestionnaire de graphe de tâches pour le calcul distribué. Cela se rapproche de Dask (https://dask.org/ ).
Dans les deux cas, on donne un graphe de tâches au gestionnaire qui gère alors la distribution des calculs sur plusieurs nœuds, sur du cloud…

Conférences Spark

Julien avait été convié à présenter ses travaux sur l’utilisation d’Apache Spark en astronomie au MeetUp Spark + AI de Londres ( https://www.meetup.com/fr-FR/Spark-London/events/254679118/ ). Ce dernier était organisé conjointement avec le Spark Summit ( https://databricks.com/sparkaisummit/europe/schedule ), une grande conférence sur Spark, à laquelle Julien n’avait pas prévu de se rendre en raison du tarif élevé. Cependant, les organisateurs du Summit (Databricks) lui ont offert un ticket, donc il y est finalement allé.

Julien a présenté ses travaux en compagnie d’une personne qui faisait du traitement automatique de la langue à des fins commerciales. Il a découvert au cours de ces événements que les utilisateurs de Spark dans le milieu privé se confrontaient finalement à des problématiques similaires à celles des chercheurs :

• des difficultés à utiliser efficacement les machines disponibles ;
• une réconciliation délicate des besoins de traitements groupés et interactifs ;
• des choix cornéliens entre clusters maison un peu bricolés et cloud plus « propre » mais posant des problèmes de confidentialité ;
• des personnes qui font tourner leurs jobs sur leurs ordinateurs portables en désespoir de cause…

Un thème très représenté était l’étude de la pertinence de l’utilisation des moyens HPC. Historiquement, il y a eu une forte propagande contre ces derniers, perçus comme moins performants et peu rentables. Cependant, on peut se demander dans quelle mesure ces rumeurs étaient fondées, et dans quelle mesure elles relevaient de la simple campagne de désinformation portée par les acteurs commerciaux du cloud et des grilles. En effet, des analyses rigoureuses montrent que les performances des deux moyens de calcul sont similaires, voire que la comparaison est parfois à l’avantage du HPC.

Par exemple, les études portant sur les systèmes de fichier distribués (Lustre, HDFS, S3…) montrent que sur des tâches usuelles de grandes lectures séquentielles, les performances de ceux-ci sont comparables. On aurait pu s’attendre à observer des différences étant donné que l’architecture varie beaucoup d’un système de fichier à l’autre (pair-à-pair, maître-esclave…), mais il est probable que sur ces cas d’utilisation simples, on soit limité par la bande passante des disques et des interconnections réseau, et non par le système de fichier utilisé.

La répartition des données entre noeuds (« shuffle ») est un point sensible pour de nombreux utilisateurs de Spark. Or, les études menées sur des machines HPC montrent que celles-ci ont un avantage sur ce type de tâches, qu’elles peuvent parfois effectuer trois fois plus rapidement que des machines HTC (grille, cloud…). On peut le comprendre en prenant en compte le fait que les machines HPC ont des interconnections très rapides de type Infiniband, qui ont en particulier des caractéristiques de latence bien meilleures que celles des réseaux Ethernet classiques. Un autre avantage du HPC est l’homogénéité des configurations matérielles, qui simplifie le déploiement de logiciels fortement optimisés et évite dans une certaine mesure les problèmes d’équilibrage de charge.

Finalement, la principale différence notable de mentalité entre secteurs privés et publics concernait les coutumes sociales. Ainsi, l’utilisation de cartes de visites demeure fréquente dans le secteur privé, là où elle est anecdotique dans le milieu académique. Il est possible d’en faire imprimer par le laboratoire, cela peut être intéressant pour ne pas être pris au dépourvu lorsqu’on se rend à ce type de conférences. Les thématiques et techniques commerciales (ex: vidéos promotionnelles) étaient aussi beaucoup plus présentes. À l’inverse, il était aussi inattendu qu’agréable de constater que le public écoutait l’orateur plutôt attentivement, au lieu de regarder son ordinateur ou son téléphone en même temps comme c’est généralement le cas en recherche.

Dans l’ensemble, le Spark Summit s’est avéré moins enrichissant que le MeetUp. Les discussions étaient souvent moins intéressantes sur le plan techniques, et les orateurs moins talentueux. Les plénières étaient aussi très autopromotionnelles (sans-doute avaient-elles été confiées aux soutiens financiers qui payaient le loyer de l’énorme centre de conférences, comme cela se fait souvent), et les sessions parallèles si nombreuses (7 à la fois) qu’il en devenait trop facile de mal choisir.

Une thématique qui revenait souvent était celle de l’apprentissage automatique, supervisé ou non. On parle d’apprentissage supervisé lorsqu’on fournit au système des exemples précis du comportement que l’on souhaite lui voir prendre lors de la phase d’ajustement des paramètres. L’apprentissage non supervisé, historiquement minoritaire car plus difficile, a connu un regain d’intérêt récemment alors qu’il commence à y avoir une prise de conscience des nombreux biais de l’apprentissage supervisé (performance qui dépend fortement de la diversité des données d’entraînement, mauvaise gestion des événements rares ou imprévus…). Un exemple de situation où l’utilisation de techniques d’apprentissage non supervisé est nécessaire est la détection d’anomalies, où l’on cherche à isoler des données qui dévient de façon peu prévisible des observations historiques.

Parmi les présentations plénières mémorables, on peut mentionner celles de Shell et Microsoft. Shell présentait un système d’analyse d’images de vidéosurveillance de station-service, qui pouvait détecter rapidement les fumeurs et ainsi oeuvrer pour la sécurité des biens et des personnes. Cependant, il était crispant de noter que le système collectait bien plus d’informations des vidéos que ce qui était nécessaire pour cet objectif affiché… Quand à Microsoft, il se sont plutôt illustrés par le ridicule puisque leur plénière consistait en une vidéo promotionnelle suivie d’un commentaire de la vidéo.

Parmi les sessions parallèles, globalement décevantes, Julien a relevé une belle présentation d’Enric Tejedor, qui organisait le Google Summer of Code au CERN cette année.

Les vidéos du Spark Summit sont disponibles à l’adresse https://databricks.com/sparkaisummit/europe/spark-summit-2018-keynotes?mkt_tok=eyJpIjoiTWpOak5UWTBObVV3T1RBMCIsInQiOiJPSklQMks3SzlkUmxwVDJCWEhSYzljR0NqOWliT2ZaUjR5bUNqcmZUNG1cLzkweUdsWW54Nkloalp3QWZoTDlZM1I2ekJYcFd0cEZ5Z0tMcHYxbEZiVXV4V3BBOGtrY2xDTWJUblpaVmIxXC96QitZVlVLUkMxSXpmbG5tcWJkUU1oIn0%3D .

Autres sujets

L’équipe pédagogique de la formation au génie logiciel du master NPAC s’interroge sur l’intérêt de présenter le typage optionnel en python. Ces « type hints » ont été introduites par la proposition de fonctionnalité PEP 484 [https://www.python.org/dev/peps/pep-0484/ ].

David aurait bien aimé encourager son stagiaire Cyril à parler de la banque de tutoriels « Coding Pool » qu’ils développent ensemble, mais il s’y est mal pris pour cette fois. La présentation est donc remise à plus tard.