Réunion Dev@LAL 47
129
LAL
Compte rendu réunion dev@LAL du 07/09/2016
Arrivée de Marica
Marica est arrivée à la rentrée pour travailler sur le projet PSPA. Possédant une grande expérience de la construction d'accélérateurs de particules, elle oeuvrera, entre autres :
- A promouvoir ce projet auprès de la communauté des accélérateurs
- A s'assurer que PSPA réponde bien aux besoins de cette communauté
Café LoOPS sur Pythran
Au dernier café LoOPS, Loïc Gouarin a fait une présentation de Pythran, un outil pour l'optimisation des performances de programmes Python. Christian Helft est venu à contrecoeur, mais a finalement trouvé ça très intéressant.
Pour poser un peu le contexte, quand on touche aux limites de performance de l'interpréteur "standard" de Python, CPython, on a aujourd'hui beaucoup d'options :
- Utiliser une implémentation Python plus performante, comme PyPy ou Numba. C'est peut-être l'option la plus simple quand elle fonctionne. Mais la compatibilité entre implémentations Python est loin d'être parfaite...
- Réécrire les "points chauds" du code sous la forme d'une bibliothèque C, qui s'interface avec CPython via son API. Le processus est extrêmement lourd.
- Réécrire les "points chauds" en Cython, un langage à cheval entre C et Python. Sous le capot, un compilateur génère ensuite du code C similaire au cas précédent. La conversion est beaucoup plus simple, mais une réécriture assez conséquente du code demeure nécessaire.
- Se limiter au sous-ensemble des fonctionnalités de Python supportées par Pythran, puis confier à ce dernier le code Python, avec juste quelques annotations en plus indiquant les fonctions à compiler et les types qu'elles prennent en entrée. Sous le capot, le reste du processus est similaire à Cython, à part qu'on travaille en C++.
Pythran propose donc de générer facilement du code compilé performant à partir d'un programme Python, en demandant aussi peu de modifications du code que possible, du moment qu'on se restreint au sous-ensemble des fonctionnalités de Python que Pythran supporte.
De plus, Pythran permet aussi d'effectuer des calculs en parallèle sur un processeur multicoeur par parallélisation OpenMP des boucles. Comme il travaille en C++, il peut en effet passer outre la GIL ("Global Interpreter Lock") de CPython, qui empêche l'exécution parallèle de code dans cet interpréteur.
L'évocation de ce point a soulevé un grand débat sur les différents rôles du thread en programmation :
- Décomposer conceptuellement un programme en tâches indépendantes.
- Donner au système d'exploitation la possibilité d'exécuter ces tâches simultanément, ou d'offrir une illusion d'exécution simultanée.
- Cacher la latence des entrées/sorties en faisant autre chose pendant ce temps.
- Utiliser efficacement les processeurs multi-coeurs.
Avec CPython, on peut décomposer un programme en tâches (avec Thread ou les générateurs) et cacher la latence de certains types d'entrées-sorties (avec des bibliothèques comme asyncio), mais on ne peut pas obtenir de l'OS une exécution simultanée (réelle ou simulée) ni utiliser efficacement des processeurs multi-coeurs. Le modèle multitâche de Python est donc un peu similaire à celui des systèmes d'exploitation coopératifs comme MacOS 9 et Windows 3.
Etait également présent le coordinateur du projet H2020 "OpenDreamKit", qui vise à développer l'écosystème de calcul open-source et améliorer l'intégration entre ses outils.
Le projet est plutôt axé sur les problématiques de mathématiques "pures" (algèbre linéaire, calcul en précision infinie, polynômes, théorie des groupes et des nombres...), mais ses contributions à des projets tels que IPython et Jupyter ont aussi un intérêt pour les sciences empiriques. Pour en savoir plus sur le contenu du projet et les pays qui y contribuent, voir le proposal.
Nouvelles de la direction de l’IN2P3
Christian Helft et Antoine se sont entretenus avec le nouveau directeur technique de l'IN2P3, Christian Olivetto. Ce dernier a été responsable technique au laboratoire APC (Paris 7), et a également été membre de l’équipe d'Atrium.
Contrairement à ses prédécesseurs, ses prérogatives sont étendues à l’informatique des laboratoires de l'IN2P3, le poste de Chargé de Mission à l’Informatique n'existant plus. Son périmètre d'action est complémentaire de celui du directeur scientifique "Calcul", Volker Beckmann, nouvelle fonction créée, dont le rôle est centré sur les problématiques globales « calcul et données ».
Christian Olivetto a une grande compétence et culture du projet, et relance le réseau projets et qualité à l'IN2P3.
Ces deux personnages sont convaincus de l'importance du réseau informatique, et seront présents aux JI. Plus généralement, on peut espérer d’eux des financements pour organiser plus de journées thématiques à l'IN2P3, et la hiérarchie semble désirer mieux nous connaître.
Quand on présente l’informatique du LAL, PSPA est un des sujets considérés comme importants. Christian Olivetto a posé la question de l'intégration d'Opera, un logiciel de modélisation de champ magnétique pour la conception d’aimant, dans PSPA, mais le DEPACC lui-même a souligné la faible pertinence, aujourd’hui, d’une telle opération. Ce logiciel a un coût non négligeable (pour l’IN2P3), mais ses fonctionnalités pour la simulation de champs tridimensionnels sont probablement plus performantes que celles de son cousin libre PRIAM développé il y a plusieurs années au LAL.
Plongeons
En préparation des JI, beaucoup de développeurs sont en train de préparer des plongeons. Pour rappel, ces derniers ont pour vocation d'être des tutoriaux courts (20 minutes maximum), faisables en autonomie, sans connexion Internet, et sur un PC quelconque. Le but est de permettre à chaque visiteur des JI d'avoir un premier contact avec des technologies qu'il n'aurait pas essayées autrement.
La contrainte "PC quelconque" signifie qu'on doit prétendre à une portabilité immédiate de l'environnement du tutoriel vers n'importe quelle combinaison de matériel et de système d'exploitation. Mais en pratique, c'est loin d'être évident.
De ce point de vue, le bilan actuel de Docker comme couche d'abstraction est le suivant :
- Portabilité des applications consoles (compilateurs, etc) : Parfait.
- Gestion du réseau : Mitigé. Pour certains comme Christian Helft, ça a marché du premier coup sans réfléchir. Pour d'autres comme David, on cherche encore à se dépêtrer dans des instructions spécifiques au système hôte.
- Applications graphiques : Peu satisfaisant. L'application Docker utilise X11, puisqu'elle est conçue pour Linux, mais l'interfaçage de X11 n'est pas forcément simple et dépend fortement du système hôte.
On peut souvent se passer des applications graphiques qui ne sont pas le sujet principal du plongeon, comme les éditeurs de texte, en montant un répertoire hôte dans le conteneur Docker et en effectuant toutes les éditions de fichier "en local". Mais pour certains plongeons comme celui sur PyQt4, le besoin demeure, et il faudra voir sur le long terme comment on peut mieux y répondre.
Au niveau du contenu, il y a eu quelques remarques sur les prérequis idéaux d'un plongeon. Peut-on dire, par exemple, que les plongeons C++11 de David, qui s'adressent aux développeurs expérimentés en C++98, sont trop difficiles ? A priori non : vu le format court des plongeons, on est forcé de supposer certains pré-requis chez le plongeur, l'important est que ces derniers soient bien spécifiés en début de plongeon (ce qui est le cas ici).
Un autre regret est que la plupart des plongeons actuellement disponibles sont fléchés "développeur", et que les ASR risquent donc de ne pas s'y retrouver. Christian Arnaud a proposé un plongeon Atrium, et il y aurait aussi des discussions sur une transformation éventuelle des ateliers ASR en plongeons.
Outils collaboratifs
À la fin de la réunion, nous avons un peu discuté la question des outils collaboratifs pour la coécriture de texte et la discussion. Quelques outils précis ont été mentionnés :
- Etherpad (écriture à N mains de texte formaté, utile pour la prise de notes en réunion)
- Confluence (grosso modo espace de partage et édition en ligne de documents, texte formaté ou autre)
- Slack (chat à historique persistant, dont il existe une instance RI3)
- IRC (LE protocole de chat historique, facile à mettre en place avec des applis web)
- Jabber (plus moderne qu'IRC, mais nécessite un peu de setup client)
- Canvas (éditeur Markdown web, collaboratif et WYSIWIG, malheureusement spécifique aux navigateurs basés sur Webkit actuellement)