Mac ARM: Apple semble en bonne voie pour réussir son pari de performances, Réactions à la publication du 30/07/2020

[Lionel]

Nous avons eu des informations de lecteurs ayant reçu leur exemplaire de test de Mac mini ARM.
Les machines sont esthétiquement identiques aux Mac mini actuels, y compris au niveau du packaging.
Les ports USB-C supportent la sortie vidéo et des moniteurs 4K branchés dessus ont parfaitement fonctionné.
Ces machines pourraient être vendues dès maintenant tant elles sont stables et la version de Big Sur exploitée dessus tout aussi efficace.

Au niveau performances, nos contacts ont été simplement bluffés par ce qu'est capable de fournir ce processeur A12Z en émulation x86-64.
Des tests ont montré dans ce cas que l'on arrive en émulation multithread sur le Mac mini à 85% des performances d'un MacBook Pro 15" de 2017 avec un CPU à 3,5 GHz (avec quand même l'hyperthreading désactivé). C'est tout bonnement bluffant.
On est à des années-lumière de ce que donnait l'émulation PPC des premiers Mac Intel.

En revanche, pour d'autres logiciels, comme Chrome ou LightRoom 4.4 64bits, ces logiciels sont inutilisables tant ils sont lents. C'est peut-être lié à l'utilisation par le code d'instructions vectorielles qui ne sont pas émulées ou à des problèmes liés à Rosetta 2.

En bref, le grand public pourrait y trouver son compte dès maintenant en ayant une machine au CPU consommant trois fois moins et pour une puissance proche. Pour les professionnels, ce serait une autre paire de manches, mais clairement, Apple pourrait en fin de compte créer une révolution et peut-être même faire un tort absolument considérable à Intel.

[MàJ] Pour en revenir aux performances médiocres de Chrome, elles sont liées à son optimisation particulièrement poussée pour tirer le meilleur parti des performances des processeurs. Le code C++ utilisé a donc du mal à être émulé par Rosetta 2. Bon, il "suffira" à Alphabet d'en faire autant pour les futurs processeurs d'Apple, mais cela implique énormément de travail de tous les développeurs, non pas en compilation, ce qui est relativement aisé, mais pour tirer le meilleur parti des spécificités CPU.

Lien vers le billet original

[radamanthys]

Lionel, tu donnes des exemples de 2 logiciels qui ne fonctionnement pas bien, as tu également des exemples concrets des logiciels qui tournent à 85% des perfs du MBP2017 ?

[Lionel]

Lionel, tu donnes des exemples de 2 logiciels qui ne fonctionnement pas bien, as tu également des exemples concrets des logiciels qui tournent à 85% des perfs du MBP2017 ?

Je fais mon max pour donner un max d'infos sans compromettre ces personnes.

[bxlt]

A propos de l'émulation x64 -> ARM, il me semble avoir lu (bien que personne ne semble avoir noté la différence) qu'il s'agit cette fois ci non pas d'une émulation à la volée mais d'une traduction qui serait faite la première fois qu'on utilise un logiciel. Un exécutable ARM serait généré à partir de l'exécutable x64 et cet exécutable serait utilisé ensuite à chaque nouvelle exécution ce qui pourrait expliquer les relatives bonnes performances.

Ce message a été modifié par bxlt - 30 Jul 2020, 10:06.

[Lionel]

A propos de l'émulation x64 -> ARM, il me semble avoir lu (bien que personne ne semble avoir noté la différence) qu'il s'agit cette fois ci non pas d'une émulation à la volée mais d'une traduction qui serait faite la première fois qu'on utilise un logiciel. Un exécutable ARM serait généré à partir de l'exécutable x64 et cet exécutable serait utilisé ensuite à chaque nouvelle exécution ce qui pourrait expliquer les relatives bonnes performances.

Oui, c'est vrai. Mais peu importe le vin tant qu'on a l'ivresse

[Twisell]

A propos de l'émulation x64 -> ARM, il me semble avoir lu (bien que personne ne semble avoir noté la différence) qu'il s'agit cette fois ci non pas d'une émulation à la volée mais d'une traduction qui serait faite la première fois qu'on utilise un logiciel. Un exécutable ARM serait généré à partir de l'exécutable x64 et cet exécutable serait utilisé ensuite à chaque nouvelle exécution ce qui pourrait expliquer les relatives bonnes performances.

