Bof, rien de vraiment nouveau sous le Soleil.

Au moins, peut-on espérer les bench en 2025. Le reste c'est de la com'.

Par contre rust pour du HPC ?! Mais attend là, c'est Chat-GPT4 qui a déconné ou bien ils sont vraiment sérieux ?

Le problème de Rust ? Son modèle mémoire.

Par HPC, j'entends calculs à mémoire partagées et à mémoires distribuées et le calcul sur des accélérateurs. Pour le dernier, il y a beaucoup de wrapper pour s'appuyer sur les API du fabricants àla fin, donc Rust, C ou Python ne change rien au problème ici. Pour la mémoire distribuée, je ne sais pas vraiment mais je ne vois pas de raison techniques pour lesquelles Rust serait en deça, surtout qu'il va wrapper les lib dédiées à cette tâche.

Non, le problème de Rust va être pour la mémoire partagées, et notamment lorsqu'on l'applique pour séparer des grosses boucles (e.g., grosse inversion de matrice) en plus petits boucles chacune allant tourner sur un coeur de calcul du CPU (en pratique, c'est plus compliqué mais c'est l'idée).
En C/C++ quand tu fais ce genre de choses tu es responsable de gérer correctement les accès mémoires (et donc d'éviter les races conditions et autres soucis du calcul //). Mais en pratique, tu utilises des libs qui t'aide à faire ce travail.

* Rust pour ça part a une vision très stricte de la mémoire et de sa façon d'accéder et de l'utiliser (en gros, on passe que par copie et on isole la mémoire à chaque coeur).
Cette façon de faire lui permet de garantir certaines sécurités à la compilation (pas uniquement au niveau des fuites mémoires, mais également au niveau des races conditions et autres choses désagréables et parfois difficile à débugger). Sauf que voilà, ceci vient avec un prix ! La copie (qui s'effectue d'abord pour feeder les coeurs puis pour récupérer les résultats) augmente l'usage de la mémoire (bottleneck n°1 à l'heure où j'écris ces lignes), sature les unités de copies mais également les caches (j'ai pas encore vu Rust être capable d'exploiter les instructions NT pour la mémoire).
* Ensuite, il y a du mauvais codes produits lors de l'utilisation des atomiques, notamment Rust utilise des atomiques alors qu'il pourrait se contenter de faire des accès mémoires directement puisqu'il a déjà sécurisé celle-ci. J'ai aussi vu des opérations atomiques très strictes sur ordonnancement des instructions assembleur alors que ce n'était pas nécessaire. Bon je mets ça sur des erreurs de jeunesses.
* La façon de partager les tâches n'est pas du modèle fork-and-join, mais plutôt vol de travail. A la différence du C++ qui peut gérer les deux, Rust se retrouve comme une quiche pour paralléliser efficacement des boucles (plus proprices à du fork-join). Et quand tu utilises du vol de tâches en C++, tu es toujours plus rapide que Rust (mais avec un écart nettement plus faible qu'en fork and join).
* Et pour terminer, Rust ne dispose pas encore de librairies performantes pour beaucoup d'applications scientifique (et ne pourra, de toute façon, pas rivaliser avec du C++ pour certaines tâches pour les raisons ci-dessus en l'état actuel). Quand il les utilise, c'est forcément via binding (et donc on perd l'intêret de Rust à part pour faire de la glue).
Et perso, je trouve ça syntaxe trop AT&T et pas suffisamment propre pour lire naturellement du code, déjà très technique et parfois délicat à comprendre (coucou le F77 )


Dans ma boîte j'ai mené, avec l'aide d'un collègue qui ne jure que par Rust, des benchmarks pour mesurer les perfs. Tu comprendras que je n'ai pas le droit de poster les résultats ici. Par contre, nous nous sommes inspirés de ce papier (même si je le trouve par super en terme de qualité) : Is Rust C++-fast? Benchmarking System Languages on Everyday Routines ainsi que ce document de l'EuroHPC.
Et nous trouvons des conclusions similaires dans nos expérimentations mais pas toujours les même écarts.
La conclusion générale que je partage, car on peut en déduire la même chose en lisant ces papiers et d'autres, c'est que pour faire un code très performants en C++ (en somme le H, de HPC) il faut un dev/ingé C++ expérimenté sur ces questions avec de larges compétences et une très bonne connaissance full-stack entre la µ-arch du CPU, le C++ et l'assembleur produit. Tandis qu'avec Rust, même sans connaissance (mais en étant pas une tanche non plus), tu arrives à être performant (le P de HPC) à condition d'utiliser des libs en C++, parce que beaucoup de libs de calculs HPC de bonnes qualités, éprouvées et de très bonnes perfs en Rust n'existe pas encore.

