Pourquoi les applications sont-elles divisées en types basés sur Intel ou M1 si des binaires universels existent ?

La principale question que je me pose est la suivante : pourquoi ces sites séparent-ils leurs applications en deux catégories en fonction du type de puce s'ils peuvent simplement publier des binaires universels ?

Bien qu'il s'agisse d'une méthode simple (et recommandée par Apple), elle augmente la taille du programme. Car il s'agit en fait des deux installateurs sous une seule enveloppe.

Les autres questions qui en découlent portent essentiellement sur la raison pour laquelle cette application ne prend en charge que X types de puces. - C'est un peu comme si l'on disait "Ce programme est conçu pour fonctionner sur les processeurs AMD mais pas sur les processeurs Intel".

La comparaison entre AMD et Intel et Intel et M1 est la même que celle entre Red Delicious et Golden Delicious et entre Apple et Orange. Ce qu'Apple dit être Intel est en fait x86 (amd64/x86-64 pour être précis) ISA. AMD et Intel sont simplement des fabricants différents. Les programmes qui revendiquent le soutien de l'un d'entre eux ne le font que s'il s'agit d'un chipset ou d'une partie du matériel de bas niveau dépendant du fournisseur ou de caractéristiques développées par le fournisseur (3DNow !, AMD-V, Vt-x). Il y a de nombreux hackintosh dans la nature qui fonctionnent avec AMD. M1, en revanche, est conçu par Apple en interne, sur la base de l'ISA ARM. Ils sont donc incompatibles. Ils font les choses différemment au niveau du code machine.

La réponse est très simple et directe. Taille de transfert du réseau et encombrement du disque dur.

Un binaire universel contient à la fois du code exécutable (langage machine) pour le processeur M1 et pour le processeur intel X86-64. Cela signifie que l'ensemble de l'application pèsera beaucoup plus lourd. La plupart des ressources d'une application ne devront apparaître qu'une seule fois (définitions de l'interface utilisateur, images, sons, icônes, etc.), mais le code exécutable proprement dit sera deux fois plus lourd.

Pour les grandes applications telles que VLC ou Google-Chrome, cela représente des dizaines, voire des centaines de mégaoctets supplémentaires.

N'oublions pas non plus que nous sommes à l'ère des disques SSD et que la plupart des Mac (en particulier les MacBooks bas de gamme) ne disposent que d'un disque interne de 256 Go à 1 To. L'accumulation d'applications fait une grande différence.

Ainsi, en pensant au temps de téléchargement et aux quotas de transfert sur le réseau (qui coûtent au fournisseur du logiciel), et en se souciant que les applications ne prennent pas trop de place sur le disque dur de l'utilisateur, on peut s'attendre à ce qu'il y ait une augmentation de la consommation d'énergie.

De nombreux distributeurs de logiciels offrent le choix entre des versions universelles, intel-only et M1-only des mêmes applications.

C'est aussi simple que cela. Téléchargez ce qui vous convient, ce qui convient à votre Mac et à votre disque dur...

Développeurs pourrait ne distribue que des binaires universels, mais cela pourrait compliquer la vie des superutilisateurs et des administrateurs système qui souhaitent installer le logiciel, par exemple, sur une flotte de Mac à base de processeurs Intel sans avoir à télécharger deux binaires (bien qu'ils soient regroupés en un seul).

Certaines applications ne prennent en charge que certains types de puces en raison de la manière dont elles sont construites/compilées. Lorsque quelqu'un écrit le code d'une application, il utilise un compilateur pour traduire le code de haut niveau (lisible par l'homme) en instructions binaires de bas niveau (des uns et des zéros) que l'ordinateur peut comprendre. Étant donné que les différents processeurs (par exemple, AMD vs. ARM-M1 est une puce ARM) utilisent différentes séquences de uns et de zéros pour les mêmes actions, le même code binaire ne fonctionnera pas sur tous les systèmes. Pour donner un très simplifié exemple (il s'agit d'un no (je ne sais pas comment cela fonctionne réellement, et les nombres binaires que j'ai utilisés sont inventés, mais cela illustre le concept), un processeur ARM pourrait interpréter l'instruction 10011100 comme une commande d'écriture dans la mémoire vive, mais un processeur Intel peut utiliser l'instruction 10001111 pour écrire dans la RAM. Si vous alimentez un CPU Intel, l'instruction pour le CPU ARM ( 10011100 ), il accomplira probablement une tâche totalement différente. Si le processeur ne fait pas ce que le compilateur a prévu, l'application ne fonctionnera pas.
Pour que les applications fonctionnent sur plusieurs architectures de puces, vous devez compiler des binaires distincts pour chaque architecture (car chacune d'entre elles a ses propres ensemble d'instructions ). C'est pourquoi vous voyez les trois options sur certains des sites que vous visitez.