NVIDIA et AMD travailleraient sur des CPU Arm prévus pour le monde PC en 2025
Le 25 octobre 2023 à 07h03
2 min
Sciences et espace
Sciences
Selon Reuters, NVIDIA développerait une nouvelle gamme de puces dédiée au monde PC, dans l’objectif de proposer des processeurs basés sur l’architecture Arm en 2025. Ce travail se ferait en liaison avec Microsoft, qui aurait alors les puces performantes tant désirées dans ce domaine.
Il ne s'agirait pas du premier pas dans le développement de CPU chez NVIDIA. Comme nous l'avons vu en mai dernier, les puces Grace Hopper intègrent à la fois des parties CPU et GPU.
Toujours selon nos confrères, AMD travaillerait lui aussi sur un tel projet, mais on n’en sait pas plus pour l’instant. NVIDIA, AMD, Arm et Microsoft ont tous refusé de s’exprimer sur le sujet.
On trouve déjà des puces Arm dans certains ordinateurs Windows, notamment chez Microsoft, comme la Surface X.
Les puces Qualcomm utilisées jusqu’à présent manquent cependant de puissance, et Windows lui-même pourrait profiter d'une passe supplémentaire d'optimisations. Le problème principal reste toutefois le manque d’applications compilées nativement pour cette architecture.
La rumeur éclaire à la fois les ambitions de Microsoft dans ce domaine et la prévalence de NVIDIA, largement renforcée par l’explosion des usages autour de l’IA. Ses puces A100 et H100 se retrouvent dans la plupart des annonces liées aux centres de données quand il s’agit d’entrainement des grands modèles de langage, comme on l’a encore vu chez OVHcloud récemment.
La date de 2025 n’est également pas anodine, comme le rappelle Reuters, puisque Qualcomm dispose d’un accord d’exclusivité pour la fourniture de puces Arm compatibles avec Windows. Dès l’année suivante, on pourrait donc avoir plusieurs offres de puces Arm, à la manière de ce que l’on connait dans le monde x86 depuis plusieurs décennies.
Même si la question matérielle apparaît comme réglée, les difficultés logicielles restent présentes. Microsoft tâche de montrer l’exemple, notamment avec son projet Volterra, mais la situation restera délicate si les éditeurs tiers ne suivent pas. Il faudra franchir ce fossé pour lutter plus efficacement contre Apple, dont la transition vers Arm (via ses puces maison) est une réussite.
Le 25 octobre 2023 à 07h03
Commentaires (30)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 25/10/2023 à 07h13
Peut-être la fin du duo Microsoft-Intel? Lors des derniers windows en arm, cela n’a pas fonctionné. Microsoft cherche à rivaliser avec Apple et sa puce M2.
Le 25/10/2023 à 08h10
MS a beaucoup d’adhérences fortes avec Intel (x86) au sein de Windows.
M’est avis qu’ils vont devoir repartir de la page blanche ou changer de noyau pour un qui existe et qui sait faire fonctionner l’architecture ARM au mieux de ses capacités.
J’dis ça, j’dis rien.
Le 25/10/2023 à 07h37
Il est clair que l’émulation x86-64 est indispensable. Ils avaient tenté le coup à l’époque, mais c’était imparfait et très lent. Cela dit, l’espoir est permis quand on voit l’efficacité de Rosetta chez Apple.
Le 25/10/2023 à 08h25
“Apple, dont la transition vers Arm (via ses puces maison) est une réussite.”
Ça dépend des domaines.
Dans le cas des jeux vidéo existants avant, les éditeurs ont l’air frileux pour adapter les “clients de jeu”.
Le 25/10/2023 à 08h52
Disons qu’Apple a mis deux gros bâtons dans les roues des développeurs :
L’abandon total du 32 bits et ensuite le changement de processeurs.
Sur un marché qui était déjà peu actif, seul les plus courageux sont restés.
Il faut quand même garder espoir, Apple semble faire de gros efforts en mettant à disposition le « Game Porting Toolkit » pour les développeurs.
Le 25/10/2023 à 09h05
Pourquoi ils ne font pas tourner Windows sur le WLS 2 ?
Faire l’inverse de ce qui existe en fait….
Le 25/10/2023 à 09h10
WSL : Windows Subsystem for Linux … cela reviendrait à porter Windows sur un noyau Linux.
Fait attention, à balancer des trucs pareils, tu vas affoler les bien-pensants et les platistes.
Le 25/10/2023 à 10h00
Depuis WSL2, c’est un noyau LInux qui s’exécute dans une machine virtuelle (légère dixit WIkipédia).
Inverser l’imbrication ne changerait (LSW
) quasiment rien au travail de portage de Windows sur ARM.
Le 25/10/2023 à 10h10
Ceci dit qemu sait gérer la virtualisation avec changement d’architecture processeur
Le 25/10/2023 à 09h45
Bah ouai :)
L’ARM étant bien supporté… autant porter Win sous Linux :)
Le 25/10/2023 à 09h57
Bien que cela reste une bonne nouvelle pour la concurrence. Je ne peux qu’avoir peur pour les vieux jeux. Je sais que Microsoft travaille sur l’émulation. Mais déjà qu’il est parfois difficile de faire fonctionner les vieux jeux, je n’ose imaginer ce que cela sera avec de l’émulation.
Le 25/10/2023 à 10h25
Le marché des CPU est comme celui de la photo. Intel ou ADM (comme Nikon vs Canon)
Si c’est bien le cas: Il faudra beaucoup de temps se comptant en décades pour changer les avis.
Un peu comme la marque de voiture KIA
Quid de l’initiative européenne de faire ses propres CPUs. La aussi si cela aboutissait ce serait aussi difficile de rentrer dans le marché grand public. Mais en plus, cela rajoutera à la complexité du choix qui pour l’instant, même avec 2 marques est bien difficile parfois.
Le 25/10/2023 à 11h08
« Quid de l’initiative européenne de faire ses propres CPUs. »
Ben justement, c’est là que le RISC V à une carte à jouer … maintenant qu’ARM et ses royalties ne font plus partie de l’europe.
Le 25/10/2023 à 10h33
Dans mon idée c’était pour Petitmou de faire un skin Windows pour Linux pour ne pas que la mamie du cantal soit brusquée, recompiler les softs en ARM sous Linux, vendre des machines complètes avec leur nouveau SoC ARM… et dire que c’est une révolution.
Le tout lancé dans une conférence “Scary Win” qui se déroulerait à 17:00.
Le 25/10/2023 à 13h01
Les problèmes sont multiple
Tu me diras oui mais si on norme bien, ca va passer. Le problème n’est pas seulement industriel mais aussi politique. Et donc ca partira en sucette pendant un moment.
Sans compter que les éléphants déjà en place ne voient pas d’un bon œil cette concurrence. Entre corruption, croche patte industriel, pression politique sur les imports/exports, etc… Bref c’est pas gagné.
Le 25/10/2023 à 13h10
Changer l’environnement X86 risque de prendre un moment oui.
Mais quel serait intérêt en fait sur des PC de bureau/multimédia/gaming ? Sur des portables pour la bureautique encore je peux comprendre pour la consommation électrique modérée mais les CPU X86 ont déjà fait d’énormes progrès dans ce sens.
Enfin tant que c’est pas un modèle de Grosbill overclocké PGM proof.
Le 25/10/2023 à 13h59
L’intérêt à quel terme ?
D’avoir le choix tout simplement ?
Parce que les industriels sont bien au courant de leur hégémonie et de la lourdeur que pourrait prendre une migration de l’existant.
Intel a tenu la dragée haute à AMD pendant 10ans grâce à leur fonderie qui était plus avancée, puis a ouvert la fonderie quand ils se sont rendus compte qu’il fallait séparer la partie CPU de la partie fonderie.
AMD est revenu en force avec le concept de chiplet et de package 2.5D et 3D; et il surveille ARM qui pour l’instant n’est pas en mesure de faire basculer le marché.
ARM surveille aussi risk-V qui pour l’instant n’est pas en mesure de produire du concret.
Pour l’instant l’architecture ARM a pris tout le marché mobile, et je crois aussi que dans l’infra réseau cloudflare qui a besoin de beaucoup d’I/O et peu de calculs a opté pour des serveurs ARM.
Après d’un point de vue soft ça va compliquer les choses pour sûr, mais dans 10ans on aura sûrement bien évolué, les outils comme la mentalité sauront se placer avec un environnement hardware qui pourrait être différent.
Le 25/10/2023 à 14h06
Faudra voir les prix aussi, côté tarifs Nvidia est pas super réputé pour faire dans le bon marché…
Le 25/10/2023 à 14h44
Et les performances de Box64 et Fex-Emu dans l’opensource.
Peut-être que ce n’est pas directement destiné à Ms, que Ms raccroche les wagons:
Windows sur ARM, ça ressemble au chant du signe, à un “je suis pas mort”. Pas à un nouveau départ.
Le 25/10/2023 à 15h55
« Le tout dans le cloud ouvre la possibilité d’un client quasi sans OS: bye bye windows, coucou les rêves du milieu des années 90 genre terminal Java »
Ça me fait penser aux discours de consultants expliquant que l’UML permettrait à un fonctionnel de faire du code, de le packager et de le déployer en Prod sans passer par les devs et les ops
Le rêve du tout cloud, c’est bien joli mais dans un monde où tout le monde il est copain avec tout le monde. « tout le monde il est beau, tout le monde il est gentil » © Jean Yanne
Disons que Windows sur ARM, effectivement ça sent le sapin pour MS. Ils partent de beaucoup trop loin pour être en mesure de proposer un truc opérationnel avec ce qu’il propose à base de technos x86 aujourd’hui. Au mieux, ils peuvent toujours essayer de porter leur
applicationinterface graphique sous GNU/Linux et abandonner le noyau NT (et WSL, et WSA).Le 25/10/2023 à 19h47
D’où ma ref aux terminaux java :)
D’ailleurs c’est devenu quoi les AGL?
Pas tout à fait d’accord. Avec powershell et DotNet core open sources, l’environnement ‘récent’ est prêt.
Ceci dit, si wasm se développe, ça fera un clou en plus (en même temps que redynamiser la possibilité d’appli universelle toute plate-forme, ce vieux rêve qui a été régulièrement poignardé depuis les années 80)
Le 26/10/2023 à 07h29
Les AGL ? … disons que les fonctionnels ont fini par comprendre que le dev c’était un vrai métier et que les ordinateurs ne peuvent pas faire n’importe quoi n’importe comment. Du coup, on est sur du « chacun son métier ».
Aujourd’hui, ce qui s’en rapproche le plus, ce sont les IDE … utilisés principalement par les devs.
Concernant .NET sous GNU/Linux, j’ai eu un REX sur le sujet où l’aspect le plus marquant est que ça marche mieux avec de meilleures perfs que sous NT
En partant de cette base, on pourrait s’autoriser à imaginer, techniquement, un possible portage de Windows vers un noyau Linux.
Ce qui plombe, entre autres, les perfs de l’architecture x86 vs ARM / RISC V c’est la gestion des changements de mode d’exécution. Mais bon, ARM / RISC V sont relativement jeunes par rapport à x86 et moins aboutis sur certains aspects importants (genre BIOS vs DeviceTree …). Et encore, j’attends de voir ce que SiFive va faire avec sa carte mère RISC V l’année prochaine.
Quant à Apple avec ses puces M1 et M2 … disons que Jim Keller étant parti de chez Apple (pour faire les Ryzen chez AMD), disons que les évolutions de ces puces vont être équivalentes à celles des iPhone après la mort de Steve Jobs : CàD cosmétiques sans réelles évolutions technologiques.
Tout pareil … pluzin !
Le 26/10/2023 à 00h33
Je pense que certains enterrent x86 un peu vite. Les CPU Intel et AMD x86 rattrapent leur retard sur l’efficacité énergétique par rapport aux puces Apple. De l’autre côté, les puces Apple commencent à stagner. M1 a fait très fort, ça a fait du bien à l’ industrie (après AMD, qui a réveillé Intel), mais M2 a déçu, et on attend d’avoir du recul sur M3.
Possible que x86 reprenne la tête de la course, alors la question de windows x86 ne se posera plus (et il a la force de sa faiblesse : un formidable écosystème d’applis x86+win32). On peut voir Windows ARM comme une roue de secours au minimum, mais ne soyons pas trop pessimiste par rapport à ce que vont pondre Intel et AMD. On verra bien. En tous cas on va manger du x86 encore pas mal d’années, et ça continuera de donner naissance à des machines aux performances tout à fait respectables.
Le 26/10/2023 à 05h24
Si perso j’admire l’efficacité et efficience des puces Arm, j’ai toujours une forte appréhension aussi quant à des PC basés dessus (j’ai le Pinebook Pro de Pine64, il marche très bien malgré ses faiblesses) car pour moi machine basée Arm = pas d’accès au bootloader, pas d’UEFI, cartographie hardware à la limite du spécifique pour chaque modèle, etc.
Je sais que c’est pas spécifiquement lié (enfin je pense pas), mais de ma fenêtre c’est la norme. Et c’est un peu chiant pour l’interopérabilité et la maîtrise du software qu’on veut mettre.
Le 26/10/2023 à 06h28
En fait si, c’est lié.
Pour x86, on a le BIOS puis l’(U)EFI qui permet la découverte complète des périphériques quels qu’ils soient (grâce aussi aux interfaces bien standardisées PCI-express aujourd’hui ou PCI et AGP pour la génération précédente et bien d’autres avant ça mais toujours gérées au niveau du BIOS).
Pour ARM, Linux a introduit le Devicetree qui permet un certain niveau d’abstraction même s’il n’est pas au même niveau et reste spécifique à chaque BSP/carte-mère.
Après, le BIOS n’est pas parfait non plus puisqu’on dépend du firmware dudit BIOS dont la qualité est… variable.
Le 26/10/2023 à 07h56
D’où la bulle “nocode” :) (c’est ironique: je suis dev, et en même temps je chapeaute une petite équipe, et le nocode c’est bien trop limité pour être utile suffisamment régulièrement)
J’ai pas tout à fait le même vécu (les perfs sont très similaires). Toutefois c’est selon la charge: les charges réseau sont très efficaces sous Linux, mais Linux n’a pas d’antivirus installé.
De même, pour les charges BDD légères, SQL Server sous Windows se montre meilleur que sous Linux (et meilleur sous beaucoup de connexions que mysql ou postgres - même infiniment meilleur que mysql)
Oui, ils se sont alourdis énormément avec les différentes failles et problèmes d’exécution. Mais c’est aussi l’OS. On compare souvent des x86 Windows avec des téléphones ou les apple qui ont soit été épurés, soit n’ont rien de la complexité soft d’un PC.
Le nombre de threads que gèrent Linux et Windows sur un PC est affolant. En ajoutant que depuis quelques années certains context switch sont accompagnés de context switch niveau du hardware (notamment la CG pour éviter les failles), ça devient délirant. Imaginez que si un clavier évolué existe, avec des fonctions qui permettraient de lire l’historique du clavier, il faudrait aussi faire son contexte switch quand on change de processus!
Enfin, le x86 aurait pu être mieux, si on l’avait utilisé correctement ave cles différent niveaux de ring. Trop tard, c’est abandonné.
Ce qui plombe le x86 aussi, c’est son architecture vieille où le CPU doit tout faire, doublé d’un nombre alarmant de systèmes de sécurité lié à son histoire.
Bien sûr, on peut parler de l’ISA - mais au final même un ARM ou un RISC-V n’exécute pas directement le code assembleur qu’il reçoit mais fonctionne en interne comme un x86 (en RISC-V, c’est déjà une frontière entre les 2 types d’implémentation: le tout câblé basse conso mais peu rapide, et le “émulé”).
Il n’y a pas qu’un seul génie au monde. Apple a (re-)ouvert la voie pour l’ARM sur desktop, en faisant des monstres. Perso je pense que dans les M1/M2, il y a des transistors qui sont là pour optimiser rosetta2, mais c’est basé juste sur un avis perso et la tronche du CPU. L’évolution pour moi c’est de virer ces morceaux qui deviendront inutiles.
Ensuite, il faut faire évoluer un produit par vagues: si on ne stabilise pas le socle, on ne sait pas ce qu’il faut évoluer.
Le 26/10/2023 à 14h08
Pour moi il y a eu un gros raté d’intel quand ils ont voulu faire du low power:
Les atoms étaient fanless avec 5W de conso, mais le chipset ventilait avec 15W de conso.
C’était du x86 compatible avec tous les défauts de ARM.
Personne n’a adhéré.
Depuis, ARM tente de pénétrer le marché des serveurs parce que le dév y est spécifique, et a réussi à intégrer les laptops d’apple parce que le dév y est spécifique aussi, et surtout que la RAM sur les M1/M2 est intégrée en 3D.
Après, c’est à la fois un bien pour la performance et un mal pour la compatibilité.
Le 26/10/2023 à 14h39
Oui, mais moins de perfs oblige à développer plus propre
Le 26/10/2023 à 14h52
Oui, comme toujours, quand tu n’as pas le choix, les métiers connexes vont compenser.
J’ai envie de te proposer la même assertion avec les métiers hardware, s’il n’était pas possible d’améliorer les ips et l’efficience, bien sûr que le code deviendrait plus critique.
On se permet des largesses parce que le coût est insignifiant;
Quand il faut faire propre et fiable, cf l’avionique et l’embarqué des véhicules, on va vers du code bien plus robuste.
Le 26/10/2023 à 16h03
Ceci dit, en développant propre avec des configs haut de gamme, on pourrait atteindre des très hauts niveaux de ce que j’appelle le « rendement applicatif / métier ».
Aujourd’hui, plus c’est puissant, plus ça sert non pas à traiter mieux et plus vite, mais plutôt à absorber tous les overhead des couches de saindoux étalées à profusion (ie le middleware non maitrisé) entre le code métier et le système d’exploitation. Malheureusement, les jeunes développeurs n’ont pas appris à exploiter les ressources des OS ni faire du code capable de tirer parti efficacement et proprement des ressources matérielles des serveurs.
A tous mes devs, je leur dit tous le temps : « le plus dur, c’est de faire simple » accompagné d’un « tu veux faire de la maintenance corrective en boucle ou coder des évolutions intéressantes avec les fonctionnels ? »