Salut, merci d'avoir lu l'article (qui promettait une suite pour « bientôt », et qui n'est jamais venue... Je suis en train d'y travailler — si si).
Je bosse dans une fac US. Les gens avec qui nous bossons varient : mon labo a aidé (bien avant que je les rejoigne) à la création de systèmes « manycore » à une époque où le multicœur n'était pas encore sur le point d'arriver sur le marché. Nous bossons sur tous les aspects « logiciel système » pour les architectures manycore à destination du calcul haute-performance: multithreading, gestion à grain fin des ressources systèmes, etc.
Concernant les langages utilisés en HPC: oui, la grande majorité des codes reste écrite en C ou Fortran (et parfois C++). Et oui, les gens utilisent en général un mix entre MPI (qui représente ~80% à 90% des codes qui tournent sur des grappes de calcul et supercalculateurs), OpenMP (pour le parallélisme intra-nœud, et qui représente peut-être 10% supplémentaires), et le reste (CUDA, OpenCL, OpenACC, etc.) se dispute les miettes. Cependant, avec l’avènement du « data science » (qui est lui-même une continuation des environnements « big data »), et plus précisément avec SPARK, on commence à voir venir les langages fonctionnels comme d'excellents langages de type « DSL » (domain-specific language). C'est d'ailleurs là où je trouve qu'ils excellent : on crée un sous-ensemble de langages de programmations pour un domaine scientifique donné, ce qui est relativement simple si on utilise des constructions fonctionnelles avec du « pattern matching ». (Common) LISP a longtemps été considéré comme le champion dans le genre.
On n'en est pas là cependant. Pour le moment, les langages façon C restent les plus utilisés, avec pas mal de scientifiques qui utilisent de plus en plus les environnements à base de Python (et qui utilisent des bibliothèques optimisées en C). Matlab est aussi pas mal utilisé dans ce contexte, et lui aussi utilise des bibliothèques optimisées, par exemple ATLAS pour l'algèbre linéaire, ou bien CuBLAS lorsqu'un GPU Nvidia est disponible, etc.
Il faut aussi mentionner OpenMP 4.x, qui tente de proposer 1000 constructions pour pouvoir tirer avantage des accélérateurs (Xeon Phi, GPU, etc.), grouper des threads ensemble, tirer partie des instructions SIMD (SSE, AVX, Altivec, etc.), étendre les possibilités de multithreading, etc. Malgré tout, ça ne reste « qu'une » extension à C/C++/Fortran.
Bref, l'utilisation de langages autres que C/C++/Fortran (avec parfois du Python en « front-end ») reste anecdotique ou cantonnée à une niche.
Il existe une famille de langages qui tente de proposer une façon d'exprimer le parallélisme pour des supercalculateurs tout en augmentant la productivité du programmeur. On les appelle langages PGAS (Partitioned Global Address Space). Les plus connus sont UPC (Universal Parallel C), X10 (proposé par IBM), et Chapel (proposé par Cray). Il y en a d'autres, cf. mon lien. La plupart proposent une implémentation de référence libre, mais malheureusement, les performances restent loin d'être au rendez-vous. Cependant, c'est normal : il est déjà difficile de correctement optimiser du code séquentiel en utilisant les graphes de flot de contrôle et de flot de données (ou de dépendance de données), alors je te laisse imaginer ce qui se passe lorsqu'en plus on doit gérer du code parallèle (même si c'est exprimé plus ou moins explicitement). Malgré tout, même si ce sont des langages « usine à gaz », je pense qu'ils représentent une bonne avancée dans le domaine, et on peut espérer qu'ils vont au moins fournir une base d'inspiration pour des langages explicitement parallèles plus « légers » — C'est déjà le cas avec X10 : le langage Habanero Java est un X10-light qui ne reprend que les mécanismes jugés vraiment intéressants (il existe un langage Habanero C, qui comme son nom l'indique repose sur un « back-end » écrit en C, mais il est par beaucoup d'aspects bien plus expérimental).
Enfin, j'aimerais mentionner Cilk/Cilk++/CilkPlus, pour plusieurs raisons:
C'était l'un des rares environnements de programmation parallèle dans les années 90 (avec la v1 d'OpenMP, et un autre machin appelé EARTH);
dans les années 90, Cilk a permis de créer l'un des meilleurs programmes d'IA d'échecs pour machine parallèle;
Cilk (et ses successeurs) est à ma connaissance l'un des rares langages qui utilise un modèle d'exécution qui a des bornes prouvables pour l'ordonnancement des tâches, en temps et en espace;
enfin, c'est l'un des rares langages qui ne nécessite pas de connaître 10000 constructions parallèles pour créer du parallélisme1
Je pense en particulier à OpenMP 4, qui ajoute plein de fonctionnalités — tellement que contrairement aux versions précédentes du standard, il n'y a pas d'exemples de code... et malgré tout, le standard a plus que doublé en taille par rapport à la v3. ↩
[^] # Re: Logiciels libres
Posté par lasher . En réponse à la dépêche Agrégation et logiciels libres. Évalué à 4.
Salut, merci d'avoir lu l'article (qui promettait une suite pour « bientôt », et qui n'est jamais venue... Je suis en train d'y travailler — si si).
Je bosse dans une fac US. Les gens avec qui nous bossons varient : mon labo a aidé (bien avant que je les rejoigne) à la création de systèmes « manycore » à une époque où le multicœur n'était pas encore sur le point d'arriver sur le marché. Nous bossons sur tous les aspects « logiciel système » pour les architectures manycore à destination du calcul haute-performance: multithreading, gestion à grain fin des ressources systèmes, etc.
Concernant les langages utilisés en HPC: oui, la grande majorité des codes reste écrite en C ou Fortran (et parfois C++). Et oui, les gens utilisent en général un mix entre MPI (qui représente ~80% à 90% des codes qui tournent sur des grappes de calcul et supercalculateurs), OpenMP (pour le parallélisme intra-nœud, et qui représente peut-être 10% supplémentaires), et le reste (CUDA, OpenCL, OpenACC, etc.) se dispute les miettes. Cependant, avec l’avènement du « data science » (qui est lui-même une continuation des environnements « big data »), et plus précisément avec SPARK, on commence à voir venir les langages fonctionnels comme d'excellents langages de type « DSL » (domain-specific language). C'est d'ailleurs là où je trouve qu'ils excellent : on crée un sous-ensemble de langages de programmations pour un domaine scientifique donné, ce qui est relativement simple si on utilise des constructions fonctionnelles avec du « pattern matching ». (Common) LISP a longtemps été considéré comme le champion dans le genre.
On n'en est pas là cependant. Pour le moment, les langages façon C restent les plus utilisés, avec pas mal de scientifiques qui utilisent de plus en plus les environnements à base de Python (et qui utilisent des bibliothèques optimisées en C). Matlab est aussi pas mal utilisé dans ce contexte, et lui aussi utilise des bibliothèques optimisées, par exemple ATLAS pour l'algèbre linéaire, ou bien CuBLAS lorsqu'un GPU Nvidia est disponible, etc.
Il faut aussi mentionner OpenMP 4.x, qui tente de proposer 1000 constructions pour pouvoir tirer avantage des accélérateurs (Xeon Phi, GPU, etc.), grouper des threads ensemble, tirer partie des instructions SIMD (SSE, AVX, Altivec, etc.), étendre les possibilités de multithreading, etc. Malgré tout, ça ne reste « qu'une » extension à C/C++/Fortran.
Bref, l'utilisation de langages autres que C/C++/Fortran (avec parfois du Python en « front-end ») reste anecdotique ou cantonnée à une niche.
Il existe une famille de langages qui tente de proposer une façon d'exprimer le parallélisme pour des supercalculateurs tout en augmentant la productivité du programmeur. On les appelle langages PGAS (Partitioned Global Address Space). Les plus connus sont UPC (Universal Parallel C), X10 (proposé par IBM), et Chapel (proposé par Cray). Il y en a d'autres, cf. mon lien. La plupart proposent une implémentation de référence libre, mais malheureusement, les performances restent loin d'être au rendez-vous. Cependant, c'est normal : il est déjà difficile de correctement optimiser du code séquentiel en utilisant les graphes de flot de contrôle et de flot de données (ou de dépendance de données), alors je te laisse imaginer ce qui se passe lorsqu'en plus on doit gérer du code parallèle (même si c'est exprimé plus ou moins explicitement). Malgré tout, même si ce sont des langages « usine à gaz », je pense qu'ils représentent une bonne avancée dans le domaine, et on peut espérer qu'ils vont au moins fournir une base d'inspiration pour des langages explicitement parallèles plus « légers » — C'est déjà le cas avec X10 : le langage Habanero Java est un X10-light qui ne reprend que les mécanismes jugés vraiment intéressants (il existe un langage Habanero C, qui comme son nom l'indique repose sur un « back-end » écrit en C, mais il est par beaucoup d'aspects bien plus expérimental).
Enfin, j'aimerais mentionner Cilk/Cilk++/CilkPlus, pour plusieurs raisons:
Je pense en particulier à OpenMP 4, qui ajoute plein de fonctionnalités — tellement que contrairement aux versions précédentes du standard, il n'y a pas d'exemples de code... et malgré tout, le standard a plus que doublé en taille par rapport à la v3. ↩