Pourquoi Apple migre- t- il ses Mac sous ARM ?
La rumeur courait depuis plusieurs années. Elle vient d’être confirmée à l’occasion de la Conférence développeurs WWDC 2020 : Apple divorce d’avec Intel. Les futurs ordinateurs de la marque à la Pomme seront bâtis autour de processeurs maison dérivés de l’architecture matérielle RISC ARM. Les premières machines conçues autour des nouveaux CPU devraient être commercialisées à la fin de l’année, Apple se donnant deux ans pour migrer toute sa gamme vers cette nouvelle technologie.
On pourra attribuer cette décision à la volonté d’apple de regagner le contrôle total sur la conception des composants utilisés dans ses machines. Un peu ironiquement, on se rappellera qu’en 2006, déjà, Apple avait abandonné la technologie Powerpc, qu’elle développait conjointement avec Motorola et IBM, au profit des processeurs x86 en raison de l’impossibilité de rendre les Powerpc à la fois performants et économes.
Retour à la case départ
Quatorze ans après, c’est le retour du balancier ! Les atermoiements d’intel autour de sa technologie 10 nm, qui aura eu presque quatre ans de retard, ont dû avoir raison de la patience des dirigeants d’apple, obligés de composer avec des procédés de gravure largement supplantés par la concurrence. On constate d’ailleurs que, depuis 2013, l’autonomie des Macbook n’augmente pas ( 12 h) et que le gain en performance devient quasi- cosmétique d’un modèle à l’autre. Pour réaliser que les performances de l’architecture Core plafonnaient, les ingénieurs d’apple n’ont sans doute pas eu un grand effort à faire.
Le choix D’ARM comme nouvelle plate- forme CPU ne doit rien au
hasard, même si, à l’heure actuelle, les alternatives à la famille x86 ne sont guère nombreuses. Apple a adopté ARM pour ses iphone dès le premier modèle – Apple avait même collaboré avec ARM pour développer le processeur de l’éphémère PDA Newton –, préférant ainsi maîtriser le couple performance- consommation dans un segment de marché où l’autonomie est un facteur critique. Rapidement, les iphone sont devenus les cobayes des ingénieurs VLSI. Apple n’a jamais packagé les processeurs ARM dans des boîtiers spécifiques, mais les intègre dans des SOC ( System On Chip) qui incorporent également la Flash ROM, la RAM et différents sous- systèmes d’entrée- sortie. Avec la miniaturisation des procédés de gravure et la montée en compétence de l’équipe de conception, chaque nouveau modèle a vu la complexité du SOC augmenter : multi- coeur ARM conçu en interne – Apple ne « licencie » plus que le jeu d’instructions –, puis une avalanche de co- processeurs comme la fameuse « enclave sécurisée » , la gestion des capteurs, le GPU et, plus récemment, les processeurs « neuronaux » .
Il ne fait aucun doute que Apple équipera ses futurs Mac avec des SOC au moins aussi performants que ceux que l’on trouve actuellement sur les iphone haut de gamme. Du point de vue de l’utilisateur, on peut ainsi espérer l’apparition sur les Macbook de nouvelles fonctionnalités, des rendus 3D bien plus rapides et des nouveaux logiciels exploitant les bibliothèques d’intelligence artificielle qui, actuellement, ne fonctionnent qu’avec l’ajout d’un GPU externe.
Maîtrise du compilateur
Mais il y a plus que la maîtrise du processeur. Avec le passage sur ARM, Apple récupère également la maîtrise sur le compilateur, un mouvement amorcé dès 2005/ 2006. À cette époque, la société californienne envisage d’abandonner GCC, dont le développement est contrôlé par la FSF, Apple ne supervisant que la partie spécifique à Mac OS. La transition de GCC vers la licence GPL v3 donne à Apple le prétexte pour passer à l’acte. En réalité, GCC, utilisé pour compiler l’ensemble de Mac OS, est un produit soi- disant open source, mais dont la maintenance par des non- initiés est impossible . Apple va donc se tourner vers un projet naissant de compilateur baptisé LLVM. Elle engage Chris Lattner, son développeur principal. LLVM, et son front- end CLANG, sont non seulement bâtis sur une architecture logicielle moderne, claire et modulaire, mais ils sont également placés sous licence BSD. Double bénéfice pour Apple : la société renforce son image dans l’open Source en finançant une brique essentielle de tout développement logiciel. LLVM/ CLANG sera d’ailleurs ensuite adopté comme compilateur natif par les différents XBSD. Et Apple peut maintenant récupérer tout le code produit par la communauté de développement, y compris hors Apple, pour produire sa propre version, fermée, de LLVM/ CLANG qu’elle fournit avec son environnement de développement Xcode. On peut raisonnablement supposer que le code ARM généré par la version propriétaire diffère de celui généré par la version open source. Les ingénieurs logiciel d’apple ont dû adapter le back- end à la micro- architecture développée par leurs homologues du hardware. Cette hypothèse a deux conséquences pour le développeur/ utilisateur : l’une positive, l’autre négative. La première est évidemment un gain de performance, puisque le code « colle » au plus près des spécifications du hardware. Nul ne sait mieux utiliser un processeur que celui qui le conçoit. On peut donc espérer qu’aux gains purement matériels générés par la transition vers ARM s’ajouteront également des gains logiciels, grâce à une compilation plus efficace. La contrepartie, c’est qu’en prenant le
contrôle à la fois du hardware et du compilateur, Apple peut décider de brider n’importe quel aspect de son système d’exploitation sans que personne ne puisse y déroger. Prenons l’exemple du « SIP » ( System Integrity Protection) : il s’agit d’un dispositif récent de protection anti- malware mis en place à différents niveaux du système, qui protège notamment les fichiers réputés essentiels contre toute destruction, y compris par l’utilisateur root. Ce dispositif est débrayable, mais uniquement en mode recovery. Rien n’empêche Apple, dans une future version de ses processeurs, d’implanter le système SIP à l’intérieur même de l’unité d’exécution sous forme d’un registre, d’instructions spécifiques, non documentées, que la version open source de LLVM ne connaîtrait pas, et qui ne seraient pas disponibles dans la version Xcode, voire de développer un co- processeur spécifique. Le résultat serait un système de protection « en dur » , impossible à désactiver. Or, on connaît l’obsession de la société californienne vis- à- vis de la sécurité, une obsession qui confine parfois à la paranoïa : comment qualifier autrement le retrait de commandes Unix aussi utiles et répandues que telnet des versions récentes de Mac OS ?
Avancées et inquiétudes
Au final, il est indéniable que, pour Apple, maîtriser sa supply chain de bout en bout, du processeur jusqu’à la couche logicielle, est une garantie de minimisation des risques et ouvre la voie à la conception de machines totalement symbiotiques. L’utilisateur devrait y trouver son compte : performances en hausse, plus d’autonomie, plus de fonctionnalités. En outre, la future compatibilité native des applications entre la gamme Mac et les ipad/ iphone facilitera certainement la tâche des développeurs et devrait favoriser le rapprochement de deux écosystèmes jusqu’ici largement indépendants. En revanche, cela signifie également que Apple sera libre de placer n’importe quelle entrave et même de la figer dans le marbre du silicium. La relative invulnérabilité du Macintosh aux virus, troyens et autres logiciels malveillants a toujours été mis en avant par la société californienne pour distinguer sa gamme des PC tournant sous Windows. Les récentes évolutions semblent indiquer que les dirigeants d’apple sont prêts à ériger des murailles pour sauvegarder cette réputation, quitte à tailler dans la souplesse du système Unix sur lequel Mac OS est assis. Espérons qu’ils laisseront toujours la possibilité aux utilisateurs de décider comment ils entendent gérer leur machine. ✖