Si j'ai bien compris il y a en réalité deux passes, traduction au premier lancement + traduction à la volée pour le code exécuté dynamiquement (JIT).
Et du coup peut être bien selon la manière dont l'application a été codée il est possible de + ou - optimiser en avance avec des perfs plus dégradée si le recours au JIT est massif.

N'hésitez pas à me corriger je suis pas dev sur Mac donc je peux me tromper, j'essaye juste de vulgariser ce que j'en ai compris.

Ce message a été modifié par Twisell - 30 Jul 2020, 10:22.

[ricobanane]

C'est un de bon augure pour la suite des évènements alors…

Une chose me questionne cependant.

Lors de la WWDC ils ont fait une présentation de Maya sur la machine.
La prévisualisation de la scène était plutôt fluide.
Par contre j'aurais aimé voir un calcul de rendu…
Histoire d’appréhender la puissance de calcul brute de la machine.

Quelqu'un a t'il fait ce genre de test ?

Ce message a été modifié par ricobanane - 30 Jul 2020, 10:43.

[Hasgarn]

Il semble que les futurs Apple Silicon soient effectivement bien étudiés pour certaines taches.
Ce Youtuber a été incapable de monter facilement des plans du EOS R5 sur de grosses config' et s'en est sorti avec son iPad Pro.

https://www.youtube.com/watch?v=zWaFOQTbZ88

De bon augure, effectivement.

[Lionel]

A propos de l'émulation x64 -> ARM, il me semble avoir lu (bien que personne ne semble avoir noté la différence) qu'il s'agit cette fois ci non pas d'une émulation à la volée mais d'une traduction qui serait faite la première fois qu'on utilise un logiciel. Un exécutable ARM serait généré à partir de l'exécutable x64 et cet exécutable serait utilisé ensuite à chaque nouvelle exécution ce qui pourrait expliquer les relatives bonnes performances.

Si j'ai bien compris il y a en réalité deux passes, traduction au premier lancement + traduction à la volée pour le code exécuté dynamiquement (JIT).
Et du coup peut être bien selon la manière dont l'application a été codée il est possible de + ou - optimiser en avance avec des perfs plus dégradée si le recours au JIT est massif.

N'hésitez pas à me corriger je suis pas dev sur Mac donc je peux me tromper, j'essaye juste de vulgariser ce que j'en ai compris.

Tout le monde semble oublier que Rosetta avait déjà des caches d'émulation pour les instructions les plus souvent utilisées.
Pour le reste, oui, le système Rosetta 2 va mettre en cache les jeux d'instruction déjà traduites pour gagner du temps. Le tout est de savoir ce qui prendra le moins de temps, traduire à la volée ou monopoliser du temps machine pour voir si cela a déjà été fait. Mais tout cela consomme du stockage et de la RAM.
En revanche, il semble aussi que le système va lors du lancement mettre en cache une version pré-traduite du code exécuté. Là ça consomme surtout de l'espace disque.

[lizuel]

Bonjour,
Je suis les informations à ce sujet avec beaucoup d'intérêt. Étant un utilisateur basique gardant très longtemps ses machines, ma principale inquiétude est la performance vis à vis des évolutions de standard. En particulier, on commence à parler en ce moment du codec H266 qui réduirait la bande passante de 50% à iso-qualité.
Si ce codec n'est pas hard-codé dans la puce ARM, il faudra en passer par un décodeur logiciel beaucoup moins performant et plus consommateur d'énergie. Il se trouve que les deux (la finalisation de la norme du codec et les premiers mac ARM) sont susceptibles d'arriver en même temps à la fin de l'année. J'espère que Apple (qui fait partie de groupe de travail de ce codec) aura l'intelligence de l'intégrer dès le départ et qu'elle ne se contentera pas d'intégrer uniquement les codec spécifiques à sa plateforme ; Par exemple, quid du décodage d'un FLAC avec un mac ARM ?

[Lionel]

