Un Mac ARM : avec ou sans Intel ?

Mickaël Bazoge |

Sous le capot du Mac, une puce ARM. Un scénario de science-fiction il y a encore quelques années, mais depuis l'apparition des puces T1 et T2 dans le MacBook Pro et l'iMac Pro, cette hypothèse n'en est plus une : petit à petit, les Mac sont bien en train de basculer dans un nouveau monde.

Il n'y aura sans doute pas de grand soir pour le Mac : un jour, la puce ARM d'un Mac prendra en charge la majorité des fonctions de l'ordinateur, ne laissant plus au processeur Intel que les tâches de calcul les plus lourdes. Cette inversion des priorités, qui va se concrétiser petit à petit, apparaitra comme la chose la plus normale au monde.

Image Marques Brownlee. Cliquer pour agrandir

Et il est même probable qu'Apple se décide à éjecter Intel de ses Mac lorsque le constructeur estimera que ses puces ARM sont suffisamment polyvalentes et puissantes, et son écosystème logiciel assez robuste pour supporter cette nouvelle transition.

Et cela pourrait arriver vite, plus rapidement qu'on ne le pense. Mais commençons par le commencement.

Au commencement, il y avait déjà le Mac ARM

Les Mac ARM, ils existent déjà : les MacBook Pro Touch Bar et l’iMac Pro sont équipés de puces ARM développées par Apple. Outre gérer divers composants (barre tactile sur le portable, caméra FaceTime et plus sur le tout-en-un), les T1 et T2 ont une lourde responsabilité : la sécurité du Mac.

De fait, la puce T1 est la porte d'entrée du MacBook Pro ; c'est par le biais de son enclave sécurisée qu'on s'identifie, c'est donc elle qui permet l'utilisation de l'ordinateur… La puce T2 de l’iMac Pro va plus loin encore : elle a en charge la séquence de démarrage sécurisé de l'ordinateur (validation du boot loader, qui valide le firmware, qui valide le kernel qui enfin valide les pilotes).

Image @Cabel Sasser. Cliquer pour agrandir

Mais ce n'est pas tout. La puce T2 prend également en charge le chiffrement AES des données, soulageant ainsi le processeur Xeon de cette tâche, et les clés de sécurité du système sont stockées dans son enclave sécurisée. La T2 fait aussi office de contrôleur de gestion du système (SMC) et s'occupe donc des fonctions bas niveau comme la gestion thermique, la gestion de la batterie, l’utilisation du bouton d’alimentation, la prise en charge d’une source vidéo externe, etc.

En attribuant aux puces Tx la gestion de fonctions aussi vitales, Apple ne fait pas que déshabiller Intel. Le constructeur dessine aussi l’esquisse d’une feuille de route qui transforme déjà en profondeur sa gamme d’ordinateurs. En posant un verrou ARM au cœur même du Mac, Apple s’assure de la meilleure sécurité possible alors que macOS ploie sous le poids d’un héritage de presque vingt ans.

Cliquer pour agrandir

Sécurité, performances, autonomie

Pour sa plateforme mobile, Apple a eu toute liberté de mettre au point des systèmes sécurisés très performants, à l’image de l’architecture de l’enclave sécurisée réputée inviolable (même si tout n’est pas parfait évidemment). La retrouver sur Mac a du sens, même si cela nécessite d’accoler au processeur d’Intel un système-sur-puce.

Cliquer pour agrandir

Il y a la problématique de la sécurité qu'Apple maîtrise avec ses différentes puces ARM. Mais sans puissance, la maîtrise n'est rien. C'est presque devenu un lieu commun, mais les performances dégagées par l'A11 Bionic des iPhone 8/8 Plus et X n'ont désormais rien à envier aux processeurs Intel les plus courants.

Cliquer pour agrandir

Les processeurs Core d’Intel ont d’autres atouts, ils assurent sur une plus longue durée les charges de travail les plus lourdes, ce qui est indispensable pour certaines activités (rendu 3D, exportation vidéo, etc.). Mais en développant en interne les moteurs sous les capots de ses appareils mobiles, Apple a toute latitude pour pousser telle ou telle technologie. On l'a vu avec la réalité augmentée, qui nécessite une grosse puissance de calcul couplée à une parfaite intégration matérielle.

La puissance des cœurs des puces ARM d'Apple n'est plus à démontrer, et demain rien n'empêchera les Mac d'en profiter eux aussi si d'aventure Apple le souhaite. Il en va d’ailleurs de même pour les graphismes, pour lesquels le constructeur développe depuis l’iPhone 8 et X ses propres puces.

