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

[iAPX]

Apple a déja eu deux gammes avec deux architectures, voire trois architectures différentes au niveau applicatif, et ça ne pose que peu de problèmes sur les logiciels grand-public (sans code natif)...

C'est peut-être l'occasion pour Apple de rebondir coté technologies et de se différencier des assembleurs de PC, en fait des cabinets de designs (si tant est qu'un parallélépipède rectangle puisse être qualifié de tel), qui font concevoir et fabriquer ailleurs.

[fuby]

Apple a déja eu deux gammes avec deux architectures, voire trois architectures différentes au niveau applicatif, et ça ne pose que peu de problèmes sur les logiciels grand-public (sans code natif)...

C'est tout l'opposé ! Apple ne fournir des outils que pour faire du code natif ! c'est d'ailleurs pour cela qu'ils demandent l'architecture cible DES LE DEBUT D'UN PROJET Xcode.
Et c'est bien la le problème, le code natif DEMANDE de l'emulation, non pas comme sur android, qui utilise Java et de la "compilation" a la volée qui simplement transforme le bytecode java en code natif du CPU de la machine (c'est pour cela que android exist sur atom simplement)



A l'heure actuelle, tout est possible, la question est principalement : pourquoi le faire !

Si c'est juste pour le fun technique : c'est pas un bonne raison pour Apple
Si c'est pour avoir plusieurs architectures : ils en on deja plusieurs, ARM et x86
Si c'est pour du pognon : c'est un bonne raison pour Apple !


Il faut quant meme comparer ce qui est comparable : les CPU ARM Apple sont comparable a des atom, voire des core i3 pas trop rapides, et Apple n'utilise ni l'atom, ni le core i3.
La seule raison pour Apple de passer a de l'ARM c'est pour faire des marges plus grosses, mais sur quel type de produit ? les portable bas de gamme genre netbook : Apple ne fera jamais de netbook, c'est trop "bas peuple"

Ensuite, vouloir passer sur ARM : pourquoi penser a Mac OS X, et pas simplement iOS avec un portable, tactile : en somme un "ipad pro" avec un clavier a du sens pour attaquer le marche de l'entreprise : gerer les portables comme les tablettes et les telephones portables, avoir la possibilité du tactile, avec l'avantage du multi device, et enfin, des applications (natives) des le debut, la seule difference pouvant etre la RAM (plus grosse) et les connecteurs (USB ?, ou plutôt lightning ;-)) enfin, plus de problème de development de l'architecture car elle propose la meme unique, et l'on un un gamme mobile/portal unique, et surtout des marges bien plus grande car on a la R&D, et on paye uniquement la fabrication du CPU.

Non, ça reste en fait le nom d'un simple compilateur, qui est simplement mieux optimisé pour Objective C (et sans doute Swift) que ne l'est le GCC. En fait, LLVM n'est plus un sigle et les quatre lettres ne se réfèrent plus forcément à une machine virtuelle, vu que le projet a très vite élargi sa mission par rapport à la vocation du début (j'avais d'abord écrit "initiale" mais c'était ambigu).

Je rappelle que les applications disponibles sur OS X (enfin sauf celles en Java) ou iOS sont compilées, à la différence d'Android, qui fonctionne avec une machine virtuelle et une compilation JIT. Là, la question de la transition d'architecture ne se pose plus du tout.

clair, et c'est pour cela qu'en meme temps, cela permet a Apple de gerer certain fonction plus facilement, et de maniere moins problematique, notamment sur la gestion de memoire (Java peut etre tres complique pour la gestion de la memoire, et de ce que l'on appelle le "garbage collector" qui demande enormement de ressource et de temps, encore plus sur des ressources mobiles) au prix d'un programation simplifee en JAVA (pas de gestion de la memoire implicite)

[Ambroise]

Et c'est bien la le problème, le code natif DEMANDE de l'emulation, non pas comme sur android, qui utilise Java et de la "compilation" a la volée qui simplement transforme le bytecode java en code natif du CPU de la machine (c'est pour cela que android exist sur atom simplement)

Une précision concernant le code natif sur Android :
L'essentiel des applications sont développées en Java, et les applications sont distribuées sous forme de bytecode. C'est lors de leur installation qu'elles sont éventuellement recompilées (à partir du bytecode) pour s'adapter à l'architecture de la cible.
Par contre les parties d'applications qui réclament de la puissance, ou bien dont ont voudrait limiter la consommation de certains traitements sont développées en C++ et compilées en binaire natif. Dans l'immense majorité des cas elles ne sont compilées que pour les ARM.
Intel a développé avec Google des outils qui font de la traduction de binaire ARM vers du x86 et qui permettent d'avoir les deux versions sur Google Play. Cela permet aux Android x86 d'exécuter les applications natives ARM mais c'est loin d'être la panacée. En moyenne la traduction fait perdre 40% d'efficacité par rapport à du cote qui aurait été compilé nativement pour x86.