Apple : les développeurs face à la transition ARM

Apple : les développeurs face à la transition ARM

Pomme d'API

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

01/07/2020 20 minutes
57

Apple : les développeurs face à la transition ARM

Lors de son discours d’ouverture de la WWDC, Apple a annoncé sa transition vers l’architecture ARM qui durera deux ans. Elle se concrétisera à la fin de l’année par de nouveaux Mac avec des SoC maison (mais aussi des machines Intel). Les questions pour les développeurs sont nombreuses. Voici ce qu’il faut en savoir.

La grande annonce d’Apple avait été quelque peu soufflée depuis des semaines par des rumeurs de plus en plus précises. Il est devenu rare que la firme puisse encore surprendre, tant elle est scrutée de près. Et c’est encore plus vrai quand l’annonce touche un sujet aussi sensible que l’architecture utilisée pour le CPU de ses machines.

Le passage à Apple Silicon sera la troisième grande transition de l'entreprise, après l’abandon de l’architecture 68000 de Motorola pour PowerPC en 1994, puis celle de PowerPC pour Intel en 2005. Des bascules significatives à chaque fois, réclamant un gros travail des développeurs pour adapter aussi bien le système que le parc applicatif.

La transition vers Intel, qui s’était bien déroulée, sert d’ailleurs de modèle. On retrouve ainsi Rosetta et les binaires Universal. Une reprise de noms pour des concepts finalement logiques : assurer la compatibilité des applications actuelles sur les prochains Mac à base de SoC ARM et distribuer les prochaines pour les deux architectures.

Car même si la fin de l’année verra l’arrivée de nouvelles machines utilisant les puces Apple Silicon, d’autres modèles Intel continueront de sortir entre temps. Les deux vont cohabiter pendant un certain temps.

Apple ARM
Steve Jobs lors de l'annonce de la transition vers Intel pendant la WWDC 2005

Qu’est-ce qu’Apple Silicon ?

C’est le nom générique désormais donné par Apple à ses puces ARM, dont celles qui équiperont ses Mac. L’entreprise n'y intègrera pas directement les puces Ax de ses iPhone et iPad, mais s’appuiera sur le travail déjà fait pour pousser plus loin les fonctions et performances.

Quelle architecture les développeurs devront-ils viser ?

La même que pour iOS/iPadOS : arm64. C’est l’une des idées les plus reprises par Apple dans sa communication aux développeurs. S’ils ont déjà créé des applications mobiles, alors ils compilent pour arm64, l’architecture des puces Ax depuis bien longtemps.

Conséquence d’ailleurs pour les applications iOS/iPadOS  – qui pourront fonctionner presque en l’état sur macOS Big Sur – le code pourra être repris en l’état. C’est du moins l’idée vendue, car on sait qu’une transition n’est jamais aussi simple.

L’objectif visé par Apple est de ne plus avoir à terme qu’une seule architecture, adaptée à ses différents appareils.

Quand la migration commencera-t-elle ?

On ne sait pas encore. Apple a présenté les grandes lignes pendant son Keynote d’ouverture, mais les détails sont pour l’instant techniques et à destination des développeurs.

Pour se « faire la main », ces derniers peuvent commander un Developer Transition Kit (DTK) vendu 500 dollars, qu’il faudra rendre ensuite. Il embarque une puce A12 (iPhone XS) modifiée (A12Z), épaulée par 16 Go de mémoire et un SSD de 512 Go. Son utilisation implique de ne pas parler de ce matériel avec qui que soit. Les testeurs ont également l’interdiction de lancer le moindre benchmark, ce qui n'empêche pas de premières fuites.

WWDC 2020

Il est probable qu’Apple se laisse de la marge pour surprendre sur le plan des performances, puisque c’est là qu’on attend le plus le constructeur. Si l’on en croit les rumeurs actuelles, un MacBook et un iMac seraient lancés vers la fin de l’année ou début 2021. La migration devrait s’étaler sur deux ans. On imagine que les machines les plus puissantes seront gardées pour la fin, le temps que la puissance des puces grandisse encore.

Ce qui attend les développeurs

On entre dans le vif du sujet. Apple s’est fait fort de communiquer intensément sur la facilité que les développeurs auront à « convertir » leurs applications pour l’architecture arm64. En fait, une part importante d’entre elles ne devrait pas requérir de modification particulière, ou alors de manière légère.

Les applications existantes, prévues pour x84_64, fonctionneront via Rosetta 2 sur les prochains Mac ARM. Apple promet, là encore, des performances à la hauteur. Mais tout le monde attend bien sûr de voir des résultats concrets, car la communication – qui cherche surtout à rassurer sur ce point – ne saurait remplacer de véritables résultats sur des applications plus ou moins gourmandes ou même le ressenti de l’utilisateur face à sa machine.

Les développeurs sont largement encouragés cependant à mettre à jour leurs applications afin de les compiler nativement pour arm64. Xcode 12, dont la bêta peut être récupérée depuis le site Apple Developer (elle réclame au moins Catalina 10.15.4 pour fonctionner), permet de générer des paquets Universal 2, qui réuniront les version Intel et ARM du code.

Ce sera d’ailleurs le mode par défaut pour toute nouvelle compilation. Dans le cas où des makefiles ou scripts personnalisés seraient utilisés, arm64 devra être ajouté manuellement.

Le code ainsi généré sera proposé pour validation sur le Mac App Store ou stocké sous forme de DMG sur le site de l’éditeur concerné. Dans le premier cas, c’est la boutique qui sera chargée ensuite d’envoyer les bons binaires vers la machine cible. Dans le second, le DMG contiendra les deux versions et installera celle adaptée. Une situation identique aux premiers Universal Binaries, quand ils contenaient les binaires PowerPC et Intel.

Il s’écoulera nécessairement une période – qu’Apple veut la plus courte possible – où les machines ARM auront face à elles nombre d’applications encore exclusivement prévues pour l’architecture x86_64. Mais que les développeurs soient prêts, car Apple enclenchera tôt ou tard un mécanisme dont elle a l’habitude : imposer ses conditions.