L’autonomie enfin est aussi un secteur dans lequel Apple excelle. Aussi bien sur iOS que macOS d’ailleurs, la maîtrise du logiciel et du matériel fait des miracles. Même avec des batteries aux capacités plus réduites, l’iPhone ou l’Apple Watch font tout aussi bien que la concurrence, voire mieux.

Le développement d'un contrôleur d'alimentation en interne court depuis le mois d'avril, et ce bruit de couloir a récemment rebondi. Après la sécurité et les performances, l'autonomie : que va-t-il rester aux processeurs Intel ?

Apple pourrait-elle lancer demain un Mac uniquement équipé d’un moteur ARM ? Sans doute. Après tout, le constructeur a déjà une expérience, malheureuse certes, d’un ordinateur doté d’une puce ARM : l’eMate ! Ce portable avec écran tactile, stylet et clavier fonctionnait avec le système d’exploitation du Newton ; il se destinait au marché de l’éducation. La commercialisation du produit, lancé en mars 1997 au prix de 800 $, s’est arrêtée un an plus tard en même temps que Steve Jobs éjectait la division Newton.

L’eMate est la preuve qu’Apple peut repartir d’une page blanche en s’appuyant sur une architecture complètement différente. Bien sûr, l’époque était bien différente… Mais par bien des aspects, le constructeur a aujourd’hui toutes les cartes en main pour se relancer sur ce marché et réussir. Il reste toutefois de sérieux obstacles sur la route, à commencer par l’héritage logiciel.

Hypothèse 1 : un Mac ARM avec un moteur Intel

Balancer le fondeur de Santa Clara par-dessus bord ? Apple n’y est sans doute pas encore prête. Les versions iOS des logiciels les plus emblématiques (Photoshop, Office…) restent encore deux ou trois crans en dessous de leurs modèles « de bureau ». On trouve certes des applications très puissantes sur iOS et globalement, on peut accomplir sur un iPad 80% voire 90% de ce qu'on peut faire sur un Mac.

Mais pour des activités spécifiques, le Mac est toujours incontournable — ne serait-ce que pour les développeurs iOS ! Xcode n'a toujours pas été porté sur iPad, et dans un autre domaine les monteurs vidéo n'auraient rien contre une version tactile de Final Cut Pro. Difficile en effet de faire une croix sur une logithèque si riche et si productive.

La perspective d'un Mac reposant entièrement sur une puce ARM a du sens, mais pas pour tout le monde donc. Dans cette optique, Apple pourrait poursuivre sur la lancée inaugurée avec le MacBook Pro du tandem ARM + x86, en laissant au premier la gestion de plus en plus de fonctions de base (sécurité, autonomie, performances graphiques), et au second le support des logiciels « historiques » avec en sus toute la puissance nécessaire (lire : Le Mac n'est (bientôt) plus un PC comme un autre).

Hypothèse 2 : un Mac ARM, et c’est tout

Une fois n’est pas coutume, Apple pourrait aussi tout simplement emprunter le même chemin que Microsoft. L’éditeur de Windows s’est lancé avec Qualcomm dans l’aventure ARM avec des « Mobile PC » équipés du Snapdragon 835. Ces ordinateurs fonctionnent sous Windows 10, on peut utiliser toute la riche logithèque historique du système d’exploitation.

Les deux larrons mettent en avant deux atouts : la connexion LTE de ces PC et leur autonomie d’une vingtaine d’heures. Il y a effectivement de quoi interpeller alors qu’Apple vante une autonomie d’une dizaine d’heures (ce qui arrive assez rarement). Les atouts ARM couplés avec ce bon vieux Windows : et pourquoi pas la même chose mais pour les Mac !

La course d’obstacles d’un macOS sous ARM

Mais cela signifie qu’Apple a dans sa manche une version de macOS capable de fonctionner parfaitement sur une puce ARM. On imagine mal en effet Apple vendre un Mac sous iOS, même si les deux systèmes sont basés sur toujours plus de technologies similaires (APFS est commun aux deux, par exemple).

En 2015, Tim Cook déclarait : « nous ne croyons pas en un unique système d'exploitation pour le PC et pour le mobile », et il soulignait la nécessité de maintenir la meilleure expérience possible sur les deux plateformes. En fait, la tentation est grande d'imaginer une version de macOS expérimentale s’appuyant déjà sur un processeur ARM dans le secret des labos souterrains d'Apple.

