Le 21/07/2024 à 10h 48

Si Rust n'arrive à intégrer le noyau, alors il aurait perdu l'une de ses plus grandes cibles "promotionnels". Rust a débarqué en voulant prendre la place du C alors qu'il n'est pas un concurrent du C, fondamentalement. Rust est plus un concurrent d'Ada.
Oui qu'il est débarqué dans le noyau Linux même timidement, c'est bien. Mais faire un wrapper en Rust de fonctions critiques n'apporte rien de vraiment intéressant. Et pour le moment, on ne l'a pas vu véritablement attaqué des choses fondamentalement sensibles dans le kernel avec tout la problématique de gestions de mémoires qui va avec ou de gestions d'interruption ou autres.

Si je devais parier, je dirais que Rust ne rentrera jamais dans le coeur du noyau. Il est trop restrictif by- design pour faire des choses efficaces en terme de perf pour un kernel monolithique.
Par contre, pour les drivers il pourrait avoir un atout à jouer. Mais vu le niveau de qualité des drivers sous Linux (en comparaison de Windows), si Rust devait avoir une utilité réelle ça serait d'être imposé par M$ aux constructeurs et fournisseurs de matériel pour les machines livrées avec Windaube.
Parce que le BSOD à cause d'un driver pissé à l'arrache, j'en ai jamais vu sous Linux (sauf quand j'en suis la responsable... Mais ça c'est une autre histoire).


Je ne sais pas ce que tu nommes délires en c++, mais si un dev ne comprends pas ce qui se passe en C++ dans la machine, il ferait mieux d'aller coder en Python. Idem pour celui qui code en Rust ou en C. Quand on est proche de la machine on se doit savoir comment ça marche, à minima.

Le 20/07/2024 à 21h 35

"C'est même pas le côté promotionnel. C'est juste que Rust n'aura alors AUCUN intérêt a être utilisé au sein du noyau. Pire, on se retrouvera avec des portions écrites en Rust, d'autre en C. 2 langages au lieu d'un, sans avantage. Chouette :/"

Je ne pense pas. Rust n'ayant pas "contaminé" beaucoup le noyau, je suis prête à parier que Linus et ses équipes feront le ménage. Au final ça ne restera qu'une expérimentation dans la mémoire du depot git pour les cyber-archéologues.

"J'avais regardé rapidement, j'ai vu un Rust like, la notoriété en moins (sans vouloir dénigrer le langage)"

De ce que j'ai vu Zig est plus un sérieux concurrent à C. Là où Rust a échoué, Zig pourrait être technologiquement un véritable concurrent du C, voir son futur. Affaire à suivre.

Le 20/07/2024 à 17h 49

Rust est dans le noyau et il peut-être utilisé. Certains drivers pour des FS ou bien pour le scheduler l'utilse. Mais très généralement ce n'est qu'un wrapper sur les fonctions importantes du kernel.

Pour moi, Rust n'a pas le choix de devoir résoudre ce problème. S'il ne peut pas s'intégrer au noyau Linux (autrement qu'en étant un wrapper), alors perdra un certains coté promotionnel. Mais oui ce n'est pas gagné pour eux.

Exact ZigBee n'est pas le langage. C'est Zig que je voulais mentionner. My bad, il fait trop chaud dans ce pays, con !

Le 20/07/2024 à 17h 33

Même si je n'aime pas ce langage, je pense que Rust est une réponse possible. Et peut-être prochainement ZigBee.

Le 20/07/2024 à 10h 10

Merci pour les infos.

Je regrette aussi l'absence de la fonction MP. C'est tellement pratique pour ce genre de cas.
Un moyen de communication privé, sans le partager à tout le monde c'est un peu chaud.

Mon pote bosse à l'observation de Nançay. C'est tout ce que je peux partager publiquement.

Le 18/07/2024 à 13h 53

Très belle performance ! ça fait plaisir à lire.

Puis-je me permettre de demander, pourquoi ne pas déporter ce genre de calculs sur GPU ?
Je demande ça car j'ai un pote qui fait du beamforming numérique pour l'étude d'objets astrophysiques et il balance tout sur GPU. Est-ce que le cas que tu décris, la latence lié au PCI serait un frein ?

Le 17/07/2024 à 22h 01

Tout dépend des calculs que tu fais. Pour en profiter pleinement, faut-il aussi que les codes de calculs soient correctement écris pour pouvoir saturer les FPU et les pipelines pour les maintenir constamment en activité. En dehors du monde du HPC, je n'ai vu aucun code (même industriel) être capable d'exploiter à fond ce genre de choses.

En outre, les calculs a qui ce genre d'optimisations s'appliquent (e.g., produits scalaire, calcul matricielle) sont pas nature limités par la bande passante mémoire que par le CPU.

Par contre, le point positif que je vois en dehors de ces cas particuliers qui peuvent atteindre le max de FLOPS, c'est que le processeur logique pourra les utiliser pour d'autres calculs en //. Et ça, ça peut devenir interessant.

Le 17/07/2024 à 19h 10

On passe à 6*16 float32., donc 96 flopc (floating operation per clock) pour chaque coeur physique du processeur.

Le 18/07/2024 à 12h 18

Je ne souhaite pas lancer un débat Linux/Windows, qu'importe les saveurs que l'on met derrière mais je veux pas non plus me laisser sans défense.

