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.