Le penser n'est pas totalement farfelu : dès 2001, Mac OS X roulait déjà sur des PC x86 alors que la grande transition vers les processeurs d'Intel n'a débuté qu'à l'été 2005 (lire : OS X sur Intel : aux origines du projet Marklar). L'idée de passer du PowerPC à Intel était même une des motivations de l'acquisition de NeXT en 1996…

En 2014, nous recevions des informations selon lesquelles Apple planchait sur une version ARM d'OS X, mais aussi sur l'adaptation de plusieurs logiciels maison, le tout sans inquiétude pour les performances (lire : Mac ARM : pas encore une réalité, mais plus un rêve). On a de la suite dans les idées à Cupertino !

Un Mac dont le moteur est une puce ARM fait trembler bien des utilisateurs qui ne sauraient se passer de Windows. La virtualisation est en effet très facile depuis le passage à Intel, que ce soit via un logiciel tiers comme Parallels ou le propre Boot Camp d’Apple. Il se trouve que la Pomme a une solution maison depuis Yosemite (OS X 10.10) : un hyperviseur, une plateforme de virtualisation avec laquelle on peut faire fonctionner d'autres OS sur le Mac.

Parallels distribue sur le Mac App Store une version allégée de son logiciel de virtualisation, Parallels Desktop Lite. Ce n'est pas encore la panacée, toutes les fonctions n'y sont pas et puis les performances restent en-deçà de celles du logiciel d'origine, mais les bases sont là (lire aussi : 10 ans de Parallels : « Nous essayons de faire disparaître Windows dans le Mac »).

L’héritage logiciel

Il parait difficile de faire une croix sur le catalogue logiciel de macOS. On peut toujours imaginer que les développeurs d’applications, notamment celles pour iPad, puissent les adapter pour un Mac dépourvu d’écran tactile. Mais d’autres ne seront jamais optimisées, c’est pourquoi un émulateur devra sans doute être mis au point. Dans ce domaine aussi Apple a de l’expérience.

La précédente transition PowerPC vers x86 s'était ainsi déroulée presque sans anicroche grâce à Rosetta qui a tiré sa révérence en 2011 avec OS X 10.7 (Lion). Cette « pierre de Rosette » était épatante, mais elle tirait beaucoup sur la batterie et les performances des logiciels « traduits » à la volée étaient en retrait.

De plus, et c'était peut-être le revers le plus important de Rosetta, sa présence au sein d'OS X ne poussait pas les éditeurs à adapter leurs logiciels à la nouvelle donne, ce qui explique en partie sa longévité. On peut penser qu’Apple fera le maximum pour pousser les éditeurs à s’adapter le plus rapidement à la nouvelle donne. Par exemple en prenant en charge une grosse partie du travail d’optimisation en échange d’une distribution par le Mac App Store…

On peut ainsi imaginer que les applications distribuées sur le Mac App Store (pour macOS Intel, donc) puissent être recompilées automatiquement pour macOS ARM. Les développeurs n'auraient donc aucun travail à faire, la moulinette d'Apple se chargeant du sale boulot à leur place…

Cliquer pour agrandir

Apple devra injecter des ressources pour redresser la barre du Mac App Store, laissé en jachère depuis de trop longues années. Ce faisant, la boutique se placerait au cœur de l'expérience de ce nouveau macOS, comme l'App Store l'est pour iOS.

Malgré tous les efforts qu'Apple voudra faire pour faciliter la vie des utilisateurs et des développeurs, l'éventualité d'un Mac tout ARM fera, c'est certain, grincer pas mal de dents. Mais un des avantages de cette transition est qu'elle permettra à tous de faire le ménage dans ses habitudes : il est toujours bon de se demander si tel ou tel vieux logiciel est réellement utile — ou si une autre application plus moderne et plus performante ne pourrait pas remplir les mêmes fonctions.

Pixelmator Pro ou Affinity Photo ne sont-ils pas en mesure de remplacer Photoshop chez beaucoup d'utilisateurs du logiciel d'Adobe ? Ces deux applications ont été pensées pour le Mac et elles sont vendues sur le Mac App Store…

Pour conclure

Un Mac équipé d'une puce ARM capable d'assumer la plus grande part des fonctions actuelles d'un ordinateur, c'est technologiquement possible quasiment dès aujourd'hui. Le goulet d’étranglement que représentent les processeurs d’Intel peut sauter, laissant à Apple toute latitude pour concevoir des machines plus fines, plus légères, plus abordables (on peut rêver).