Il y a fort à parier que les règles du Mac App Store seront mises à jour afin que les nouvelles applications et mises à jour soient obligatoirement en Universal 2. Potentiellement avant que Big Sur n’arrive, afin que le parc applicatif ait le temps de « mûrir » dans les mois qui précèderont l’arrivée de cette nouvelle génération de Mac.

Il y aura des erreurs

Même si le message est centré sur le mot « facilité », il arrivera souvent que la compilation arm64 génère des erreurs. Car le code devra pouvoir être compilé aussi bien pour tout ce qui touche à l’interface graphique (GUI) qu’à l’espace utilisateur. La transition devient encore plus complexe pour les outils systèmes et/ou ayant besoin d’un accès particulier au matériel.

Apple a consacré pendant sa WWDC une vidéo de 40 min environ au sujet, avec des exemples simples. Même si Xcode 12 est prévu pour mâcher une partie du travail, les développeurs ne pourront pas éviter de plonger les mains dans le cambouis, car il existe d’importantes différences entre les architectures x86_64 et arm64, même si les paramètres de compilation n’auront pas besoin d’être modifiés.

Par exemple, la taille des pages CPU est de 4 ko pour Intel, mais 16 ko pour arm64. La macro PAGE_SIZE n’est donc plus une constante et Apple donne des méthodes alternatives dans sa vidéo. Notez que Rosetta 2 fournira automatiquement des pages de 4 ko pour les applications Intel sur Mac ARM.

Apple ARM

Le problème s’étend à toutes les différences architecturales : fonctions variadiques, mémoire pouvant simultanément être écrite et exécutée, compilation Just-in-Time, threads temps réel, priorités explicites des threads et ainsi de suite.

Les développeurs devront également renoncer à des instructions spécifiques, notamment AVX, AVX2 et AVX512. Si des applications y font appel, leur compilation pour arm64 génèrera des erreurs. Les optimisations liées devront être soit remplacées par des équivalents – s’ils existent – soit supprimées, purement et simplement.

Une consolation tout de même, le boutisme des deux architectures est le même : little-endian.

S’éloigner des spécificités, des anciennes technologies et du matériel

Apple recommande aux développeurs d’analyser leur code à la recherche des éléments suivants :

  • Interactions avec des bibliothèques tierces (donc sous contrôle d’une autre personne, physique ou morale)
  • Interactions avec le noyau ou le matériel
  • Besoins de comportements spécifiques du GPU
  • Instructions en assembleur
  • Gestion ou optimisation particulière des threads
  • Code spécifique à un certain matériel ou des optimisations de performances

L'entreprise présente cette liste comme un point de départ : elle donne une idée des pans de code pouvant poser problème à la compilation. Cas classique, celui des bibliothèques tierces. Cupertino rappelle donc que tout le code d’un même processus doit s’adresser à une même architecture. Il ne sera par exemple pas possible de produire une version universelle si les bibliothèques tierces n’ont pas évolué.

Ce qui explique d’ailleurs qu’il ne faudra pas compter sur Rosetta pour se charger d’une partie de code non traduite. Un processus est soit exécuté nativement, soit traduit, dans les deux cas en intégralité.

Il est chaudement recommandé aux développeurs de s’éloigner d’un certain nombre d’anciennes technologies dépréciées comme OpenGL et OpenCL, pourtant supportées par les puces Apple Silicon. La solution proposée est bien entendu de passer à Metal. D’autres anciennes API comme AdressBook ou celles de Carbon ne devraient plus être utilisées, même si Big Sur restera compatible. Le fonctionnement des applications ne sera cependant pas garanti.

L’accès au matériel change également avec Big Sur (macOS 11). Tout pilote devra obligatoirement avoir été créé depuis DriverKit. Les développeurs d’extensions noyau devront probablement y avoir recours aussi. Globalement, Apple suggère de laisser ses technologies de haut niveau s’occuper de la plupart des aspects, et donc de ne plus réaliser soi-même certaines tâches de bas niveau, notamment dans la gestion des threads.

Pour ce point, la firme demande aux développeurs de laisser Grand Central Dispatch s’occuper du travail, afin notamment que le code soit analysé et les actions réparties entre les cœurs d’exécution qui sont asymétriques (2 performants et 4 basse consommation pour les derniers en date). GCD ne pourra bien sûr pas paralléliser de lui-même le code. Il incombera toujours aux développeurs de découper les tâches lourdes afin que Dispatch puisse créer ses files d’attente.

Apple reconnait toutefois que sa technologie ne peut pas prendre en charge tous les cas, et que les développeurs pourront être amenés parfois à gérer eux-mêmes les threads et les optimisations de performances. La société y consacre d’ailleurs une fiche récapitulative.

Apple très active sur l’aide aux projets open source

Elle ne compte pas attendre que les développeurs gèrent par eux-mêmes la transition, intervenant parfois directement. Elle a ainsi annoncé une aide à bon nombre de projets open source.

Parmi les plus importants, Chromium, même si Microsoft avait largement préparé le terrain en s’occupant de la compatibilité avec Windows on ARM. Bien que la plateforme finale soit différente, le code de Chromium est censément déjà compilable pour arm64. Il devrait donc plus s’agir d’un travail de finition.

On trouve également Electron, le framework permettant de développer des applications multiplateformes avec les technologies du web. Là encore une participation essentielle, puisque les nouveaux Mac s’assureront une compatibilité d’emblée avec de nombreuses applications connues. Skype pour ordinateurs l’utilise par exemple.

Les gestionnaires de paquets Homebrew et MacPorts, la plateforme .NET Mono, les langages Go et Python 3, la bibliothèque Qt, le framework Node.js ainsi que Nginx, Bgfx, Blender, Boost, Skia, Zlib-Ng, cmake, FFmpeg, Halide, Pixar USD, Swift Shader, nmap, OpenCV, OpenEXR, OpenJDK, SSE2Neon, Redis, Cineform CFHD, et V8 sont aussi dans la boucle.

