oui effectivement je dis que il y en toujours eu et il dis que il y en aura de plus en plus mais je ne suis quand même pas d'accord avec ça. Il fait un lien de causalité entre la complexité des systèmes et le nombre de faille matérielles connue qu'il y aura dans le futur. Je suis d'accord que plus un système est complexe plus il y a de chance d'avoir une faille, mais cela peut être compensé par le fait qu'on peut mettre plus de moyen pour les trouver et les corriger avant release. Donc pour moi le lien de causalité n'est pas avec la complexité d'un système mais avec l'étendu des tests fait (test coverage en anglais)

Je n'ai pas de chiffre mais je n'ai pas l'impression qu'il y en ait plus qu'avant au contraire je dirais que il y en a autant et qu'elles sont moins évidente, les failles deviennent ultra complexe à trouver alors qu'avant sur des systèmes moins complexe il y avait des failles pas si dure à trouver. En plus vu que plus de monde s'intéressent à ce genre de faille et leur conséquence on en entends plus parler aussi.

Les GPU sont un bon exemple ils sont aussi complexe que les CPU et ont des failles et pourtant on en entends pas ou presque pas parlé. Next par exemple n'en as pas parlé ou le moteur de recherche de next ne les trouvent pas et pourtant il y en a aussi.
https://www.01net.com/actualites/les-cartes-graphiques-dapple-amd-et-qualcomm-sont-victimes-dune-faille-de-securite.html
https://www.hardwarecooking.fr/nvidia-corrige-8-importantes-failles-de-securite-sur-ses-gpu/

non rien à voir avec la complexité d'un matériel. Il y a toujours eu des bugs/failles hardware et il y a de plus en plus de gens qui s'intéressent de près à ces failles car cela contourne toutes les protections logicielles. Et statistiquement plus tu mets de personnes qui cherche quelque chose plus tu as de chance d'en trouver.

Le financement vient du pourcentage du PIB que mette chaque état dans leur propre défense, les membres de l'OTAN s'était mis d'accord pour atteindre 2% on y arrive à peine mais il faut atteindre 2,5% voir 3% la Pologne est à plus de 4,5% et sont en train de prendre le lead de l'Europe à la place du couple Franco-Allemand. Vous croyez que les F22 ou F35 ils donnés gratuitement ?

Ce qui me fait le plus peur c'est plutôt le fait que Trump affirme haut et fort laisser tomber l'Europe concernant la défense, donc d'ouvrir la porte à des scénarios plus que probable qu'après l'Ukraine, ce soit les pays balte, la moldavie etc.
Je ne pense pas qu'un seul pays Européen soit en mesure de mener une guerre actuellement, tout le monde se "repose" sur le parapluie Américain, donc Trump a raison, mais maintenant il faudrait que l'Europe se réveille rapidement...et pas pour acheter Américain (bonne chance pour construire une défense fiable sans financement).

les US ne sont pas nos alliés

Et pendant ce temps, nos politiques font des restrictions budgétaires pour satisfaire une note comme lorsqu'ils étaient à leur "grande école", note qui est attribuée par les agences américaines dont la mentalité sur le rôle de l'état (sécurité sociale, santé, éducation) est antagoniste du notre.

En phase, quand on voit EELV et Sandrine Rousseau prof d'économie ... Mais ça va même plus loin que l'économie. Mettons au ban de la société ces sectes qui nous font régresser.