Les obstacles techniques (rénovation du Mac App Store, virtualisation, transition pour les développeurs et adaptation des utilisateurs) sont importants bien sûr, mais ils semblent presque plus simples à franchir qu'à l'époque de la bascule entre les PowerPC et les processeurs x86. L'Apple d'aujourd'hui est autrement plus forte et bien mieux armée que l'entreprise de 2005.

Mais la meilleure des hypothèses au fond, c’est le mélange des deux. Apple pourrait réserver à sa gamme Pro le couple ARM + x86 : cela en prend le chemin avec le MacBook Pro et l’iMac Pro. Et il y a fort à parier que le Mac Pro embarquera sa propre puce T3. Le grand public profiterait lui de Mac bénéficiant de tous les bienfaits d’une puce ARM, polyvalente, peu gourmande, sécurisée.

Bandeau de une : Thomas Meyer.

avatar Liena | 

« nous ne croyons pas en un unique système d'exploitation pour le PC et pour le mobile »
On a bien eu un « stylet » hein ?

Apple, nouveau fondeur ? Ça apparaît comme logique tant la politique du tout intégré et géré par eux-mêmes est consubstantielle à Apple.
Merci pour ce bon article du matin ?

avatar Florent Morin | 

Bel article.

Pour la transition automatique Intel vers ARM, Apple pourrait s’appuyer sur LLVM en extrayant le bitcode et en recompilant les binaires à la volée comme sur iOS.
Ce qui expliquerait le passage obligé au 64 bits annoncé en juin pour le prochain macOS.

avatar RyDroid | 

Le bitcode est une étape intermédiaire. Un fois que le binaire est fait, il n'y a plus de bitcode. Translater le jeu d'instructions x86-64 en bitcode de LLVM n'est probablement pas chose facile et rapide à coder.

Le jeux d'instructions x86 est plus simple que le jeu d'instructions x86-64. Forcer à passer à x86-64 au détriment de x86 est donc une très mauvaise idée si on veut faire une moulinette pour convertir dans un jeu d'instructions ARM.

avatar BeePotato | 

@ RyDroid : « Le bitcode est une étape intermédiaire. Un fois que le binaire est fait, il n'y a plus de bitcode. Translater le jeu d'instructions x86-64 en bitcode de LLVM n'est probablement pas chose facile et rapide à coder. »

FloMo faisait probablement référence au fait que, depuis quelque temps, l'envoi d'une application sur l'app store pour iOS inclut par défaut le bitcode.
Sauf que, si je ne m'abuse, ce n'est pas (encore) le cas pour l'app store pour Mac.

avatar Frodon | 

Il est évident que la transition vers l'ARM aura lieu, au moins sur une partie de la gamme. On aurait ou en douter si ce n'était pas un mouvement de toute l'industrie et non des juste Apple, comme le montre les premiers PC ARM sous Windows 10.

Cette transition arrivera d'autant plus vite chez Apple, si ces fameux PC ARM ont du succès, et cela l'avenir nous le dira.

avatar sensass | 

Grosse transition en perspective et j'espère juste qu'Apple nous sortira un macOS sauce ARM au niveau d'un Snow Léopard question stabilité.
Et cela quitte à ce qu'elle prenne plus de temps à le développer...
Ces temps-ci on est pas gâté. Et c'était un des critères pour certains pour venir sur l'écosystème Apple à l'époque.

avatar mak972 | 

Apple a deja fait la transition d’architecture à plusieurs reprises avec succès la dernière en date et le passe de Risc à Intel.

avatar RyDroid | 
avatar frankm | 

Je pense que le Mac ARM : c’est un des futurs iPhone.
Les iPhone ne vont plus évolués en termes de fonctionnalité, ils évoluent déjà côté prix sur le terrain des Mac. On changera moins souvent d’iPhone.
Mais cet iPhone du futur sera capable de s’afficher sur une iStation qui ressemblera à un MacBook Pro mais vide côté puissance. Cette station sera les bras et les jambes de l’iPhone, sa version interface utilisateur type Mac.
Évidemment l’iPhone à proximité suffit à faire fonctionner cette station. Aucun fil

avatar vache folle | 

Je vais faire mon troll, pour une fois:

Vanter la sécurité hardware du Mac quand on voit les dernières bourdes de sécurité au niveau softwares n’a, à mon avis, peu d’intérêt.

C’est bien joli d’avoir des Tx si le logiciel ne suit pas.

avatar reborn | 

@vache folle

Il s’agit d’eviter d’autres failles du type thunderstrike.