La participation active d’Apple ne repose bien sûr pas que sur la générosité. En annonçant aller spontanément aider les développeurs, l’entreprise s’assure aussi que le sujet de transition est bien sur la table. Plus globalement, elle veut inciter par l’exemple. Si de grandes entreprises comme Adobe et Microsoft travaillent déjà à la recompilation de leurs produits pour arm64 et que de nombreux projets open source en font état, le mouvement est d’autant plus visible.

Catalyst nettement enrichi

Catalyst est pour rappel une technologie lancée l’année dernière avec macOS Catalina. Elle permet à des applications iPad d’être transformées en versions macOS, en adaptant le code automatiquement et en laissant les développeurs s’occuper des finitions. Elles peuvent d’ailleurs s’avérer nombreuses, car il faut s’assurer non seulement que l’interface correspond aux canons Mac, mais aussi des interactions, car passer du 100 % tactile au duo clavier/souris n’est pas toujours si simple.

Catalyst a cependant une grosse limitation : de nombreuses API spécifiques à iOS n’ont aucun équivalent sur Mac. Il fallait donc que les développeurs placent dans leur code des exclusions conditionnelles. Le retard est maintenant rattrapé.

Puisque les applications iOS peuvent en théorie s’exécuter sans modification sur Big Sur, il fallait que Catalyst suive le mouvement. Ce qui inclut des ajouts récents comme la gestion des évènements clavier dans iOS, disponible pour Catalyst dans la dernière révision de Catalina et la bêta de Big Sur. Un support crucial, car des actions aussi simples qu’utiliser les flèches du clavier n’étaient pas permises dans les applications iPad après leur transition vers le Mac.

Apple ARM

Dans la même veine, la méthode NSCursor est également supportée, permettant des actions supplémentaires sur le curseur de la souris. Par exemple le rendre invisible dans certains contextes (comme la lecture d’une vidéo) ou lui faire adopter une forme différente selon son positionnement (curseur texte, marqueur de redimensionnement, symbole d’ajout, etc.). Des actions très classiques auxquelles, là encore, les applications Catalyst n’avaient pas droit.

Parmi les autres contrôles maintenant autorisés, on trouve le sélecteur de couleurs (qui renvoie vers l’interface standard de macOS), le sélecteur de date et d’heure, les menus pull-down, les fenêtres popover, le support de trois colonnes pour UISplitViewController ou encore celui de SF Symbols.

Catalyst propose en outre un nouveau mode baptisé « Optimized for Mac », qui proposera aux développeurs des étapes supplémentaires pour s’assurer que l’interface de l’application est bien adaptée à macOS. La mise à l’échelle, actuellement de 77 %, passe notamment à 100 %. De nouveaux éléments y seront proposés, comme les cases à cocher.

C’est également l’occasion pour Apple de remettre en avant sa technologie SwiftUI, qui permet pour rappel de concevoir des interfaces en les modélisant graphiquement, créant le code Swift correspondant. Si une application a été entièrement conçue avec SwiftUI, elle n’aura pas besoin de Catalyst pour être envoyée sur Mac.

Au sujet des applications iOS sur Big Sur

Comme dit, la transition vers ARM déverrouille une possibilité attendue de longue date sur l’écosystème Apple : la capacité de faire fonctionner des applications iOS directement sur un Mac équipé d’une puce Apple Silicon, en les récupérant depuis l’App Store. La thématique semble fortement liée à Catalyst, mais est pourtant différente.

Cette possibilité renvoie en effet au fonctionnement natif et sans recompilation d’une application, qui sera donc exécutée telle quelle. Il ne s’agit pas de prévoir à l’avance qu’elle sera exécutée sur macOS, en prévoyant des contrôles spécifiques et une compilation s’appuyant sur le SDK idoine. Comme on s’en doute, il y aura des avantages et inconvénients.

Gros avantage : nul besoin de toucher à quoi que ce soit pour de nombreux comportements comme la génération de fenêtre, l’intégration à la barre Menu, le panneau des préférences, le Dock, le mode sombre, la gestion du texte, les panneaux des polices et couleurs, la Touch Bar, l’impression, les notifications et le glisser-déposer.

Gros inconvénient : il ne faudra pas en demander plus. C’est toute la différence entre ce fonctionnement et celui d’une application passée à la moulinette de Catalyst. Apple l’explique clairement dans sa vidéo dédiée au sujet. Si un développeur veut pousser plus loin, avoir des contrôles spécifiques, mieux intégrer son application dans macOS et profiter des API et frameworks de ce dernier, il faudra travailler un peu.

Apple ARM

En outre, pour qu’une application iOS puisse fonctionner sur macOS 11, elle ne devra être dépendante d’aucun framework qui ne serait pas présent nativement dans le système. Plus surprenant, Apple avertit que toute application détectée comme compatible sera automatiquement proposée sur le Mac App Store.

Les développeurs, bien sûr, auront le dernier mot. Ils peuvent s’y opposer pour de nombreuses raisons : présence d’une application dédiée pour macOS, intérêt financier, expérience utilisateur jugée inférieure (avec risque de mécontentement des utilisateurs), etc. Mais même dans le cas d’une compatibilité automatique, Apple pointe trois domaines de différences marquées entre les environnements iOS et macOS : matérielles, d’interface et de système.

Les différences matérielles comprennent notamment les interactions très différentes entre l’un et l’autre. iOS s’appuie sur des interactions tactiles directes, macOS sur le clavier et la souris, indirects. La majorité des manipulations tactiles sont traduites automatiquement en équivalents clavier/souris, mais les gestes personnalisés auront besoin de débouchés spécifiques. De même, il faudra prévoir quoi faire dans le cas d’applications s’appuyant sur les capteurs des appareils mobiles : accéléromètre, gyroscope, magnétomètre, profondeur de champ et GPS. Notez que la fonction GPS sera automatiquement liée à CoreLocation sur Mac. La position obtenue sera moins précise, mais fonctionnelle.