Pour moi, Windows n'a pas sa place. Il n'est pas stable (je connais pas un PC Windows qui ne doit pas rebooter au bout 3 semaines, ni qui maintient des perfs constantes dans le temps d'utilisation...). Sa seule stabilité, c'est sa rétro-compatibilité et son ABI & API. Mais c'est une force comme une faiblesse. Celà dit je concède que je me suis déjà écharpé avec Linux sur ce point.

La documentation est inférieure à celle de Linux. Exemple, tu cherches la doc pour mmap. J'ai besoin de parcourir plusieurs sous-liens pour trouver l'information de savoir si c'est du COW ou pas. Linux, un simple Ctrl-F et j'ai mon info. Et mieux, j'ai le code source pour répondre à mes interrogations.
En revanche, elle est accessible. Le ticket d'entrée pour la doc de Windows est nettement inférieure à celle de Linux.

Windows n'est pas sécure. Désolé mais le principe de kerckhoffs est pour moi strictement requis pour avoir confiance sinon c'est de la sécurité par obscurantisme. Et nous savons que c'est un échec.

Je pourrais aussi te parler des faibles performances du NTFS et du scheduler I/O du kernel. Pour un OS 2024 d'entreprise c'est assez risible. Ce qui le sauve, c'est la latance des SSD.
La question se pose également pour les autres schedulers et la capacité de Windows à gérer correctement du multiprocessing.

Je termine sur ceci. Windows sera un vrai OS quand il pourra gérer un supercalculateur du top-500. A defaut, pouvoir être aussi rapide qu'un Linux sur un benchmark du LINPACK. Même à code équivalent en asm, Windows reste significativement derrière (sur nos benchmark, ~10-15 % derrière du Linux [Fedora Workstation]).

Le 17/07/2024 à 19h 17

Je rajouterais, tu veux quand même pas demander à MS de faire un vrai OS par hasard. Un truc qui marche correctement (par rapport à un Linux) et pas une daube sans nom.

Le 19/06/2024 à 19h 25

La boîte est Mellanox et ça concerne toute l'infrastructure réseau (switch, cables, adaptateurs...). Couplé avec ces compétences, Nvidia en fait des DPU sorte de CPU dédiés aux réseaux pour les data-centers et supercalculateurs.

Le 16/06/2024 à 09h 55

Je suis pas super d'accord avec la slide sur l'histoire du neurone. La sortie d'un neurone ce n'est pas plutôt les synapses ?
L'axone ne sert qu'à transmettre l'information électrique, mais c'est à la synapse que ce fait la conversion électrique chimique.

Où alors j'ai manqué quelque chose...

Le 16/05/2024 à 13h 16

Je ne sais pas si ce qui va suivre peut répondre à ton besoin.
Sur smartphone (Android en pour ma part), il y a les applications CPU-L & GPU-L qui résument les caractéristiques de chaque puce.

A titre perso, je regarde même plus l'Intel Ark car il n'est pas aussi complet.

Le 16/05/2024 à 11h 03

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

Le 15/05/2024 à 10h 18

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 14/05/2024 à 18h 44

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 09/05/2024 à 09h 53

Reste à définir ce que tu entends par "expertise humaine". Oui, pour des problèmes simples et sans contraintes particulières (aide à un script de configuration Docker, petite question de code trivial ou recherche d'une info dans une doc en ultra rapide), les LLM sont redoutables.

Par contre, dès qu'on touche à des trucs plus techniques (POO, métaprogrammation, réflexion algorithme [dernièrement j'ai testé avec un collègue Quadtree vs Kd-tree sur deux LLM], optimisations), clairement l'expertise humaine a toujours l'avantage.

Je pense que, la vague de bullshit passé, les LLM assisteront les humains dans certaines tâches dev... Si entre temps ont apprends à faire des apprentissages qui ne nécessite pas 10 tranches de réacteurs nucléaires.

Le 25/04/2024 à 18h 49

Une application peut demander recourir à des pages plus grandes sur l'x86_64 tel que 2 MiB et 1GiB par exemple. Évidemment l'OS doit pouvoir gérer ces situations.
Sous Linux : Huge Page.

En pratique, quand j'ai besoin, j'utilise mmap et madvise. L'intêret est de ces grandes pages est de pouvoir réduire la pression sur le TLB, un cache mémoire en charge de faire le lien entre mémoire virtuelle et physique. Pour certaines applications (notamment BDD, traitement de fichiers de grands volumes ou encore calculs), ce genre d'optimisations permet d'améliorer les performances de, facilement, quelques dizaine de pourcents comme indiqué par @Wosgien.

Le 22/04/2024 à 18h 57

En vrai ? Enormément de boîtes même les sensibles. Quid des managers qui échangent via What's App ? Des consultants qui parlent avec leur collègue ou demande un avis sur ses canaux ? Qui des externes qui parlent entre-eux ? Veux-tu que je te parle des militaires aussi ?
Car oui, si What's App n'est pas censé être autorisé pour des raisons de sécurité, en pratique très peu de gens respectent cette règle car c'est plus rapide et efficace qu'un email pour échanger rapidement de l'information (voir échanger de l'info sensible car MS, Office et NSA...)

Bref, oui il y aurait des dommages collatéraux via l'espionnage économique. Alors certes les ricains le font déjà avec MS, mais qudi si les Chinois, les Russes, Les coréens... et j'en passe le font parce qu'on aura remplacer le chiffrement de bout en bout par du 3DES (ok, j'exagère mais l'idée est là). L'impact économique sera là. Vicieux, mais bien présent. Après suffira-t-il pour faire bouger les lignes ? Je ne sais pas.