avatar bobytron | 

« Mais sans puissance, la maîtrise n'est rien ». Je ne suis vraiment pas d’accord. Je comprends, vu le contexte, que l’on ait envie de dire ça, mais à mon sens, c’est juste l’inverse.
Sans maîtrise , la puissance n'est rien.

avatar madzed73 | 
avatar iRobot 5S | 

On irait donc enfin vers un macOS XI.

Mais comme le souligne l'article Apple est il prêt à mettre en place un Rosetta 2 avec ce que ça implique niveau performances. Vu déjà ce qu'on leur reproche ces temps ci sur la qualité de leurs OSs, je ne suis pas sur qu'ils soient prêt à affronter une nouvelle tempête.

Dans tous les cas le support des Macs 100% Intel est maintenant compte.

avatar roccoyop | 

@iRobot 5S

Peut-être que la qualité des systèmes récents baisse car il y a moins de développeurs dessus, vu qu’ils nous font un macOS pour ARM en parallèle.

avatar iRobot 5S | 

@roccoyop

J'y ai pensé, mais dans ce cas qu'ils fassent un nouveau Snow Leopard et non une nouvelle version majeure chaque année en attendant la version ARM

avatar harisson | 

Le concept Mac X présenté dans le bandeau est totalement irréaliste ^_^

Après pour le Mac full ARM, je ne vois pas autre chose qu'un MacBook Air "low-cost" (799$ au lieu de 999$).

Pour les Tx, je pense qu'à terme, comme dans la news, le proc Intel ne servira plus qu'à fournir de la puissance de calcul brute et le proc ARM de coordonner intelligemment les résultats.

avatar supermars | 

20 heures d'autonomie... ce serait top.

avatar mp_ | 

Aussi un moyen comme un autre de juguler la perte que représentent les Hackintoshs, j’imagine

avatar marenostrum | 

ça changera rien pour nous (on s'en fout de leur pièces, ils peuvent mettre ce qu'ils veulent dedans c'est leur problème). on aura toujours un système pour en faire les mêmes choses que maintenant. perte de temps ces articles. mais bon du journalisme.

avatar Moonwalker | 

Yep!

avatar smog | 

On fera les mêmes choses pour plein d'applications. Mais on aura quand même des améliorations dans ce qui touche à certains domaines où le calcul est roi (3D, encodage vidéo etc.)
Mais pour le traitement de texte, on aura de logiciels dix fois plus lourds en terme d'octets, qui permettront toujours les mêmes documents in fine, effectivement.

avatar Simeon | 

Devoir racheter une flopée d'appli ou disposer d'une autonomie doublée seraient des changements tout à fait visibles. On peut aussi imaginer une porosité beaucoup plus importante encore entre un macOS ARM et iOS et donc une bibliothèque d'applis beaucoup plus conséquente (ce qui n'a pas que des bons côtés...). Les puces ARM chauffant relativement peu, J. Ives pourrait de nouveau assouvir ses fantasmes anorexiques, etc.

Bref, la partie visible de l'iceberg ne serait pas si réduite.

avatar ovea | 

«Mac App Store» a bootstrap iOS montre/iPhone/iPad Pro/iMac Pro/…
À quadrature, on trouve mieux …!mais chez Apple ça y est ! Oufff

avatar JOHN³ | 

Marrant comme les choix d’une société lucrative peut fasciner tant de gens.

avatar inumerix | 

@JOHN³

Ça peut se comprendre. Dans mon cas le mac est mon outil de travail. C’est mon quotidien. Ce qui fait vivre toute ma famille. Donc toutes les grandes décisions stratégiques concernant le mac me concernent au plus haut point.

avatar matamoski | 

@inumerix

Vraiment? Je serais toi je regarderai également ce que fait la concurence. Mettre toutes ses billes dans un sac n’est pas la meilleure stratégie

avatar kinon | 

C'est sûr qu'une société qui perd de l'argent...

avatar ever1 | 

d'un point de vue technique je pense que utiliser une puce ARM et Intel à la fois est très compliqué, bien plus que de faire une transition 100% sur ARM:

-soit on va présenter une API pour la puce ARM mais dans ce cas il faudra réécrire le code, il sera aussi bien plus complexe. Les applications legacy ne le prendra pas en charge.
-Si les bascules ARM-intel se font à la volée, alors qu'est ce qui vas dispatcher les instructions ? Le kernel ? Cela risque de provoquer un goulot d'étranglement + conversion des instructions x86 et ARM. Puis la gestion de la mémoire...