Pour l’interface, Apple insiste pour que les développeurs s’en remettent aux méthodes existantes, sans chercher à réinventer la roue, particulièrement sur des actions comme sélectionner un fichier. De même, le recours à AutoLayout permettra aux applications d'être redimensionnées de manière cohérente. Mais ces constats sont vrais uniquement pour celles destinées aux iPad. Une exclusivement pensée pour iPhone, comme Instagram, s’exécutera dans une fenêtre de taille fixe (il est probable que Facebook en bloque la publication sur le Mac App Store).

Une grande partie du travail est déjà accomplie par Apple. Mais puisque l’éditeur ne peut prendre en compte les comportements personnalisés créés par les développeurs, la traduction automatique se fera sur la base des API et frameworks qu’il connait, les siens. Plus une application s’appuiera dessus, moins il y aura de travail d’adaptation.

De nombreuses réponses encore en attente

Cette transition, attendue depuis des années, va procurer à Apple de nombreux avantages. Pour une société tablant sa réussite sur l’intégration serrée du matériel et du logiciel, le contrôle de la puce centrale est un élément crucial. En outre, c’est un sérieux mouvement de simplification dans la technique des gammes. À terme, les développeurs ne cibleront qu’une seule architecture – arm64 – et un lot grandissant d’API de haut niveau, communes à toutes ses plateformes.

C’est également une démonstration de maitrise technique, car Apple a une longueur d’avance dans le domaine des SoC. Ses puces Ax font systématiquement mieux que la concurrence, au point que l’on se retrouve aujourd’hui avec un iPhone SE à 489 euros dont les performances surpassent des modèles vendus plus de 1 000 euros. La majeure partie des constructeurs Android est dépendante de Qualcomm pour ses SoC milieu et haut de gamme.

La feuille de route des Mac sera ainsi débarrassée d’Intel, dont les développements ces dernières années ont accumulé trop de retard. Mais cette indépendance a un prix : l’utilisateur doit n’y voir, si possible, que du feu. Plus la transition sera invisible, plus l’entreprise aura réussi son pari. Car Apple sera largement attendue sur deux aspects : les performances et la logithèque. Il est probable qu’elle ait dans ses cartons de « bonnes surprises » en préparation.

Des performances décevantes ou trop limitées hors de l'utilisations de certains accélérateurs seraient d’emblée un facteur bloquant d’achat. La question de la logithèque est beaucoup plus complexe. Qu’Adobe propose son Creative Cloud ou Microsoft sa suite Office ne répond pas à toutes les questions. Se posera particulièrement le cas des jeux : dans quelle mesure les titres actuellement prévus pour les Mac Intel et exploitant des GPU AMD ou NVIDIA pourront-ils fonctionner ?

Transiter vers ARM signifie exploiter également la partie graphique intégrée. macOS pourrait devenir paradoxalement la plus grande plateforme de jeux, pour peu que ceux pour iOS s’y déversent. Les studios concernés auront le dernier mot. La présence ou non des Radeon dans cette nouvelle aventure n'a pour le moment pas été confirmée.

Cette grande transition venant tout juste d’être annoncée, les informations continueront d’arriver progressivement dans les mois à venir. La situation devrait être beaucoup plus claire d’ici la sortie de Big Sur puisque le système, en plus de présenter un important renouvellement, alimentera les futurs Mac équipés de puces Apple Silicon.

On en saura également davantage sur le fonctionnement des applications iOS sur Big Sur, en particulier qui autorisera quoi. Il est peu probable par exemple que Microsoft laisse les applications iOS Word, Excel et PowerPoint être reprises telles quelles dans le Mac App Store.

57

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Qu’est-ce qu’Apple Silicon ?

Quelle architecture les développeurs devront-ils viser ?

Quand la migration commencera-t-elle ?

Ce qui attend les développeurs

Il y aura des erreurs

S’éloigner des spécificités, des anciennes technologies et du matériel

Apple très active sur l’aide aux projets open source

Catalyst nettement enrichi

Au sujet des applications iOS sur Big Sur

De nombreuses réponses encore en attente

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (57)


Ah ouais jeter à la poubelle AVX etc. ça promet


Tout dépendra si Apple intègre des instructions équivalentes de son côté ou pas (SIMD 512 bits ça existe dans le monde ARM, mais plutôt sur de gros SoC serveur). Mais pour le moment, c’est évoqué comme un cas nécessitant adaptation effectivement <img data-src=" />


Merci David pour l’article qui reprends pas mal de point sur la migration logicielle des Mac Intel vers les Mac Apple Silicon.



Autant sur certains aspects ça va apporter du bon, autant sur d’autres la questions va se poser en fonction des conditions/choix de chacun (client/dev), autant, dans une dernière portion des cas, ça va apporter des emmerdes.



Pour le moment, parallèle, VMWare ont du soft qui tourne sur MacOS car puces Intel.

Demain, avec des puces Apple Silicon, quid de ce marcher ? Je t’avoue que je me sers pas mal de parallèle sur mon MacIntel16.

Je sais que VMWare avait bossé y’a quelques années sur justement un système de virtualisation fonctionnant sur ARM et permettant de passer outre l’architecture, même si très lent à l’époque (faire tourner Windows 98 sur un téléphone si ma mémoire est bonne). A voir si Apple autorisera ce genre de pratiques ou non, qui ont un intérêt pour une frange de la clientèle.

Pour ce qui est de Boot Camp, Apple a déjà annoncé la couleur.. est c’est noir.. gros trou noir pour cette appli.


C’est intéressant de comparer avec le projet de Microsoft, lors de windows RT. Ça va être intéressant comme transition. Est-ce qu’il y aurait des passerelles entre l’arm64 de Microsoft et l’arm64 d’Apple avec un code facilement compatible, on est d’accord qu’on a deux approches differentes pour l’avenir de l’informatique. Avec d’un coté un soft modulable qui s’adapte selon le hardware et de l’autre vers une architecture commune pour une seule famille d’os.



