Actualités processeurs

C'est l'été dernier qu'Intel avait annoncé un changement de stratégie. Durant des années, la firme de Santa Clara s'est tenu au Tick-Tock : lancer un nouveau process de fabrication une année (un Tick), et lancer l'année suivante une nouvelle architecture (un Tock). Un cycle de deux années (parfois étendu de quelques mois) qui se répétait depuis l'introduction du système dans les années 2000.

La version classique du packaging utilisée par Intel pour ses SoC mobiles U (15W)

Après un passage au 14nm difficile qui nous avait valu un "Haswell Refresh", Intel avait annoncé que son process 10nm serait repoussé à fin 2017 (il aurait du être introduit cette année) et que l'on aurait droit pour 2016 à un nouvelle entrant, Kaby Lake, une version "optimisée". La stratégie passante ainsi de "Process-Architecture" à "Process-Architecture-Optimisation".

La version compacte du packaging utilisée par Intel pour ses SoC mobiles Y ("4.5W")

Lors de l'annonce des résultats financiers au second trimestre l'année dernière, le CEO d'Intel Brian Krzanich avait décrit Kaby Lake comme "bâti sur les fondations de la micro architecture Skylake" mais "avec des améliorations clefs de performances". Nous pensions à l'époque qu'Intel ne ferait possiblement évoluer que son GPU.

Aujourd'hui on en sait enfin un peu plus. Intel annonce Kaby Lake comme la septième génération de processeurs Core et lance aujourd'hui six modèles de processeurs dont le "TDP" varie entre 4.5 et 15W. En pratique il s'agit des SoC deux coeurs (avec Hyper Threading) destinés aux PC portables légers (type Macbook/Ultrabook et 2-in-1). Le lancement des autres versions (mobiles 4C, avec Iris Graphics, et les versions desktop) se fera en janvier.

La plus grosse nouveauté mise en avant par Intel est l'évolution de son process de fabrication, le constructeur le qualifiant de 14nm+ (faisant echo aux 16FF+ de TSMC par exemple). Intel indique avoir amélioré la géométrie de son process, au niveau de la forme des "fins" (les ailettes qui constitue les transistors FinFET) et aussi du canal. La société annonce 12% d'amélioration de performances (sans préciser à quel niveau) ce qui est assez vague.

En effet, au fil de l'exploitation d'un process, sa fiabilité, son rendement, et incidemment ses performances évoluent. Etant donné les difficultés rencontrées par Intel au début de l'exploitation du 14nm, il est difficile de juger réellement ce que ce chiffre représente, et s'il s'agit vraiment d'une évolution par rapport à la production ayant eu lieu par exemple ces derniers mois, ou s'il s'agit tout simplement de l'évolution naturelle, lié au débogage et à l'exploitation du process.

L'autre nouveauté concerne le "Media Block", la partie du GPU qui regroupe les fonctions de décodage et d'encodage vidéo. Si Skylake avait ajouté le décodage vidéo HEVC (H.265), il n'était effectif que pour le profil "Main". Le profil "Main 10" (vidéos encodées avec 10 bit par composante), qui sera utilisé pour les Blu-Ray UHD par exemple n'était par contre pas pris en charge. C'est désormais corrigé, le Media Block de Kaby Lake décode désormais le HEVC "Main 10". On notera également l'arrivée du décodage de VP9, le codec de Google en 8 et 10 bit (un décodage "partiel" de VP9 était disponible précédemment, comme pour le HEVC Main 10 mais il était insuffisant en pratique).

En plus du décodage, l'encodage HEVC est lui aussi possible en "Main 10", ainsi qu'en VP9. L'encodage H.264 (AVC) profite d'une amélioration de performances sur l'une de ses composantes.

Dernier point, Intel parle d'une meilleure réactivité du Turbo en mode Speed Shift, permettant d'atteindre la fréquence Turbo maximale plus rapidement qu'auparavant. On passerait ainsi de 35ms à 15ms pour atteindre cette fréquence maximale.