On est pas dans un scénario avec 2 cpu de même architectures, qui gèrent les interconnections (comme QPI) et se partagent la ram.

avatar pagaupa | 

Ou comment mieux emprisonner ses clients...

avatar apotheker | 

Il faudra faire gaffe qu’ils nous foutent pas les laser VSCEL de l’iPhone X qui nous bousillent potentiellement les yeux sur le long terme.

avatar fousfous | 

@apotheker

Ou t'as vue qu'il y avait des lasers si l'iPhone X?

avatar DDivo | 

@apotheker

? Si, et ils le feront exprès, dans l’unique but de nous vendre des iLunettes ??‍♂️

avatar bxlt | 

Par contre, quelque de possible et de très simple à mettre en place par Apple : compiler toutes les API en ARM (pas très compliqué : une case à cocher dans Xcode) et faire en sorte qu'à chaque appel à une API, ce soit la version ARM qui soit appelée.
Mine de rien, ça devrait être plutôt intéressant car la majeure partie du travail processeur se fait dans les API système.

avatar BeePotato | 

@ bxlt : « Par contre, quelque de possible et de très simple à mettre en place par Apple : compiler toutes les API en ARM (pas très compliqué : une case à cocher dans Xcode) et faire en sorte qu'à chaque appel à une API, ce soit la version ARM qui soit appelée. »

C'est le genre d'approche qui a été utilisée par Apple lors de la transition 68000 → PowerPC. À l'époque, le Mixed Mode Manager permettait d'avoir de mélanger du code 68000 et PowerPC au sein d'une même application.

« la majeure partie du travail processeur se fait dans les API système. »

Ça dépend évidemment des applications. Certaines ne passent que peu de temps dans des appels système et tout le reste dans de longs calculs faits par leur propre code. Or ce sont justement les applications de ce type qu'on apprécie de voir optimisées pour le CPU qu'on utilise.

avatar SartMatt | 

"C'est le genre d'approche qui a été utilisée par Apple lors de la transition 68000 → PowerPC"

Ce n'est pas tout a fait comparable quand même. À cette époque, il n'y avait bien qu'un seul CPU, qui n'exécutait qu'un seul type d'instruction. Les instructions 68000 étaient traduites en PowerPC par un émulateur.

avatar BeePotato | 

@ SartMatt : « Ce n'est pas tout a fait comparable quand même. À cette époque, il n'y avait bien qu'un seul CPU, qui n'exécutait qu'un seul type d'instruction. »

J'ai répondu au commentaire de bxlt en pensant qu'il parlait d'utiliser cette approche dans le cas d'un Mac avec juste un CPU, dans le but d'améliorer les performances des logiciels émulés (comme à la bonne époque du 68000 → PPC, du coup).
Je ne me plaçais pas dans le cas de ce délire à deux processeurs évoqué par MacG et certains commentateurs — comme tu l'as écrit dans un autre commentaire, une telle approche serait probablement infaisable.

avatar SartMatt | 

Simple, faut le dire vite...

Parce que ça veut quand même dire que soit il faut trouver un moyen pour qu'un CPU x86 et un CPU ARM se partagent le même espace mémoire, et ça, c'est un beau merdier, dans la mesure où les CPU Intel actuels ne fonctionnent qu'avec leur propre contrôleur mémoire, contrôleur sur lequel ils ont un accès exclusif (donc pas possible de faire un contrôleur mémoire partagé, exposant une interface vers le CPU x86 et une vers le CPU ARM), soit à chaque appel à du code ARM depuis du x86 il faudra préalablement recopier les données utiles de l'espace mémoire du CPU x86 vers l'espace mémoire du CPU ARM, et inversement dans l'autre sens pour les réponses...

Au final, les gains éventuels de consommation qu'une telle solution pourrait apporter seront ruinés par cette couche de complexité supplémentaire.

Accessoirement, "la majeure partie du travail processeur se fait dans les API système", c'est quand même une vision bien réductrice de l'importance du code des applications... C'est sûr que pour une appli bureautique ou de consommation de contenu, les API système font beaucoup. Mais pour les applis un peu plus "évoluées", c'est bien dans le code de l'application elle même que le CPU passe le plus de temps hein, parce que les API système elles fournissent pas ce dont l'appli à besoin...

avatar victoireviclaux | 

Sans, je pense.

avatar Pipes Chapman | 

Concrètement please. Quelqu'un écrivait "Le Hackintosh est mort" suite à l'arrivée de ces puces.