Bonjour,
Je suis les informations à ce sujet avec beaucoup d'intérêt. Étant un utilisateur basique gardant très longtemps ses machines, ma principale inquiétude est la performance vis à vis des évolutions de standard. En particulier, on commence à parler en ce moment du codec H266 qui réduirait la bande passante de 50% à iso-qualité.
Si ce codec n'est pas hard-codé dans la puce ARM, il faudra en passer par un décodeur logiciel beaucoup moins performant et plus consommateur d'énergie. Il se trouve que les deux (la finalisation de la norme du codec et les premiers mac ARM) sont susceptibles d'arriver en même temps à la fin de l'année. J'espère que Apple (qui fait partie de groupe de travail de ce codec) aura l'intelligence de l'intégrer dès le départ et qu'elle ne se contentera pas d'intégrer uniquement les codec spécifiques à sa plateforme ; Par exemple, quid du décodage d'un FLAC avec un mac ARM ?

Le H.266 sera un jour supporté par la partie graphique, mais comme à chaque fois il faudra 2 ans au minimum.
Pour le FLAC, ce sera certainement rapide en revanche.

[pacoul]

En revanche, pour d'autres logiciels, comme Chrome ou LightRoom 4.4 64bits, ces logiciels sont inutilisables tant ils sont lents. C'est peut-être lié à l'utilisation par le code d'instructions vectorielles qui ne sont pas émulées ou à des problèmes liés à Rosetta 2.

En bref, le grand public pourrait y trouver son compte dès maintenant en ayant une machine au CPU consommant trois fois moins et pour une puissance proche. Pour les professionnels ce serait une autre paire de manches, mais clairement, Apple pourrait en fin de compte créer une révolution et peut-être même faire un tort absolument considérable à Intel.

Lien vers le billet original

Chrome et Lightroom, des logiciels pros ?

[Lionel]

En revanche, pour d'autres logiciels, comme Chrome ou LightRoom 4.4 64bits, ces logiciels sont inutilisables tant ils sont lents. C'est peut-être lié à l'utilisation par le code d'instructions vectorielles qui ne sont pas émulées ou à des problèmes liés à Rosetta 2.

En bref, le grand public pourrait y trouver son compte dès maintenant en ayant une machine au CPU consommant trois fois moins et pour une puissance proche. Pour les professionnels ce serait une autre paire de manches, mais clairement, Apple pourrait en fin de compte créer une révolution et peut-être même faire un tort absolument considérable à Intel.

Lien vers le billet original

Chrome et Lightroom, des logiciels pros ?

J'ai dit ça moi ? Seulement le codage de Lightroom ou même de chrome sont des trucs assez chiadés et complexes. Donc si Lightroom ne marche pas, peu de chances que Photoshop le fasse, non ?

[flan]

Les navigateurs web ont des moteurs de rendu HTML+JS qui sont extrêmement complexes, certainement bien plus que la plupart des logiciels « pro ».

[bxlt]

A propos de l'émulation x64 -> ARM, il me semble avoir lu (bien que personne ne semble avoir noté la différence) qu'il s'agit cette fois ci non pas d'une émulation à la volée mais d'une traduction qui serait faite la première fois qu'on utilise un logiciel. Un exécutable ARM serait généré à partir de l'exécutable x64 et cet exécutable serait utilisé ensuite à chaque nouvelle exécution ce qui pourrait expliquer les relatives bonnes performances.

Si j'ai bien compris il y a en réalité deux passes, traduction au premier lancement + traduction à la volée pour le code exécuté dynamiquement (JIT).
Et du coup peut être bien selon la manière dont l'application a été codée il est possible de + ou - optimiser en avance avec des perfs plus dégradée si le recours au JIT est massif.

N'hésitez pas à me corriger je suis pas dev sur Mac donc je peux me tromper, j'essaye juste de vulgariser ce que j'en ai compris.

Tout le monde semble oublier que Rosetta avait déjà des caches d'émulation pour les instructions les plus souvent utilisées.
Pour le reste, oui, le système Rosetta 2 va mettre en cache les jeux d'instruction déjà traduites pour gagner du temps. Le tout est de savoir ce qui prendra le moins de temps, traduire à la volée ou monopoliser du temps machine pour voir si cela a déjà été fait. Mais tout cela consomme du stockage et de la RAM.
En revanche, il semble aussi que le système va lors du lancement mettre en cache une version pré-traduite du code exécuté. Là ça consomme surtout de l'espace disque.

