Réunion Dev@LAL 54

mercredi 11 janv. 2017, 10:30 → 11:30 Europe/Paris

166 (LAL)

Séminaires et blockchains

Après avoir lancé une idée de séminaires de vulgarisation, Christian doit maintenant mettre ce projet en pratique. Oleg propose d'y parler de blockchains.

Une application possible de ces dernières serait de gérer les quotas de ressources dans une infrastructure Spark de calcul distribuée. Mais une question demeure: la complexité de la solution blockchain est-elle vraiment justifiée pour cette application?

Hadoop dans l'EventIndex de ATLAS

Julius est actuellement le seul utilisateur important de l'infrastructure Hadoop d'ATLAS, la question de la gestion des ressources se pose donc assez peu dans son cas.

Pour cette application, Spark a été testé, mais ne se révèle pas très intéressant non plus: aucun bénéfice significatif n'est observé en termes de performances. La raison la plus probable est que les requêtes Hadoop sont loin d'être un goulot d'étranglement pour les performances: une requête prend de l'ordre de 30ms, c'est loin d'autres latences comme celle du réseau et des services web.

Aujourd'hui, les principaux facteurs limitants pour les performances seraient plutôt le transfert de données sur le réseau et l'interface utilisateur.

On peut accéder à l'EventIndex de trois manières: une API REST, un programme en ligne de commande, et une interface web. Les principaux use cases sont:

• L'"Event picking", où l'utilisateur veut déterminer la localisation des données d'un événement. On effectue généralement cette opération en ligne de commande.
• Des requêtes plus avancées à la SQL, pour lesquelles l'interface web est plus utilisée.

Une des difficultés de cette aplication est de gérer le cycle de vie du jeu de données, par exemple les cas où un jeu de données est invalidé. Pour y parvenir, l'application doit interagir avec beaucoup d'autres services: AMI, RUCIO, etc...

Java dans ATLAS

Il existe une certaine hantise de Java dans ATLAS, qui tient sans doute à plusieurs facteurs. Le premier, et sans doute le plus valable, est que l'expérience a surtout une expertise en Python et C++, ce qui y rend difficile la maintenance de code Java. Mais par ailleurs, nombre de développeurs ATLAS vivent aussi dans le souvenir traumatique de la performance d'anciennes implémentations Java, dont une partie n'est plus d'actualité.

Ainsi, la performance à l'exécution de la JVM est aujourd'hui très supérieure à celle de CPython et se trouve à moins d'un facteur 2x d'une implémentation C++ simple dans nombre de benchmarks (exemple). Il faut souvent être expert en vectorisation, macros/templates, et autres concepts C++ avancés pour la dépasser en pratique. En revanche, la consommation de RAM très importante de la JVM (on parle parfois d'un facteur 500x ou plus par rapport à une application C++ de complexité équivalente) demeure un problème pour des applications avares de cette ressource comme les code de calcul intensif. Sur ce point, c'est plutôt le C++ qui rend les choses nettement plus faciles à la base, même si un développeur Java expert pourra là aussi améliorer les choses.

Guerre des langages

Pour revenir à la question de la maintenance, elle tient à plusieurs facteurs. D'une part, si le développeur d'un programme utilise un langage obscur pour sa communauté, il sera difficile de trouver d'autres personnes capable de maintenir ce programme, surtout après le départ du développeur principal. D'autre part, il est souvent nécessaire d'interfacer des codes écrits dans différents langages, ce qui se révèle d'autant plus difficile qu'on est souvent forcé de s'en remettre au plus petit dénominateur commun d'une interface C, qui est fondamentalement incapable d'exprimer efficacement des concepts modernes tels que l'objet.

Le sujet de la guerre des langages étant lancé, chacun s'est lancé dans la discussion de ses langages favoris: Go, Python, Scala... Il était difficile de prendre des notes, mais voici quelques bribes de ces conversations:

• Les principaux points fort du langage Go sont sa simplicité conceptuelle ("faire beaucoup avec peu d'idées de base", comme le C) et son support natif de la programmation concurrente (à la manière d'Ada ou d'Erlang).
• Il existe des compromis importants entre différents aspects de conception d'un langage comme l'expressivité, la simplicité, la généralité et la détection des erreurs utilisateur, dans laquelle les langages se positionnent à différents niveaux. Par exemple, Scala introduit un grand nombre de raccourcis syntaxiques par rapport à son parent Java, ce qui le rend plus expressif au prix d'une plus grande complexité.
• Face à la popularité de Python dans le domaine du calcul scientifique, tâche à laquelle ce langage est très peu adapté à la base (du point de vue des concepts comme de la performance), des efforts ont été fait pour concevoir un langage alliant la souplesse et l'expressivité du Python à une conception plus orientée calcul: Julia. Quelqu'un ayant discuté du sujet avec Loïc Gouarin en était ressorti avec l'impression que l'agitation initiale autour de ce langage serait un peu retombée, ce qui laisserait son devenir en question. Mais une conversation directe à ce dernier suggère qu'il n'aurait rien dit de tel et ne partage pas cette opinion.

Dans tous les cas, rappelle Christian, le choix initial d'un langage pour un projet se fait plus souvent vis à vis des connaissances de la communauté que des qualités intrinsèques de chaque langage. En effet, former une communauté entière à un nouveau langage a un coût titanesque, comme on a pu s'en rendre compte lors du douloureux passage de la communauté HEP de Fortran à C++.