Le 22/04/2024 à 18h 34

Même si une tel loi venait à passer, il y aurait un sacré méli-mélo avec d'autres textes sur la sécurisation. Donc, rien de nouveaux pour nos politiques qui sont dépassées par les nouvelles technologies (et je soupçonne aussi leurs conseillers). Le seul point bon pour eux, c'est que ce genre de sujet n’intéresse pas grand monde, donc mis à part les gens qui s'en soucie ça ne fera pas grand bruits sur les mass medias.

Pour le particulier, rappelons nous qu'une très grande majorité de la population sont des Michus (y compris des gens qui bossent dans l'IT). Donc pas de changement pour eux. Pour la minorité de geek, cypherpunks et co, des applications utilisant du chiffrement feront rapidement leur apparition avec la quasi-impossibilité pour le gouvernement français d'empêcher son installation (contournement DNS, APK...).

En fait, le seul truc drôle serait que ça passe, que l'affaiblissement se fasse (backdoor ou autres) est que des conséquences économiques se fassent sentir très rapidement.
Je suis sur que si ces inepties touchent concrètement aux portes-feuilles, ils légiféreront immédiatement pour ne jamais le refaire. Et ces discours de charlants (car oui, c'est du même niveau que Didier) disparaîtront une bonne fois pour toute.

Le 22/04/2024 à 18h 43

J'exclue MS car sinon c'est pas fair-play de ma part.

Pour Linux, Rust est critiqué un peu en ce moment : https://lwn.net/Articles/967049/
Disons que c'est des erreurs de jeunesses.

Autant Rust a des atouts sur le C++, autant le vendre comme un argument marketing en fait un outil détestable. Car certains pensent que tout peut se faire en Rust et que Rust surpasse le C++. Encore faudrait-il y mettre une métrique.

Chose assez rigolote au passage, beaucoup de dev qui critique le C++ sur sa sécurité code en vieux "C++" et visiblement semble oublié que le C++ a évolué et que, la manipulation de pointeurs brutes est vu maintenant comme une erreur de design.

Bref, Rust a du sens dans le noyau Linux. Mais pour le moment Rust fait du binding et du wrapping que de réels avancées sur le noyau. Et pour une raison : Son modèle mémoire est une plaie pour des tâches parallèles.

Le 28/03/2024 à 17h 09

A voir si la conso est identique.

Le 25/03/2024 à 11h 33

Les pages de 4k peuvent être pénibles pour certaines tâches, mais tu omets qu'il y a maintenant (et même depuis un certains temps) la possibilité d'utiliser des pages de 2M voir 1G. Alors c'est pas forcément la panacé car ça augmente la pression sur les niveaux supérieurs du TLB mais ça marche bien voir très bien pour les scénarios que tu décris.

Pour du calcul matriciel si la taille des pages aide, il ne faut pas omettre que ça reste aussi et avant tout des problèmes de bande passante. La RAM n'arrive toujours pas nourrir suffisamment vite le CPU. Mais je te rejoins que mettre fin la vieillerie de l'x86 pour partir sur des bases plus modernes seraient bénéfique.

En revanche je me demande dans quelle mesure ce type de CPU pourra être disponible sur des PC Linux. Qualcomm n'étant pas une boîte ouverte pour ses datasheets, alors pour des puces aussi complexes que des CPU à destination de l'open-source, je doute un peu de voir du Linux dessus.

Le 21/03/2024 à 21h 21

Possiblement ou bien il ne transpose pas l'intégralité de la matrice. Peut-être une simple copie d'une colonne vers ligne.

Je vais réessayer de reproduire le code dont je parle pour le DP. Si j'y arrive, je te MP.

Concernant le code que tu montres, je peux au mieux te donner deux pistes à explorer:
1. Les conditions dans la boucle for, c'est une mauvais pour les GPU. Ces petites bêtes ne sont pas très bien équipées pour ce qui touche à l’exécution spéculative. L'écrire de manière "branchless" serait plus pratique pour le GPU et plus dans son fonctionnement (SIMD).

2. A la ligne 54, tu as des accès non-contigüe entre tes deux matrices sa & sb. Le GPU n'est pas super friand de ça (encore une fois en raison de sa façon de fonctionner). Note que le même problème existe avec les CPU.

Le 21/03/2024 à 11h 38

En utilisant un bête produit scalaire entre deux vecteurs sur un kernel fait main, et non en utilisant les fonctions dédiées. Le kernel fait main te permet de régler plus finement la saturation des unités FMA. Tu peux le vérifier à la fois avec l'assembleur produit par le compilateur du GPU et le résultat que tu obtiens en terme de FLOPS.

La multiplication de matrice peut difficilement atteindre les perfs max. à cause du besoin de transposition d'une des matrices pour le produit, et d'accès mémoires plus coûteux. C'est pourquoi je préfère bêtement faire un produit scalaire sur des vecteurs à n-dimensions car, en dehors du chargement mémoire (mais le prefetcher sont redoutables), le FLOPS est uniquement du FMA. Mais je maintiens qu'il ne s'agit que d'un test pour vérifier les perfs annoncés par le constructeur. En pratique, ce test ne représente pas la réalité ou l'usage commun (éventuellement en IA mais j'en doute).