Je ne sais pas si c’est comparable les approches de microsoft et d’apple ou si ils n’ont rien a voir…








the_Grim_Reaper a écrit :



Demain, avec des puces Apple Silicon, quid de ce marcher ? Je t’avoue que je me sers pas mal de parallèle sur mon MacIntel16.





Le logiciel Parallels a justement été présenté dans la conf. Il fonctionnera nativement sur ARM, donc pas d’inquiétude de ce côté, quoique pour les clients, faudra probablement repasser à la caisse !









bilbonsacquet a écrit :



Le logiciel Parallels a justement été présenté dans la conf. Il fonctionnera nativement sur ARM, donc pas d’inquiétude de ce côté, quoique pour les clients, faudra probablement repasser à la caisse !





Oui, il fonctionnera, pour de la virtualisation de systèmes gérant arm64 <img data-src=" />









bilbonsacquet a écrit :



Le logiciel Parallels a justement été présenté dans la conf. Il fonctionnera nativement sur ARM, donc pas d’inquiétude de ce côté, quoique pour les clients, faudra probablement repasser à la caisse !





Le logiciel fonctionne sur abonnement ou par achat définitif d’une version donnée, avec reduc sur les versions suivantes, donc ça change pas grand chose.



En l’état, on pourra faire tourner en virtualisé MacOS, Linux, BSD, .. mais WinOnArm ne semble pas (encore) compatible, et la version “standard” de Windows ne pourra pas tourner en l’état de ce que j’ai compris des annonces.

En effet, certains logiciels Windows ne seront pas forcément dispo sur la version WinOnArm, du coup “dansc*llulu” pour les faire tourner sur les futurs Mac Apple Silicon.









ThomasBrz a écrit :



C’est intéressant de comparer avec le projet de Microsoft, lors de windows RT. Ça va être intéressant comme transition. Est-ce qu’il y aurait des passerelles entre l’arm64 de Microsoft et l’arm64 d’Apple avec un code facilement compatible, on est d’accord qu’on a deux approches differentes pour l’avenir de l’informatique.





Le principe d’ARM c’est quand même de devoir pas mal réadapter selon les architectures/implémentations. C’est tout le souci du suivi logiciel des smartphones/tablettes d’ailleurs. Et sans doute un élément qui a intéressé Apple dans le projet.



Après pour les développeurs, il y aura forcément un travail commun pour les différentes plateformes arm64. Ce qu’il faudra voir, c’est quel sera l’IDE permettant de développer une fois et d’adapter au minimum pour compiler, avec tous les soucis que ça implique en pratique s’il n’y en a pas.



Au pire, ça favorisera un peu plus les PWA et WebAssembly <img data-src=" />









David_L a écrit :



Oui, il fonctionnera, pour de la virtualisation de systèmes gérant arm64 <img data-src=" />