Et... c'est tout ! Il n'y a en effet aucun autre changement architectural pour Kaby Lake, que ce soit au niveau du GPU ou du CPU. Intel met a profit son process pour faire monter les fréquences, ce qui rappellera aux plus anciens les "speed bump" qu'introduisait auparavant le constructeur. Sur le modèle Core i7 15 watts, la fréquence turbo maximale augmente ainsi de 400 MHz, ce qui se traduit par 12 à 19% d'avantage dans les benchmarks sélectionnés par Intel pour sa présentation.

Pour récapituler, voici les six références lancées ainsi que celles qu'elles remplacent :

On notera des gains de 100 à 400 MHz sur les fréquences Turbo pour les modèles U (15 Watts) et jusque 500 MHz sur les modèles Y (avec un "TDP" de 4.5 Watts), ce qui n'est pas négligeable même si l'on rappellera que ces derniers ne tiennent pas leur fréquence Turbo maximale en charge prolongée. Sur ces derniers, on notera qu'Intel fait disparaitre ses nomenclatures Core m5 et m7, remplacées par Core i5 et i7 ! Le Core m3 continue par contre d'exister.

Cette absence de changements conséquents pousse le constructeur à être créatif, comparant dans sa présentation les performances de Kaby Lake à une plateforme mobile datant de cinq ans. Un discours marketing qui aura du mal a cacher la réalité : cette septième génération est avant tout un "speed bump" légèrement amélioré de Skylake. Si l'on apprécie les gains de fréquences annoncés, il faudra attendre le mois de janvier, probablement autour du CES, pour voir en pratique ce que le constructeur proposera comme gains de fréquences pour sa plateforme desktop.

Vous pouvez retrouver la présentation "performance" fournie par Intel ci dessous :

 

 

Ainsi que la présentation plus générale :

 

 

La conférence Hot Chips qui se tenait la semaine dernière a donné lieu a d'autres annonces intéressantes que nous avons essayé de regrouper dans cette actualité !

Rajouter des tiers de mémoire côté serveur

On avait déjà noté un peu plus tôt la volonté de rajouter de la mémoire HBM à divers endroits, et même la volonté de Samsung de travailler sur une version moins onéreuse, mais l'on rajoutera ce slide issu d'une présentation d'AMD qui rappelle les objectifs de la société côté serveurs, prenant pour le coup l'exemple du big data

On s'attardera sur le graphique à droite qui pointe l'ajout d'une mémoire intermédiaire côté CPU, type HBM ou HMC (AMD misera plutôt sur la HBM pour les déclinaisons serveurs de Zen), et aussi l'utilisation de NVDIMM pour s'intercaler avant un SSD. Il faudra attendre encore un peu pour voir comment seront déclinées ces technologies, mais il est intéressant de noter la manière dont les avancées côté mémoire sont mises en avant, parfois un peu trop tôt comme l'a fait Intel avec 3D XPoint, dans toute l'industrie.

Quelques détails de plus sur SVE

Chez ARM, outre une présentation de Bifrost côté GPU dont on vous avait déjà parlé, l'annonce principale concernait SVE, la nouvelle extension vectorielle introduite par la société.

Le premier partenaire annoncé par ARM est Fujitsu, qui mettra au point des processeurs ARMv8 avec extension SVE pour le futur supercalculateur japonais Post-K. Fujitsu a donné quelques détails, indiquant par exemple que les unités vectorielles auraient une largeur de 512 bits sur ses puces.

 

 

Chez ARM, le constructeur présente plusieurs benchmarks assez théoriques, on notera surtout sur les barres grises les améliorations qui ont été effectuées côté auto-vectorisation, c'est a dire la capacité du compilateur à utiliser des instructions vectorielles pour extraire du parallélisme. ARM devrait proposer dans les semaines qui viennent des patchs pour les différents compilateurs open source, incluant LLVM et GCC.

Le Samsung M1, un timide premier pas

La particularité de l'écosystème d'ARM est que les partenaires peuvent soit utiliser des coeurs "clefs en main", développés par ARM (les gammes Cortex, comme par exemple le Cortex A57), ou créer leurs propres implémentations de l'architecture ARM (qui restent compatibles, tout en étant différentes, à l'image des processeurs d'AMD et d'Intel qui diffèrent bien que restant compatibles). Plusieurs sociétés disposent de licences "architecture" qui permettent de créer ces puces, Apple étant jusqu'ici la société la plus à la pointe sur armv8 même si de nombreuses sociétés proposent tour à tour leurs architectures.

