Rhea, le processeur européen pour les supercalculateurs n’arrivera que l’année prochaine, en retard de deux ans sur le planning initial. Les soucis n’étaient pas techniques, mais financiers et la levée de fonds effectuée il y a quelques mois dégage l’horizon. La commercialisation du processeur se fera l’année prochaine, nous affirme l’entreprise.
SiPearl est en charge de développer le processeur pour les supercalculateurs exaflopiques européens. En avril, l’entreprise bouclait son premier tour de table avec 90 millions d’euros de financement pour « lancer Rhea, le microprocesseur basse consommation dédié au HPC ».
90 millions d’euros et ce n’est pas fini…
Parmi les investisseurs, on retrouve ARM, un partenaire privilégié puisque SiPearl utilise ses cœurs Neoverse v1 pour construire son processeur. Atos est également présent « au travers de sa branche Eviden composée des activités digital, big data et sécurité », comme le fonds d’investissement European Innovation Council (EIC) ainsi que l’État via via French Tech Souveraineté (dans le cadre du plan France 2030).
« D’autres investisseurs devraient rejoindre le tour de table d’ici la fin de l’année », précisait alors la société. Aujourd’hui, elle nous confirme – lors du FDDay qui se tient en ce moment même à Paris – que c’est toujours d’actualité, sans plus de détails.
Les « embauches étaient un peu bloquées »
Quoi qu’il en soit, cette manne financière de 90 millions d’euros permet déjà « à SiPearl de commercialiser Rhea début 2024 », expliquait l’entreprise il y a quelques mois. C’est en retard sur le planning initial qui prévoyait alors un lancement cette année.
Marie-Anne Garigue (directrice de la communication de la société) nous explique que ce décalage est « lié à notre levée de fonds ». En effet, faute de moyens suffisants, les « embauches étaient un peu bloquées » auparavant. Le problème était uniquement financier et pas technique, nous confirme-t-elle.
Commercialisation en 2024, avec deux ans de retard
Désormais, la commercialisation est prévue pour 2024, « depuis le début du projet, on a pris deux ans » de retard, reconnait-elle. La levée de fonds était vraiment importante pour permettre à SiPearl d’avancer et de communiquer sur une période fiable pour le lancement : « Jusqu’en avril, on n’était pas sûrs des dates ».
Au début de l’année prochaine, SiPearl va lancer la commercialisation de son processeur, qui se fera en deux temps. Une annonce au début de l’année, lorsque « tous les tests auront été faits », puis la commercialisation à proprement parler dans le « courant de l’année ». Il sera alors temps d’étudier les caractéristiques précises de Rhea et de comparer ses performances à celles des autres puces.
Toujours en attente des caractéristiques
Interrogée sur les caractéristiques techniques du processeur, notre interlocutrice nous explique que SiPearl n’a « toujours pas annoncé le nombre de cœurs », mais confirme qu’il n’y a pas de changement sur l’architecture de base qui reste en Arm Neoverse v1 (sans précision sur le nombre de coeurs). Bien évidemment, au moment de la commercialisation, la société « va revenir sur les spécifications et les rendre publiques ». Voici ce que la société pouvait pour le moment nous indiquer :
Le décalage d’un an sera aussi présent sur la prochaine génération de processeur. Au lieu d’arriver en 2024, il faudra attendre 2025 pour la seconde génération de Rhea qui devrait fort logiquement intégrer davantage de cœurs.
Si SiPearl n’est pas bavard sur les caractéristiques techniques de sa puce, d’autres le sont à sa place… à commencer par L’European Processor Initiative (EPI), Fin 2021, le consortium se félicitait de terminer la première phase de son projet « avec la livraison [par SiPearl] de technologies de pointe pour la souveraineté européenne – dans les temps et avec un budget limité, malgré la pandémie –. Elle comprend la définition des spécifications architecturales de Rhea, la 1ère génération du microprocesseur européen et le lancement de son implémentation. Avec 29 cœurs RISC-V, l’architecture Arm Neoverse V1 utilisée par SiPearl pour concevoir Rhea offrira une solution efficace, évolutive et personnalisable pour les applications HPC »
Lors d’une présentation en octobre de l’année dernière (ACAT ou Advanced Computing and Analysis Techniques in Physics Research), Estela Suarez a publié un récapitulatif du processeur Rhea de SiPearl, basé sur des informations officielles et des rumeurs pour certaines :
Commentaires (13)
Quelqu’un sait sous quel OS tourne ce genre de supercalculateur ?
Linux. Plus d’info ici
Le top 10 c’est que du kernel Linux avec une majorité de HPE Cray OS ou de RedHat mais j’ai vu du ubuntu (!) et un truc chinois (https://en.wikipedia.org/wiki/Kylin_(operating_system) qui est un fork d’ubuntu.
Pour le top500 c’est ici : https://www.top500.org/statistics/details/osfam/1/
En gros le kernel Linux a totalement fait disparaitre Unix & FreeBDS.
Franchement, j’ai du mal à voir l’intérêt de Rhea pour du HPC. Vu d’ici ça ressemble juste de l’ARM avec un tampon “Made in France”.
Il y a pas d’innovations majeures pour du HPC. C’est une archi connu mais qui ne vas pas forcément rivaliser avec Genoa. Visiblement Ils n’ont pas fait d’optimisation pour cette architecture en ajoutant des accélérateurs pouvant être utile pour le HPC (fonction transcendente, algèbre linéaire, matrice creuse…). Là il y aurait eu une innovation et sûrement un intérêt, même au delà d’un calculateur exaflop.
On n’a aucune info concernant les supports dans le compilo (donc en déduit qu’ils n’ont rien fait de ce coté).
Pas d’info non plus concernant les perf théoriques attendus, ni sur une éventuelle consommation (parce que là, ARM peut s’avérer intéressant).
Et leur com’ est maladroite. Sérieusement, pourquoi il y a si peu d’infos sur ce processeur quand les grands (Intel & AMD) en font des tonnes (et surement trop) ?
Je comprends bien qu’il faut sortir un produit pour récupérer des fonds et avancer la R&D. Mais là, je vois pas pourquoi un supercalcullateur ExaFlop devrait venir avec ce genre de CPU. Peut-être à être moins chère qu’une solution x86_64.
Si quelqu’un peut m’éclairer…
L’argument principal, c’est “souverain”.
Merci.
Je voyais mal sous quel autre OS ça aurait pu fonctionner.
Je me suis posé la question des compilateurs aussi. Il y a forcément du travail dessus, sinon le calculateur ne sert à rien.
Curieux qu’ils n’aient pas fait du risc V. Car l’architecture dépend des licences d’ARM…
Que veux-tu dire par travail ?
Les processeurs de ces machines (à quelques exceptions près comme Fugaku) sont des x86_64. Les architectures ne diffèrent guère des processeurs classiques (nombres de ports FPU, ISA AVX, FMA, BMI*…). Et ce travail est déjà réalisé par les différentes équipes de compilateurs lors de la sortie des nouvelles architecture.
Eventuellement icc est parfois en avance sur certains points, mais gcc le rattrape très vite.
En pratique, c’est surtout le dev qui va faire la différence. Les solveurs étant ce qu’ils sont, les compilos ne sont pas, à l’heure actuelle, capable d’avoir une vision complète de ton solveur. De fait, les optimisations sont souvent réalisés par les devs pour savoir quand paralléliser une boucle est utile et comment (distribué, partagé, hybride ?) avec toutes les subtilités (lock-free vs barrier, divide and conquer pour merger…). Et je passe sous silence les GPUS et autres accélérateurs.
Pour des machines comme Fukagu, c’est les gars de Fujitsu qui ont en fait le travail de créer (peut-être pas from scratch) le compilateur pour produire un code capable d’exploiter correctement leur processeurs. Mais, c’est du marginal devant l’omniprésence du x86_64.
Les compilateurs que j’ai vu passé pour ces machines sont icc, gcc et clang (sauf pour le fortran). J’ai aussi vu du fasm (de mémoire) et du Python. Je me souviens plus d’un autre compilateur payant et closed-source (pg, peut-être).
De mon expérience, mes confrères et moi-même étions soit sous gcc ou icc. (En vrai, je compilais avec gcc mais je regardais d’abord l’assembleur produit par icc pour comparer ^^).
Et en général, les devs qui étaient à l’aise utiilisé gcc et ce qui étaient moins à l’aise icc. Mais la différence de perfs provenait surtout de la qualité des devs à avoir su optimisé leur code pas des options passées au compilo.
En revanche, là où tu as du travail, c’est les libraires. Celle qui me vient immédiatement en tête c’est LINPACK et BLAS, très célèbres bibliothèques pour l’algèbre linéaire (et très utilisé dans les solveurs). Elles sont le fruit de nombreuses optimisations pour arriver à des perfs acceptables et profitent d’une expérience très longues. Parfois, les centres de calculs (voir les devs) ont leur propre version optimisé par leur soin. Je sais qu’il existe une autre librairie que j’ai massivement utilisé car elle était mieux optimisée que ces deux là, mais là je me souviens plus du nom. Faudrait que je recherche dans mes notes poussiéreuses.
PS : Les devs, c’est des chercheurs, ingénieurs de recherches, post-doc, doctorants, étudiants qui ont plus ou moins d’appétence à coder.
PGI peut-être ? Il a été racheté par NVIDIA et est devenu le compilateur inclus dans leur HPC SDK.
Intel MKL ? L’implémentation très optimisée d’Intel de BLAS/LAPACK.
Yep ! C’était lui. Merci.
J’ai oublié la MKL, diantre c’est vrai. Je pensais plus (ça m’est revenue) à openblas.
Risc V, on y viendra sans doute. Mais à l’heure actuelle, c’est encore balbutiant.
Pas d’architecture performante pour le moment. Ne pas confondre ISA et architecture. RISC v en est au point du powerpc début des année 90. Et peu de réalisations dans le cadre du calcul - on a plus de concepts sur de l’informatique embarquée pour le moment avec cette techno