Les derniers contenus liés au tag AVX2

AMD détaille l'architecture de Zen

Tags : AMD; AVX2; Excavator; Jaguar; SGX; TSX; Zen;
Publié le 24/08/2016 à 02:45 par Guillaume Louel

Comme annoncé, AMD a profité de la conférence Hot Chips pour dévoiler les détails de l'architecture des cores CPU Zen, utilisée par ses prochains processeurs. AMD avait déjà dévoilé la semaine dernière quelques grandes lignes, cette fois on dispose de beaucoup plus de détails techniques.

Notez qu'en ce qui concerne les versions disponibles des puces, le nombre de cores, la fréquence, ou le fonctionnement du contrôleur mémoire, il faudra attendre, AMD ne dévoilera ce type de détails qu'ultérieurement. On a tout de même droit à nombre de détails techniques.

Le message de base d'AMD est de dire que l'architecture est repartie d'une feuille blanche, même si AMD concède avoir réutilisé certains blocs fonctionnels de ses architectures précédentes. En pratique, Zen aura été développé pour remplacer intégralement Jaguar et Excavator, ce qui laisse penser qu'on verra Zen décliné dans de larges gammes de TDP dans les mois à venir.

Le jeu d'instruction

Avant d'entrer dans les détails, un point sur les jeux d'instructions. AMD se met à jour en supportant à peu près toutes les extensions existantes, on retrouve ainsi AVX et AVX2, l'accélération des instructions SHA, mais aussi des choses plus originales comme les instructions de mémoire transactionnelle (TSX), introduites avec assez peu de succès par Intel pour Haswell. AMD rajoute en prime deux instructions, dont une pour libérer une ligne de cache, et l'autre pour combiner des pages mémoires. AMD est donc aligné sur ce que proposait Intel jusque Broadwell, Skylake n'ajoutant que SGX et MPX dont l'utilisation est plus particulière.

Zen dans les grandes lignes

Ce schéma des grandes lignes avait déjà été présenté mais désormais AMD y accole beaucoup plus de détails. Pour rappel ce schéma commence en haut à droite, avec la partie Branch Prediction ou les instructions arrivent avant d'être décodées. Le point important à retenir est qu'AMD distingue clairement le chemin "Integer" (bloc rouge, opérations sur les nombres entiers, et toutes les opérations classiques comme les boucles, etc...) et le chemin "Floating Point" (bloc orange, opération sur les nombres à virgules). Ils disposent de chaque côté de leurs propres schedulers et Mike Clark, l'architecte en chef de Zen qui a effectué la présentation pour AMD les décrit comme des coprocesseurs indépendants.


Schéma de fonctionnement des Haswell avec leurs ports d'exécution qui mélangent entiers et flottants sur les ports 0 et 1

