Est-ce qu'Apple peut remplacer le x86 par un processeur ARM ?, Réactions à la publication du 14/11/2014

[Lionel]

Voilà quelque temps que cette question taraude énormément de monde, et nous vous avons appris de source très fiable qu'Apple a dans ses cartons des Mac ARM prêts à être produits.
Est-ce qu'Apple va ou peut remplacer les processeurs x86 de nos Mac par des puces ARM? La question se pose d'autant plus vivement depuis que l'on en sait plus sur l'A8X est ses performances particulièrement élevées.

La réponse est aussi simple qu'évidente, oui Apple le peut ou le pourrait. Il lui suffirait de muscler encore la partie graphique de ses puces et de passer de trois à quatre ou six cœurs. On aurait alors des processeurs tout à fait aptes à faire fonctionner des Mac de manière très satisfaisante sous un environnement OS X tel qu'on le connaît.

Maintenant les vraies questions sont certainement ailleurs. En voici quelques exemples:

• Est-ce qu'une puce ARM boostée serait un meilleur choix qu'un processeur x86 d'Intel ? Ce n'est pas certain. En effet, pour gagner en puissance Apple va devoir augmenter les fréquence de ses puces et le nombre de leurs transistors. Or, Intel a fait d'énormes efforts de consommation dans ses processeurs récents, assez pour que la différence à puissance égale avec les puces ARM ne soit plus aussi évidente à voir. Pour s'en convaincre il suffit de voir l'autonomie des plus récents MacBook Air, on arrive facilement à une longue journée de travail sans les recharger.
• Est-ce qu'Apple a un intérêt commercial à passer du x86 à l'ARM ? Oui et non. Oui, car la société pourra proposer des machines réellement différentes de tous les autres PC, et on peut être assuré que ce sera le principal but d'un éventuel changement d'architecture. D'un autre côté, perdre la compatibilité x86 via BootCamp sera sans conteste un manque qui freinera beaucoup d'acheteurs potentiels.
• Est-ce que ce serait une bonne affaire au niveau du prix des composants ? D'un côté Apple n'aura plus à payer Intel en monopole, de l'autre, Intel fait payer à Apple un prix qui n'a rien à voir avec celui auquel on peut acheter un processeur.
• Est-ce que ce serait un gage de réussite à l'avenir ? Rien n'est moins sûr. En prenant le train Intel (quitte à s'en étrangler), Steve Jobs a en 2005 préparé sa sortie d'Apple et pérennisé son département ordinateur (pratiquement le seul à l'époque). Diverger du monstre Intel pourrait soit provoquer une réussite, soit en cas d'un quelconque accident industriel provoquer la chute.

Une dernière question pour couper court à certains fantasmes:

• Est-ce qu'il serait possible de faire un rosetta x86 sous ARM. Oui, mais il faudra dans ce cas des puces ARM au moins deux fois plus puissantes que leur pendant Intel. Autant dire que ce n'est pas pour demain sauf à renoncer à toute idée d'efficacité énergétique et l'on passerait donc d'une décision empreinte d'un certain pragmatisme à une autre purement dogmatique.

Lien vers le billet original

[aigo]

Non pas besoin de Rosetta, rappelez-vous du temps de NeXTStep, une application avec Fat Binary, lors du build il suffit de cocher tous les type de CPU qu'on veux supporter.

[GregWar]

Non pas besoin de Rosetta, rappelez-vous du temps de NeXTStep, une application avec Fat Binary, lors du build il suffit de cocher tous les type de CPU qu'on veux supporter.

J'en rajoute une louche désolé… mais même sans entrer dans la technique, ou reprendre le cas ADOBE (déjà fait), les techniques "Yaka-focon", c'est un peu marketing, non ?

Ok, donc "il suffit de cocher", en admettant que ce soit vrai… prenons par exemple: mon driver de ma clef 3G.
J'ouvre XCode… ok, facile.
J'ouvre Fichier > Ouvrir… ok, facile.
Et… ah ? quoi les sources ? ah mince.

Admettons j'ai un coup de chance fétide, c'est sur GitHub/SourceForge, etc… 
Bon bah, youpi, je télécharge… ok, facile.
Je reprends, j'ouvre… je prie pour trouver un fichier xcode, ouf.
Quoi, Framework ? version ? plateforme ? target ? build ? 32bits ?
Bonjour, mais qui êtes vous ? Et, c'est quoi tout ce rouge?

Google…. 3h…. cours de programmation accéléré… 2jours… ouf je comprends presque de quoi on me parle.
Ah, ca date de 2011, hum ca compile sur SnowLeo, parce que ceci-cela, et qu'Apple a au mieux déprécié la moitié des Apis (3 ans c'est long déjà pour Apple).



Bref, tout ça pour dire que pour le mec qui a fait l'implémentation initiale, sans doute, dans les cas simples, il peut en qqs heures seulement proposer une target supplémentaire.
Mais si il n'est plus la, ne veut pas, ne veut plus… ou qu'il a pas le temps pour le moment… t'es bien content qu'il faille juste "cocher une case".

[Guest_dtb06_*]

Non pas besoin de Rosetta, rappelez-vous du temps de NeXTStep, une application avec Fat Binary, lors du build il suffit de cocher tous les type de CPU qu'on veux supporter.

J'en rajoute une louche désolé… mais même sans entrer dans la technique, ou reprendre le cas ADOBE (déjà fait), les techniques "Yaka-focon", c'est un peu marketing, non ?

Ok, donc "il suffit de cocher", en admettant que ce soit vrai… prenons par exemple: mon driver de ma clef 3G.
J'ouvre XCode… ok, facile.
J'ouvre Fichier > Ouvrir… ok, facile.
Et… ah ? quoi les sources ? ah mince.

Admettons j'ai un coup de chance fétide, c'est sur GitHub/SourceForge, etc… 
Bon bah, youpi, je télécharge… ok, facile.
Je reprends, j'ouvre… je prie pour trouver un fichier xcode, ouf.
Quoi, Framework ? version ? plateforme ? target ? build ? 32bits ?
Bonjour, mais qui êtes vous ? Et, c'est quoi tout ce rouge?

Google…. 3h…. cours de programmation accéléré… 2jours… ouf je comprends presque de quoi on me parle.
Ah, ca date de 2011, hum ca compile sur SnowLeo, parce que ceci-cela, et qu'Apple a au mieux déprécié la moitié des Apis (3 ans c'est long déjà pour Apple).



Bref, tout ça pour dire que pour le mec qui a fait l'implémentation initiale, sans doute, dans les cas simples, il peut en qqs heures seulement proposer une target supplémentaire.
Mais si il n'est plus la, ne veut pas, ne veut plus… ou qu'il a pas le temps pour le moment… t'es bien content qu'il faille juste "cocher une case".

De plus, moi qui ne suis absolument pas codeur, rien qu'à voir les performances des trucs multiplateformes (Java/Flash), je ne suis pas convaincu.