Les derniers contenus liés aux tags Intel et AVX2

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