Mac Apple Silicon : comment Apple prépare le grand saut avec macOS Big Sur !

Christophe Laporte |

Ce n'est plus qu'une question de jours avant qu'Apple ne lâche macOS Big Sur. En accolant le nombre 11 à son système d'exploitation, Apple cherche à marquer le coup et montrer à quel point cette version est en rupture après Catalina.

Lorsqu'il installera cette version pour la première fois, l'utilisateur retiendra avant tout la nouvelle interface du système d'exploitation d'Apple, interface qui risque de ne pas faire l'unanimité tant les choix opérés par l'équipe d'Alan Dye sont discutables. On peut citer la barre de menus qui perd en lisibilité, les nouvelles icônes qui nous rappellent les plus belles heures de MSN ou encore les nombreux éléments d'interface dont on ignore s'ils ont été vraiment pensés pour une utilisation au trackpad ou au doigt (lire : macOS Big Sur : ces régressions qui peuvent agacer).

Quelle est l'icône la plus moche ?

Mais ce qui interpellera peut-être en premier l'utilisateur finalement, c'est le poids de l'installeur de macOS Big Sur. Depuis la bêta 3, le développement de macOS 11.0 est unifié. Autrement dit, l'archive permet d'installer macOS aussi bien sur un Mac Intel que sur un Mac Apple Silicon, ce qui à ce jour se limite au DTK. Conséquence, l'installeur flirte avec les 12 Go, là où Catalina nécessitait moitié moins.


avatar fosterj | 

J’ai rien compris sur la possibilité d’avoir Windows ou pas sur les macs Silicon.. parallèle fonctionne(ra) ou pas dessus ?

avatar Léopold FEZEU | 

@fosterj

Paralels fonctionnera, mais ne peux pas émuler la version actuelle de Windows (conçue pour les processeurs x86). C’est la raison pour laquelle il faudrait que Microsoft mette à disposition une version ARM de Windows.

avatar Florent Morin | 

@DrStrange

Il existe un Windows ARM.

avatar fte | 

@FloMo

"Il existe un Windows ARM."

Sans applications. :)

avatar Frodon | 

@fte

Si avec toutes les applications ARM 32 et 64 bits, et x86 32 bits seulement pour l’instant et x86 64 bits dès Novembre 2020 pour les utilisateurs ayant opté pour les versions de tests « Windows Insider », et début 2021 pour les autres.

Bref, toutes les applications (hors apps de virtualisation) qui fonctionnent aujourd’hui sous Windows 10 Intel fonctionnent aussi sous Windows 10 ARM si une version 32 bits existe et pour celles en 64 bits seulement, elles fonctionneront aussi très bientôt.

avatar raoolito | 

@Frodon

Heuuuuu
Les app x86 tournent treeeeees lentement, hein? En fait roseta est d’ailleurs un quasi miracle dans notre cas sur mac, si microsoft l’avait eu, il auraient approché ce que vous enoncez
Autre detail qui compte, sur mac, ce sera arm ou rien, l’app store d’ios en support, sur windows, ben non intel est toujours là, ca n’aide pas a pousser la transition

avatar Frodon | 

@raoolito

Il y a en effet une perte de 20 à 50% par rapport à du natif, pas plus (c’est du JIT quand même !).

Mais par contre les SoC utilisé sur les PC ARM sont peu performants, même le SQ1 de la Surface Pro X ne fait pas mieux en natif ARM64 qu’un i5-8250U (8eme génération), en en émulation x86 il est du niveau d’un Core i5-6300U (6eme génération).

Ça reste tout à fait exploitable et correct, mais on peut clairement mieux faire.

avatar raoolito | 

@Frodon

J’avais en souvenir le terme « inutilisable et très lent » or un i5 meme ancien devrait soutenir pas mal d’app sans soucis? ( relativement)
Bizarre

Par contre 0% de perte en émulateur je demande à développer là :)

avatar Frodon | 

@raoolito

Pardon, c’est une erreur de frappe, je voulais mettre 20%, je corrige ;)

avatar raoolito | 

@Frodon

Hahaha
Du coup suivant la puissance de la puce...
Oui ca rappelle ce qu’on avait vecu lors de la dernière transition

avatar Frodon | 

@raoolito

Suivant surtout le type d’algorithmes exécutés, l’émulation JIT par définition est très efficace quand il doit exécuter des opérations qui se répètent, la première fois (en fait il ne le fera seulement que s’il les rencontre plusieurs fois, pour éviter de compiler des opérations uniques) il va les compiler et optimiser (nativement), et quand il va les rencontrer à nouveau peu de temps après il exécutera le code précédemment compilé.
Par contre si le programme exécuté fait des opérations très différentes avec peu de reéxecutions de celles-ci, alors le JIT sera peu performant.

C’est effectivement similaire au fonctionnement de Rosetta premier du nom. Rosetta 2 lui utilise une approche qui s’appelle AOT (Ahead Of Time), c’est à dire qu’il compile en avance, à l’installation comme l’a précisé Apple à sa présentation, ce qui fait qu’il n’y a pas le coût de la compilation en temps réel comme en JIT (qui est efficace surtout sur les opérations qui se répètent, et lorsqu’elle se déclenche, elle seule, pour son travail de compilation à la volée, va consommer du CPU, ce qui a ces moments là réduit la puissance CPU disponible pour les autres opérations).