Et pour finir, ceci n'est valable qu'à cet instant T. Rust est libre d'évoluer pour ce perfectionner dans le HPC mais ça ne sera pas, selon moi, sans devoir faire des sacrifices sur son fonctionnement. Et dès lors, Rust ou C++ ne sera plus qu'une question de goûts et de couleurs. Et comme j'aime taquiné mon collègue syntaxe AT&T vs Intel

Le problème avec Rust est sa communauté qui est trop "social network" dans son fonctionnement et part facilement en live si tu critiques leur langage fétiche. Je suis trop jeune pour ses conneries de vieux jeunes.

Oui la notion de tradeoff est présente, comme toujours. Et d'ailleurs Python se retrouve en HPC, notamment des communautés moins "geeks" (e.g., sciences plus orienté biologie...). J'ai souvenir lors d'une conf en Asie d'avoir retrouvée une amie virologue qui présentait un talk sur la simulation de virus biologique sur ordinateur. Et quand j'ai discuté avec elle, elle me racontait que son équipe est divisée en deux sous-équipes. L'une de virologues (doctorants, post-doc...) qui code en Python et une autre avec un profil plus d'info/math appliquée qui développe les outils mathématiques et numériques pour les premiers.
Mais Rust, j'ai encore du mal à voir l'idée tant (et c'est un avis personnel) je trouve que la courbe d'apprentissage est plus ardu que Python en raison d'une syntaxe assez horrible, pour au final ne pas apporter de vrais avantages (la fuite mémoire ok, mais si c'est uniquement lors de l'initialisation de la matrice (par ex.) c'est pas la peine de se faire chier à compiler pendant 30 ans).

Les fuites mémoires sont catastrophiques en HPC aussi. Pas forcément pour les failles de sécurités (quoi qu'on puisse en discuter car il y a un gap entre le HPC sur un cluster du CEA et celui chez un provider).
Le gros problème des fuites mémoires en HPC selon moi, c'est surtout le risque de corrompre des données, et donc d'affecter les résultats obtenus. Parfois ça saute aux yeux qu'il y a un problème (tiens mes électrons sont plus rapide que la lumière de 231% ) et parfois c'est plus chiant et subtile (#MyLife : Genre un petit dépassement mémoire qui se détecte pas sur le résultat obtenu car le solveur la corrige pour toi au prix d'être x10 fois plus lent... ).

La perte d'un noeud je ne sais pas à l'heure actuelle si ça réagit comme avant. J'ai quitté le domaine depuis un moment.
Mais je me souviens une fois d'un noeud de calculs qui a claqué (en tout cas c'est que j'en ai déduis) car subitement mon calcul a brutalement planté. Les logs de mon code n'ont rien indiqué d'anormal mais par contre celui de la session de calculs m'a poliment dit qu'il ne trouvait plus le noeud (l'IP était injoignable et que la fonction que je demandais ne pouvait pas fonctionner -> crash [Et aussi parce que je n'ai pas prévu ceci dans mon code]).
Maintenant, avec une sorte de convergence qu'on observe entre le monde du HPC et du data-center, je me demande si, avec des softs comme openStack, ce genre d'incident (rare sur une machine entretenue) ne ce gère pas en sous-marin.

Pour l'aspect sécurité, oui il y a des choses de valeurs (codes, résultats) pour des questions de gros sous industriels mais aussi pour des choses plus militaires.
Tu te connectes toujours à un front-end pour préparer tes simulations. Généralement compiler le code, mettre les données, configurer les chemins et soumettre le job aux back-ends (le calculateur en lui-même).
En fonction des endroits, de ta nationalité... tu peux te connecter directement avec la création de ton compte en SSH avec une machine de ton institut (filtrage MAC au niveau du pare-feu) et le front-end n'est pas joignable de l'extérieur ni via le VPN.
Dans d'autres endroits, tu dois montrer patte blanche et surtout, tu ne peux pas déposer ton code sans ce que celui-ci ne soit pas revue par un soft ou un humain pour s'assurer que tu n'as introduit de backdoor ou autres exploits. Et parfois, tu n'as pas même pas le droit de le faire, tu es obligé de passer directement par un intermédiaire (confrère ou sous-traitant) qui s'occupe de tout faire pour toi.
Note que ça devient une tendance d'isoler les simulations (soit à la "docker" ou avec des hyperviseurs de type 1).

Edited: typos + reformulations