Comme vous pouvez le voir ci dessus, il s'agit d'une implémentation qui diffère de ce que propose Intel sur ses architectures Core ou les instructions flottantes sont traitées sur les mêmes ports que les autres instructions (un port peut regrouper plusieurs unités d'execution), avec un scheduler unique. Par le passé, cette scission était nécessaire pour AMD, l'architecture Bulldozer regroupait dans un module deux blocs "Integer" et partageait un seul bloc "Floating Point". Ce qui ressemblait a une bonne idée s'est heurtée à de nombreux problèmes sur Bulldozer et ses dérivés. AMD a voulu conserver l'idée de la séparation tout en résolvant les problèmes restant, nous y reviendrons.

Le front-end

Tout en haut du graphique d'architecture précédent, on retrouve la partie du front end qui récupère (fetch) les instructions. Son rôle est d'extraire les instructions à exécuter, la prédiction de branchements (on parle de conditions, si elle est vraie, effectue ceci, sinon, effectue cela) tentant de déterminer lesquels seront nécessaires. Le TLB (un cache pour traduire les adresses mémoires virtuelles) est intégré et tout le mécanisme a été amélioré pour être plus efficace en ajoutant une table pour les adresses de retour des branches (l'endroit ou l'exécution doit se poursuivre à la fin de la branche, le bloc d'instruction exécuté après la condition).

Les instructions récupérées vont ensuite être placées dans le cache d'instruction avant d'être décodées. C'est ici que les instructions x86 sont lues par le processeur, qui les transforme en des micro-opérations (micro-op) qui seront exécutées par la suite dans le pipeline. Les décodeurs sont capables de traiter jusque quatre instructions par cycle (c'est équivalent à ce que propose Intel sur Haswell et Skylake) qui sont transformés en jusque 6 micro-op. Certaines instructions peuvent être fusionnées en une seule micro-op (notamment celles de branchements), la encore les similarités avec ce que propose Intel sont fortes.

Comme chez Intel, AMD utilise un cache qui stocke la correspondance entre une instruction décodée et la micro opération qui en est issue. Le jeu d'instruction x86 comportant un bon millier d'instructions de tailles variables, l'idée est de garder en cache les instructions les plus récemment décodées en mémoire pour pouvoir les traduire automatiquement en micro-op sans repasser par la case décodage. Cela permet d'ajouter plusieurs micro-op supplémentaires par cycles a traiter.

Par rapport à ses architectures précédentes, AMD dit avoir "significativement" augmenté la taille de son Op Cache et que ce seul changement est responsable d'une grande partie des gains d'IPC et de consommation. On y retrouve une logique semblable aux évolutions architecturales que l'on a vu à la concurrence : le front end joue un rôle excessivement important dans les architectures x86 sur les performances du reste de la puce. Le voir soigné de la sorte est plutôt une bonne nouvelle pour Zen même si comme toujours nous réserverons notre jugement en pratique !

On notera que les micro-ops sont placées dans une file, ou plus exactement deux files. AMD implémente pour rappel le SMT (Simultaneous Multi Threading) qui permet de gérer deux threads par coeur (l'HyperThreading est le nom marketing de l'implémentation SMT d'Intel). La file de micro-op est ainsi scindée en deux (ce qui est identique à ce que fait Intel pour Sandy Bridge et Skylake, Haswell ayant utilisé une file commune). Les instructions vont enfin être dispatchées vers les ports. En pratique 10 micro ops peuvent être envoyées (6 vers la partie "Integer" de la puce, 4 vers la partie "Floating Point"), soit deux de plus que sur Haswell (Intel ne nous a pas donné l'information pour Skylake).

Les unités d'executions

Les micro-op vont être dispatchées vers 6 files d'exécution (l'équivalent des ports d'Intel) dont la taille a été significativement augmentée (14 entrées par file, soit 84 pour cette partie de la puce, Skylake en compte 97 en tout mais il faut ajouter celles dédiées aux opérations FP, nous y reviendrons). AMD dispose de deux files dédiées aux opérations mémoires (AGU, adress génération unit) qui asservissent un système de lecture/écriture mémoire (Load/Store) sur lequel on reviendra. Quatre files sont dédiées aux instructions de "calcul" et de branchements. AMD les appelle ALU sur son schéma, il s'agit en pratique d'une série d'unités d'executions. Chaque ALU regroupe au minimum la possibilité de traiter les instructions logiques de base. AMD ne le détaille pas sur son schéma, mais d'autres unités sont présentes.

Le constructeur nous a confirmé que deux des ALU contiennent une unité dédiée au branchement, une ALU contient une unité gérant les divisions, une ALU contient une unité gérant les multiplications entières, et enfin une ALU contient une unité dédié au CRC32. AMD ne détaille pas la répartition exacte des unités sur les ALU, mais on apprécie les détails supplémentaires qui ont été donnés. L'efficacité de ces unités dépendra en grande partie de la capacité du front-end a les alimenter, mais sur le papier là encore, le design semble largement adéquat.

Comme nous le disions, les AGU asservissent les unités qui lisent et écrivent les données dans le sous système de cache. On retrouve des longueurs de files comparables à ce que l'on a chez le concurrent (72/44 pour Zen, 72/42 pour Haswell et 72/56 pour Skylake). Pour les chargements, AMD rentre dans le détail en indiquant qu'un des autres points faibles de ses architectures précédentes était lié aux opérations de chargement mémoire. Deux accès séparés 128 bits en lecture sont désormais possibles, et les unités peuvent accéder en simultanée au cache L1 et au cache TLB pour maximiser le débit, et ainsi streamer les données rapidement du cache L2 vers le L1.

L'efficacité des prefetchers (qui tentent de récupérer les informations en avance du moment ou le processeur en aura besoin) est indiquée comme meilleure et là encore il faudra attendre pour en savoir plus. Si AMD ne donne pas la rapidité de ses caches, il nous a été confirmé que la bande passante pratique est significativement plus rapide désormais, ce qu'on ne manquera pas de vérifier.

Si l'on revient en arrière, le dispatcher de micro-op pouvait envoyer jusque 6 instructions vers la partie Integer, et quatre vers la partie Floating point. Le scheduler dédié aux unités flottantes dispose ici de 96 entrées ce qui nous donne un total de 180 entrées par coeur (contre 97 pour Skylake). Il s'agit même en pratique d'un double scheduler.

C'était l'un des points faibles du design séparé que l'on évoquait plus haut : sur Bulldozer un scheduler trop petit sur la partie FP pouvait arriver à bloquer la partie Integer du CPU, un cas qui visiblement était assez fréquent. Avec un double scheduler, AMD dit avoir résolu le problème en pratique. On disposerais désormais bel et bien de deux blocs réellement indépendants pouvant travailler en parallèle (et ne se bloquant plus l'un l'autre).

Quatre unités d'exécution FP 128 bits sont donc présentes, deux dédiées plus spécifiquement aux multiplications et deux aux additions. Elles peuvent être combinées pour réaliser jusque 2 FMA 128 bits en parallèle par cycle. Sur ce point AMD est en retrait puisque Haswell pouvait effectuer deux FMA 256 bits par cycle. Il faudra voir l'impact pratique sur les performances, mais sur de micro benchmarks ou des cas spécifiques, ce sera un point limitant pour Zen.

Les caches mémoires

Sortons de la partie exécution pour regarder plus précisément les caches mémoires. AMD a choisi d'utiliser un cache L1 write back au lieu du write through utilisé précédemment, s'alignant là aussi sur ce que fait Intel. Cela devrait assurer une bien meilleure bande passante mémoire pour le L1 dont la taille est de 32 Ko. Chaque coeur dispose en prime d'un cache L2 de 512 Ko (le double de Skylake), et l'on retrouve un cache L3 partagé de 8 Mo assez spécial. Il est en prime (principalement) exclusif par rapport au cache L2.

Les blocs de coeurs

C'est l'un des rares détails d'un peu plus haut niveau qu'aura partagé AMD : les coeurs Zen sont regroupés par blocs de quatre. Chaque coeur comme indiqué plus haut est relié a son propre cache L2 de 512 Ko, et également à 2 Mo de cache L3. Ces quatre partitions de cache L3 sont reliées ensemble et chaque coeur peut accéder a chacune des partitions. Selon l'emplacement des données, la latence ne sera pas la même, même si AMD n'a pas voulu quantifier l'éventuelle différence (on admirera la manière dont AMD a tenté de détourner le sujet en parlant de latence moyenne !). Chaque CCX (le nom donné au groupe) dispose donc au total de 8 Mo de cache, et AMD peut ainsi construire des puces utilisant plusieurs modules CCX.

Ces derniers sont reliés point à point au reste du système (notamment au contrôleur mémoire, etc) par un data fabric, un système de bus interne. Dans le cas d'une puce disposant de deux CCX, un coeur souhaitant accéder à la mémoire L3 de l'autre bloc CCX passera par les blocs en amont du contrôleur mémoire, avec un système de cohérence type MOESI. Il n'y a pas de lien direct point à point entre les CCX à ce qui nous a été indiqué, en tout cas pour ce qui concerne les premières versions de Zen (les déclinaisons serveurs pourraient être reliées différemment). On notera enfin que les coeurs/L2 et le L3 disposent d'un plan de fréquence séparé.

Un dernier mot sur le Simultaneous Multi Threading

AMD a terminé sa présentation en indiquant avec beaucoup de précisions la manière dont les blocs sont partagés lorsque l'on utilise le SMT. En pratique il n'y a que très peu de cas ou AMD partitionne en deux des buffers pour chacun des threads. C'est le cas, nous l'avons vu plus haut, de la file de micro-op principale, et l'on notera que c'est le cas aussi pour la file d'écriture vers les caches. Les autres structures sont partagées entre les threads en fonction des besoins, ce qui est plutôt une bonne nouvelle là aussi.

En résumé

Cette présentation de Hot Chips était l'une des plus attendues, et l'on est obligé de dire que sur le papier au moins, AMD semble proposer une architecture vastement supérieure à ce qu'il proposait auparavant avec ses coeurs Jaguar ou Excavator. Certains diront que c'était un moindre mal, mais les changements sont conséquents.

Sur le papier, le travail important réalisé sur le front-end nous rappelle de nombreux choix également effectués par Intel pour son architecture Core, ce qui semble être une très bonne chose pour les performances et la consommation.

AMD garde un design différent pour la partie exécution en scindant en deux les ports "Integer" et "FPU". Un design qui n'avait pas particulièrement réussi aux modules de Bulldozer, mais AMD semble avoir appris des problèmes que cette partition avait causé. Il faudra voir si en pratique cette séparation portera enfin les fruits attendus.

De la même manière l'architecture des caches semble avoir été revue dans le bon sens, le passage au write back pour le L1 devrait augmenter largement sa bande passante, et le reste des caches est confortablement dimensionné.

Sur le papier, le retard architectural d'AMD semble en très grande partie comblé, et il n'y a que sur le choix des unités 128 bits en virgule flottante que l'on émettra un bémol.

Reste qu'entre la théorie et la pratique, de nombreuses choses peuvent jouer et si AMD martèle avoir fait progresser de 40% l'IPC par rapport à son architecture précédente, on rappellera que le chiffre est obtenu en comptant l'effet de l'intégration du Simultaneous Multi Threading. Sur ce qui est des performances monothread, point primordial, rien n'a été indiqué. Le fait que la notion de coeur ait été malmenée par Bulldozer et Excavator complique de toute manière l'interprétation de ces chiffres.

Comme toujours, seuls des tests pratiques pourront nous donner la réalité de la situation. Dans l'attente d'autres détails, que ce soit sur la partie uncore, et bien évidemment sur les fréquences et quantités de coeurs embarqués (sans parler des prix), nous n'irons pas plus loin dans les prédictions.

Dans tous les cas, le retour d'un semblant de concurrence dans le marché du x86 ne serait pas pour nous déplaire !

Vous pouvez retrouver ci dessous l'intégralité de la présentation d'AMD :

 
 

Nouvelle extension vectorielle ARMv8-A SVE

Tags : ARM; ARMv8; AVX-512; AVX2; Intel;
Publié le 23/08/2016 à 15:32 par Guillaume Louel

ARM profite également de la conférence Hot Chips pour présenter une nouveauté importante de son jeu d'instruction, une extension vectorielle baptisée SVE (Scalable Vector Extension).

Les instructions vectorielles permettent pour rappel d'effectuer une même opération sur plusieurs données à la fois (regroupées dans un vecteur au sens informatique , un tableau à une dimension). Dans les architectures x86, on a vu de multiples extensions se succéder. Si l'on reste chez Intel, après les différentes variantes de SSE, on aura connu plus récemment AVX dans Sandy Bridge, AVX2 dans Haswell et AVX-512 pour les Skylake serveurs uniquement.

Dans la grande tradition du x86 qui est un jeu d'instruction "large" (CISC), chaque extension rajoute de nouvelles instructions vectorielles adaptées spécifiquement aux unités matérielles présentes dans chaque génération de processeur introduite. Parmi les changements d'une version à l'autre, outre de nouvelles opérations (par exemple effectuer une multiplication et une addition en simultanée), ce qui évolue surtout est la quantité de données qu'une puce est capable de traiter. Ainsi, comme son nom l'indique, AVX-512 permet d'effectuer des opérations sur des données par groupes de 512 bits (par exemple 16 données 32 bits) à la fois, là ou les unités d'AVX2 travaillaient sur des groupes de 256 bits (dans le même exemple, 8 fois 32 bits).


Les instructions FMA3 d'AVX2, on notera la large quantité de variantes proposées

Ce modèle d'instructions adaptées a chaque variante de matériel à l'avantage d'être simple pour les constructeurs, chaque nouveauté est géré par de nouvelles instructions, mais en pratique ce mode de fonctionnement est très problématique. Comme nous avions eu l'occasion de le voir, en général, les programmes sont compilés pour une architecture donnée, parfois deux lorsque l'on a de la chance, ce qui pousse souvent les logiciels commerciaux à ne pas forcément utiliser les dernières nouveautés matérielles par souci de compatibilité.

Cela permet aussi aux constructeurs qui disposent d'un compilateur, comme on l'avait vu avec Intel, d'augmenter artificiellement l'avantage proposé par une architecture. S'ajoute en prime le problème de la vectorisation du code source des logiciels, un problème compliqué qu'on résout soit à la main, soit en laissant faire le compilateur qui, malgré sa meilleure volonté, se retrouve assez souvent dans des situations ou il ne peut pas vectoriser automatiquement le code, par prudence.

Dans le monde ARM, la situation est beaucoup plus simple. Le jeu d'instruction ARM repose pour rappel sur le principe d'un jeu d'instruction réduit (RISC) et rajouter de nouvelles instructions à chaque nouveau processeur n'est pas une option. ARM avait tout de même introduit une extension vectorielle, NEON , qui rajoute des instructions vectorielles (VFP) sur 128 bits. Cette extension avait été conçue il y a une douzaine d'année, exploitée notamment sur l'architecture précédente (ARMv7 en 32 bits).

Pour le passage à son architecture 64 bits, ARMv8-A, ARM n'avait pas apporté de changement fondamental à NEON. C'est désormais chose faite avec l'introduction de SVE, dont les ambitions vont pour le coup beaucoup plus loin.

ARM donne quelques petits détails dans un post de blog  sur le fonctionnement de sa nouvelle extension. L'idée de base de SVE se retrouve dans son nom : il s'agit d'une extension Scalable, la taille des vecteurs sur lequel les instructions s'appliquent n'est pas fixe (contrairement à AVX-512 et ses vecteurs 512 bits).

Côté matériel, la spécification d'ARM laisse le choix aux designers de processeurs qui peuvent choisir la largeur de leurs unités de calcul, entre 128 et 2048 bits (!). Cela donne un maximum de flexibilité, permettant de créer des designs orignaux et adaptés à des marchés spécifiques (ARM vise principalement avec SVE le marché des serveur et du HPC, même si le jeu d'instruction devrait se retrouver sur d'autres puces).

Le plus intéressant est ce qui se passe au niveau du jeu d'instruction : il est indépendant de la taille des vecteurs à traiter (la société parle de VLA, Vector Length Agnostic). Concrètement, plutôt que d'utiliser des instructions qui traitent (par exemple) 4 données 32 bits, les instructions VLA indiquent directement quelles instructions appliquer aux vecteurs sans s'occuper d'un quelconque découpage.

Techniquement, ARM ne détaille pas vraiment comment sera implémenté la chose côté matériel, se contentant de dire que c'est le matériel qui, en fonction de la taille de ses unités, s'occupera de découper le vecteur en autant de passes que nécessaire pour le traiter dans ses unités. ARM indique simplement que l'encodage de la taille du vecteur n'est pas nécessaire et qu'elle est déterminée par les mécanismes de prédiction des puces (qui seraient particulièrement performants y compris pour les boucles imbriquées).

Le fonctionnement exact est assez flou, et diffère d'une proposition d'extension - sur le fond assez proche - que l'on avait vu l'année dernière pour le jeu d'instruction RISC-V (PDF) . D'après ARM, un travail important a été effectué sur les instructions qui permettent de charger les données en mémoire pour les traiter, elles représenteraient la majorité des instructions ajoutées.


Extrait de la présentation de proposition vectorielle pour RISC-V, à gauche un code SIMD classique 128 bits, à droite un code vectoriel. La première instruction vsetvl indique la taille des vecteurs traités

L'approche est très différente de celle des SSE/AVX, on peut même la qualifier d'élégante, et devrait permettre de conserver un jeu d'instruction très compact tout en offrant une grande flexibilité. ARM indique que seul un seizième de l'espace d'encodage d'instruction RISC disponible est utilisé pour les nouvelles instructions VLA (les instructions AArch64 sont encodés sur 32 bits, 75% de cet espace est déjà utilisé aujourd'hui par le reste des instructions).

En prime, cela résout le problème de la compilation que nous évoquions plus haut : un programme compilé avec des instructions vectorielles VLA pourra profiter pleinement de toutes les architectures matérielles SVE existantes et à venir.

Cette extension devrait permettre de voir des puces ARM assez différentes arriver sur le marché et si le monde des serveurs et du HPC est clairement visé - ARM met en avant Fujitsu qui développera une puce ARMv8-A avec SVE pour le supercalculateur Post-K prévu pour 2020 - on s'intéressera aussi à l'arrivée de SVE dans des puces plus classiques. La publication de la version finale de la spécification est prévue pour la fin de l'année ou le tout début 2017.

Intel dévoile l'AVX-512

Publié le 24/07/2013 à 18:45 par Guillaume Louel

C'est par le biais d'un de ses blogs  qu'Intel vient d'annoncer la prochaine version d'AVX, que l'on connaissait précédemment sous le nom de code 3.1 et 3.2. Il s'agira finalement d'AVX-512.

Comme son nom l'indique, AVX-512 est une extension du jeu d'instruction AVX qui rajoute des instructions SIMD (une instruction qui s'applique à de multiples données) 512 bits, soit le double de l'AVX actuel, pouvant cibler aussi bien des données entières que flottantes. Ce n'est pas la première fois que l'on voit un jeu d'instructions 512 bits chez Intel car c'est précisément ce que proposait le jeu d'instruction de Larrabee, et plus récemment de Knights Corner que l'on connait sous la dénomination commerciale Xeon Phi.


AVX-512 apporte une série de changements détaillés dans ce document PDF, on notera en premier lieu le nombre de registres qui passe de 16 à 32, tandis que les nouvelles instructions sont préfixées EVEX (au lieu de VEX pour AVX2). Ces dernières concernent aussi bien les entiers que les flottants et vous pourrez retrouver ci-dessous les grandes familles (classes) d'instructions disponibles.


La liste des classes d'instructions d'AVX-512. Vous retrouverez dans le PDF la liste complète des instructions à la page 75.


Notez qu'Intel parle dans son document "d'AVX-512 Foundation", sous entendant qu'il s'agit là du socle commun et que certains produits pourraient proposer des instructions supplémentaires. Ce n'est pas forcément surprenant puisque ces slides  indiquaient que Knights Landing (la prochaine version de Xeon Phi) utiliserait AVX3.1, tandis que Skylake (la prochaine nouvelle architecture CPU d'Intel qui apparaitra après Broadwell en 14nm) utilisera AVX 3.2.

Il sera intéressant de voir ce qu'Intel fera exactement de ces unités AVX 512 bits dans le processeur Skylake. Le directeur du Visual and Parrallel Architecture Group d'Intel, Ofri Wechsler est en effet à la fois en charge des projets Xeon Phi du constructeur (l'actuel Knights Corner, le suivant Knights Landing, et le futur Knights Hill) mais aussi de l'architecture graphique qui sera utilisée dans Skylake.

Sa biographie sur le site d'Intel indique également qu'il était responsable du projet qui tentait de construire un pipeline de rendering 3D logiciel fonctionnant sur Larabee, l'ancêtre des actuels Xeon Phi. Si des rumeurs laissaient penser qu'Intel pourrait un jour utiliser ce type de solution pour remplacer un GPU, l'échéance de Skylake est probablement encore trop proche pour que l'on voit arriver ce type de solution pour remplacer l'iGPU intégré aux processeurs. Skylake dans sa version desktop est en effet prévu pour 2015.

Focus : Haswell et mémoire transactionnelle

Tags : AVX2; Haswell; Intel;
Publié le 08/02/2012 à 17:48 par Guillaume Louel

C'est par l'un de ses blogs qu'Intel vient d'annoncer une mise à jour de sa spécification AVX2 concernant Haswell, le prochain "Tock" d'Intel attendu pour 2013.

Cette extension d'AVX2 baptisée TSX apporte de nouvelles instructions qui permettent de gérer ce que l'on appelle mémoire transactionnelle. Contrairement à ce que son nom indique, la mémoire transactionnelle n'est pas un type de mémoire différent, il s'agit plutôt d'une manière différente...

[+] Lire la suite

Intel présente le jeu d'instructions d'Haswell

Tags : AVX2; Haswell; Intel;
Publié le 15/06/2011 à 22:30 par Guillaume Louel

C'est par l'un de ses blogs  qu'Intel a présenté le jeu d'instructions qui animera Haswell, l'architecture utilisée pour les processeurs qui remplaceront Sandy Bridge début 2013 (le tock en 22nm).

Comme a son habitude Intel étend le déjà large jeu d'instructions x86 avec AVX2 (format PDF) . Les nouveautés sont multiples et l'on notera en premier lieu l'arrivée de version 256 bits SIMD des instructions arithmétiques x86 classiques dédiées aux entiers (une partie des instructions dédiées aux flottants ayant été traitée par AVX). Le but du SIMD étant d'appliquer pour rappel une même opération à plusieurs données en simultané, l'extension aux nombres entier est bienvenue. On trouvera également dans le lot des nouveautés présentées des opérations de manipulations sur les bits, pour aider côté cryptographie, et sur le calcul de hash (avec l'apparition de RORX et MULX entre autre). Des opérations de permutations, et de shift sur des vecteurs sont également de la partie.


Les instructions entières SIMD 256 bits ajoutées par AVX2

D'autres instructions très "GPU" sont ajoutées avec en premier lieu des Gather qui permettent de charger dans des registres des données non adjacentes en mémoire. Le plus gros morceau reste l'implémentation du FMA, Fused Multiply Add. Pour rappel ces instructions permettent d'effectuer en une instruction une multiplication et une addition (a x b + c). Avec son architecture Bulldozer, AMD sera le premier à proposer le FMA dans un processeur (les AMD FX/Zambezi attendus pour la fin de l'été) avec une implémentation de type FMA4. Intel de son côté se contente d'une version FMA3. La différence entre les deux versions est que le FMA4 permet de stocker le résultat d'une opération dans un registre additionnel (d = a x b +c) là ou en FMA3, le résultat doit être stocké dans l'un des registres utilisés précédemment (par exemple : c = a x b + c). Une incompatibilité qui se paiera du côté des compilateurs et qui crée une différence de plus entre les architectures AMD et Intel.


Les instructions FMA3 proposées par AVX2)

Si l'on regrette l'incompatibilité FMA3/FMA4 entre AMD et Intel (en notant que et Intel, et AMD ont changé leur fusil d'épaule sur le sujet, Intel ayant présenté d'abord un FMA4 avant d'arriver au FMA3, AMD ayant fait l'inverse !), AVX2 continue sur la lancée d'AVX en rendant le jeu d'instructions x86 de plus en plus capable d'effectuer des opérations en parallèle de manière efficace. Un modèle intéressant, censé contrer en partie la poussée du GPGPU, mais qui nécessitera un gros travail côté compilateurs pour pouvoir tirer parti des nouvelles instructions.

Top articles