A partir de Big Sur, les applis contiendront deux exécutables, l'un en X64, l'autre en ARM.
Pour les anciennes applis ne comportant que le code X64, le code ARM sera généré au premier lancement. Ce n'est pas à proprement un "cache", et même si la traduction automatique ne sera pas aussi bien optimisée qu'un vrai code natif, ça permettra de faire bcq mieux qu'une traduction à la volée, même contenue dans un cache mémoire. Et n'oublions pas que les API ont été évidemment réécrite en code ARM.

[Twisell]

A partir de Big Sur, les applis contiendront deux exécutables, l'un en X64, l'autre en ARM.

Ça part contre si c'est confirmé c'est un peu dommage. Du point de vue de l'AppStore c'est cohérent d'exiger des développeurs la livraison d'un UB2 pour accélérer l'adoption.
Mais coté utilisateur ce serait plus appréciable de récupérer un binaire personnalisé pour son architecture ou d'autoriser à tronquer le code inutile après l’installation pour consommer moins d’espace disque

PS: Bon Ok le soucis c'est que ça limiterais la possibilité de se passer des Apps entre deux postes d'archi différentes, mais je suis pas sur que ça corresponde encore à un cas d'usage très répandu.
Téléchargement en https depuis le site de l'éditeur ou AppStore au choix, mais je pense pas que beaucoup de gens s'échangent régulièrement des mise à jour d'applications en se refilant des Jaz

Ce message a été modifié par Twisell - 30 Jul 2020, 14:11.

[ekami]

Tout ceci semble de bonne augure.
Apple s'en tape d'Intel: ses principaux concurrents sont Google et Microsoft, et Huawei/Samsung (ce dernier étant aussi un de ses fournisseurs)
Le couple x86+Microsoft reste encore très présent dans le grand public et la plupart des entreprises, mais je ne saurais dire s'ils font de la résistance ou de l'innovation.
Apple devait en finir avec cette dichotomie x86/ARM et ces deux OS, elle fait le choix logique d'ARM, car c'est là qu'elle fait le plus gros de son chiffre d'affaires.
Pour l'instant Intel est en retard, mais tôt ou tard tous les grands fondeurs seront face au mur quantique (on à déjà atteint le mur de la fréquence, +- 5 GHz), et si à ce moment là aucun loup ne sort du bois avec une technologie réellement disruptive (IBM ?), alors on verra comment se re-équilibrent les PDM des 3 grands OS.
N'oublions pas que le processeur le plus puissant du moment est le Power 9 d'IBM, et les monstrueux Power 10 et 11 à venir (gravés à "seulement" 7 nm) vont rebattre les cartes dans le monde des super-calculateurs.
Mais aussi passionnantes qu'elles soient, toutes ces spéculations technologiques ne sont que peu de chose au vu des convulsions climatico-écolo-sanito-économico-sociales qui s'avancent…

Ce message a été modifié par ekami - 30 Jul 2020, 14:31.

[ekami]

PS: Bon Ok le soucis c'est que ça limiterais la possibilité de se passer des Apps entre deux postes d'archi différentes, mais je suis pas sur que ça corresponde encore à un cas d'usage très répandu.
Téléchargement en https depuis le site de l'éditeur ou AppStore au choix, mais je pense pas que beaucoup de gens s'échangent régulièrement des mise à jour d'applications en se refilant des Jaz

Détrompe toi, les clouds on remplacé les Disquettes, Syquest, Zip, Jaz et autres CDR/DVDR depuis belle lurette, mais garder une "vieille" version d'un .dmg ou .pkg et l'échanger au besoin est encore monnaie courante.
Mais si à l'avenir Apple force le passage par le Mac App Store, elle perdra énormément de clients qui ne feront pas le "grand saut" et quitteront définitivement la marque.
Gageons qu'elle aura la sagesse de ne pas scier la branche sur laquelle elle est assise…

[playfans]

