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 17/07/2024 à 19h 10

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

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 : Next

(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 ?

Le 22/08/2023 à 19h 32

fred42 a dit:

Par contre, je préfère ce sujet à l’espace : il reste plus proche des thèmes de NXI par l’aspect électronique et informatique embarqués dans le véhicule.

Tu n’as pas du mettre ton nez dans un satellite, pas vrai ? Parce que l’automobile c’est des Michus à coté du spatial. Entre l’aspect radio (rien que ça NXI pourrait des dossiers pendant des mois), les différentes bandes de fréquences, leur usage, limites, les algorithmes de compressions, le code-correcteur d’erreur (je parle pas de CRC32, mais de Reed-Solomon et ses variantes bien plus sophistiqué et plus joli mathématiquement que ce tu trouves dans les télecoms [Bien que leur réseau euclidien soit sexy]). Et je te parle pas des microprocesseurs blindés, redondés, des “OS” tournant sur ses machines et des FPGA. Tu peux également ajouter l’électronique de traitement et même des processeurs analogiques. Sans parler des idées folles du JPL de faire une ordinateur mécanique pour Vénus.

Perso, je n’aime pas l’automobile. Mais j’apprécie NXI pour me faire sortir de ma zone de confort.
Par contre je reconnais que j’apprécierai des sujets spatiaux plus orienté info et hardware.

Le 22/08/2023 à 17h 16

Tiens, ça faisait longtemps. C’est pas comme si la France avait d’autres problèmes plus urgents !

Ce que j’en pense c’est qu’il y a 3 scénarios possibles : 1. A la fin flicage à la Chinoise. Moi qui est toujours cru que Macron était plus pro US que pro Chine, je me suis bien trompée.

1. ça fait flop sur tout la ligne et se termine en jettant l’eau du bain et le bébé mort-né vers l’ANFR.


2. ça fait un flop après adoption, mais etre-temps des dommages réels ont pu être commis (cf @Arbyter #27).

Je n’y crois pas pour le 1. Pas encore. Le 2 est le plus probable. Le 3. me le semble moins. Car si l’aspect technique est hors de portée de nos dirigeants (quelles plaies ces Michus), au moins des arguments concernant la protection des femmes, des enfants et autres victimes (morales ou physique) feront probablement mouche pour nos dirigeants. En tout cas, Macron et son gvt ne veulent pas se faire plus mauvaise pubs qu’ils n’ont déjà.

Pour le point 2., c’est comment la France (petit pays sur la scène internationale concernant le numérique) va réussir à obliger M\(, Google, Apple et co à faire ça ? Autant M\)… Bah M\( quoi. Mais Apple vend incluant le respect de la vie privée dans leur marketing.
Et surtout, c'est quoi les moyens de pressions qu'à la France pour les obliger ? Interdire M\) ?! (Avec plaisir, mais les conséquences économiques seront catastrophique). Mettre une amende ?

Pour l’open-source (e.g., Mozilla), je vois pas non plus ce que la France veut faire (bloquer Mozilla via DNS ? Bah, ça va arrêter que les Michus et cette espèce doit pas vraiment être au courant de Firefox).
Et surtout, comme il s’agit d’un projet open-source, pourquoi ne pas le forker en faisant appel à une ESN (svp Cap Gé ) ?

Franchement, mis à part un délire de magie sous psychotrope lors d’une soirée ENA-HEC, je vois pas comment ça peut marcher, ni être réalisable.
On va encore passer pour des cons sur la scène internationale Comprends pas comme les investisseurs et les milliardiares veulent venir dans ce pays.

Le 21/08/2023 à 11h 20

OlivierJ a dit:

Je suis d’accord sur le fait que pour certaines réunions où on n’intervient pas (ou très peu), on peut se permettre d’écouter en diagonale et de continuer à travailler sur un autre sujet. Cela dit, je parlais de certaines réunions où j’attends d’être présent car c’est parfois plus pratique. On a beau avoir des partages d’écran, le tableau blanc ou bien regarder 2 écrans en même temps c’est parfois plus efficace. né

Le né, c’est bien celui-ci ね ?

Le tableau blanc uniquement pour les équations, je suis d’accord du besoin en présentiel. (Et encore, c’est ça quand tes collègues ou le client ne parle pas couramment le LaTeX).
Pour le reste, je pense que je n’ai pas rencontré ce genre de situation ou que je m’en sois accomondée.

Les vieux profils techniques que j’ai rencontré sont uniquement des gens avec une maîtrise de techno indispensable à l’ESN pour les contracts. Genre un assembleur pour un processeur de satellites ou une connaissance spécifique sur un soft développé par l’ESN qui est utilisé par un très gros client (CNES, Airbus…). En dehors de ces cas, et donc de s’être formé dessus en interne, c’est quasi-impossible d’évoluer en ce sens.

Comme me disait un ex-collègue dans cette situation : “C’est à double tranchant. Je fais de la technique et je suis super bien payé. Par contre, le jour où la techno cesse d’exister je suis foutu”. Et dans une ESN, j’ai vu un “vieux” être “pousser” à partir car le client changait de techno pour un truc US. Soit il restait mais son salaire était renégocié. Soit il partait ailleurs.

En tout cas, et c’était le point de mon propos, si tu rentres dans une ESN tu as rarement la possiblité de faire la technique durant tout ta carrière. A un moment donnée, le management va te ratrapper.

Le 20/08/2023 à 09h 25

Kiroha a dit:

Disons que c’est normal que à un moment tu regardes ce qui te reviens. Les ESN se gavent fortement … Quand je suis arrivé dans le Nord, je n’ai pas forcément fait gaffe et je suis arrivé avec mes prétentions Normandes … Quand je me suis rendu compte que mon ESN faisait 57% de marge entre le CA et mon Super Brut j’ai essayé de renégocier mais comme d’hab c’est compliqué blabla ouin ouin … Dans mon ESN actuelle, c’est 37%. De mon point de vue c’est encore trop, cela devrait tourner autour des 15% vu ce qu’elle me fourni. En Freelance si tu t’en sors bien tu peux descendre à 8% de ton CA mais il va falloir gérer pas mal par toi meme.

Dans mon ESN (taille PME), c’est 17%. Le reste va aux salaires et aux primes (qui font facilement du 15ème voir 16ème mois).
Il faut oublier les grosses ESN. Elles n’attirent que parce qu’elles font le chalutier sur LinkedIn et qu’elles profitent encore un peu de naïveté des jeunes diplomés ou les gens dans le besoin.

Kiroha a dit:

Heureusement maintenant il y a pas mal de boîte qui font du clé en main.

C’est-à-dire, en mode plateforme ? Tu fais la technique, elles font l’administratif ?

Le pire là-dedans c’est que à la base les ESN vendent un accompagnement sans faille avec de la formation, une assistante qui va te permettre de te concentrer sur ton travail etc etc. Dans les faits il n’y a rien, on est juste là pour engraisser les “business manager” et les cadres de la direction. On te promet une prime annuelle à l’embauche et finalement il n’y a rien. De mon point de vue, c’est le début de la fin des ESN qui vont avoir de plus en plus de mal à garder les profils séniors. Ils vont devenir des boites ou il y aura une grosse partie de l’effectif en junior sortant de l’école pour se faire une première expérience et ensuite ces mêmes juniors passeront freelance une fois qu’ils auront compris le fonctionnement.

C’est déjà le cas. Les profils seniors sont rarements des techniques. Ils sont devenus managers machin-truc et c’est comme ça qu’elles empêchent leur fuite (car des managers machin-truc ça se trouve facilement). Les gens techniques restent grand max. 4 ans dans une ESN avant de partir chez leurs clients. On m’avait dit : “Si tu restes 4 ans, c’est que tu es mauvais. Oublie la technique et fait du management pour sauver tes fesses”.
Les seules ESN qui sont en “difficultés” sont les grosses ESN qui se plaigne de la tension et de la difficulté de trouver des “vierges” (aka des jeunes diplomés un peu naïfs.).
Mais c’est leur choix de managements, conditions de travail, salaires qui les mets dans cette situation. Les ESN qui ont compris ça et qui se sont adaptées aux changements n’ont pas de soucis.
Les dinosaures vont “mourrir” et les mammifères vont survivre et occuper le paysage. La météorite dans l’histoire, c’est le sras-cov-2.

Le 21/08/2023 à 11h 00

Wosgien a dit:

Les boucles qui recherchent dans un résultat SQL la valeur d’une colonne en indexant par le nom de la colonne. ou comment faire 500 cycles CPU à chaque ligne là où deux indirections et 10/2à cycles suffiraient.

Je ne suis pas experte en SQL donc je m’avancerai pas sur ce point. Par contre, les indirectons je m’en méfie. J’ai connu des codes de calculs (le code qui a besoin de 34 000 cores) qui souffraient justement des indirections car ça pétait les caches CPUs en permanence. Sur le papier, l’idée était très bonne mais en pratique, l’approche plus “naïve” était finalement la plus rapide.

Tout dépend de ce qu’on appelle “la même chose”. Pour taper une lettre, c’est pas kif/kif, mais au final la lettre sera tapée. Je parle de l’efficacité “métier”. Et dans ce domaine, les interfaces graphiques puis le web ont fait énormément de mal.

Autant pour moi, j’ai mal évalué le critère.

Dernier point, et pas des moindres: quand on parle de PC “inutilisable” (exemple: les PC donnés au lycée), je ne suis pas d’accord. Ces PC sont utilisables MAIS ils sont soumis à l’environnement sécuritaire actuel: faire une tâche sur ces PC (consulter les manuels, internet, faire un document ou du python) n’est pas désagréable. Par contre, la faire quand l’antivirus se lance, c’est dur…

C’est un énorme sujet. Mais entre marketeux, politiciens et crétins de consommateurs nous n’y sommes pas rendu. Les 3 cavaliers de la conneries pour lutter contre le réchauffement climatique… Autant demander à Trump d’avoir le prix Nobel de physique.

Le 21/08/2023 à 07h 57

Wosgien a dit:

Autre constat: émuler Win95+Word 97 en Javascript est plus réactif à l’utilisation qu’utiliser Word 2016 en natif sur un Core i5. On me rétorquera qu’il y a plus de fonctionnalités dans le 2016. Mais lesquelles vous utilisez?

Je te rétorque qu’il y a probablement moins d’espionnage dans le premier que le second. Ou que espionnage il y a, il est déporté chez l’hébergeur et non sur ta machine.

Et vous savez ce qu’un CPU fait le plus et pour lequel peut de CPU on progressé en efficacité? Transformer et comparer des chaînes de caractères (opération très dépendante de la mémoire)… Tu charges un HTML: il faut l’interpréter, elle ne sont pas forcément en majuscule/minuscule. Ensuite il y a le CSS. Les identifiants sont en texte -> comparaison. Le javascript est en texte. Le Json aussi.

Les CPUs ont progressé sur ces points. Tu trouves facilement des libraries optimisés pour faire ce genre de choses et qui exploite proprement les unités vectorielles (mettons de coté SSE4 .2 pour la manipulation des strings). Celle qui me vient immédiatement en tête concerne JSON.

Le problème provient parfois des effets de ramp-up concernant l’activation des unités vectorielles.

Tout ces traitements de texte sont lourds et long. Sans parler du fait que l’ASCII n’est plus le seul standard de codage: nicode, UTF-8, ISO8859, … Cela demande des conversions permanentes des chaînes (et souvent, leur présence en double dans la RAM)

+1. Mais faudrait déjà que ce cancer de Windows comprennent que l’UTF-8 (et 16 et 32) sont la norme et qu’il n’est qu’une métastase dans un monde ou Linux (donc les serveurs) et OSX l’ont déjà par défaut.

Ensuite le calcul de position des éléments, de taille. Là on a de la virgule flottante pour les polices.

Vu les perfs des processeurs en calculs flottants de nos jours (évidemment il faut bien coder le truc. A noter que les polices vectorielles s’appuient sur des B-splines dont il existe des algos très efficaces, je suis pas sur que ce soit si visible en dehors de pages pathologiques).

Mais en gros, sur le Web, sur Excel, dans la plupart des softs, la vitesse de calcul n’est pas importante. Ce qui est important, c’est la vitesse de comparaison des chaînes et l’accès à la RAM.

Ce qui encore plus important, c’est les optimisations des structures de données pour justement optimiser ses accès. Et là, tout les softs sont rarement bons sur ce point.

Et vous pensez que le sordis sont plus efficaces? Oui, sur le papier, à la prise, un atari, un 286 ça consommait au max moins que nos ordis en Idle (ordis fixes): 20W.

Il serait plus pertinent de comparer la puissance électrique / flops pour avoir une idée. Parce que tu ne fais pas la même chose avec 286 et un i7.

Idem, ton atari n’a pas de NVMe, ni d’USB 3.0.

Pour gagner en efficacité, être capable de faire des choses à peu près semblables avec des CPU plus économiques, il faudrait prétokenizer les pages, “compiler” le HTML/CSS, … A partir de là, n’importe quel CPU de 800MHz serait convenable et on aurait besoin de moins de RAM et moins rapide.

J’approuve !

Je suis d’accord avec toi, en particulier sur le dernier point.

Le 20/08/2023 à 17h 49

(quote:2147596:127.0.0.1)
Je ne suis donc pas près d’avoir un browser web qui prenne moins de place sur mon disque-dur… sauf si la brique de base (chromium) diminue en taille.

Heu, tu es sérieux là ? La place d’un browser web sur un disque de nos jours, c’est vraiment pas un problème. Le prix d’un support de stockage est abordable de nos jours en occassion. Et les systèmes de fichiers font de la compression efficacement.
Alors je suis d’accord pour dire que le Web moderne souffre de l’obésité d’un américain moyen, mais là tu exagères de dire que 2 ou 3 Go sont critiques pour ton support de stockage.

Et si la taille est un problème de ton navigateur, tu en as des alternatifs open-source qui vise justement à être économe sur ce point.

Le 19/08/2023 à 16h 52

Wosgien a dit:

Je ne vois pas pourquoi le chiffrement augmenterait le volume de données. Que le protocole effectivement nécessite un handshake (très léger, part le problème de latence), ok, mais les donnée ne changent pas de taille.

Dans le cas de l’AES, en fonction du mode de chiffrement (CTR, CBC, GCM…) tu peux avoir un padding ajoutant quelques octets sur l’ensemble des données. Mais ça reste très marginal au regard d’une requête HTML.

Pour le cas des algorithmes asymétriques, je sais que cette notion de padding existe aussi et, de mémoire, c’est également marginal.

Au final, oui il peut avoir une augmentation de données mais ça reste très marginal dans plus de 99% des usages réels.