Des annonces, c’est bien ce qui ressort, du coup, faire tourner une VM avec Win98, même si techniquement c’est envisageable (VMWare l’avait montrer) ce ne sera certainement pas possible :(









the_Grim_Reaper a écrit :



Merci David pour l’article





Hey ho <img data-src=" /> <img data-src=" /><img data-src=" />









teddyalbina a écrit :



Ah ouais jeter à la poubelle AVX etc. ça promet





J’ai eu la même réaction en lisant ça. J’espère effectivement qu’Apple intègre une instruction similaire car sinon, il vont perdre énormément de puissance de calcul.



Dans la conf, parallels faisait tourner un linux !



Donc oui, il existera toujours mais la plupart des gens l’achète pour virtualiser windows !

Et si pas de windows arm, ça prive l’éditeur de la plupart de ses utilisateurs potentiels !


Super article David <img data-src=" />








Vincent_H a écrit :



Hey ho <img data-src=" /> <img data-src=" /><img data-src=" />





<img data-src=" />

Oh pardon Vincent ! j’ai tellement pris l’habitude que chacun comment sur ses articles, sauf cas particulier, que je suis passé à côté. <img data-src=" />



10 000 000 d’excuses ! <img data-src=" /> <img data-src=" />



Patapay !!! Déjà que Titia a prévu y’a quelques années de me laisser dans le caniveau <img data-src=" />









wanou2 a écrit :



Super article David <img data-src=" />





Ouai bon ça va <img data-src=" />



Si encore ils en profitaient pour revenir à des prix corrects et des machines plus ouvertes où on peut faire évoluer RAM et SSD ça pourrait être intéressant, mais ce ne sera probablement pas le cas car il faut financer l’“innovation”.



Le Mac n’a plus aucun intérêt à part pour frimer. Pour les gains d’autonomie, à performances égales avec le x86 je n’y crois pas trop car ce dernier a fait d’énormes progrès.








David_L a écrit :



Oui, il fonctionnera, pour de la virtualisation de systèmes gérant arm64 <img data-src=" />







Ça m’étonnerai qu’ils ne permettent pas l’émulation x86. Sinon, ça ne servira pas à grand chose, vu que la version Windows ARM n’est pas installable actuellement (légalement s’entend…)





Les gestionnaires de paquets Homebrew et MacPorts, la plateforme .NET Mono, les langages Go et Python 3, la bibliothèque Qt, le framework Node.js ainsi que Nginx, Bgfx, Blender, Boost, Skia, Zlib-Ng, cmake, FFmpeg, Halide, Pixar USD, Swift Shader, nmap, OpenCV, OpenEXR, OpenJDK, SSE2Neon, Redis, Cineform CFHD, et V8 sont aussi dans la boucle.





Mouais. Ils ont annoncé ça, mais personne n’a contacté qui que ce soit chez FFmpeg…


|&nbsp;Les applications existantes, prévues pour x84_64, fonctionneront via Rosetta 2 sur les prochains Mac ARM. Apple promet, là encore, des performances à la hauteur.Il est impossible d’avoir des performances correctes quand ont fait tourner des applications x86/x86_64 sur de l’ARM. Tout simplement parce que la traduction des instructions est extrêmement lente, et ça c’est une limitation technique inhérente au fonctionnement des CPU.&nbsp;Toute l’optimisation du monde n’y changera rien, une application conçue pour tourner sur du x86 tournera forcément&nbsp;lentement sur de l’ARM. Ce qui ne posera aucun souci pour de petites applications peu gourmandes, mais qui sera bien plus problématiques pour des logiciels lourds.








tiret a écrit :



Si encore ils en profitaient pour revenir à des prix corrects et des machines plus ouvertes où on peut faire évoluer RAM et SSD ça pourrait être intéressant, mais ce ne sera probablement pas le cas car il faut financer l’“innovation”.



Le Mac n’a plus aucun intérêt à part pour frimer. Pour les gains d’autonomie, à performances égales avec le x86 je n’y crois pas trop car ce dernier a fait d’énormes progrès.





Le but d’Apple n’a jamais été de faire des machines accessibles, leur but inavoué est de faire des machines qui transpirent le luxe et donnent envie. D’où le fait qu’on puisse “frimer” avec. C’est pour ça que le prix y est associé ; s’ils vendaient leur matériel moitié moins cher (ce qu’ils pourraient faire) l’image de luxe disparaîtrait parce qu’elle est (entre autre) intimement liée au prix des produits.



Et les Mac ont bel et bien un intérêt, celui d’accéder à macOS :p

Pour les gains d’autonomies par contre, on peut bel et bien s’asseoir dessus oui.



Je me suis acheté un MBP 13” 2013 et honnêtement… j’ai été déçu. Même en gonflant la machine aux hormones avec un SSD d’1 To et 16 Go de RAM macOS s’avère poussif comparé à une machine équivalente en PC sous Debian Buster / KDE. (Core i7 2640M vs Core i5 3310M - sinon les deux ont 16 Go de RAM et un SSD Crucial 1 To en MLC)


C’est un sujet qui nous occupe beaucoup actuellement on va dire <img data-src=" />


vu le nombre d’articles et le contenu, vi, on peut se douter.



Et ça ne semble pas près de s’arrêter, courage à vous <img data-src=" />








tiret a écrit :



Je me suis acheté un MBP 13” 2013 et honnêtement… j’ai été déçu.





J’ai un MBP de 2012 i7 avec 16 Go de RAM et un SSD de 2To et la machine se débrouille encore bien, même par rapport à des machines récentes.



Et même pour les jeux, lorsqu’il est couplé à un eGPU. Par contre sur les machines récentes, pas moyen d’ajouter de la RAM ni de l’espace disque interne, ça limite énormément et c’est pour ça que j’ai pas envie que ma machine actuelle lâche…



Il y à-t-il vraiment une différence de prix notable avec un ordinateur portable d’une gamme “professionnelle” genre thinkpad ?



Parce que il y à des différence assez significative de prix sur des éléments qui sont pas des composant mais sur la finition, les matériaux, l’organisation de l’aération, etc… sur les ordinateurs portable.


J’ai tout de même un doute sur “la plus grande plate-forme de jeu”.. Vu ce qui est dispo sur Windows en sachant qu’on peut y faire tourner les jeux Android….


“Par exemple, la taille des pages CPU est de 4 ko pour Intel, mais 16 ko

pour arm64. La macro PAGE_SIZE n’est donc plus une constante”



Ce n’est pas correct. La macro définit toujours une constante, elle est définie à une valeur différente selon le compilateur utilisé (générant du code pour Intel ou ARM) mais ça&nbsp; a toujours été le cas.



C’est d’ailleurs l’usage de ce genre de macro et typedefs qui permet de réutiliser le même code tout en ciblant différentes architectures. Si un code utilisait des constantes magiques (tel que d’utiliser 4096 en lieu et place de PAGE_SIZE) alors, oui, le portage vers ARM ne sera pas facile ^^








jb a écrit :



Mouais. Ils ont annoncé ça, mais personne n’a contacté qui que ce soit chez FFmpeg…





Ça promet <img data-src=" />



Question naïve au passage :

Dans le listing des projet open source censés être “soutenus par Apple” pour une transition ARM, une chié possède déjà une version ARM. Du coup en dehors de l’aspect com, que compte soutenir Apple ? Des optis dédiés à l’archi Apple Silicon ?









Vincent_H a écrit :



C’est un sujet qui nous occupe beaucoup actuellement on va dire <img data-src=" />



Laisser Grim Reaper dans le caniveau? <img data-src=" />



Oui quand même, même si ça dépend des modèles. Les Dell sont hors de prix mais les autres sont moins chers quand même.



Après l’intérêt des machines est qu’elles sont fines mais pour le prix ne pas pouvoir changer la RAM ni le stockage ça fait très mal !


#MéchancetéOrdinaire








Vincent_H a écrit :



Hey ho <img data-src=" /> <img data-src=" /><img data-src=" />





<img data-src=" />







jb a écrit :



Mouais. Ils ont annoncé ça, mais personne n’a contacté qui que ce soit chez FFmpeg…





C’est parce qu’ils sont dans TENET <img data-src=" />



J’ai pas trop suivi ce que propose Apple en terme de carte graphique ces derniers temps. Mais j’avais pas pensé au fait que la transition concerne à la fois le CPU et le GPU en fait. Adieu les cartes graphiques AMD et Nvidia. Je me demande comment se comporte un GPU intégré à une puce Apple par rapport à un GPU dédié ou à un GPU intégré Intel. La différence de performance est du même ordre de grandeur qu’entre x86 et ARM ?








Patch a écrit :



Laisser Grim Reaper dans le caniveau? <img data-src=" />





Méheu ! <img data-src=" />





Vincent_H a écrit :



#MéchancetéOrdinaire





<img data-src=" /> <img data-src=" /> <img data-src=" />





David_L a écrit :



<img data-src=" />





<img data-src=" /> je vais me faire buter avec tes *onneries !





tiret a écrit :



Oui quand même, même si ça dépend des modèles. Les Dell sont hors de prix mais les autres sont moins chers quand même.



Après l’intérêt des machines est qu’elles sont fines mais pour le prix ne pas pouvoir changer la RAM ni le stockage ça fait très mal !





Chez Lenovo (Thinpad) c’est le même ordre de prix, pour ça que je suis passé au Mac en fin d’année dernière (et pour MacOS). De mémoire, Dell, idem ou pas beaucoup moins cher. HP, idem.









Mr.Nox a écrit :



J’ai tout de même un doute sur “la plus grande plate-forme de jeu”..





C’est énorme si tu peut jouer au jeux de l’appstore sur un mac. Après au niveau de la qualité c’est une autre histoire et ils devront rendre les jeux compatible clavier + souris. Ca promet de sulfureux poste sur les réseaux sociaux comme avec fortnite et son aimbot manette.



&nbsp;









tiret a écrit :



Oui quand même, même si ça dépend des modèles. Les Dell sont hors de prix mais les autres sont moins chers quand même.



Après l’intérêt des machines est qu’elles sont fines mais pour le prix ne pas pouvoir changer la RAM ni le stockage ça fait très mal !





Que tu prennes Asus, Dell, HP, Lenovo, Razer, tout les miels équivalent sont dans la même fourchette, après si tu veux tu évolutif et que macOS tu t’en cogne tu as le choix c’est sur









Rozgann a écrit :



J’ai pas trop suivi ce que propose Apple en terme de carte graphique ces derniers temps. Mais j’avais pas pensé au fait que la transition concerne à la fois le CPU et le GPU en fait. Adieu les cartes graphiques AMD et Nvidia. Je me demande comment se comporte un GPU intégré à une puce Apple par rapport à un GPU dédié ou à un GPU intégré Intel. La différence de performance est du même ordre de grandeur qu’entre x86 et ARM ?





J’ai du mal a imaginer un Mac Pro ARM sans CG externe quand même, ok pour les MacBook Air, ou un iMac de base mais le reste de la gamme ça risque d’en refroidir plus d’un a moins qu’Apple ai un GPU capable de rivaliser avec AMD au minimum.



A moins que leur Afterburner sur MacPro soit un prémisse mais j’en doute fortement vu qu’elle est ultra specialisée









Norde a écrit :



Question naïve au passage :

Dans le listing des projet open source censés être “soutenus par Apple” pour une transition ARM, une chié possède déjà une version ARM. Du coup en dehors de l’aspect com, que compte soutenir Apple ? Des optis dédiés à l’archi Apple Silicon ?







Bah, justement, c’est ce qu’on se demande: FFmpeg, dav1d et x264 sont carrément optimisés pour ARMv8. Donc, aucune idée de ce qu’ils peuvent soutenir.



surtout que Apple Silicon n’étant qu’une marque, votre code est déjà optimisé pour leurs processeurs. VLC fonctionne nickel sur iDevice quel qu’il soit y compris AppleTV.&nbsp;


Pareil.



Sachant que l’USB 4 qui arrive sera certainement supporté et qu’il dispose de Thunderbolt 3, ce serait étonnant qu’Apple renonce aux eGPU et GPU. Après par contre l’API Metal sera certainement nécessaire même si y a 11 ans le duo OpenGL/CL était montré comme le partenaire parfait de GCD dont on avait plus entendu parler avant Big Sur.&nbsp;


J’avoue que j’y connais pas grand chose en matériel. Il y a rien techniquement qui empêcherait d’utiliser une carte graphique “classique” sur une carte mère avec un CPU ARM ? On branche et ça fonctionne pour peu qu’il y ait des pilotes adaptés pour l’OS en question ? Ou ça demanderait des nouveaux standards différents de ceux qui sont utilisés dans le monde x86 ?








Rozgann a écrit :



J’avoue que j’y connais pas grand chose en matériel. Il y a rien techniquement qui empêcherait d’utiliser une carte graphique “classique” sur une carte mère avec un CPU ARM ? On branche et ça fonctionne pour peu qu’il y ait des pilotes adaptés pour l’OS en question ? Ou ça demanderait des nouveaux standards différents de ceux qui sont utilisés dans le monde x86 ?





Les Powermac avaient les même Carte que les PC, juste un firmware different parfois, mais on pouvait installer une CG faite pour win bien souvent.



D’ou la question <img data-src=" />










Rozgann a écrit :



J’avoue que j’y connais pas grand chose en matériel. Il y a rien techniquement qui empêcherait d’utiliser une carte graphique “classique” sur une carte mère avec un CPU ARM ? On branche et ça fonctionne pour peu qu’il y ait des pilotes adaptés pour l’OS en question ? Ou ça demanderait des nouveaux standards différents de ceux qui sont utilisés dans le monde x86 ?







Un début de réponse probablement avec l’usage d’un carte graphique “standard” sur du RISC-V:

https://youtu.be/L8jqGOgCy5M?t=523









misterB a écrit :



Les Powermac avaient les même Carte que les PC, juste un firmware different parfois, mais on pouvait installer une CG faite pour win bien souvent.









hurd a écrit :



Un début de réponse probablement avec l’usage d’un carte graphique “standard” sur du RISC-Vhttps://youtu.be/L8jqGOgCy5M?t=523





Merci pour vos réponses. Du coup, oui, vu que macOS est quand même pas mal utilisé pour certains usages professionnels intensifs en GPU (genre le montage vidéo), ce serait étonnant qu’ils choisissent de se priver d’un GPU dédié AMD ou Nvidia. Et donc les (rares) joueurs mac devraient en profiter au passage.









Rozgann a écrit :



Merci pour vos réponses. Du coup, oui, vu que macOS est quand même pas mal utilisé pour certains usages professionnels intensifs en GPU (genre le montage vidéo), ce serait étonnant qu’ils choisissent de se priver d’un GPU dédié AMD ou Nvidia. Et donc les (rares) joueurs mac devraient en profiter au passage.





Je me demande si les jeux seront portés de Windows vers Apple/ARM



La Xbox et la PS5 sont des PC, en x86_64 . Porter sous ARM pour toucher quelques joueurs en plus, je pense pas.



Les applis métiers sont chères et les gens qui ont des Mac ont l’habitude de payer des trucs hors de prix, je m’en fait pas.



Les moteurs multi-plateforme type Cryengine, Unity, etc, ne sont pas censés faciliter le portage sur des architectures différentes ?


Merci pour l’article !



J’utilise mon MacBook uniquement pour du contenu web, regarder des séries/films, etc, donc qu’on gagne plus de puissance je m’en fous, même si j’aimerai bien plus d’autonomie.

Par contre il y a un truc qui m’intéresse sur le passage au processeur ARM, c’est le portage « facile » des applications iOS sur macOS. J’aimerai vraiment profiter d’application comme Netflix sur MacBook. En espérant que certains ne bloque pas le portage sur l’App Store.


Si, mais la seule console encore en vente avec un CPU ARM c’est la Switch.&nbsp;



Après des jeux “PC” existent sur Switch ET iPad. Ils devraient donc exister sur Mac ARM.&nbsp;



Faut reconnaître que si le Mac seul ne va pas forcément intéresser les devs, quand on voit que Civ 6 existe sur Switch et iPad et que l’interface existe déjà pour PC et Mac Intel, pourquoi les Mac ARM n’auraient pas droit à une version ARM au lieu de Rosetta 2?&nbsp;



Mais bon ça fait peu de jeux comparé au catalogue Steam.&nbsp;



ça peut aussi expliquer les tentatives de séduction d’éditeurs par Apple avec son Apple Arcade.&nbsp;


Y a quelques trucs à faire pour finir ce travail.


D’accord :) Bah ça marche déjà bien :)&nbsp;