Bonjour,
Je suis les informations à ce sujet avec beaucoup d'intérêt. Étant un utilisateur basique gardant très longtemps ses machines, ma principale inquiétude est la performance vis à vis des évolutions de standard. En particulier, on commence à parler en ce moment du codec H266 qui réduirait la bande passante de 50% à iso-qualité.
Si ce codec n'est pas hard-codé dans la puce ARM, il faudra en passer par un décodeur logiciel beaucoup moins performant et plus consommateur d'énergie. Il se trouve que les deux (la finalisation de la norme du codec et les premiers mac ARM) sont susceptibles d'arriver en même temps à la fin de l'année. J'espère que Apple (qui fait partie de groupe de travail de ce codec) aura l'intelligence de l'intégrer dès le départ et qu'elle ne se contentera pas d'intégrer uniquement les codec spécifiques à sa plateforme ; Par exemple, quid du décodage d'un FLAC avec un mac ARM ?

Très honnêtement, cela serait surprenant que l'A14 intègre le décodage matériel du H.266, 2022 semble le minimum, surtout quand on voit l'implémentation du H.265 qui reste malheureusement marginale encore aujourd'hui.

Pour le FLAC, il n'y a pas de décodage hardware à ma connaissance, tout se fait en soft. Et même en parlant de fichiers FLAC avec DoP pour du DSD en MCH, même un vieux CPU peut le faire sans trop de soucis. Sachant que le flac et apple n'ont jamais été de bons amis, la vérité est ailleurs.


Rien ne t'interdit de revendre tes macs en occasion, ce qui te permet de perdre peu d'argent car les machines gardent très bien leur valeur. et utiliser les fonds pour en acheter un neuf. Tu fais plaisir aux acheteurs avec moins de moyens et cela te permet de changer de machine et rester à la page techniquement.
La technologie longtermiste est un oxymore.

Ce message a été modifié par playfans - 30 Jul 2020, 14:44.

[stephn666]

Bonjour,

je préfère attendre un peu plus longtemps la transition que de me jeter immédiatement sur ces nouvelles machines, je crois qu'à la fin de l'année nous avons les "nouveaux" et derniers iMac intel qui vont arriver en plus (23" contre 21,5" et 30" contre 27" ayant la même taille que nos machines actuelles).

Bonne soirée.

Ce message a été modifié par stephn666 - 30 Jul 2020, 15:53.

[vlady]

Tout ceci semble de bonne augure.
Apple s'en tape d'Intel: ses principaux concurrents sont Google et Microsoft, et Huawei/Samsung (ce dernier étant aussi un de ses fournisseurs)
Le couple x86+Microsoft reste encore très présent dans le grand public et la plupart des entreprises, mais je ne saurais dire s'ils font de la résistance ou de l'innovation.
Apple devait en finir avec cette dichotomie x86/ARM et ces deux OS, elle fait le choix logique d'ARM, car c'est là qu'elle fait le plus gros de son chiffre d'affaires.
Pour l'instant Intel est en retard, mais tôt ou tard tous les grands fondeurs seront face au mur quantique (on à déjà atteint le mur de la fréquence, +- 5 GHz), et si à ce moment là aucun loup ne sort du bois avec une technologie réellement disruptive (IBM ?), alors on verra comment se re-équilibrent les PDM des 3 grands OS.
N'oublions pas que le processeur le plus puissant du moment est le Power 9 d'IBM, et les monstrueux Power 10 et 11 à venir (gravés à "seulement" 7 nm) vont rebattre les cartes dans le monde des super-calculateurs.
Mais aussi passionnantes qu'elles soient, toutes ces spéculations technologiques ne sont que peu de chose au vu des convulsions climatico-écolo-sanito-économico-sociales qui s'avancent…

Les sources ? Moi, j'ai vu autre chose :

https://www.phoronix.com/scan.php?page=arti...9-arm&num=2

Perso, je ne crois pas dans le miracle ARM. Apple a lourdement insisté sur la "performance per watt". On verra les vraies perfs sur les vraies machines et dans les conditions de vrais workloads (compilation, base de données, docker, vm linux, 3D, jeux).

[M-Rick]

C'est marrant car il y a tout juste un mois les messages étaient plutôt dithyrambiques envers les Macs ARM 😉

https://forum.macbidouille.com/index.php?sh...p;#entry4334844

Ce message a été modifié par M-Rick - 30 Jul 2020, 17:49.

[Twisell]

