Mac ARM: Apple pourrait attendre encore un an ou deux, Réactions à la publication du 16/01/2015

[Lionel]

A plusieurs reprises nous vous avons rapporté de source très fiables qu'Apple avait dans ses cartons des prototypes totalement fonctionnels de Mac dotés de processeurs ARM.
Un célèbre analyste appelé Ming-Chi Kuo y croit. Mais pour lui, et nous sommes d'accord, Apple n'a pas l'intention de sortir ces machines dans un avenir proche. La société pourrait attendre au moins un an ou deux pour se lancer et prendre un des plus gros paris de son histoire récente.

Toujours selon ses informations, Apple aurait besoin de ce temps pour que ses puces ARM soient capables de concurrencer un processeur Core i3 ou un Atom. Cela permettrait à la société de proposer toute une entrée de gamme ARM, le reste devant continuer à tourner sur des processeurs Intel.

Cela introduit l'idée qu'Apple puisse avoir deux gammes de Mac avec deux architectures radicalement différentes. Ce serait difficile à gérer et même Microsoft qui avait deux modèles de tablettes Surface, une ARM et une x86 a fini par jeter l'éponge sur le premier modèle, se focalisant sur le second.
En effet, on aurait alors des Mac pouvant faire tourner certains logiciels, chose dont les autres modèles ne seront pas capables, un vrai casse-tête même au niveau commercial. Certes, certains imagineront à nouveau un miracle Rosetta mais nous vous rappelons qu'Apple avait réussi ce pari de l'émulation en remplaçant dans tous ses modèles un processeur G4 ou G5 par deux coeurs x86 déjà plus puissants individuellement. Or, il serait aujourd'hui certes possible de proposer un processeur ARM doté de 8 ou 16 cœurs puissants, mais il aurait alors une consommation supérieure à son pendant chez Intel, ce qui réduirait de manière totale son intérêt.
Lien vers le billet original

[Tophe974]

Encore une fois : oui, peut-être qu'il y a les deux dans le paquet, mais ça n'empêche pas qu'il y a quand même un mec à la base qui a été obligé de coder pour deux architectures différentes. Ce n'est pas parce que tu codes un truc pour un processeur ARM que magiquement ton compilateur te sort une version x86 à côté.
C'est comme si j'offre un CD et un livre à ma petite cousine, je peux très bien faire un seul paquet global donc un seul cadeau, ça ne m'empêcheras pas d'avoir à acheter les deux séparément !

C'est bien pour ça qu'on code avec un langage "haut niveau" et pas en assembleur : ton même source en C peut tout à fait compiler pour ppc, ppc64, x86, x64, arm et arm64.
Il y a bien sur quelques règles à respecter, mais en utilisant les frameworks d'aujourd'hui, le surcoût en développement est nul ! (je ne parle pas des tests ici).
Si on regarde le passage en 64bits sur iPhone, il n'a posé aucun problème majeur.
Il n'y a guère que les personnes qui injectent du code assembleur qui ont eu du boulot ; mais ça, ils le savaient dès le début.
Pour 99% des applications, pas 1 seule ligne d'asm est nécessaire.
Le 1% restant ? je peux découper le besoin en 2 :
- ceux qui le font pour la beauté
- ceux qui en ont vraiment besoin : ces personnes auraient de toutes façons retravaillé leur soft pour profiter de la nouvelle architecture processeur disponible

Intel a accepté d'utiliser un jeu d'instruction 64 bits compatible avec celui d'AMD : c'était plutôt une preuve de bonne volonté. Ils auraient pu imposer leur propre version en profitant de leur position dominante.
Et quand aux difficultés qu'ils auraient éprouvé pour rattraper leur retard sur AMD ? leur premier processeur x86 64 bits est sorti 6 mois après le K8... Visiblement ils étaient à l'aise sur la question.

C'est surtout Microsoft qui a imposé son choix à Intel, en leur expliquant :
- qu'ils avaient déjà fait un portage vers Itanium, et que les performances pour le grand publique n'étaient pas convaincantes
- qu'ils avaient déjà fait un autre portage 64 bits vers l'archi AMD64 (maintenant nommée x86_64)
- qu'ils n'allaient pas refaire un 3è portage 64 bits vers une nouvelle extension x86 64 bits.

[Ambroise]

C'est surtout Microsoft qui a imposé son choix à Intel, en leur expliquant :
- qu'ils avaient déjà fait un portage vers Itanium, et que les performances pour le grand publique n'étaient pas convaincantes
- qu'ils avaient déjà fait un autre portage 64 bits vers l'archi AMD64 (maintenant nommée x86_64)
- qu'ils n'allaient pas refaire un 3è portage 64 bits vers une nouvelle extension x86 64 bits.

Microsoft a bien annoncé qu'ils ne souhaitaient pas développer deux versions 64 bits de Windows x86 et on les comprend. Mais ils n'ont rien imposé à Intel (et il n'aurait pas pu le faire quoi qu'il en soit : si Intel avait sorti sa propre version 64 bits les processeurs Intel auraient continuer à faire 90% des ventes quoi qu'il en soit et la version d'Intel se serait imposée d'elle-même).
Intel a décidé d'être (à peu près) compatible avec l'architecture présentée par AMD dès le lancement du projet Yamhill en 2001, soit 4 ans avant la sortie de la version x64 de Windows XP Pro. Et le premier processeur x86 64 bits d'Intel est sorti près d'un an avant la présentation de Windows XP Pro x64.

Pour moi la raison principale qui a conduit Intel à rester compatible avec AMD c'était avant tout que l'implémentation d'AMD était intelligente et correspondait en grande partie aux extensions 64 bits possibles dont Intel avait déjà parlé dix ans auparavant. S'ils avaient choisi leur propre architecture, ils auraient de plus pris le risque d'un procès pour abus de position dominante. Mais l'influence de Microsoft n'a à mon avis pu n'être que marginale. Ils auraient pu au pire faire leur mauvaise tête en ne livrant que des versions OEM limitées à AMD de Windows XP Pro x64 entre 2005 et 2007: mais dès la sortie de NT 6.0 (Vista) en 2007 ils seraient revenus à la crèmerie Intel pour être compatibles avec les millions de processeurs x86 vendus entre temps.