Rozgann a écrit :



J’avoue que j’y connais pas grand chose en matériel. Il y a rien techniquement qui empêcherait d’utiliser une carte graphique “classique” sur une carte mère avec un CPU ARM ? On branche et ça fonctionne pour peu qu’il y ait des pilotes adaptés pour l’OS en question ? Ou ça demanderait des nouveaux standards différents de ceux qui sont utilisés dans le monde x86 ?





Ca dépend des cas, faut un support de l’OS déjà.

Après, dans le monde HPC y’a une/des machines qui mélangent ARM + GPU (nVidia de mémoire), donc c’est faisable pour autant que le support soft suive.

Idem pour les modules pour automobile/dev de nVidia (Soc ARM semi-personnalisé + GPU nVidia)





misterB a écrit :



Les Powermac avaient les même Carte que les PC, juste un firmware different parfois, mais on pouvait installer une CG faite pour win bien souvent.



D’ou la question <img data-src=" />





Ou comment faire payer 50% plus cher la même carte avec juste une valeur de bios qui change.





Rozgann a écrit :



Merci pour vos réponses. Du coup, oui, vu que macOS est quand même pas mal utilisé pour certains usages professionnels intensifs en GPU (genre le montage vidéo), ce serait étonnant qu’ils choisissent de se priver d’un GPU dédié AMD ou Nvidia. Et donc les (rares) joueurs mac devraient en profiter au passage.





