En quoi l'architecture ARM diffère-t-elle de x86? [fermé]


192

L'architecture x86 est-elle spécialement conçue pour fonctionner avec un clavier alors que ARM s'attend à être mobile? Quelles sont les principales différences entre les deux?


37
À moins que le x86 n'ait un port ps / 2 que je ne connais pas, il n'est pas plus conçu pour les claviers qu'une paire de sous-vêtements sales :-)
paxdiablo

6
Je pense que le clavier fait référence à un rôle de PC typique par opposition à l'appareil physique.
bruit

24
Le x86 n'a pas été conçu; Il a évolué sur une île, avec un étrange oiseau qui mangeait tout ce qui essayait de prier dessus. Il semble maintenant plus étrange qu'un ornithorynque à bec de canard, et ne ferait pas bien si un navire rempli de nouveaux animaux arrivait.
ctrl-alt-delor

5
@richard - malheureusement, c'est la description la plus précise historiquement de x86 que j'ai jamais vue. Cela en dit long sur l'industrie.
Leeor

6
@Leeor Désolé j'ai fait une petite erreur dans mon commentaire, j'ai dit que l'oiseau mangeait des prédateurs du x86, là où comme il ne les mangeait pas, il s'assit dessus. Il convient également de noter que les plumes douces de l'oiseau étaient si très très bien rangées.
ctrl-alt-delor

Réponses:


306

ARMest une architecture RISC (Reduced Instruction Set Computing) alors qu'elle x86est une CISC (Complex Instruction Set Computing).

La principale différence entre celles-ci dans cet aspect est que les instructions ARM ne fonctionnent que sur des registres avec quelques instructions pour charger et enregistrer des données depuis / vers la mémoire tandis que x86 peut également fonctionner directement sur la mémoire. Jusqu'à la v8, ARM était une architecture 32 bits native, favorisant les opérations sur quatre octets par rapport aux autres.

ARM est donc une architecture plus simple, conduisant à une petite zone de silicium et à de nombreuses fonctionnalités d'économie d'énergie, tandis que x86 devient une bête de puissance en termes de consommation d'énergie et de production.

À propos de la question sur " L'architecture x86 est-elle spécialement conçue pour fonctionner avec un clavier alors que ARM s'attend à être mobile? ". x86n'est pas spécialement conçu pour fonctionner avec un clavier ni ARMpour les mobiles. Cependant, encore une fois, en raison des choix architecturaux de base, x86 a également des instructions avec lesquelles travailler directement, IOcontrairement à ARM. Cependant, avec les bus IO spécialisés comme les USB, le besoin de telles fonctionnalités disparaît également.

Si vous avez besoin d'un document à citer, voici ce que le Guide des programmeurs de la série Cortex-A (4.0) explique sur les différences entre les architectures RISC et CISC:

Un processeur ARM est un processeur RISC (Reduced Instruction Set Computer).

Les processeurs CISC (Complex Instruction Set Computer), comme le x86, ont un riche jeu d'instructions capable de faire des choses complexes avec une seule instruction. Ces processeurs ont souvent des quantités importantes de logique interne qui décodent les instructions de la machine en séquences d'opérations internes (microcode).

Les architectures RISC, en revanche, ont un plus petit nombre d'instructions plus générales, qui pourraient être exécutées avec beaucoup moins de transistors, rendant le silicium moins cher et plus économe en énergie. Comme les autres architectures RISC, les cœurs ARM ont un grand nombre de registres à usage général et de nombreuses instructions s'exécutent en un seul cycle. Il a des modes d'adressage simples, où toutes les adresses de chargement / stockage peuvent être déterminées à partir du contenu du registre et des champs d'instructions.

La société ARM fournit également un article intitulé Architectures, Processors, and Devices Development Article décrivant comment ces termes s'appliquent à leur entreprise.

Un exemple comparant l'architecture du jeu d'instructions:

Par exemple, si vous avez besoin d'une sorte de bloc de comparaison de mémoire par octet dans votre application (généré par le compilateur, en ignorant les détails), voici à quoi cela pourrait ressembler sur x86

repe cmpsb         /* repeat while equal compare string bytewise */

tandis que sur la ARMforme la plus courte peut ressembler (sans vérification d'erreur, etc.)

top:
ldrb r2, [r0, #1]! /* load a byte from address in r0 into r2, increment r0 after */
ldrb r3, [r1, #1]! /* load a byte from address in r1 into r3, increment r1 after */
subs r2, r3, r2    /* subtract r2 from r3 and put result into r2      */
beq  top           /* branch(/jump) if result is zero                 */

qui devrait vous donner une idée de la différence de complexité des jeux d'instructions RISC et CISC.


9
ARMv8-A a une architecture 64 bits appelée AArch64.
kyrias

9
Bien que le x86 ait des instructions très puissantes, le bras peut toujours le battre dans un combat (si les deux ont la même vitesse d'horloge). C'est en partie parce que le bras a un bon ensemble de registres, alors que le x86 passe la moitié de son temps à déplacer des données dans et hors de son ensemble limité de registres (c'est moins vrai pour x86-64, il a plus de registres ). Et en partie parce que la simplicité de l'Arm laisse de la place pour un cache plus grand et que toutes les instructions sont conditionnelles (ce qui réduit les pertes de cache). Et l'instruction multiple de mouvement de bras (la seule instruction non RISC), lui permet de déplacer rapidement les données.
ctrl-alt-delor

4
Je pourrais écrire du code ARM plus rapidement, bien que plus grand, en utilisant plus de registres. Si je regarde cette implémentation, le x86 prend 5 + 9 × N horloges, l'ARM prend 4 × N horloges (les deux chiffres sont pour aucun cache manque). Le x86 obtient de meilleurs résultats pour les octets d'instructions dans cet exemple: x86 = 2 octets, arm = 16 octets. ARM obtient de bien meilleurs résultats sur cette métrique dans des tests plus réalistes, par exemple à la sortie de la boucle, r2 aura des informations sur si les chaînes sont égales / qui est plus grande, de même que les codes de condition. Le bras peut exécuter d'autres instructions avant de vérifier les codes de condition. L'armement n'a pas à brancher lors de la vérification des codes de condition.
ctrl-alt-delor

2
@JeremyFelix Cela ressemble à ceci stackoverflow.com/questions/13106297/... Il existe différents tuyaux pour différents types d'instructions, même s'il y en a en double. Le processeur divise les instructions en micro-instructions et celles-ci peuvent s'exécuter en parallèle entre les pipelines.
auselen

2
Vous dites "tandis que x86 peut également fonctionner directement sur la mémoire." cependant pour le x86 (pré x86-64), il a si peu de registres qu'il n'y avait pas de «ainsi», il fallait tout stocker en mémoire; environ la moitié des instructions dans un programme où il suffit de déplacer les choses. Alors que dans ARM, très peu d'instructions sont nécessaires pour déplacer des données.
ctrl-alt-delor

94

Ni l'un ni l'autre n'a rien de spécifique au clavier ou au mobile, à part le fait que pendant des années, ARM a eu un avantage assez substantiel en termes de consommation d'énergie, ce qui le rendait attrayant pour toutes sortes d'appareils fonctionnant sur batterie.

En ce qui concerne les différences réelles: ARM a plus de registres, prend en charge la prédication pour la plupart des instructions bien avant qu'Intel ne l'ajoute, et a longtemps incorporé toutes sortes de techniques (appelez-les "astuces", si vous préférez) pour économiser de l'énergie presque partout où il le pourrait.

Il y a aussi une différence considérable dans la façon dont les deux instructions codent. Intel utilise un codage de longueur variable assez complexe dans lequel une instruction peut occuper de 1 à 15 octets. Cela permet aux programmes d'être assez petits, mais rend le décodage des instructions relativement difficile (comme dans: le décodage rapide des instructions en parallèle ressemble plus à un cauchemar complet).

ARM a deux modes d'encodage d'instructions différents: ARM et THUMB. En mode ARM, vous avez accès à toutes les instructions et l'encodage est extrêmement simple et rapide à décoder. Malheureusement, le code du mode ARM a tendance à être assez volumineux, il est donc assez courant pour un programme d'occuper environ deux fois plus de mémoire que le code Intel. Le mode pouce tente d'atténuer cela. Il utilise toujours un codage d'instructions assez régulier, mais réduit la plupart des instructions de 32 bits à 16 bits, par exemple en réduisant le nombre de registres, en éliminant la prédication de la plupart des instructions et en réduisant la plage de branches. Au moins d'après mon expérience, cela ne donne toujours pas tout à faitaussi dense de codage que le code x86 peut l'être, mais c'est assez proche, et le décodage est encore assez simple et direct. Une densité de code inférieure signifie que vous avez généralement besoin d'au moins un peu plus de mémoire et (généralement plus sérieusement) d'un cache plus grand pour obtenir des performances équivalentes.

À un moment donné, Intel a mis beaucoup plus l'accent sur la vitesse que sur la consommation d'énergie. Ils ont commencé à mettre l'accent sur la consommation d'énergie principalement dans le contexte des ordinateurs portables. Pour les ordinateurs portables, leur objectif de puissance typique était de l'ordre de 6 watts pour un ordinateur portable assez petit. Plus récemment ( beaucoup plus récemment), ils ont commencé à cibler les appareils mobiles (téléphones, tablettes, etc.) Pour ce marché, ils recherchent au maximum quelques watts. Ils semblent s'en tirer plutôt bien, bien que leur approche ait été substantiellement différente de celle d'ARM, mettant l'accent sur la technologie de fabrication où ARM a principalement mis l'accent sur la micro-architecture (pas surprenant, étant donné qu'ARM vend des conceptions et laisse la fabrication à d'autres).

Selon la situation, la consommation d'énergie d'un processeur est souvent plus importante que sa consommation d'énergie. Au moins comme j'utilise les termes, la consommation d'énergie fait référence à la consommation d'énergie sur une base (plus ou moins) instantanée. Cependant, la consommation d'énergie se normalise en fonction de la vitesse, donc si (par exemple) le processeur A consomme 1 watt pendant 2 secondes pour effectuer un travail et que le processeur B consomme 2 watts pendant 1 seconde pour faire le même travail, les deux processeurs consomment la même quantité totale d'énergie (deux watts secondes) pour faire ce travail - mais avec le CPU B, vous obtenez des résultats deux fois plus rapidement.

Les processeurs ARM ont tendance à très bien fonctionner en termes de consommation d'énergie. Donc, si vous avez besoin de quelque chose qui nécessite presque constamment la "présence" d'un processeur, mais qui ne fait pas vraiment beaucoup de travail, cela peut très bien fonctionner. Par exemple, si vous faites de la visioconférence, vous collectez quelques millisecondes de données, les compressez, les envoyez, recevez des données d'autres personnes, les décompressez, les lisez et répétez. Même un processeur très rapide ne peut pas passer beaucoup de temps à dormir, donc pour des tâches comme celle-ci, ARM fonctionne très bien.

Les processeurs Intel (en particulier leurs processeurs Atom, qui sont en fait destinés aux applications basse consommation) sont extrêmement compétitifs en termes de consommation d'énergie. Alors qu'ils fonctionnent presque à leur pleine vitesse, ils consommeront plus d'énergie que la plupart des processeurs ARM - mais ils finissent également de travailler rapidement, de sorte qu'ils peuvent se rendormir plus tôt. En conséquence, ils peuvent combiner une bonne autonomie de batterie avec de bonnes performances.

Donc, lorsque vous comparez les deux, vous devez faire attention à ce que vous mesurez, pour être sûr que cela reflète ce qui vous tient vraiment à cœur. ARM fonctionne très bien en termes de consommation d'énergie, mais selon la situation, vous pouvez facilement vous soucier davantage de la consommation d'énergie que de la consommation d'énergie instantanée.


c'est pourquoi ? RISC a besoin de plus de RAM, tandis que le CISC met l'accent sur une taille de code plus petite et utilise moins de RAM dans l'ensemble que RISC
Waqar Naeem

Le mode pouce (longueur variable permettant des encodages courts) n'est pas une différence ; c'est ainsi que x86 fonctionne toujours (mais plus encore, avec une longueur d'instruction variant de 1 à 15 octets, et beaucoup plus difficile à décoder que Thumb2). Le mode ARM (codage à largeur fixe avec des instructions non destructives à 3 opérandes) est la différence par rapport à x86!
Peter Cordes

Avoir un processeur beaucoup plus rapide n'est pas d'une grande aide - la visioconférence pourrait être un meilleur exemple: une faible latence signifie que vous ne pouvez pas simplement faire une rafale de décodage dans une mémoire tampon de taille décente et retourner dans un état de sommeil de niveau profond ou moyen . "Race to sleep" est un concept clé de la consommation d'énergie pour une quantité fixe de calcul, étant donné que les processeurs modernes peuvent économiser de l'énergie lorsqu'ils sont complètement inactifs (horloge arrêtée, ou même mise hors tension de certaines parties du cœur. après la réécriture.) ... et c'est le point que vous faites valoir dans le paragraphe suivant, bien sûr. >. <
Peter Cordes

@PeterCordes: l'encodage en mode pouce ne ressemble pas beaucoup à l'encodage x86. Bien que ce ne soit pas aussi régulier que l'encodage ARM, son format reste assez fixe.L'augmentation de la densité provient en grande partie de l'élimination de bits qui sont simplement rarement utilisés dans l'encodage ARM. Par exemple, pratiquement toutes les instructions ARM sont conditionnelles, mais les conditions ne sont utilisées qu'un assez petit pourcentage du temps (donc la plupart des instructions THUMB non-branchées sont inconditionnelles).
Jerry Coffin le

@PeterCordes: Vous avez raison: la visioconférence est un meilleur exemple - je l'ai édité. Merci.
Jerry Coffin le

39

En plus du premier paragraphe de Jerry Coffin . Par exemple, la conception ARM réduit la consommation d'énergie.

L'entreprise ARMne concède que la technologie CPU. Ils ne fabriquent pas de puces physiques. Cela permet à d'autres entreprises d'ajouter diverses technologies périphériques, généralement appelées SOC ou système sur puce. Que l'appareil soit une tablette, un téléphone portable ou un système de divertissement embarqué. Cela permet aux fournisseurs de puces d'adapter le reste de la puce à une application particulière. Cela présente des avantages supplémentaires,

  1. Coût du conseil inférieur
  2. Puissance inférieure (note1)
  3. Fabrication plus facile
  4. Facteur de forme plus petit

ARMprend en charge les fournisseurs de SOC avec AMBA , permettant aux développeurs de SOC d'acheter des modules tiers prêts à l'emploi; comme un Ethernet, des contrôleurs de mémoire et d'interruption. Certaines autres plates-formes de processeur prennent en charge cela, comme MIPS , mais MIPS n'est pas aussi conscient de la puissance.

Tous ces éléments sont avantageux pour une conception portable / à piles. Certains sont tout simplement bons partout. De plus, ARMa des antécédents d'appareils à piles; Apple Newton , organisateurs Psion . L' infrastructure du logiciel PDA a été exploitée par certaines entreprises pour créer des appareils de type téléphone intelligent . Cependant, ceux qui ont réinventé l'interface graphique pour une utilisation avec un téléphone intelligent ont eu plus de succès .

La montée en puissance des Open sourcejeux d'outils a operating systemségalement facilité les différentes SOCpuces. Une organisation fermée aurait des problèmes pour essayer de prendre en charge tous les différents appareils disponibles pour l'ARM. Les deux plates-formes cellulaires les plus populaires, Andriod et OSx / IOS, sont basées sur les systèmes d' exploitation Linux et FreeBSD, Mach et NetBSD . Open Sourceaide les SOCfournisseurs à fournir un support logiciel pour leurs jeux de puces.

Espérons que la raison pour laquelle x86 est utilisé pour le clavier est évidente. Il a le logiciel et, plus important encore, des personnes formées pour utiliser ce logiciel. Netwinder est un ARMsystème conçu à l'origine pour le clavier . En outre, les fabricants recherchent actuellement ARM64 pour le marché des serveurs. L'électricité / chaleur est une préoccupation dans les centres de données 24/7.

Je dirais donc que l' écosystème qui se développe autour de ces puces est aussi important que des fonctionnalités telles que la faible consommation d'énergie. ARMse bat depuis un certain temps (du milieu à la fin des années 1980) pour un calcul à faible puissance et à hautes performances et ils ont beaucoup de monde à bord.

Remarque 1: plusieurs puces ont besoin de pilotes de bus pour communiquer entre eux à des tensions connues et conduire. En outre, des puces séparées nécessitent généralement des condensateurs de prise en charge et d'autres composants d'alimentation qui peuvent être partagés dans un système SOC .


22

L'ARM est comme une voiture de sport italienne:

  • Moteur bien équilibré, bien réglé. Donne une bonne accélération et une vitesse de pointe.
  • Excellentes poursuites, freins et suspension. Peut s'arrêter rapidement, peut tourner sans ralentir.

Le x86 est comme une muscle car américaine:

  • Gros moteur, grosse pompe à essence. Donne une excellente vitesse de pointe et une excellente accélération, mais consomme beaucoup de carburant.
  • Des freins épouvantables, il faut mettre un rendez-vous dans votre agenda, si vous voulez ralentir.
  • Terrible direction, il faut ralentir en virage.

En résumé: le x86 est basé sur un design de 1974 et est bon en ligne droite (mais utilise beaucoup de carburant). Le bras consomme peu de carburant, ne ralentit pas pour les virages (branches).


Métaphore terminée, voici quelques vraies différences.

  • Arm a plus de registres.
  • Arm a peu de registres à usage spécial, x86 est tous des registres à usage spécial (donc moins de choses en mouvement).
  • Arm a peu de commandes d'accès à la mémoire, seulement charger / stocker le registre.
  • Arm est en interne l'architecture de Harvard ma conception.
  • Le bras est simple et rapide.
  • Les instructions de bras sont à cycle unique du point de vue architectural (à l'exception du chargement / stockage multiple).
  • Les instructions de bras font souvent plus d'une chose (en un seul cycle).
  • Là où plus d'une instruction Arm est nécessaire, comme le stockage en boucle et l'incrémentation automatique du x86, l'Arm le fait toujours en moins de cycles d'horloge.
  • Arm a plus d'instructions conditionnelles.
  • Le prédicteur de branche d'Arm est trivialement simple (s'il est inconditionnel ou à l'envers, alors supposez une branche, sinon supposez pas de branche), et fonctionne mieux que le très très très complexe du x86 (il n'y a pas assez d'espace ici pour l'expliquer, non pas que je puisse ).
  • Arm a un jeu d'instructions cohérent simple (vous pouvez compiler à la main et apprendre le jeu d'instructions rapidement).

7
Cette analogie rompt avec le fait que les voitures de sport italiennes tombent en panne à chaque instant, alors que les processeurs ARM ne le font pas, et que même si cela pourrait être facilement fait, vous ne pouvez pas réellement acheter un seul processeur ARM capable de faire des vitesses de processeur de bureau. , sans parler de ceux qui sont connectés et des cartes mères pour les mettre. :)
Evi1M4chine

1
En termes de performances, il est en concurrence directe avec certains des processeurs Xeon les plus gros et les plus rapides (par exemple E5-2690 v3), mais à moindre coût. quora.com
ctrl-alt-delor

1
Pour les charges de travail massivement parallèles telles que les bases de données et les serveurs d'E / S, bien sûr. Pour les performances à un seul thread, personne n'a conçu un noyau ARM aussi gros que x86. Aucune raison pour laquelle ils ne pouvaient pas, personne ne l'a fait. La «taxe x86» sur l'alimentation et la surface de la puce n'est pas si grande comparée à la quantité de silicium utilisée pour les machines hors service dans les cœurs de processeur haute puissance. Il y a certainement des verrues dans x86, mais RISC a un inconvénient de densité de code (qui n'a généralement pas beaucoup d'importance, mais cela compte toujours). Cela est discuté à plusieurs reprises sur les forums de realworldtech.com .
Peter Cordes

1
@richard: Il y a beaucoup de choses dont vous n'avez pas "besoin", mais cela augmente la densité du code. L'astuce consiste à équilibrer la complexité du décodage avec la taille du code / le nombre d'instructions. L'augmentation de la largeur d'un noyau en panne est extrêmement coûteuse en consommation d'énergie, il est donc précieux de fournir plus de travail dans chaque instruction. Une petite augmentation de la complexité de décodage est beaucoup moins chère. Les processeurs x86 modernes parviennent déjà à décoder rapidement x86. (Pas assez rapidement pour garder un cœur OOO de 4 larges alimenté par les décodeurs au lieu de uop-cache ou de tampon de boucle, et bien sûr à un coût élevé en énergie.)
Peter Cordes

3
@ Evi1M4chine, cela rompt également avec le fait qu'une voiture de sport italienne est extrêmement chère, tandis qu'une muscle car américaine est relativement bon marché. Et la muscle car est ce qu'elle est parce qu'elle est simple, alors que quelque chose comme une Ferrari est très très compliqué. Tout le contraire de CISC vs RISC
Lorenzo Dematté

15

L'architecture ARM a été conçue à l'origine pour les ordinateurs personnels Acorn (voir Acorn Archimedes , vers 1987, et RiscPC ), qui étaient autant d'ordinateurs personnels à clavier que les modèles de PC IBM x86. Seules les implémentations ARM ultérieures ont été principalement ciblées sur le segment de marché mobile et embarqué.

À l'origine, de simples processeurs RISC de performances à peu près équivalentes pouvaient être conçus par des équipes d'ingénierie beaucoup plus petites (voir Berkeley RISC ) que celles travaillant sur le développement x86 chez Intel.

Mais, de nos jours, les puces ARM les plus rapides ont des unités d'envoi d'instructions dans le désordre multi-issues très complexes conçues par de grandes équipes d'ingénierie, et les cœurs x86 peuvent avoir quelque chose comme un cœur RISC alimenté par une unité de traduction d'instructions.

Ainsi, les différences actuelles entre les deux architectures sont davantage liées aux besoins spécifiques du marché des niches de produits ciblées par les équipes de développement. (Opinion aléatoire: ARM fait probablement plus de frais de licence à partir des applications intégrées qui ont tendance à être beaucoup plus limitées en termes de puissance et de coût. Et Intel doit maintenir un avantage de performance dans les PC et les serveurs pour leurs marges bénéficiaires. Ainsi, vous voyez différentes optimisations de mise en œuvre.)


Il existe encore d'énormes différences architecturales. Cependant, Intel a fait un travail formidable et investi beaucoup d'argent, pour faire fonctionner très bien un processeur mal architecturé (on se demande ce qui aurait pu être fait, si tout cet effort avait été mis dans un processeur bien architecturé).
ctrl-alt-delor
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.