Tout ceci semble de bonne augure.
Apple s'en tape d'Intel: ses principaux concurrents sont Google et Microsoft, et Huawei/Samsung (ce dernier étant aussi un de ses fournisseurs)
Le couple x86+Microsoft reste encore très présent dans le grand public et la plupart des entreprises, mais je ne saurais dire s'ils font de la résistance ou de l'innovation.
Apple devait en finir avec cette dichotomie x86/ARM et ces deux OS, elle fait le choix logique d'ARM, car c'est là qu'elle fait le plus gros de son chiffre d'affaires.
Pour l'instant Intel est en retard, mais tôt ou tard tous les grands fondeurs seront face au mur quantique (on à déjà atteint le mur de la fréquence, +- 5 GHz), et si à ce moment là aucun loup ne sort du bois avec une technologie réellement disruptive (IBM ?), alors on verra comment se re-équilibrent les PDM des 3 grands OS.
N'oublions pas que le processeur le plus puissant du moment est le Power 9 d'IBM, et les monstrueux Power 10 et 11 à venir (gravés à "seulement" 7 nm) vont rebattre les cartes dans le monde des super-calculateurs.
Mais aussi passionnantes qu'elles soient, toutes ces spéculations technologiques ne sont que peu de chose au vu des convulsions climatico-écolo-sanito-économico-sociales qui s'avancent…

Les sources ? Moi, j'ai vu autre chose :

https://www.phoronix.com/scan.php?page=arti...9-arm&num=2

Perso, je ne crois pas dans le miracle ARM. Apple a lourdement insisté sur la "performance per watt". On verra les vraies perfs sur les vraies machines et dans les conditions de vrais workloads (compilation, base de données, docker, vm linux, 3D, jeux).

Pour le coup c'est pas qu'une question de croyance, Lionel à eu des infos fiables basées sur la machine de dev qui sera à priori moins puissante que les premières "vraies" machines.
Je peux lui reprocher bien des choses, mais certainement pas d'être dithyrambique sur Apple sans raison valable.

Pour les workloads tu as raison (quoi que si la 4K passe, je ne vois pas bien ce qui ferais frémir une base de données) mais alors pour les benchmark il faut que tu expliques....
On est à priori pas du tout sur des puces Apple, quelle est la pertinence de ces benchs dans l'histoire??

Ce message a été modifié par Twisell - 30 Jul 2020, 17:55.

[Boboss29]

Il ne s'agit pour le moment que d'un KIT pour les dév, pour se faire la main sur l'architecture. On parle de A14, mais qui nous dit qu'Apple va utiliser les mêmes processeurs pour les mac ? Si ça se trouve on aura la surprise de voir des bécannes surboosté avec des processeurs spécialement conçus pour des machines de bureaux et non pas des tablettes (aussi puissants que sont les Ipad Pro). Si Apple quitte Intel pour ses propres processeurs, j'imagine qu'ils ont de quoi concurrencer les Xeons et autres i9. D'autant qu'ils parlent d'une transition complète sur 2 ans. A mon avis, on va être bien surpris. Ce A12z c'est juste pour faire patienter 😀

[ekami]

Tout ceci semble de bonne augure.
N'oublions pas que le processeur le plus puissant du moment est le Power 9 d'IBM, et les monstrueux Power 10 et 11 à venir (gravés à "seulement" 7 nm) vont rebattre les cartes dans le monde des super-calculateurs.
Mais aussi passionnantes qu'elles soient, toutes ces spéculations technologiques ne sont que peu de chose au vu des convulsions climatico-écolo-sanito-économico-sociales qui s'avancent…

Les sources ? Moi, j'ai vu autre chose :
https://www.phoronix.com/scan.php?page=arti...9-arm&num=2
Perso, je ne crois pas dans le miracle ARM. Apple a lourdement insisté sur la "performance per watt". On verra les vraies perfs sur les vraies machines et dans les conditions de vrais workloads (compilation, base de données, docker, vm linux, 3D, jeux).