AMD et nVidia font des drivers spécifiques pour une gamme pro, non optimisé pour le jeu.

Si Apple leur demande, l’un comme l’autre feront des Drivers spécifiques pour l’usage souhaité par Apple, excluant le jeu si nécessaire. Et comme Apple pourrait s’amuser à racheter l’un comme l’autre et représente malgré tout du volume “captif” ce sont d’autres bonnes raisons de ce plier à son client.

AMD fait en plus du custom pour d’autres clients sur ces cartes graphiques (les versions consoles sont pas tout à fait les mêmes que les versions PC).





linkin623 a écrit :



Je me demande si les jeux seront portés de Windows vers Apple/ARM



La Xbox et la PS5 sont des PC, en x86_64 . Porter sous ARM pour toucher quelques joueurs en plus, je pense pas.



Les applis métiers sont chères et les gens qui ont des Mac ont l’habitude de payer des trucs hors de prix, je m’en fait pas.





Le portage sous ARM des jeux PC/Console de salon c’est pas forcément gagné.









the_Grim_Reaper a écrit :



Ou comment faire payer 50% plus cher la même carte avec juste une valeur de bios qui change.





Mais fallait bien choisir sa carte car le firmware pour les mac prenait plus de place donc on avait parfois le souci de y a pas assez de place pour flasher la carte <img data-src=" />



Oui aussi, c’était la belle époque… rah que de souvenirs…


Visiblement, le Raspebrry Pi 4 dispose d’un port PCI Express interne, qui permet de connecter des cartes externes (type cartes réseau) en jouant un peu du fer à souder. Par contre, connecter une carte graphique ne fonctionne pas parce qu’il n’y a pas les interface nécessaires pour permettre à la carte d’accéder à la mémoire :https://www.techrepublic.com/article/want-your-raspberry-pi-4-to-run-a-modern-gr…



Donc confirmation que c’est tout à fait possible, même si ça nécessite d’être prévu. Pour info, il semble que chaque vendeur de carte graphique a son propre jeu d’instruction (comparable à x86 ou ARM pour les CPU). Le pilote graphique expose des interfaces standardisées (OpenGL, Vulkan, DirectX, etc…) et utilise en interne les bons jeux d’instruction :https://stackoverflow.com/questions/1697842/do-graphic-cards-have-instruction-se…


La Switch est la seule console avec une architecture ARM via sa puce Tegra, mais Unity et l’Unreal Engine sont aussi utilisés pour des jeux smartphone. (et en cherchant un peu, apparemment le Cryengine est en train de sortir en beta pour smartphone)



Les gros moteurs du marché sont multi-plateforme déjà. Donc à part les jeux développés avec leur propre moteur, j’ai du mal à comprendre pourquoi le portage serait plus difficile sur les Mac ARM.


Les gros moteurs…. offert aux studios qui n’ont pas les moyens de faire le leur.



Mais oui ça facilitera la vie.&nbsp;