Je vais conclure là-dessus:
- tout à fait d'accord, RISC ou cisc, ce n'est qu'une façade. Et même RISC-V n'est qu'un ensemble d'ISA, l'implémentation 'hardwired' d'un RISC-V est possible, mais ne permet pas les performances d'un CPU qui redécoupe/réorganise
- en termes de langages, je connais fortran et ses extensions (MPI/OpenMP) que j'ai utilisé il y a plus de 20 ans sur du code matriciel et 64 CPU. Je n'ai pas compris que fortran ne soit pas utilisé avec le GPGPU et le SIMD.
- pour les dev, c'est très variables. Mais j'estime que dans les outils bureautiques/internet, les CPU sont sollicités essentiellement pour de la comparaison de chaîne (indexation des colonnes, des attributs par nom, interprétation de scripts, de XML, de HTML...) +le chiffrement (donc multiplication et division entières). Tout soft de compta utilise une représentation parfaite des nombres (donc pas de virgule flottante) et ces opérations n'ont pas de bench généralement (bon, un peu avec les benchs bdd). Donc se poser la question de comment ma structure va tomber avec les pages mémoire ou si mes nombres sont alignés et si ma boucle passe en cache... C'est loin de 90% des dev.
- est-ce que les Apple M ne ressembleraient pas un peu aux transmeta?

Actuellement les cpu sont une jungle. Les ISA sont pleines d'extensions, certaines remplaçant les autres, d'autres à mi-chemin d'être un NPU.
Mais les langages 'classiques' sont incapables de gérer correctement ces instructions. C'était d'ailleurs le constat dans les années 80 qui a amené le RISC et les 1er ARM: l'adoption de compilos haut niveau faisait disparaître l'usage des instructions cisc (par exemple, un x86 a des instructions de calcul en mode quasi texte ou de recherche qui ne correspondent à rien dans les langages).

Bref, je te donne raison sur l'intérêt de bien connaître son archi.