Chaque type de processeur possède son propre jeu d'instructions, et certaines sont hyper-spécialisées et adaptées à certains types d'usages.
Cela explique que les processeurs IBM Power sont mauvais en encodage/décodage vidéo et au top dans d'autres types d'usages.
Les Processeurs Power d'IBM sont utilisés pour le Big data et les applications scientifiques, mais ils consomment beaucoup.
Et ARM est sur l'autre versant, ayant un excellent rapport performance/watt.
Côté grand public, le problème est plutôt que les concepts fondamentaux Dossiers/Fichiers et Application/Fichier n'ont pas bougé depuis 1960.

[linus]

A partir de Big Sur, les applis contiendront deux exécutables, l'un en X64, l'autre en ARM.

Ça part contre si c'est confirmé c'est un peu dommage. Du point de vue de l'AppStore c'est cohérent d'exiger des développeurs la livraison d'un UB2 pour accélérer l'adoption.
Mais coté utilisateur ce serait plus appréciable de récupérer un binaire personnalisé pour son architecture ou d'autoriser à tronquer le code inutile après l’installation pour consommer moins d’espace disque :

Lors de la transition PPC Intel, les appli étaient "fat" (2 binaires dans le bundle). Il était toujours possible de récupérer ou supprimer l'un ou l'autre avec la commande "lipo". On peut imaginer que ce sera pareil avec le code "fat Intel/ARM)

[fxn]

Il ne s'agit pour le moment que d'un KIT pour les dév, pour se faire la main sur l'architecture. On parle de A14, mais qui nous dit qu'Apple va utiliser les mêmes processeurs pour les mac ? Si ça se trouve on aura la surprise de voir des bécannes surboosté avec des processeurs spécialement conçus pour des machines de bureaux et non pas des tablettes (aussi puissants que sont les Ipad Pro). Si Apple quitte Intel pour ses propres processeurs, j'imagine qu'ils ont de quoi concurrencer les Xeons et autres i9. D'autant qu'ils parlent d'une transition complète sur 2 ans. A mon avis, on va être bien surpris. Ce A12z c'est juste pour faire patienter 😀

oui bien sûr. En fait on ne peut même pas dire pour faire patienter…

à ce stade cela ne regarde que les développeurs uniquement pour du langage. Donc c’est amusant de spéculer comme d’habitude mais c’est totalement sur du vent. Cela n’a même que peu de sens de regarder les performances. Si ce n’est pour « découvrir » que les applications qui n’ont pas encore été optimisées: ne sont pas optimisées !

Machine transitoire pour développeurs, processeur de transition, et la question de l’émulation elle-même est purement transitoire par définition.

Ce message a été modifié par fxn - 30 Jul 2020, 18:29.

[malloc]

Merci @Lionel. C'est pour lire ce genre d'articles qu'on vient sur MB

C'est de bon augure pour ceux qui attendent la machine polyvalente et légère que le MBAir aurait pu être si elle avait été déclinée en plus de 13"...
Allez, un petit MBArm en 15" ou 16", et j'abandonne enfin mon MBPro 2014 (putain, six ans...)

[ekami]

A partir de Big Sur, les applis contiendront deux exécutables, l'un en X64, l'autre en ARM.

Ça part contre si c'est confirmé c'est un peu dommage. Du point de vue de l'AppStore c'est cohérent d'exiger des développeurs la livraison d'un UB2 pour accélérer l'adoption.
Mais coté utilisateur ce serait plus appréciable de récupérer un binaire personnalisé pour son architecture ou d'autoriser à tronquer le code inutile après l’installation pour consommer moins d’espace disque :

Lors de la transition PPC Intel, les appli étaient "fat" (2 binaires dans le bundle). Il était toujours possible de récupérer ou supprimer l'un ou l'autre avec la commande "lipo". On peut imaginer que ce sera pareil avec le code "fat Intel/ARM)

Ca sera surement possible, mais à l'époque les applications n'étaient ni signées ni "notariées".
A présent une appli est censée ne pas être modifiée d'un seul octet (sauf mise à jour de sa signature) sous peine de voir sa checksum être différente de celle de sa signature et être rejetée par Gatekeeper.
Mais en pratique le lancement d'une appli "modifiée" se contourne facilement avec le terminal, donc au final ça ne devrait pas poser beaucoup de problèmes.

[PierreH]

Ca fait de la peine pour ceux qui ont mis 20000 balles dans un MacPro 2019...