Parmi les nouveaux venus, il y a Samsung qui s'est lancé lui aussi dans le design d'une architecture armv8 custom pour ses Exynos M1. A la tête du projet, on retrouve Brad Burgess qui était architecte chez AMD pour les Bobcat. Il aura même été rejoint un court instant par Jim Keller (K8 chez AMD, A7 chez Apple, puis Zen chez AMD), qui n'est cependant pas resté très longtemps chez Samsung et qui n'aura probablement pas eu un grand impact. Le projet aura nécessité trois années, et en soit arriver a produire quoique ce soit du premier coup en un temps si court est un exploit.

Côté architecture, Samsung indique utiliser un perceptron  (un réseau de neurones simple) au niveau de ses mécanismes de prédiction de branches. Deux branches sont considérées par cycle, mais il est difficile d'estimer quoique ce soit sur l'éventuelle efficacité.

Quatre instructions peuvent être décodées/dispatchées par cycle aux unités d'exécutions qui sont regroupées sur sept files. On note deux files dédiées aux écritures mémoires, trois aux opérations mathématiques simple (avec un port sur lequel sont ajoutés les multiplications/divisions) et une aux branchements. Les opérations en virgules flottantes sont regroupées séparément avec un scheduler unique pour deux files. Samsung annonce 5 cycles pour effectuer une opération FMA.

Dans une configuration quatre coeurs, le M1 dispose de 2 Mo de cache L2 coupé en quatre blocs, les coeurs accèdent au L2 via une interface commune. On appréciera aussi les schémas très spécifiques que propose Samsung, pas vraiment avare de détails techniques.

Reste qu'en pratique, les benchmarks mis en avant par Samsung ne sont pas forcément très convaincants. Avec 200 MHz de plus, sur un coeur, un M1 propose 10% de performances en plus qu'un Cortex A57 à consommation égale, ce qui est tout de même très peu. Samsung fait beaucoup mieux sur les opérations mémoires (c'est relativement facile, on l'a évoqué de nombreuses fois, les contrôleurs mémoires ARM ne sont pas particulièrement véloces/adaptés aux hautes performances), mais n'en tire pas particulièrement profit hors des benchmarks théoriques.

La présentation se termine en indiquant que ce n'est qu'un premier pas pour Samsung et que d'autres designs sont en cours d'élaboration. En soit si les performances ne vont pas révolutionner le monde des SoC ARM, Samsung a au moins une base de travail qu'ils pourront faire évoluer par la suite. A condition évidemment que Samsung continue d'investir sur le sujet dans les années à venir !

Les curieux pourront retrouver la présentation en intégralité ci dessous :

 

 

Parker/Denver 2 : design asymétrique

Nvidia était également présent à Hot Chips, donnant quelques détails sur son futur SoC baptisé Parker. Ce dernier est annoncé comme crée spécifiquement pour le marché automobile avec des fonctionnalités dédiées à ce marché. On ne sait pas si le constructeur le déclinera en d'autres versions plus génériques.

Les détails techniques ne sont pas particulièrement nombreux, on notera côté SoC que l'encodage 4K est désormais accéléré à 60 FPS, que l'on peut contrôler jusque trois écrans en simultanée, et que le contrôleur mémoire passe sur 128 bits (contre 64 précédemment). Côté GPU, Parker utilisera une version dérivée de son architecture Pascal.

 

 

C'est du côté CPU que les choses sont les plus originales, après avoir utilisé son architecture Denver sur les TK1, puis être revenu aux Cortex A57 sur les TX1, Nvidia propose une architecture asymétrique avec deux coeurs "Denver 2" (sur lesquels aucun détail n'aura été donné, à part un gain performance/watts de 30% donné sans précision sur les process comparés) et quatre coeurs Cortex A57. Ce n'est pas la première fois que l'on voit des configurations originales, durant Hot Chips, le taiwannais MediaTek présentait un SoC 10 coeurs avec quatre coeurs Cortex A53 à 1.4 GHz, quatre coeurs Cortex A53 à 2 GHz, et deux coeurs Cortex A72 à 2.5 GHz !

