Après des mois d’attente, Microsoft a finalement déployé son émulateur x64 pour Windows ARM. Ce dernier est disponible pour les testeurs du système.
1 « J'aime »
C’est une bonne nouvelle.
Sur les pas d’Apple.
1 « J'aime »
la différence entre apple et micrsoft est ! l’un innove pour le futur, l’autre pour le passé.
Quand est-il du dev ARM pour le soc maison chez micrsoft ? Sortira ou sortira pas ? On peut dire qu’Apple a fait un énorme boulot, tout comme AMD ! C’est deux là ont réussis leurs innovations contrairement à d’autres.
2 « J'aime »
Le soucis est que le développement natif ne se fait plus sur l’API Windows historique (normal), mais sur Universal Windows Plateform (UWP) qui oblige à une distribution via le store.
Or les développeurs Windows ne sont pas habitué à donner 30% de leur chiffre d’affaire à un store et ne sont guère enclin à mettre le doigt dans l’engrenage.
C’est pour cela que le Store Windows 10 reste désespérément vide (comparé à celui d’Apple ou de Google).
@bmustang : Avec le M1, Apple frappe fort, mais non, MS innove aussi.
Ils ne sont pas plus bête que les autres.
Ils ont montré des projets vraiment sympa : comme la surface Néo ou la Surface Studio.
Leur téléphone a été un échec commercial, mais il était très très bien.
Les portables sous Windows ont des écrans tactiles depuis un moment, des écran détachables ou retournables etc.
On voit bien - depuis Windows RT - que MS cherche désespérément à se débarrasser de la compatibilité Intel dont ils sont prisonnier. Mais ni les utilisateurs, ni les développeurs ne veulent de cette rupture pour des raisons différentes.
Sans compter qu’il y a d’autres facteurs, comme celui qu’Apple amorti le cout de ses processeurs sur l’ensemble de la machine, contrairement à Intel qui doit vendre ses processeurs sec et des assembleurs qui margent peu.
2 « J'aime »
Intel va devoir sortir une architecture avec un jeu d’instruction plus efficace s’ils veulent survivre. Et vite.
1 « J'aime »
« On voit bien - depuis Windows RT - que MS cherche désespérément à se débarrasser de la compatibilité Intel dont ils sont prisonnier. Mais ni les utilisateurs, ni les développeurs ne veulent de cette rupture pour des raisons différentes. »
Microsoft n’a pas toujours été lié à l’architecture x86. Puisque jusqu’à nt4 inclus on pouvait installer sur du mips ou même alpha, power pc ou itanium par exemple. Cependant les applis porté pour l’une ne fonctionnaient pas sous l’autre sans une nouvelle compilation. Microsoft a grandement aidé le développement d’un parc massif de compatible PC. Ce qui a naturellement entraîné qu’enormement d’acteurs ont concentré leurs efforts uniquement sur du x86. Le marché a donc pousser m$ d’en faire autant. Et avec l’émergence d’ARM il concentre un nouvel effort de portage. L’émulation va ici permettre aux usagers de faciliter la transition d’architecture. Mais il n’y a pas d’histoire d’être prisonniers d’Intel et ça n’a jamais été le cas. C’est une opportunité de marché.
Intel va devoir sortir une architecture avec un jeu d’instruction plus efficace s’ils veulent survivre. Et vite.
L’idée que les jeux d’instruction RISC seraient plus efficace, elle date des années 80.
Beaucoup de choses ont changé depuis.
En espérant que les developpeurs prennent quand même peu à peu l’habitude developper pour les 2 architectures, pour gagner encore en performance…mais je suis dubitatif.
Intel ou ARM, 32 ou 64 bits, ça ne change absolument rien pour un bon développeur.
Si un programme est écrit correctement au départ, il suffit de recompiler et ça fonctionne.
2 « J'aime »
Ce qui est sûr c’est que les ordinateur portable sous ARM sont le futur pour le grand public. Cela ne m’étonnerait pas que dans quelques années, les ventes de laptop soient monopolisées par des ordinateur sous processeur ARM.
C’est tout bénéf pour le grand public, on a des ordinateurs plus performants, moins chers, avec une meilleure autonomie et moins encombrants comme le refroidissement est passif et non plus actif avec des ventilateurs comme avec les architecture x64…
C’est plus complexe qu’une histoire de débat des années 80. Les processeurs x86 et apple ARM sont des processeurs à exécution dans le désordre, qui décodent les instructions à l’avance pour déterminer quelles sont les dépendances de registres et mémoire, pour les distribuer vers les unités d’exécution. On peut multiplier les unités d’exécution, et c’est ce qu’apple a fait, mais il faut pouvoir leur trouver quoi faire, et donc décoder le maximum d’instructions. Or les instructions ARM ont une longueur fixe, ce qui fait qu’on peut les décoder très à l’avance et en parallèle, alors que le décodage des instructions x86 doit se faire en séquence (je simplifie) car la position de chacune dépend du codage des précédentes. On pourrait imaginer un nouveau front end à instructions simples et de taille fixe, avec plus de registres, et ce ne serait pas très difficile à faire pour Intel car l’essentiel de la complexité des processeurs est dans le back-end, et Intel l’a déjà fait avec l’implémentation du mode 64 bit qui a un codage différent.
L’idée que les jeux d’instruction RISC seraient plus efficace, elle date des années 80.
Beaucoup de choses ont changé depuis.
Je regrette mon palm avec piou piou palyer et poulpx , cette architecture récente ARM pourrai me convenir mais au niveau professionnel avec beaucoup de ram pour la mao , version tablette avec prise en charge de ma MOTU
C’était vrai avec Windows RT, ça n’est plus le cas depuis Windows on ARM.
On peut multiplier les unités d’exécution, et c’est ce qu’apple a fait, mais il faut pouvoir leur trouver quoi faire, et donc décoder le maximum d’instructions. Or les instructions ARM ont une longueur fixe, ce qui fait qu’on peut les décoder très à l’avance et en parallèle, alors que le décodage des instructions x86 doit se faire en séquence (je simplifie) car la position de chacune dépend du codage des précédentes. On pourrait imaginer un nouveau front end à instructions simples et de taille fixe, avec plus de registres, et ce ne serait pas très difficile à faire pour Intel car l’essentiel de la complexité des processeurs est dans le back-end, et Intel l’a déjà fait avec l’implémentation du mode 64 bit qui a un codage différent.
Justement, par rapport au fonctionnement d’un processeur moderne, ce n’est pas forcément un problème majeur. Rappelons qu’en pratique les x86 exécutent de nombreuses instructions par cycle. S’il ne parvenaient pas du tout à paralléliser le décodage, il serait par définition impossible de dépasser un IPC unitaire.
Et il ne faut pas mal interpréter le le fait qu’un processeur RISC doit être prévu pour décoder plus d’instructions par cycle. C’est d’abord est lié à un inconvénient majeur de ce type d’architecture : le fait de nécessiter plus d’instructions pour résoudre un même problème. Il faut un IPC plus élevé pour atteindre une efficacité comparable à un CISC. Amusez vous à charger une constante immédiate dans un registre sur un ARM et vous comprendrez ce que je veux dire.
Ce qui nous amène à l’une des tare majeur du RISC, à savoir une consommation de bande passante mémoire supérieure. A long terme, avec l’augmentation du nombre de coeurs, cela pourrait être un inconvénient majeur.
D’ailleurs, les RISC ne sont pas les processeurs les plus efficients en terme de décodage. Car décoder n’est que la première étape d’un processus. Par exemple, les architecture VLIW sont en mesure d’arriver à une complète parallélisation de l’ensemble du processus.
Intel à été l’un des rare fabricant à réaliser un tel processeur généraliste (l’Itanium pour rappel) sait mieux que quiconque pourquoi l’enjeu n’est pas forcément la.
Parce qu’en réalité, c’est un faux débat. La limite majeure de la parallélisation par le processeur n’est aujourd’hui plus tant le matériel que le logiciel lui même qui est écrit de façon majoritairement séquentielle et ne permet pas d’extraire beaucoup plus de parallélisme.
Attention, le code est essentiellement séquentiel mais le CPU analyse de 500 à 800 instructions (selon le CPU) pour repérer les chaînes parallélisables. On voit là l’intérêt de décoder le maximum d’instructions pour repérer ces chaînes. Les ARM et x86 continuent de s’améliorer dans ce domaine. De plus, ils continuent d’ajouter des unités d’exécution spécialisées, ce qui prend de la place sur la puce. Et il y a plus de place à prendre sur une architecture simple que sur un x86 qui est ultra-complexe et qui a besoin de plein de transistors juste pour supporter les très nombreux modes et instructions plus ou moins utiles.