ARM : Windows émule (enfin) les applications x86 64 bits
Microsoft présente la première build publique de Windows 10 pour ARM capable d’émuler les applications 64 bits. Depuis son lancement en 2017, Windows 10 pour ARM était capable d’émuler l’immense majorité des applications x86 historiques, déclinées dans une version 32 bits. Mais la plupart des applications récentes sont disponibles dans une version 64 bits.
Windows 10 pour ARM intègre une couche d’émulation des instructions x86, dont les objectifs sont similaires à Rosetta sur macOS. Les instructions x86 sont « traduites » en instructions ARM, un système de cache conservant des traductions courantes en mémoire pour accélérer les performances. Dans son incarnation originale, cette couche d’émulation ne prenait en charge ni les vieilles applications 16 bits, ni les applications 64 bits récentes.
Bien sûr, Microsoft promeut la compilation native des applications pour l’architecture ARM. Elle montre elle-même l’exemple avec de nouvelles versions optimisées de Visual Studio Code et de Microsoft Teams. Reste que l’immense majorité de la logithèque Windows est composée d’applications x86. La plupart sont compilées pour 32 et 64 bits, comme Google Chrome, mais les plus récentes et plus exigeantes sont disponibles uniquement en 64 bits, comme Autodesk Sketchbook.
Avec cette annonce, Microsoft résout le problème de la transparence de la couche d’émulation. Dans les mois qui viennent, les utilisateurs de machines ARM n’auront plus à se soucier de la compatibilité de leurs applications avec telle ou telle architecture. Va-t-elle aussi résoudre le problème des performances, point noir de l’émulation x86 sur Windows ?
Une chose est sûre : Microsoft boucle un long chantier, indispensable à la généralisation des machines ARM, même si les applications natives se multiplient. Espérons qu’elle considèrera bientôt Windows 10 pour ARM comme un produit fini, digne d’une « édition » en bonne et due forme. Les builds de développement peuvent être virtualisées sur les Mac M1, mais une reconnaissance officielle serait bienvenue.
"Va-t-elle aussi résoudre le problème des performances, point noir de l’émulation x86 sur Windows ?"
Ça marche plutôt bien sur les Mac M1... Le problème n'est peut-être pas logiciel...
@marc-5
si, c'est aussi logiciel.
@oomu
Quand on voit les performances franchement pas terrible de Photoshop Bêta en natif ARM sur une Surface Pro X, on se dit que c’est surtout le matériel qui est franchement pas terrible en terme de performances, et en l’occurrence ici le GPU Adreno intégré.
En effet, on aurait pu espérer des performances au minimum acceptables en natif sur Photoshop, et pourtant même en natif, ça rame, contrairement bien sûr aux Macs M1 qui font fonctionner Photoshop très bien que cela soit sur la Bêta native ARM64 ou via Rosetta 2.
Cela corrobore aussi les premières impression des apps Intel x86 sous Windows ARM virtualisé sur Mac M1 qui sont assez bonnes, bien meilleures que ce que craignait les testeurs au regard de ce qu’ils avaient vu sur Surface Pro X, et largement utilisable.
C’est une mauvaise nouvelle pour les utilisateurs de Surface Pro X qui pouvaient espérer que les mauvaises performances étaient principalement dues à l’émulation x86 alors que c’est très clairement principalement dû au matériel.
Ça explique probablement qu’Adobe n’ait pas portée Photoshop sur Windows ARM plus tôt alors qu’ils l’avaient promis, par communiqué de presse, à la sortie de la Surface Pro X. Ils ont certainement fait des POC et vue que cela nuirait bien trop à leur image s’ils le sortait au vu des performances exécrables.
Là en le sortant pour Mac M1 en même temps, cela leur permet de montrer que c’est une question avant tout de performances matériel.
Par contre c’est une bonne nouvelle pour les utilisateurs de Mac M1 qui souhaitent une solution de compatibilité Windows 10 suffisamment performante, y compris pour faire tourner des logiciels x86/x64, ils peuvent espérer que cela soit le cas en virtualisation, en particulier quand les versions optimisées M1 de Parallels et VMWare Fusion sortiront.
https://youtu.be/kcXkKBQT7Ps
@Frodon
Il y a déjà une beta de Photoshop native pour M1 sous macOS ? Ou uniquement pour Windows ARM ?
@flux_capacitor
Oui elle est sortie simultanément sur macOS et Windows
@Frodon
Super je ne savais pas, merci 🙏
L'écart de perf entre un Mac M1 et une Surface Pro X est tellement grand, que seul le matériel ne peut être en cause, il est certain qu'il y a une quantité astronomique d'amélioration à apporter sur l'OS.
@Valiran
Je parlais de Windows en virtualisation sur les M1, donc si c’est matériel.
Les Snapdragon ne sont pas assez puissants pour une bonne émulation.
L’émulation fonctionne bien sur les M1 et offre de bonnes performances mesurables via Geekbench.
Microsoft se prend une telle leçon sur le passage (inévitable) vers ARM...
Ce n’est que le début des emmerdes pour eux, la transition sera beaucoup plus dure que chez App’e vu qu’ils ne maîtrisent pas le hardware. Les fabricants hésiteront à faire du matériel faute d’apps, les développeurs hésiteront à faire des apps faute de matériel, et cette inertie va faire mal.
AMD s'y met donc d'ici 3 ans tu verras les machine ARM sous Windows partout dans les magasins. Elles remplaceront dans un premier temps les chromebooks puis les machines de bureau.
@bonnepoire
Mais comment acheter une machine si les apps tournent mal ? Et comment développer des apps si ARM représente une goutte d’eau dans l’ensemble des ordinateurs ?
@Furious Angel
très simple : les apps tourneront bien.
Les éditeurs de logiciels les plus en vus, feront l'effort de migrer, MS aidera les éditeurs de logiciels "stratégiques" (indispensable pour intéresser le public)
etc.
c'est plié. ce sont des structures qui savent faire ça.
On ne vous dit pas que ça sera d'un claquement de doigt, mais ça ne leur ait pas impossible et aucune raison que le marché leur échappe. Y a personne d'autre de toute façon.
@oomu
Sauf qu’actuellement, les apps tournent très mal.
@Furious Angel
"Sauf qu’actuellement, les apps tournent très mal."
Strictement aucune importance 😉
Oomu t’explique fort bien pourquoi.
@YetOneOtherGit
Ben à ce jour Microsoft n’y arrive pas. La réalité c’est ça. Le reste, ce sont des appréciations au doigt mouillé.
Nokia, IBM et bien d’autres ont vu leur business de base s’écrouler.
@Furious Angel
"Nokia, IBM et bien d’autres ont vu leur business de base s’écrouler."
Strictement incomparable tu ne veux pas voir le contexte de la domination de Windows et Intel 😉
@Furious Angel
> Mais comment acheter une machine si les apps tournent mal ?
Attention à ne pas prendre les benchs de la Surface X pour des benchs "windows sur ARM".
C'est surtout un benchmark de la puce de la Surface X, qui est loin d'être performance.
Y'a aucun raison que du code Windows (OS ou apps) natifs ou transcompilé tourne moins vite sur une puce ARM parce c'est du code "Windows". C'est du code ARM, natif ou transcompilé, point barre.
D'ailleurs la démo via QEmu d'un Windows ARM tournant sur un mac M1 le démontre très bien.
> Et comment développer des apps si ARM représente une goutte d’eau
> dans l’ensemble des ordinateurs ?
Comme pour le mac M1 : pas d'effort particulier si la transcompilation est suffisante au départ (et avec le support 32bits *et* 64 bits le champ est couvert), recompilation en natif dans un second temps si la part de marché des ordinateurs compatible Windows ARM le justifie.
Les apps qui sont optimisés à la mimine pour un jeu d'instruction CPU particulier sont extremement minoritaire. On est plus en 1990.
@byte_order
"Les apps qui sont optimisés à la mimine pour un jeu d'instruction CPU particulier sont extremement minoritaire. On est plus en 1990."
C’est une des choses qui a du mal à passer plus encore quand on annonce des versions “optimiser” M1 alors que ce n’est qu’un portage.
Beaucoup imaginent un travail d’optimisation spécifique au matériel, alors que les portions de code interagissant directement avec le matériel sont aujourd’hui rarissime et fortement déconseillés d’ailleurs.
Le choix des mots a un impact et les médias devraient préférer “Portage M1” à “Optimisation M1”
Le choix des mots a un impact et les médias devraient préférer “Portage M1” à “Optimisation M1”
Vu que les applis utilisent intensivement les frameworks ou api optimisés par Apple pour M1 le raccourci est tout à fait valable non?
@Manu
"Vu que les applis utilisent intensivement les frameworks ou api optimisés par Apple pour M1 le raccourci est tout à fait valable non?"
Les API et les Framework sont ceux de l’OS il ne sont pas liés au matériel c’est justement l’intérêt de ces approches.
On ne “parle” pas directement au matériel.
Il s’agit bien du portage sur un même OS mais sur une architecture matériel différentes, nullement d’une optimisation du code spécifique à une architecture cible.
Les api et frameworks sont plutôt liés au langage je crois. Par exemple chez Apple on a un AppKit en Objective-C et un AppKit en Swift. Le lien au matériel se faisant au biais de la compilation du programme avec un compilateur pour chaque langage. Tout cela tourne sur le même OS. OS lui même dont certains composants comme le Finder utilise entre autre le composant View de l'AppKit.
@Manu
"Les api et frameworks sont plutôt liés au langage je crois"
Pour essayer de schématiser une API (Application Programing Interface) est la part visible de l’extérieur d’une solution logicielle, pour pouvoir être utilisé par une autre solution logicielle.
On peut dire que c’est un ensemble de règles et de conventions pour obtenir des services d’un programme dans un autre programme.
Les OS modernes offrent, voir impose, l’usage de cette approche par des API pour interagir avec le matériel.
Le code dépend du matériel sous-jacent avant compilation est aujourd’hui assez rare et une bonne pratique est d’éviter le plus possible cela.
Formellement le Framework est un concept d’architecture: c’est un ensemble de composants génériques posant les bases d’une architecture.
Au final la tendance lourde depuis longtemps est d’abstraire le plus possible le code du matériel sous jacent qui l’exécutera.
Et les réelles optimisations dans le code source liées à l’architecture sont très rares pour des applications standard.
D’ailleurs de plus en plus de code n’est pas exécuté nativement sur le CPU mais via une machine virtuelle comme par exemple JavaScript qui est au cœur de ton browser web.
@Manu
"Par exemple chez Apple on a un AppKit en Objective-C et un AppKit en Swift. Le lien au matériel se faisant au biais de la compilation du programme avec un compilateur pour chaque langage."
Yep une API est une pure abstraction qui peut être instanciée dans divers langages.
Un OS moderne est une superposition de couches entre le matériel et l’application qui s’exécute et qui ne communique en général qu’avec les couches les plus élevée.
@Manu
"Tout cela tourne sur le même OS"
Un portage sur des plateformes d’OS multiples est bien plus complexe que sur un même OS avec une architecture différente.
Beaucoup d’acteurs passent par une couche intermédiaire dans leur architecture logicielle pour s’abstraire en partie des spécificités de l’OS.
Il est assez intéressant de voir comment des entreprises tel MS ou Adobe gèrent la contrainte d’avoir des produits multiplateforme.
Il y a quelques chouettes conférences en ligne sur ce type de sujets.
@ furious angel :
tu es un sacré visionnaire toi !
comme te l'as dit oomu, ça tournera ne t'en fait pas.
tu compare un système sur quelques machines vs un système sur des combinaisons de configurations dépassant l'entendement, comment veux-tu faire pour tout optimiser...
Pages