Mais à quelle échéance ?

- Cela veut-il dire qu'il est mort parce qu'un jour arrivera un système qui ne s'installera/ fonctionnera qu'en présence d'une puce ARM ?

- Dans ce cas cela signifierait que ce jour n'arrivera que quand Apple aura déclaré "obsolètes " TOUS les macs actuels en dehors du MacBook Pro génération touchbar et l'iMac Pro... Donc on aurait le temps de voir venir ...

Où c'est n'importe quoi ce que je dis ?

avatar McDO | 

@Pipes Chapman

Si c'est exactement ça. Le hackintosh sera mort le jour où Apple passera à du full ARM et ne supportera plus les Mac actuels avec x64.

Personnellement, je pense que ce jour n'arrivera jamais. Le jour où un ARM écrasera un i7, i9 et Xeon n'est pas près d'arrivé, voir n'arrivera jamais. Et puis faut pas oublier que l'ARM a été désigné pour motoriser les appareils nomades. Dire qu'on va mettre de l'ARM dans une station de travail est aussi bête que de dire qu'on va mettre un i7 dans l'iPhone XI à mon sens.

avatar Pipes Chapman | 

@McDO

Compris pour le problème qu'un ARM de dépassera jamais Intel CAD ne remplacera jamais un Intel dans une machine purement et simplement.

Par contre est-ce que ce système de puce ARM en "chienne de garde" à l'entrée du boot , en plus du "vrai proc" ne leur permettra pas de bloquer les Hackintosh à tout nouvel OS le jour où ils voudront le faire ?

avatar Un Type Vrai | 

En fait, pour compléter l'article, il faut aussi voir les contraintes.

L'abandon du powerPC est la conséquence de deux événements concrets :
1) IBM ne reprend pas le modèle 32/128 bits de Motorola et sort un 64bits pleins de promesses mais qui ne sera jamais adaptable aux ordis portable.
2) Motorola annonce que leur G4 va evoluer vers un processeurs utilisant d'autres IO (rapidIO) le rendant incompatible avec la ram, les bus etc du G5 (et des x86).
Apple ne peut plus faire marche arrière sur son marqueting de l'époque : le 64 bit, c'est la vie.

Quel est le problème avec le x86 du coup ?
L'architecture est déjà mal présentée. Un ordi avec un core i7 peut être moins rapide qu'un core i5, dans la gamme core i7 pour portable, Apple choisi toujours les plus chers, mais ils ont le même nom que les processus qui chauffent plus et se limitent en fréquence en permanence...
Mais aussi la puce d'Intel fait de plus en plus de chose et coûte de plus en plus cher.

Comment s'en débarrasser ? En reprenant la main sur les fonctions, petit à petit, laissant au x86 uniquement le calcul.

A terme, la puissance pourrait être accessible via des techno type CUDA pour les carte graphique. Et du coup, que ce soit du x86, de l'ARM ou du NVidia, ce serait transparent pote le logiciel (faisant chauffer plus ou moins la machine et durant plus ou moins longtemps, évidemment )

avatar gspot | 

Rien à voir mais quelqu’un pourrait me dire où trouver ce fond d’écran ?
Merci !!!

avatar Stardustxxx | 

L'article enfonce des portes ouvertes, Windows et Linux sont déjà deja dispo sur ARM, donc il n'y a aucun obstacle pour le Mac.

Par contre, je pense qu'il aurait été intéressant de mettre cette prochaine évolution dans une perspective plus générale : la révolution Machine Learning, Deep Learning, ...

Il faut regarder la tendance a moyen terme en informatique, le futur est la programmation probabiliste (ie Machine Learning, AI, ...), alors que la programmation était déterministe. Cela va changer totalement la façon de concevoir des processeurs.

Apple, Google, IBM, etc... sortent tous des processeurs qui supporte plus ou moins le ML.
La tendance est donc a l'intégration de ces technos dans les processeurs actuels, ou bien a la création de chips spécialisé pour ca (IBM).

Il faut aussi noter que le modèle économique et de license d'ARM est quasi idéal, il permet a Apple et autres, de pouvoir intégrer leur propres solutions ML a des processeurs sans soucis. Obtenir une license x86 est une autre paire de manche.

Bref, je suis curieux de voir quel sera le paysage dans 10 ans. Mais pour exemple, récemment j'ai entendu dire que 40% des calculs chez Google fonctionnaient avec du ML, et seulement 1% de processeurs spécialisé ML.

avatar ovea | 

@Stardustxxx