Sur Rosetta 2, ce que j’ai compris, c’est que les programmes exécutés ainsi n’utilisent que les cœurs dit « hautes performances » et ne peuvent pas tirer parti des cœurs économes, ce qui explique que malgré une compilation à l’avance (AOT) il y ait tout de même une perte de performances, certes bien plus faible qu’avec du JIT, mais tout de même visible. Les apps natives ARM64 pouvant elles bénéficier de l’ensemble des cœurs du SoC.
Peut être que cela pourrait être amélioré à l’avenir (mais est-ce que cela en vaudrait la peine?).

Cela étant dit le mieux est un mélange d’AOT et de JIT (comme le fait Android aujourd’hui), car le JIT a un avantage indéniable par rapport à la de la compilation purement à l’avance: du fait qu’il se réalise à l’exécution il peut optimiser les instructions binaires en fonction du contexte d’exécution, ce que ne peut évidement pas faire un compilateur qui opère avant l’exécution.
Sur les versions récentes d’Android (> 6), est compilé et optimisé en AOT ce qui ne peut pas avantageusement bénéficier du JIT et ce qui peut être avantageusement optimisé en JIT est compilé et optimisé à l’exécution.
Peut être que Rosetta 2 utilise en plus ce mécanisme, mais j’ai pas assez creusé pour le savoir (si ce n’est pas le cas, cela pourrait également être un point d’amélioration de Rosetta 2, mais est-ce que ça en vaudrait la peine, encore une fois?)

avatar melaure | 

@fte

Et tout l’intérêt est de faire tourner les dizaines de milliers d’applis pro souvent développées à la demande et qui ne seront PAS recompilées pour ARM ...

Un èmulateur est indispensable du coup ...

avatar iftwst | 

@FloMo

Et non commercialisé pour le grand public....

avatar ValentBay | 

@iftwst

Il y a bien Windows RT, mais bon, je pense que tout le monde préfère l’oublier.

avatar oomu | 

@ValentBay

quoi ça ?

avatar Sindanárië | 

@oomu

Windows, et passer au travers des vitres.

avatar ValentBay | 

@oomu

Un dérivé de Windows 8, mais pour les appareils ARM. Les applications x86 ne fonctionnaient bien sûr pas. Seules les logiciels du Microsoft Store pouvaient tourner.

C’était un four monumental. Une seule surface de 2012 en était pourvue (surface que j’ai possédé pendant 6 mois avant de la vendre au plus offrant),et seules quatre autres tablettes de quatre autres marques (dont Samsung) l’utilisèrent comme OS. Ils abandonnèrent très vite le navire pour ne plus jamais retenter l’expérience. À titre personnelle j’ai compris pourquoi.

avatar cecemf | 

@FloMo

Oui mes elle est pas en vente. Tu peut pas l’acheter. Elle est que pré-installer sure des produits comme surface. Mes tu peut pas acheté de licence. Il faut que Microsoft mettre Windows ARM disponible à la vente.

avatar raoolito | 

@fosterj

En fait il faut juste comprendre la différence entre EMULATION et VIRTUALISATION
Le second revient a « cacher » à un système d’exploitation (type windows) qu’il y a un autre OS entre lui et le matériel
Le premier revient à construire une fausse plateforme en logiciel pour que ce meme windows pense etre sur intel

Le second c’est ce que font parallel ou VMware, le premier, ben faut avouer qu’on en entend plus parler depuis un certain temps mais yavait VirtualPC qui faisait ça.
Au niveau des performances c’est simple: la virtualisation peut aller jusqu’à ne rien perdre, l’emulation si vous atteignez 50% de la meme performance c’est un exploit

avatar Derw | 

@raoolito

VirtualBox, c’est de la virtualisation ou de l’émulation ? Je sais, le nom laisse penser à de la virtualisation, mais les noms, on leur fait dire ce qu’on veut ; la preuve : VirtualPC…

avatar raoolito | 

@Derw

😏
Virtualisation, mais vous avez raison
Le mot « virtuel » est piege ici

avatar andr3 | 

Avec la dernière bêta publique, la barre des menus est de nouveau bien lisible.

Ce que j’apprécie également, c’est le centre de contrôle tout iOS. Il permet de regrouper une série de contrôles (wifi, Bluetooth ...) sous une même icône. Une app comme Vanilla perd sa raison d’être sous Big Sur.

Et si le rapprochement entre l’iPad et le Mac ARM pouvait engendrer l’utilisation de VM sur iPad ... on pourrait finalement avoir ce qu’une Surface Pro n’a jamais pu offrir, à savoir la puissance d’un laptop combiné au touché du stylet sur un iPad.

avatar kinon | 

"Quelle est l'icône la plus moche?"

Moche? en tous cas pas de quoi en faire un plat, ou un titre...
Et la différence avec les actuelles ne saute pas aux yeux

avatar iftwst | 

Quel dommage en tout cas de devoir attendre novembre.

Bon l’iPhone 12 c’est sympa ... de la 5G ..., une couleur bleue .... génial ... l’iPhone 11 en mieux, on sait.

Mais ca reste dans la continuité de ce que l’on connaît déjà largement.

Avec les Mac Silicon bcp de choses vont changer !

avatar raoolito | 

@iftwst

Lors d’un grand saut, les derniers pas sont les plus sensibles 😋

Pages

CONNEXION UTILISATEUR