Dans le cas de MediaTek, l'idée est de proposer différentes options à différents niveaux de consommation. Pour ce qui est de Nvidia, le choix est différent, le Cortex A57 étant "haute performance" contrairement aux A53 de MediaTek. Il faut dire surtout que le marché visé, l'automobile, n'a pas les mêmes contraintes de consommation que le marché mobile. Reste que Nvidia se doit de gérer cette asymétrie avec un scheduler qui doit décider sur quel coeur placer les threads, ce qui n'est pas particulièrement simple. On notera que chaque groupe de coeurs dispose de son propre cache L2 de 2 Mo.

Côté performances, Nvidia avec ses 6 coeurs se présente comme moitié plus rapide qu'un A9X d'Apple en deux coeurs. Le graphique mélangeant des puces à TDP différents (on y retrouve des puces pour smartphones et pour tablettes), on admettra que la comparaison n'est pas faite à TDP identique.

TSMC parle de ses packages InFo

Une des nouveautés présentées cette année par TSMC est la disponibilité d'un nouveau type de packaging, l'InFo-WLP. L'idée est de permettre de relier plusieurs dies en les "moulant" dans un substrat commun très fin qui contient également les interconnexions entre les puces. Il s'agit d'une version à cout beaucoup plus faible que les interposer (utilisés par exemple par AMD pour Fiji).

La présentation de TSMC est dédiée aux interconnexions entre les puces, et présente une puce 16nm reliant un SOC à une puce mémoire avec une bande passante de 89.6 Go/s sur 256 bits, le tout avec une consommation très réduite.

En plus de la solution présentée qui évoque le cas simple d'une puce mémoire et d'un Soc, TSMC évoque la solution comme permettant un jour de relier également plusieurs dies de logique, par exemple des groupes de coeurs séparés, pour réduire le coût de fabrication des puces (qui augmentent exponentiellement avec la taille des dies).

 

 

La présentation est technique mais reste intéressante, l'InFo-WLP ouvre des opportunités supplémentaires pour réaliser des produits qui mélangent processeur et mémoire. Le coût réduit et la finesse de l'interconnexion fait qu'on pourrait retrouver assez rapidement cette technique utilisée, y compris sur le marché mobile. Les prochains SoC d'Apple pourraient par exemple utiliser un tel package.

Et Skylake !

Juste avant la présentation de Zen, Intel proposait aussi une présentation de son architecture Skylake, lancée l'année dernière. Si la majorité du contenu est déjà connu, on aura noté un détail intéressant : un diagramme sur les unités d'exécution de Skylake. On rappellera que l'année dernière durant l'IDF, Intel nous avait promis plus de détails sur le sujet, sans jamais nous les donner !

Pour rappel, voici la répartition sur Haswell :

Récapitulatif des ports/unités d'exécution sur Haswell

Un an après, voici enfin un diagramme similaire pour Skylake :

Conformément à ce que nous avaient indiqué les ingénieurs d'Intel l'année dernière, le nombre d'unité a bel et bien augmenté. Le nombre de ports reste constant, à 8, mais l'on compte... une nouvelle unité. Sur le port 1, Intel a en effet ajouté une unité de shift vectorielle. Pour le reste, la répartition reste similaire à celle d'Haswell. Un mystère enfin élucidé !

AMD vient d'annoncer un nouveau bundle avec Deus Ex : Mankind Divided. Il ne concerne cependant pas les cartes graphiques du constructeur, mais ses processeurs AMD FX, en versions 6 à 8 coeurs.

La promotion est valable jusqu'au 14 novembre 2016, uniquement pour l'achat chez un des revendeurs partenaires affichant l'offre. Ils vous fourniront, généralement après le délai de rétractation, un code qui vous permettra via une page spéciale chez AMD  de récupérer un second code pour télécharger le jeu sur la plateforme ou il est distribué.

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 :

 

 

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.