En même temps ces annonces ARM me rappellebt les années 90 quand IBM/Apple faisaient du Power PC (et les difficultés d'IBM à sortir le meilleur des power pc - ainsi que la difficulté de prédire comment allait se comporter le cpu ce qui gênait les dev en assembleur).

Bref, même si Apple a un excellent CPU, je n'enterrerait pas le x86 avant un moment. (Tout en remerciant AMD de montrer à Intel comment implémenter AVX512)

Petit complément pour illustrer un peu la situation actuelle, où le CISC (et cela touche aussi ARM avec les différentes extensions d'ISA) reste difficile à mettre en place dans les compilo: Twitter

(en espérant que ce x94 en perf n'équivaut pas à générer un film en noir et blanc :) )

"c'est les détails plus profonds comme l'IPC, la longueur du décodeur d'instruction, le TLB, l'organisation des unités flottantes, la longeur du data path"

Autant ce sont des informations précieuses quand on fait des compilateurs CPU, autant sur des machines ultra hétérogènes et des traitements répartis comme maintenant, ça a peu d'intérêt je trouve, sans compter que l'IPC ARM et l'IPC x64 sont non comparables, surtout si on parle d'IPC de type AVX ou autre.

Ce qui m'intéresserait, c'est de voir comment les Apple Mx réorganisent les instructions. Je penche depuis le début pour une réorganisation qui tant vers une exécution proche du VLIW, ce qui expliquerait en grande partie les perfs en émulation.

Mais c'est du pinaillage: si je développais des compilateurs ça m'intéresserait, mais pour de l'utilisation, ce qui m'intéresse c'est plus le confort (qui n'est pas totalement /uniquement lié aux perfs théorique d'un CPU)

C'était assez superficiel quand même pour le M1.

Et les concours de com de Intel et AMD ne servent qu'à une partie des clients, une autre partie d'en moque. Cela contribue même à l'impression d'ultracomplexité de l'informatique. Plus on a d'infos, plus on a de comparaisons à faire, plus il y a de doutes...

Un peu comme vendre une voiture de série en indiquant jusqu'au 0 à 100 par défaut...

"C'est un back-end Apple top moumoute encore mieux que le précédent "

Tu voulais quel genre de com de leur part ?
Apple communique rarement sur la partie matériel, c'est "accessoire", le plus important c'est l'expérience utilisateur.

Je peux t’assurer qu’on sait faire du cloud efficace.
C’est juste pas mis en avant parce que Cloud Avenue, le navire amiral (et FCA/FE/FCP en leur temps) sont des usines à gaz, avec trop d’intervenants et de commerciaux, chefs de projets et toute l’armée mexicaine. (Et probablement quelques décisions discutables dues à des tentatives de faire simple)
Ça n’est pas tellement compatible avec une tentative de cost-killer tel que les GAFAM les ont construits…

Il y a des clients privés, qui ont leur cloud privé, qui sont très contents de ce qu’on leur a construit.

Les box c'est Sagemcom, hein (et pour moi, le matos est pas si mauvais c'est la couche soft qui est catastrophique dans ces box, tant en terme de stabilité que de fonctionnalités. Or pour ces dernières c'est bien orange qui est à la manœuvre).

Pour le réseau, je suppose que ça dépends assez fortement des critères personnels sur ce qui est bon ou pas.

HP je suis pas fan non plus mais plus sur l'aspect commercial (coder les SFP et les disques pour qu'on puisse ne mettre que ceux acheté 10x le prix chez HP par exemple) que sur le matériel , sur lequel j'ai eu, statistiquement, plus de panne que sur du Dell par exemple (je parle de serveurs) - et là encore impossible de savoir "ce qui se passe" , le support réponds "achetez un nvx serveur car le votre est plus sous garantie".

Si ça ne te dérange pas d’installer une application Electron de plusieurs centaines de Mégas, tu as Upscayl (Open Source) :
https://github.com/upscayl/upscayl

Disclaimer : je ne l’ai testé que sous Windows.

Sinon, en ligne de commande, il y a Real-ESRGAN (qui est utilisé par Upscayl, d’ailleurs) :
https://github.com/xinntao/Real-ESRGAN

Pas sûr. Il abandonnera l'Ukraine. Il ne lèvera pas le petit doigt pour défendre Taïwan. La guerre ne sera pas mondiale : les USA n'y seront pas mêlés.

Non, Rust n'est pas mur. Son ABI n'est pas encore très stable dans le temps.

"je pense que tout langage qui en rajoutera sa couche avec en prime une perte de performance, même faible"

Justement, Rust est un peu le premier langage a avoir réussi à améliorer des choses niveau perf, et niveau fonctionnalités. D'où son acceptation dans les kernels (Linux, Windows, BSD un jour?)
Certaines constructions sont très intéressantes, sa façon de les compiler plutôt clean.

Franchement, c'est un vrai langage neuf - malgré effectivement une syntaxe dure à appréhender au 1er abord (et au 2nd, et au 3ème...)

"surtout pour le pb très largement réglé de la mémoire"
Bof bof. C'est réglé par de bonnes pratiques difficiles à maintenir/vérifier, soit par des mitigations compilo potentiellement coûteuses.

Mais attention: si Rust règle les problèmes mémoire, il ne règle pas les problèmes de sécu ou de perf liés à l'architecture même du programme ou des protocoles.

"C'est pas une nouvelle solution a la mode qui sera abandonné dans 3 ans."

Rust a 10 ans passés. Il est maintenant mûr, il a montré de très grandes qualités native sur la sécu, le multitâche, les perfs et la conso de ressources.

Mais je comprends parfaitement l'agacement de la réécriture face à la maintenance. Le risque à réécrire est grand. Et les développeurs noyau ont un sacré égo - donc rust pour la ligne de commande ça ne les dérange pas, mais rust dans les pilotes ça les gêne.

De même, le C, c'est très (très très) proche de l'assembleur - on a l'impression de piloter hyper finement, de maîtriser, là ou rust n'est pas aussi transparent.
Par contre rust implémente certains concepts comme le parallélisme et le SIMD via des librairies de base et la syntaxe normale, pour le C c'est franchement de l'extension et ça sent bon la verrue depuis toujours par exemple.

Je me demande s'il n'existe pas aussi des "lasers radio" qui pourraient cramer les antennes à distance.

Oui, sur des routines ciblées, je le conçois. Mais juste sur le coeur du sydtème, ça m'étonne.

Non, pas vraiment. La prédiction de branche, elle sert à exécuter des instructions en avance au cas où.

Exemple: a = a + 1; si a = b alors c = c + 1
Le processeur peut commencer c=c+1 avant même d'atteindre la comparaison s'il considère que ça l'arrange.

Ca s'applique bien sur le prefetch, mais pas forcément sur toute la longueur (schématiquement quand le "si" est l'avant-avant dernière instruction, on s'en préoccupe). Et je ne sais pas si il s'applique sur des instructions x86 ou sur les micro opérations générées.

Par contre j'ai du mal à admettre qu'un mise à jour permette de débloquer autant de perf sur de l'optimisation pour le CPU sur un OS.
Que TOUT recompiler en mode Zen5 augmente les perfs, je n'en doute pas. Que certains point précis touchés par cette màj débloque 10%, je n'en reviens pas (bon, à voir la taille de la màj).

Par ailleurs, quel impact pour les autres archis?

L'ONU n'est pas une démocratie, c'est une organisation qui a pour but d'organiser le dialogue et la coopération entre les nations. Le fait que des pays se regroupent pour travailler sur un texte et votent ce texte au niveau du groupe de travail pour ensuite le présentent à l'assemblée ne semble pas en sois un problème démocratique.

Même après une adoption en session plénière de cette convention, les pays membres ne sont pas obligés de la signer et peuvent bloquer au moment de la ratification.

Ce qui est plutôt interpellant, c'est que l'influence des pays occidentaux soit occupée à fondre comme neige au soleil et que ce genre de texte ne soit pas corrigé pour être compatible avec leurs prétendues valeurs démocratiques.

Nous sommes peut-être occupés à voir la disparition de l'influence occidentale à l'ONU, avec des pays comme la Chine, l'Inde et la Russie gagnant de plus en plus en influence.

D'après cet article, le temps d'exécution des tests peut être augmenté de 1,8 à 77 fois. Après je l'ai lu en diagonal, et n'irai pas plus loin. Mais dans le pire cas, si votre test de base dure 3 heures, et que vous dites, pour être sûr, à chaque nouvelle version du logiciel, on va augmenter le temps du test par "fois 77", vous pouvez mais bon, c'est comme tout, ça se discute et c'est une question de choix. Dans un autre langage, encore une fois, ce serait beaucoup plus simple.

Mais même si vous utilisez un boundary checker pendant les tests, vous ne pouvez pas l'utiliser en production. Et si le problème arrive quand même en production, il pourrait y avoir pire que le "système plante", le système pourrait continuer son exécution dans un état incohérent (d'autant que c'était dans l'espace noyau si j'ai bien compris), avec des conséquences incalculables.

Quant au canari, ça peut fonctionner pour la case N+1, mais est-ce que ça fonctionnera pour la case N+10 ?

Après, ce n'est pas une question de compétence pour moi, mais c'est juste une question de choisir un langage un poil moins casse gueule. Sur des projets de cette importance, comme sur des projets modestes, ça s'envisage ! De cette manière vous pourrez mettre vos compétences, votre concentration, et donc votre argent ailleurs. Mais si vous préférez le C, vous faites comme vous le sentez ! Tout comme moi !

Et puis vu la lourdeur de ces outils en C qui dégradent significativement les performances, et sachant qu'il peut y avoir des tests qui prennent des heures, c'est vraiment pas l'idéal.

Oui enfin, c'est plus complexe à mettre en place, d'autant plus si le projet est fastidieux. C'est quand même plus simple si le langage gère nativement ces problèmes en 2024, surtout sur des machines modernes qui n'ont pas peur de stocker un int+un test à chaque accès.

En gros, même les hyperviseurs se basent sur des ressources physiques. Et tu ne peux pas émuler plus de vcpu que ce que le système physique dispose.
Enfin, même si c'était possible, ça voudrait dire qu'une ressource virtuelle qui n'a plus de tâche de calcul laisse sa place à une autre et donc ce n'est pas simultané. Donc ça se verra dans les résultats.

Enfin, rajouter une couche d'hypervision pour gérer du calcul, je ne sais pas si c'est pertinent, car ça doit rajouter une couche intermédiaire de traitement.
Autant avoir un système dédié qui alloue les ressources matérielles du cluster HPC directement. Mais je ne sais pas comment c'est fait en vrai.

D'abord @BlackLightning etb @alex.d. , merci pour vos réponses, je me sens moins bête grâce à vous !

Secundo, pour ce qui est de tricher sur le nombre réel de processeurs physiques, je me suis basé sur le fait qu'il existe depuis un moment des technos sophistiquées de VM à base d'Hyperviseur.

Si j'ai bien tout compris (corrigez-moi si trompette !), lorsque tu démarres ton bousin, l'hyperviseur prends le relais à un très bas niveau, et peut simuler X nombres de machines incluant X nombre de processeurs avec X Go de RAM, etc...

C'est cela que j'appelle "simulation" (manifestement un terme impropre, désolé...). Puis-je régler un hyperviseur de façon à ce qu'il "prétende" avoir 4999 machines dispo, alors qu'il n'y a en fait que 3990 machines physiques dans ma salle, le reste étant situé ailleurs ?

(Là, si j'ai bien tout compris, on peut détecter la tricherie en examinant le timing des opérations, du fait qu'une connexion même optique entre deux SC distants sera toujours plus lente que la même connexion optique entre deux racks physiquement présents... Si je ne m'abuse ?)

....Ou le contraire : Puis-je prétendre, en réglant finement l'hyperviseur, avoir "seulement" 3990 machines, alors que j'en ai en réel 4990 ?

Là je me base sur mon expérience du Hackintosh : aux tous débuts de cette aventure, on pouvait se servir de PearPC pour "simuler" un processeur PowerPC et faire croire à OSX Tiger qu'il était lancé sur un vrai Mac...

S'il est possible de "simuler" un PowerPC (ses instructions, son jeu de données...), ne serait-il pas possible de "simuler" un bon vieux Intel ou AMD x86 ?

Exemple : "réunir" quatre processeurs x86, et grâce mon couple "hyperviseur + émulateur" , prétendre qu'il n'y a qu'un seul processeur physique...

EDIT : En partant de l'hypothèse que mon émulateur est "parfait" et réagit exactement comme le ferait un proc x86 physique Cela me parait aller de soi, mais cela va mieux en le disant... Enfin je crois...

Et lorsque je parle de "simulation", ou encore de "tricherie", je ne pointe pas du doigt les constructeurs / architectes / concepteurs, pas du tout même, mais plutôt les utilisateurs "étatiques" qui pourraient avoir un intérêt - politique ou stratégique - de mentir (en positif ou en négatif) sur leurs capacités de calcul réelles.

Je sais, tout cela n'est qu'hypothétiques hypothèses, rêves éveillés de béotien qui se complet dans son costume d'ignorance en queue-de-pie....

Si Linpack est vraiment aléatoire, comment est vérifié le résultat de cet ensemble de calcul ?

Un exemple : la plupart de ces super-calculateurs ne sont pas en accès direct, mais uniquement interrogés à distance.

Qu'est-ce qui m'empêche de réaliser un groupement de super calculateurs situés à des endroits différents, et de te faire croire que les résultats viennent tous du même endroit ?

Je peux très bien te faire croire que mon SC a passé l'épreuve Linpack avec seulement 5000 processeurs, alors qu'en fait j'en ai employé 10 000. Avec les technos actuelles je peux très bien simuler le nombre de procs.

Peux-tu me prouver que tu es capable de détecter toute forme de tricherie, sachant que tu n'as pas un accès physique au bâtiment contenant mes serveurs ? Et même ainsi, qu'est-ce qui m'empêche d'interconnecter discrètement mon SC à d'autres SC, et de te faire croire que je dispose de bien plus de puissance et de capacité que celle physiquement présente dans un lieu donné ?

Pourquoi Rust aurait échoué ?
On parle programmation système et pas script ou dev web où on en est limite à concurrencer l'industrie du textile tellement les langues / bibliothèque/ canevas / whatever... arrivent aussi vite qu'ils repartent.

Le fait que Rust ai pu rentrer dans le nayau linux, même timidement est déjà énorme. Si cela permet déjà de limiter fortement la problématique de la gestion de la mémoire, ce cera très bien.
Et Rust reste très proche de la machine donc on évite les délires du c++ ou d'autres languages où le dev n'a aucune idée des conséquences de ses choix structurels.

Perso, je regarde parfois le résultat en assembleur entre deux manières de faire pour voir la plus efficace sur la cible. J'ai déjà eu des grosses surprises.

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 !

Il y a eu des tentatives au niveau du noyau Linux pour utiliser Rust. Mais se pose des problèmes avec le modèle de gestion de la mémoire qui est radicalement différent et incompatible en l'état. Je ne sais pas si cela sera possible de résoudre ce problème ou pas.

Zigbee, je ne connais pas ce langage. Pour moi, c'est un protocole de communication. Et je ne trouve pas de référence en tant que langage. Tu es sûr ?

Quel langage à part C/C++ permet d'écrire un driver à la fois pour Windows, MacOS et Linux ?

Je suis tout ouïe.

On fait sur GPU mais des fois on ne peut pas :

- c'est de l'embarqué, certaines plateformes n'ont simplement pas de GPU
- dans certains cas, le volume d'un bloc de données n'est pas suffisamment gros pour exploiter correctement toutes les ressources. Néanmoins les blocs arrivent à une fréquence très rapide, ce qui fait qu'en charge de calcul c'est quand même très important. Et on ne peut pas bufferiser les données pour les envoyer par gros paquet au GPU, parce qu'après le beamforming, on a des traitement très séquentiels qui ne sont pas adapté au GPU. Et comme le traitement utilise des sorties du bloc N pour traiter le bloc N+1... En fait sur certains applications très gourmandes en puissance de calcul, paradoxalement le GPU n'est pas toujours la bonne architecture. Le FPGA ou le CPU restent plus adaptés.
- en effet, les aller-retour vers la mémoire GPU peuvent diminuer, voir annihiler les gains de temps d’exécution. Ça peut être en partie éviter en envoyant directement les données codeurs dans la mémoire GPU par GPUDirect, puisque ce sont les premières étapes du traitement qui sont efficaces sur GPU. Il y a le cas particulier des calculateurs à base d'AGX qui n'ont pas ce problème, la mémoire étant partagée.

Tiens moi aussi je connais quelques personnes qui font du beamforming sur GPU pour la radioastronomie. Comme il ne doit pas y en avoir 50 qui font ça en France, il y a une probabilité non négligeable que ton pote en face partie. Je t'aurais bien envoyé un MP pour savoir si c'est le cas, mais il n'a pas ça sur nextinpact. Si tu as un moyen de communication privé, je suis preneur !

Dans mon cas, un point chaud, en terme de charge de calcul, que ce que je fais tourner, c'est du beamforming numérique d'antenne (multiplication de matrices) et de l'estimation de matrices de covariance (également des multiplication matrice-matrice + addition de matrice). Sur ces fonctions, j'atteins généralement 85/90% des FLOPS FP32 théoriques d'un CPU.

Merci pour la confirmation.

C'est un très belle avancée pour nous autres faisant du calcul scientifique.

Et ça se positionne très bien face à Intel qui fait 32 flop/cycle sur les cpu grand public et 64 flop/cycle sur les Xeon scalable haut de gamme, même si pour en profiter pleinement il faut faire des calculs du genre x = x + a * b + c

Windows est un vrai OS qui tient a route ... Et bien mieux documenté pour une entreprise que Linux, et plus stable dans le temps sur bien des points.
Si tu veux un vrai conccurent à Windows dans l'entreprise, ce serait FreeBSD, ou Readhat, ou Oracle ou Debian, pas "Linux"