À ne pas oublier : la multiplicité de sens de l'acronyme ML ;)
1/Méta Language
2/Makeup Langage
3/Machine Learning

L'important c'est que le ML (3) devienne un langage contextuel local universel quant au statistiques d'exécutions.
En effet, ce ML devrait plutôt être le relais des autres qui ne peuvent tenir compte de nouveaux contextes d'exécution afin d'en déterminer statistiquement un type concret calculable sur une architecture machine de déploiement à un instant précis, et seulement pour un problème particulier. Voilà la variable.
Plus prosaïquement, l'installation d'Xcode commence après son installation par le MacAppStore et génère une occupation en calcul sur votre machine très très importante !

Comment un ML (2) pourrait en rendre compte ? Là où Logs, et activités des divers processus … ne conviennent plus.
La nécessité d'apprendre du traçage des liens dynamique différés n'est pas encore bien expliqué à l'utilisateur par le système afin d'en différer/devancer la mise en place selon la nature des ordonnances exigeante d'un ou plusieurs profils d'utilisations (adaptation de l'écran à la lumière ambiante/travail avec la lumière, prévisions puissance nécessaire/batterie, déploiement reparti de puissance de calcul/communication …)

Et au début il y a le ML (1). Malgré son inspiration SmallTalk toute la programmation sur Mac on est loin du slogan
«Tout est modifiable. Le langage permet par exemple de changer d'IDE en cours d'utilisation, sans recompiler ni redémarrer l'application» ou «Le seul aspect intégré par défaut est la syntaxe pour envoyer un message à un objet».
En effet, même si la communication est au cœur du concept, on ne trouve pas en pratique d'utilisation concrète des deux autres «ML» pour faire remonter l'information et fournir une assistance PLUTÔT moins conne qu'avec un PC quelconque sur un Mac récent (((et ne parlons même pas d'iOS)))

Pourquoi ?
Et bien à cause du contrôle d'Appel sur l'interface graphique sensée être le saint graal du «design» des années 80 et qui n'a guère évolué depuis.

Le constat est glacial mais réaliste : l'interface graphique et sa programmation par l'utilisateur à plusieurs degrés a sombré dans une torpeur digne de l'âge glaciaire à venir dans dix mille ans … et les excellentes raisons du smalltalk d'origine ne résistent absolument plus à une exécution de preuve de calcul, seul capable de justifier de l'utilisation de tout un tas de ressources dans des cas précis et des contextes variés.

Alors ARM/x86/carte Graphique/… devrait être le moindre des soucis.

avatar heero | 

Je ne vois pas encore la suite Adobe tourner sur un ARM (Première, Encore, Photoshop (full options),...)

avatar sachouba | 

"Même avec des batteries aux capacités plus réduites, l’iPhone ou l’Apple Watch font tout aussi bien que la concurrence, voire mieux."

?
Il fallait l'oser, celle-là, tout de même ! Les iPhone non Plus ont une autonomie au mieux anémique face à la concurrence.
Les iPhone X et 8 Plus sont loin d'avoir l'autonomie des derniers smartphones haut de gamme de Samsung (S7 Edge, S8 Plus, Note8...), Huawei (Mate 10, Mate 10 Pro...), LG (V30), Google (Pixel XL 2)...
Et c'est sans prendre en compte les smartphones milieu de gamme, qui sont parfois encore meilleurs, ou encore les modèles spécialisés dans l'autonomie (Galaxy S8 Active, Gionee Marathon...).

Il suffit de regarder les mesures de GSMArena (le seul protocole strict et transparent qu'on trouve sur Internet, avec une luminosité fixée...), ou au pire les vidéos YouTube où le protocole n'est pas aussi précis, mais tout aussi transparent.
https://www.gsmarena.com/battery-test.php3

Quant à l'Apple Watch, la Series 3 est ridicule même face à une vieille Gear S2 (2015), qui tient 4 jours avec mon usage.

avatar NestorK | 

@sachouba

?

L’article est intéressant, ne concerne absolument pas le monde Android et tout ce que tu retiens, c’est ça ? T’en as pas marre de ta guerre des chapelles ? T’es aussi casse bonbon que Doctomac.

avatar lecureuil | 

Mon hypothèse la plus probable c'est qu'Apple abandonne Intel dans les 12 prochains et qu'au lieu de tout remplacer par une seule puce le Mac aura plusieurs puces arm
Vu leur taille et vu comment ils savent réduire les cartes mère ils pourraient en coller 3-4

Pages

CONNEXION UTILISATEUR