Est-il possible de comparer les performances de ARM et x86 via des benchmarks?
A en juger par les dernières nouvelles, le nouveau Apple processeur A11 Bionic gagne plus de points que le mobile Intel Core i7 dans le benchmark Geekbench.
Si je comprends bien, il y a beaucoup de tests différents dans cette référence. Ces tests simulent une charge différente, y compris la charge, qui peut survenir au quotidien.
Certaines personnes affirment que ces résultats ne peuvent pas être comparés aux résultats x86. Ils disent que x86 est capable d'effectuer "des tâches plus complexes". À titre d'exemple, ils dirigent Photoshop, la conversion vidéo, les calculs scientifiques. Je conviens que le logiciel pour le ARM n'est souvent qu'une version "légère" du logiciel pour les ordinateurs de bureau. Mais il me semble que cette limitation est causée par le format des systèmes d'exploitation mobiles (faites votre travailler en déplacement, pas de souris, etc.), et non par les performances d'ARM.
Comme exemple opposé, regardons Safari. Un navigateur est un programme complexe. Et sur l'iPad, Safari fonctionne aussi bien que sur Mac. De plus, si l'on prend les résultats de Sunspider (benchmark JS), il s'avère que Safari sur iPad gagne plus de points.
Je pense que dans les tâches quotidiennes (Web, Office, Musique/Films) ARM (A10X, A11) et x86 (Intel i7 mobile dual core mobile) les performances sont comparables et égales.
Existe-t-il des types de tâches où ARM est vraiment loin derrière x86? Si oui, quelle en est la raison? Qu'est-ce qui empêche Apple de libérer un ordinateur portable sur ARM? Ils font déjà la même chose avec la migration de POWER vers x86. Ce sont des restrictions techniques, ou juste du marketing?
(J'avais l'intention de le faire car cette question est hors sujet, mais elle est devenue longue ..). Bien sûr, vous pouvez comparer, il vous suffit d'être très prudent, ce que la plupart des gens ne font pas. Le fait que les entreprises publiant (ou "divulguant") les résultats soient biaisés n'aide pas beaucoup non plus.
L'idée fausse la plus répandue est que vous pouvez comparer une référence sur deux systèmes et obtenir un score unique pour chacun. Cela ignore le fait que différents systèmes ont des points d'optimisation différents, le plus souvent en ce qui concerne la puissance (ou "TDP"). Ce que vous devez regarder est la courbe puissance/performances - ce graphique montre comment le système réagit à plus de puissance (augmentation de la fréquence, activation de plus de fonctionnalités de performance, etc.), et dans quelle mesure il contribue à ses performances. Un système peut gagner sur la plage de faible puissance, mais perdre lorsque la puissance disponible augmente, car il ne s'adapte pas si bien (ou même s'arrête à un moment donné). C'est généralement le cas avec Arm, car la plupart de ces processeurs sont réglés pour une faible consommation, tandis que x86 couvre un domaine plus large et évolue beaucoup mieux.
Si vous êtes obligé d'observer un seul point le long du graphique (ce qui est un scénario légitime, par exemple si vous recherchez un processeur pour un appareil à faible puissance), assurez-vous au moins que la comparaison est juste et utilise la même puissance enveloppe. Il y a bien sûr d'autres facteurs qui doivent être alignés (et parfois ne sont pas dus à une négligence ou à une intention de tricher) - la charge de travail devrait être la même (j'ai vu des versions différentes comparées ..), le compilateur devrait être aussi proche que possible (bien que générer du code arm vs x86 soit déjà une différence, mais les optimisations intermédiaires du compilateur devraient être similaires. Lorsque vous comparez 2 x86 comme Intel et AMD, vous devriez préférer le même binaire, sauf si vous souhaitez également autoriser des optimisations spécifiques à la machine). Enfin, le système devrait également être similaire, ce qui n'est pas le cas lorsque l'on compare un smartphone à un pc/macbook. La mémoire peut différer, le nombre de cœurs, etc. Cela peut être une différence légitime, mais ce n'est pas vraiment lié à une architecture meilleure que l'autre.
le sujet est faux, de ISA à une application ou un code source, il y a beaucoup de niveaux d'abstraction et la seule métrique que nous avons (temps d'exécution ou débit) dépend de nombreux facteurs qui pourraient en profiter un ou l'autre: les choix d'algorithmes, l'optimisation écrite en code source, l'implémentation/optimisations du compilateur/interprète, le comportement du système d'exploitation. Ils ne sont donc pas exactement/mathématiquement comparables. Cependant, en regardant les chiffres, et le utilitaire de l'application mobile écrit en parlant comme ingénieur de gestion, la puce ARM semble pouvoir fonctionner assez bien. Je pense que le la seule raison est l'inertie de la propagation standard (si vous remarquez que Microsoft propose une variante de fenêtres fonctionnant sur ARM processeurs, debian ARM la variante est prête https://www.debian.org/distrib/netinst ) .Les cœurs ARMv8 semblent proches de ceux x86/64 en regardant les nombres bruts
note les résultats i7-3770k: https://en.wikipedia.org/wiki/Instructions_per_second#MIPS
résumé des dernières caractéristiques du processeur Armv8, notez la quantité de décodage, de répartition, de caches et comparez la dernière colonne du cortex A73 au i7 3770k https://en.wikipedia.org/wiki/Comparison_of_ARMv8-A_cores =
caractéristiques du pont ivy intel: https://en.wikichip.org/wiki/intel/microarchitectures/ivy_bridge_ (client)
Détails A75. https://www.anandtech.com/show/11441/dynamiq-and-arms-new-cpus-cortex-a75-a55
le sujet de la consommation d'énergie est à nouveau complexe, la règle de base qui va sous toutes les règles de fréquence/tension (utilisées et abusées) sur www est: les transistors augmentent le temps. https://en.wikipedia.org/wiki/Rise_time
Il y a un délai fixe dans la commutation d'un transistor, cela détermine la fréquence maximale qu'un transistor pourrait commuter, et avec plusieurs d'entre eux liés en cascade, ce temps se résume de manière non linéaire (nécessite une intégration pour le démontrer) , par conséquent, il y a 10 ans, pour augmenter le GHz, les entreprises tentent de diviser en plusieurs étapes l'exécution d'une opération et les exécutent (opérations) de manière pipeline, même à l'intérieur de la phase de pipeline logique. https://en.wikipedia.org/wiki/Instruction_pipelining
le temps de montée dépend des caractéristiques physiques (matériaux et forme des transistors). Il peut être réduit en augmentant la tension, de sorte que le transistor commute plus rapidement, car la commutation est associée (laissez-moi le terme) à la charge/décharge d'un condensateur qui déclenche l'ouverture/la fermeture du canal du transistor.
Ces puces ARM sont conçues pour les applications à faible puissance, en changeant la conception, elles pourraient facilement gagner en MHz, mais elles utiliseront beaucoup d'énergie, combien? Encore une fois pas comparable si vous ne travaillez pas à l'intérieur d'un fonderie et avoir les chiffres.
un exemple d'applications serveur de processeurs ARM qui pourraient être plus proches du processeur de bureau/station de travail car la consommation d'énergie sont les processeurs Cavium ou qualcomm Falkor, et certains tests de référence indiquent qu'ils ne sont pas mauvais.