Les algos de FFT sont plus basées sur de la permutation de lanes SIMD que du FMA. La mesure en FLOPS est moins pertinente pour ces algorithmes, mais pas dénué d’intérêt.

LINPACK mesure les perfs sur un type de calculs très commun dans les milieux scientifiques et industrielles ( de mémoire, c'est de l'inversion de matrice dense). Le but de LINPACK est d'être représentatif des calculs les plus utilisées, pas de chercher à atteindre les perf max. vendus par le constructeur. C'est plutôt le rôle de ce "bête" benchmark c = vec{a} \dot \vec{b} de vérifier ceci.

Le 20/03/2024 à 21h 56

Je sais pas si ça peut répondre à ta question pour du split-step (résolution d'EDP par des méthodes pseudo-spectrales ?).

Pour ma part quand je dois faire cette exercice, je mesure les FLOPS de mon code et je calcule le FLOPS_de_mon_code/FLOPS_theorique, ayant pris soin de vérifier que j'arrive à retrouver les FLOPS_theoriques (typiquement, je trouve ~99% des perfs théoriques). De là, je me sers de ce ratio pour le multiplier par les perfs théoriques du constructeur pour un autre modèle pour estimer les FLOPS que je vais disposer pour mon code, et de la estimer le temps.

Ce n'est pas parfait comme méthode. Elle a des limitations et fait des hypothèses mais en pratique, l'ordre de grandeur est correct.

Pour l'aspect mémoire (quand la limitation est plus memory bound), j'utilise le throughput (GB/s) dont je calcule un ratio par rapport aux perfs théoriques. Les limitations sont les même qu'au-dessous. A noter, qu'avec la mémoire, l'ordre de grandeur est parfois moins fiable qu'avec le FLOP.

Mes deux cents.

Le 20/03/2024 à 21h 58

On parle d'accélérateur assez couramment pour désigner ce genre de puce.

Le 15/03/2024 à 21h 15

Est-ce que le système de paiement inclut une vérification du compte bancaire ? Sinon, il suffirait de générer un faux (mais valable) numéro de CB

Le 14/03/2024 à 21h 04

Il ne faut pas oublier qu'il y a eu la pandémie de sras-cov 2 avec les retards que cela a engendré sur la production de semi-conducteur. SiPearl étant une petite boîte devant des clients comme Nvidia ou AMD pour TMSC, il est probable que la production de leur CPU a été impactée.
Après, je suis biaisée car je viens originellement du spatial académique. Et dans ce genre de milieu, les retards sont monnaies courantes et tout le monde le sait (surtout les indus d'ailleurs mais c'est pas le sujet ici.)


Oui la puce sera dépassée. D'après ce que je sais en lisant par ici ou par là, les Neoverse v3 supportera le PCIe 6 et la DDR5 et disposera de plus de coeurs (>100 de mémoires, mais à confirmer).
Mais même si la puce est dépassée, elle sera encore utile.
D'une certaine façon, les supercalculateurs suivent la même loi que les machines de monsieur et madame tout le monde. Quand tu achètes ton supercalculateur ou ta tour, tu sais parfaitement que dans 1 ou 2 ans les nouveaux procs seront légèrement plus performant (~ qq %). Ce n'est pas pourtant que les machines sont changées.


Merci pour tes précisions sur le placement des commentaires. J'ai encore un peu de mal avec le nouveau fonctionnement, même si je le trouve meilleur.

Le 13/03/2024 à 21h 30

Edited: Ce message s'adresse à @fred2vienne, mais j'ai raté la mise à page comme une noob :(


Exact, nous n'avons jamais été leader mais pas non plus à les derniers. A l'exception de la fabrication et la conception de CPU (ou autres [GPU, FPGA]...) pour le monde des supercalculateurs, la France n'est pas en reste des US, Japonais ou Chinois (bon le dernier est sujet à discussion, mais passons).
Nous sommes presque souverains sur ce point via Eviden.

Oui on rentre dans le game, et surtout sans volonté politique française ni européenne en la matière (je parle d'une vrai volonté politique pas de bullshit marketo-GPT policienne). Et on pars de loin. Voir des boîtes se jeter dans l'aventure est à saluer !

Évidemment que dès le 1er round ils ne vont rien révolutionner, mais même une contribution mineur (par exemple un processeur ARM avec plus d'unités flottantes en pipeline à la façon des puces Apple Silicon et des librairies de calculs [e.g., LAPACK] recompiler/programmer pour exploiter cette modification) auraient été un bien meilleur signe, même si c'est mineur encore une fois mineur (mais mesurable, par exemple avec un simple bench de produit scalaire saturant les pipelines).

Pourquoi ça aurait bien ? Parce que c'est de la technique, que c'est pas anodin à réaliser et qu'on peut faire de la vrai com' touchant aussi bien les investisseurs que les geeks (évidemment pas avec le même discours).

Mais le hic, c'est que SiPearl n'est pas vendeur dans les journaux grand publiques. Par conséquent, c'est le monde de la tech et des geeks, nerds qui vont être au courant. Et pas de bol, c'est aussi un public exigeant et qui préfère lire un graphique de benchmark pour en parler (et comparer) que de se nourrir d'une vide (plus que quantique) d'une com' à la chatGPT plus digeste pour les chaînes d'informations.


La puce en action ? Mais je n'attends que ça pardi ! J'attends que ça que SiPearl me sorte un petit bench sur un pauvre produit scalaire en 64-bits flottants avec les unités SVE pour voir ce qu'elle a dans le ventre. Je me dessèche les yeux devant l'absence de données sur le ratio FLOPS/W, sur la température des coeurs, la gestion du budget thermique, le scaling des fréquences, le détails de la µarch...
Mais, et sauf erreur de ma part, on connaît même pas le nombres de coeur ni la version PCI-E supportée....

Tu penses pas qu'il y a un problème quand même pour un proc de 2020 dont on a manifestement aucune infos et aucunes innovations pour le HPC (même mineur) et qui semble être juste un néoverse d'ARM avec un tampon "Made in France, BPI France approved" ?

Quand à la question de qui sommes-nous pour juger ? Et bien, nous sommes citoyens qui contribuent indirectement à cette boîte comme le rappel @fred42 ci-dessus et aussi des lecteurs de Next (c'est peut-être ça le pire ^^).

Le seul point où je suis en désaccord avec fred42, c'est pour les 2 ans de retards. Je trouve ça pas si grave au vu de ce que SiPearl fait. Mais je lui concède que la pilule passerait mieux s'il y avait de l'innovation.

Le 13/03/2024 à 21h 03

Oui la critique est rude. Une critique moins rude est plus informative sur le précédent article de Vincent : https://next.ink/840/supercalculateurs-exascale-europeens-sipearl-nous-confirme-commercialisation-rhea-en-2024/

(Désolé pour le copier-coller, la balise lien n'a pas l'air de fonctionner).

Quand à m'y voir à leur place, s'ils proposent un poste intéressant je veux bien postuler.

Le 13/03/2024 à 13h 21

En effet SiPearl n'a rien d'innovant. Ils ne font juste que prendre un CPU Neoverse (comme on s'en doutait lors du dernier article de Vincent) et mettre un tampon "Start-up Nation, Made in France".

Sur le plan technique, ils n'ont rien innové, ni ajouté comme pierre à l'édifice pour répondre aux enjeux des supercalculateurs. Alors, que même avec un CPU il y a matière.

L'absence de communication autour d'un compilateur (back-end surtout) montre qu'ils ne vont rien innover sur ce plan.
Également, l'absence de benchmark pour vanter leur processeur va dans ce sens, tout comme l'absence de mention à un nouveau design (par exemple favoriser certains circuits par rapport à d'autres) ou bien d'innovation utile aux HPC (e.g., unité vectorielle pouvant gérer des données éparses).

Et je ne pense pas que Rhea2 ou 3 changeront la donne. D'ailleurs sait-on dans quelle partie du supercalculateur ces processeurs devront se trouver ? Encore une question qui en dit long.

Le 05/03/2024 à 10h 03

Sans dépend des mondes. Dans l'industrie, tu trouves encore des vieux codes datant de cette époque. Maintenant, avec les logiciels comme Matlab et la tendance à faire du C++/Rust non Fortran n'est plus vraiment utilisé car, pour les managers (même ceux avec soit disant des diplômes d'ingé), Fortran c'est has-been.

J'ai un client qui a préféré voir sa facture être multiplié par 3 parce qu'il a préféré une lib écrite en C++ qu'en Fortran pour du calcul d'algèbre linéaire. Alors qu'à la fin il ne fait qu'un appel à cette lib (donc il s'en fiche de la techno tant que l'ABI est stable). Mais dans sa tête Fortran sentait les cartes perforées...

Dans le milieu académique, on trouve encore du Fortran (qui plus est sous sa forme moderne). Même si les doctorants ne l’apprennent plus en cours, en général ils deviennent accros une fois qu'ils ont compris que, pour des problèmes s'exprimant avec l'algèbre linéaire, Fortran est génial. J'ai souvenir d'un étudiant de M2 qui ne jurait que par le C++. Et puis, lorsqu'il a découvert Fortran pour ses calculs de mécaniques quantiques en thèse, il a vite changer son fusil d'épaule.

Le 05/03/2024 à 09h 57

ça dépend. As-tu déjà essayé de faire des R-tree avec Fortran ? Si oui, tu sais alors que C/C++ (ou autres) sont plus appropriés tant pour le confort d'écriture que la possibilité d'optimiser plus finement le code.

OpenMP n'est pas compatible avec Rust nativement en raison de son modèle mémoire. MPI aurait un sens, mais il est souvent implémenté en C. Je ne vois dès lors peu l’intérêt de l'adjoindre à Rust. Un MPI en Rust (je ne sais pas si ça existe) aurait dès lors plus un sens. Mais bon, faire une réduction en Rust avec son modèle mémoire sur un supercalculateur, faut avoir de l'argent à perdre.

Le 04/03/2024 à 13h 18

80% dans l'industrie ?! Sérieux tu as le chance d'avoir ce genre de perfs. Je constate, pour ma part, des codes perfs de l'ordre de 40 % max. des capacités de calculs d'un processeur par rapport à un code optimisé. Et ceux même avec des logiciels de calculs d'ingé spécialisé.

Après de quelle industrie parle-t-on aussi. Perso, les contrats qu'on me file à exécuter en ce moment, c'est des grands groupes qui ont besoin de ré-optimiser des codes mal écrits ou mal fichus et soit disant vendu pour être performant.

Le 04/03/2024 à 13h 15

Oui et non. Oui quand tu fais du code série, la différence étant la capacité du dev à utiliser correctement le compilateur, chose que Rust ne laisse pas trop faire et dans certains scénarios de de type calculs haute-performances, C peut très légèrement battre Rust.

En revanche en code parallèles (type calculs scientifiques/ingé), Rust est jusqu'à x10 (d'après mon expérience) que du C/C++. Non pas en raison du compilateur mais du modèle mémoire qui n'est pas fait pour des tâches de type fork-join de manière efficace.

Le 28/02/2024 à 11h 08

Mais comme il était sous Windows, ça ne va pas être difficile de cracker la clé de chiffrement (Bitlocker c'est du SHA et de l'AES, rien d'insurmontable pour des GPUs).

Autant considérer que les infos sont connus de l'ennemi. La question étant qui est le voleur ? Vol d'opportunité (revente de PC...) ? Espionnage ?

Le 16/11/2023 à 21h 06

Je ne pense pas que Musk va faire quoi que ce soit. Donc il serait peut-être temps que l’UE montre ses crocs et éclate proprement (mais légalement) X au lieu de faire des contorsions et en demandant gentiment d’appliquer le DSA.

Les US ne nous font pas de cadeaux. Inutile de tortiller du fion pour Musk comme me le laisse penser Breton. Mais bon, quand il s’agit de faire du ChatControl contre la population UE c’est les premiers, par contre remettre les pendules à l’heure de certains, visiblement ça traîne.

Le 10/11/2023 à 09h 39

Je pense que ton soucis vient de matériel qui est conçu avec les pieds.
Le fils d’un collègue (étudiant) s’est racheté un Lenovo suite à une noyade de son précédent PC dans de la vodka à l’orange.

Et après avoir installé une distro dessus, ce fut la merde. L’analyse des logs du kernel a mis en évidence un problème dans l’ACPI. Une petite recherche sur Internet sur le git du kernel a permis d’apprendre que Lenovo a fait de la merde sur un certains nombres de modèles en mélangeant du legacy ACPI avec des trucs plus modernes.

Le rapport ? Comme Lenovo vend du Windows, ils ont bien évident testé avec Windows et fait toute les modifs nécessaires (de façon certainement crade) pour que Windows fonctionne. En revanche, Linux n’ayant pas eu la chance de connaître ce traitement, c’est plus olé-olé. Et c’est récemment une mise à jour du kernel qui lui a permis d’avoir un PC qui fonctionne car les petits gars du kernel ont fixé cette merde de conception de Lenovo. Et pour info, tu retrouves la même chose chez Dell ou HP en fonction de la gamme de leur produit.

Donc, je t’invite à jeter un oeil tes kernel logs pour voir le soucis.

PS : Utilisatrice pro d’une Arch avec 3 GPUs (2 Nvidia & 1 AMD) sur la même machine avec un kernel custom. Impatiente de voir Windows faire ça

sebsauvage a dit:

Si quelqu’un vient vous dire “Mais Windows c’est plus professionnel”, vous pouvez lui rire au nez.

Tant que Windows sera incapable de tourner aussi efficace qu’une distro Linux sous Desktop et pire, de faire tourner correctement un super-calculateur du Top500, Windows ne restera qu’un cancer adulé par les sous-développés de grandes écoles de commerces à la noix. Mais comme dit le dicton : “Les geeks prendront un jour le pouvoir, mais d’abord j’ai un raid sous WoW à finir “

Le 25/10/2023 à 17h 19

fred42 a dit:

Pourquoi faire un truc comme ça alors qu’il maîtrise l’accès au contenu en clair par Chrome ?

Que veux-tu dire ? Si j’utilise Chrome pour faire mes impôts, Chrome envoie à Google mes informations fiscales dans mon dos ?

S’il forgeait des certificats illégaux avec son autorité de certification, elle ne vaudrait plus rien et serait blacklistée par les autres navigateurs. Ça lui laisserait l’essentiel des utilisateurs avec Chrome, mais pas sûr qu’avec un tel scandale, Chrome serait autant utilisé.

Ah oui, j’oubliais : c’est quoi pour toi un chiffrement de bout en bout pour naviguer sur le WEB ? Le TLS est déjà un chiffrement de bout en bout (quand il y a chiffrement). Je rappelle qu’un des bout est le serveur WEB et l’autre le navigateur.

Un chiffrement qui résisterait à un MiTM ou du moins le rendrait caduque. Aujourd’hui, si je fais un MiTM propre (certificat de confiance ….), je peux voir ce qui se passe quand Alice interroge sa banque car Alice négocie sa connexion avec moi, puis moi avec la banque. L’idée du chiffrement de bout en bout WEB tel que j’imagine est que même si je fais un MiTM, il soit impossible pour moi de voir ce qu’Alice a écrit.

En vrai je ne sais pas comment le faire, ni même si c’est possible à l’heure actuelle. Mais ce genre de pratique, ça me parait pas déconnant de passer à un niveau supérieur pour la protection de sa navigation. Surtout si Google commence à abuser un peu de sa position hégémonique (par exemple, avec un site des impots uniquement compatible avec lui).

Le 25/10/2023 à 13h 48

J’aimerais comprendre un truc.

Si Google met des proxies en place. Est-ce qu’il serait en mesure de faire du MiTM de façon parfaite car il est une autorité de certification. Ce qui signifierait que : 1. le HTTPS ne sert plus à rien pour Google et qu’il peut lire l’intégralité des échanges (c’est la NSA qui va être contente). 2. Que le The Great US Firewall serait en place. 3. Que les idées stupides de certains politiciens de tout bords et pays sur la censure et le flicage de leur population seront possibles.

Au final, il faudrait procéder à du chiffrement de bout en bout pour naviguer sur le Web. J’ai bon ou pas ?

Le 12/10/2023 à 07h 52

tazvld a dit:

Quand je vois qu’un collègue a déjà des problèmes avec des bibliothèques de base de python (multiprocessing) sur ces nouveaux macs, j’ose imaginer le bordel sur des trucs un peu plus tatillon.

Multiprocessing est embêtant sous Mac et Windows. Pour Mac, il suffit de changer d’indiquer la méthode de création des processus enfants avec la méthode set_start_method de la lib multiprocesisng.

Pour Windows, ça doit marcher aussi. Mais on ne travaille bien qu’avec les bons outils

Le 07/10/2023 à 11h 59

L’H2 n’est pas fait pour un véhicule automobile. Il y a énormément de problèmes avec cette petite molécule.

D’abord tu as le stockage qui est un défi en soi (disclaimer, je bosse en ce moment sur la modélisation des fuites de H2 à l’échelle moléculaire) et le H2 tend à se barrer assez facilement.
Son utilisation pour les véhicules nécessite de le compresser et de le stocker avec tout les problèmes d’inflammabilité et d’explosivité. Le H2 c’est safe soit qu’en c’est en très petite quantité, soit quand il n’y a presque de lui. Imagine un carambolage de véhicule en H2 sur une autoroute.
Ensuite, la combustion du H2 produit une flamme très chaude mais aussi invisible. J’attends avec impatience les véhicules qui vont se faire incendier lors des manifestations avec du H2. Déjà qu’avec l’électrique c’est très impressionnant et toxique, le H2 ça va être pire.

Au niveau de la motorisation, le H2 se dilue assez mal dans les chambres à combustion. Je pense que ça va se résoudre, mais on ne sera pas avec l’efficacité d’un moteur à combustion classique. Et puis, l’H2 tend à former des “poches” lors de son mélange et qui lors de la combustion vont créer des points très chauds au sein de la chambre, avec du stress thermique potentiellement plus important pour les pièces mécaniques.

Et surtout personne ne parle de l’impact de l’eau rejeté par les moteurs. Quid en hiver des routes verglacées ? Quid en été des villes se trouvant sous une couche d’inversion avec toute l’humidité qui va augmenter l’impact des sensations de chaleurs ? Quid de l’émission massive d’eau dans l’atmosphère terrestre sur les précipitations et donc la distribution des précipitations sur des zones urbanisées par des porcs ?

Bref le H2 n’existe uniquement que parce qu’il permet au constructeur de ne pas fermer tout de suite leur usine, de rassurer les actionnaires et l’Etat. Mais ce n’est qu’un pansement de bobologie sur une carotide tranchée.

Le 22/09/2023 à 10h 24

underground78 a dit:

PGI peut-être ? Il a été racheté par NVIDIA et est devenu le compilateur inclus dans leur HPC SDK.

Yep ! C’était lui. Merci.

underground78 a dit:

Intel MKL ? L’implémentation très optimisée d’Intel de BLAS/LAPACK.

J’ai oublié la MKL, diantre c’est vrai. Je pensais plus (ça m’est revenue) à openblas.

Le 22/09/2023 à 07h 27

OlivierJ a dit:

Je me suis posé la question des compilateurs aussi. Il y a forcément du travail dessus, sinon le calculateur ne sert à rien.

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.

Le 21/09/2023 à 07h 38

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…

Le 20/09/2023 à 19h 50

Linux. Plus d’info ici

Le 15/09/2023 à 13h 40

carbier a dit:

Il y a quelques années, je me suis rapproché d’une structure universitaire qui avait monté un calculateur à partir de financements de l’état et de la région. Nous avons pu l’utiliser pour des besoins ponctuels mais ce n’était absolument pas gratuit.

Sauf erreur de ma part, je ne vois pas où j’ai écris que l’utilisation d’un supercalculateur était gratuite pour l’académique ? Si ma tournure de phrase le laisse sous-entendre, j’en suis navré de ne pas avoir noté ce point pour la changer. Mais nous sommes d’accord c’est payant même pour l’académique.

D’ou tu sors que l’accès à l’utilisation d’un supercalculateur serait gratuit ? En quoi le fait d’ouvrir x% de ses capacités au privé pour financer le fonctionnement serait une mauvaise idée ?

Quand un SC (supercalculateur) “sort de terre”, il est déjà occupé à quasiment 100% (les projets sont souvent là, les équipes prêtent et les accès planifiés). Et très grande majorité, c’est pour des programmes scientifiques ou industrio-académique. Mais la règle qui semble être général est que si une entreprise privé veut utiliser un peu de la puissance du SC, elle doit comme tu l’écris, se rapprocher des universitaires. J’ai déjà vu une grande boîte française se rapprocher d’un des labos dans lequel je bossais pour utiliser une partie de cette puissance. Mais en échange, cette boîte avait autorisé la conduite de certaines expériences dans ses locaux. Et le tout avec un intêret académique (donc fondamentale) et industrielle. Bref, c’était assez légit.

Des jeunes pousses en IA, ça sonne très start-up. Et allouer x% de puissance d’un SC à des start-up en IA qui ne sont pas associés à des travaux académiques me dérangent énorment pour trois raisons :

1. D’après l’article, il ne s’agit que de l’IA. Ok, c’est à la mode et sa vend du rêve à nos politiques (dommage que la science fonda ne leur fassent pas le même effet). Mais pourquoi uniquement l’IA et pas d’autres domaines comme des jeunes pousses en pharmaco, en chimie, électronique quantique et autres domaines où un SC peuvent être un atout ? Pourquoi juste l’IA ?





2. Une grosse majorité des start-up en IA sont des boîtes vides vendant du marketing à des marketeux. Elles font des levées de fonds de millions € voir plus. Et elles ne peuvent pas se payer un calculateur pour entrainer leur modèle elle-même ? Genre AWS, OVH et co c’est pas sufficient pour leur besoin ?
   Tu me diras, “et alors, elles sont l’argent”. Oui, elles ont l’argent pour payer. Sauf que la puissance disponible est quasiment pleine. Donc, ça veut dire que les x% que tu vas dédier uniquement à ces boîtes va être perdus pour d’autres programmes de recherches… Et en plus c’est pour entrainer des modèles de langage. Serait-il pas plus pertinent de chercher à faire des langages de modèles plus économes en ressources de calculs ?





3. La raison est plus idéologique. Le SC a été construit avec des finances publiques. Son utilisation doit donc aussi aller dans le sens d’un service publique. La recherche est un service publique (même si la découverte d’une mousse de spin quantique ne me sert actuellement à rien dans ma vie), c’est une découverte pour l’humanité. Les rares connections avec les industrielles ont également une retombée pour la recherche publique (en tout cas pour les projets dont j’ai eu connaissance).
   Ici, les jeunes pousses risquent surtout de faire tourner leur modèle pour faire du fric (et encore si c’est pas pour se faire racheter par une boîte étrangère) au détriment d’un progrès scientfiquement pour l’humain.
   Ok pour de l’IA sur les SC de boites privées, mais en lien avec des universitaires pour faire de la merde. Ce que je veux surtout éviter, c’est une “Argent publique, bénéfice privée” avec les SC à l’échelle de l’UE.

Tu es une boîte privée, tu as besoin de puissance de calcul ? Bah tu regardes du coté d’OVH, AWS et autres cloud providers. Tu as un gros besoin, fais comme Total, achète-toi un SC (et la puissance que tu utilises pas, loue-là à d’autres).

En UE, nous avons Atos Bull (j’ai oublié le nouveau nom) pour le moment. Mais pour info, le supercalculateur en Finlande est de HPE. Et je crois que l’Italien est Bull. Pour Jules Verne, je pense qu’il est Bull aussi (mais faudrait vérifier sur le Top500).

Et des boîtes qui ont besoin d’un SC en France, tu as Total. Quand tu es une start-up licorne, ne vas pas me faire croire que tu ne peux pas te payer un SC (sans forcément viser celui d’un centre de calcul) ou un cloud provider. Et encore, c’est pas si compliqué que d’acheter plusieurs racks HPC GPU dans ce genre, de mettre en réseau et d’administrer ? (Perso, j’ai fais ça au US dans un labo avec deux machines de ce genre. Et je suis pas informaticienne ni sys admin de base).
Bref l’éventail des possibilités est là.
Je concède que pour la partie électrique je ne sais pas si tu en mets une 10 comme ça se passe avec ton fournisseur d’énergie.

Le 15/09/2023 à 11h 31

Je suis totalement contre l’accès aux supercalculateurs pour des entreprises ! En général, ces machines sont financés avec de l’argent qui vient de nous impôts et sont souvent dédiées à la recherche scientfiques et militaire (et parfois à l’industrie, mais souvent en lien avec l’académique).

Et quand un supercalculateur ouvre, il est très vite occupé à un maximum de ses capacités. Donc qu’une boîte en IA (et d’ailleurs pour l’IA et pas d’autres domaines comme la pharmaco, les semi-conducteurs…) veut calculer, sa signifie qu’elle va pomper cette puissance sur d’autres projets plus académique. Si une boîte veut faire du calcul, elle se paye sa machine (ou bien un cloud !).
Sinon, c’est trop facile de financer des supercalculateurs avec de l’argent publique dont on ne verra probablement pas le retour pour des boîtes privées.. Et puis, quand on est un petite boite, me faites pas rire qu’avec des levées de fonds de plusieurs dizaines voir centaines millions d’euros on peut pas investir dans un calculateur !

Bref, comme dit ragoutoutou Ursula faut vraiment arrêter les crapaux !

A moins que l’idée derrière, c’est d’éviter qu’ATOS HPC (j’ai oublié le nouveau nom) ne ferme pour cause de mauvaise gestion de la boîte ?

Le 23/08/2023 à 18h 44

fred42 a dit:

Mais NXI n’en parle jamais comme ça. C’est déprimant quand NXI parle du spatial européen : jamais content, pas beau l’avion ; Carrément méchant jamais content, pour parodier Souchon. Ça ne me fait pas rêver.

Perso je trouve que NXI fait la différence entre les sujets scientifiques (e.g., Euclide) et les sujets spatiaux mélangeant des implications politiques (e.g., Ariane).
Personnellement je comprends ce point de vue. La France a un énorme potentiel dans le spatial mais souvent parasité par des considérations et des enjeux de politiciens derniers de classe (mais comme d’en d’autres domaines).

Après, peut-être que NXI lira notre échange et pourrait se dire : “Tiens en voilà une bonne idée”. Qui sait ?