Actualités processeurs

AMD détaille l'architecture de Zen

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

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 cage 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 rapellera que le chiffre est obtenu en comptant l'effet de l'intégration du Simultaneous Multi Threading. On suppose également que le chiffre est donné à process égal, une question à laquelle nous n'avons pas encore pu obtenir de confirmation. Sur ce qui est des performances monothread, point primordial, rien n'a non plus été indiqué. Le fait que la notion de coeur ait été malmenée par Bulldozer et Excavator compliquerait 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
Envoyer Imprimer

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.

AMD en dit un peu plus sur Zen

Publié le 18/08/2016 à 15:56 par
Envoyer Imprimer

Lors d'une présentation organisée hier soir en marge du forum technologique d'Intel, AMD est revenu sur sa future architecture Zen. Mark Papermaster, Chief Technology Officer, a dévoilé quelques détails de plus sur ces processeurs très attendus.

De nombreux espoirs reposent sur cette architecture CPU Zen et, à l'approche de sa concrétisation, AMD va progressivement dévoiler de plus en plus de détails. AMD insiste lourdement sur le fait d'être reparti d'une feuille blanche, ce qui arrive de moins en moins souvent dans l'industrie, les évolutions étant en général progressives. Mais pour qu'AMD revienne dans la course une rupture radicale était nécessaire par rapport à Bulldozer et ses dérivés.

AMD réaffirme ainsi toute sa confiance dans l'architecture Zen et estime pouvoir revenir dans le segment x86 haute performances, allant même jusqu'à parler de sa "zone de confort historique". Une forte progression du taux d'IPC, +40%, et du rendement énergétique devrait permettre à Zen de mieux se positionner face aux CPU d'Intel.

 
 

Pour pousser autant le taux d'IPC, comme nous le savons déjà, Zen abandonne la structure de module et a recours au Simultaneous Multi-Threading (SMT), dont l'HyperThreading en est l'implémentation d'Intel. Mais ce n'est évidemment pas tout. Il est également question d'une nette amélioration du front-end. La prédiction de branchement évolue, comme c'est le cas à chaque nouvelle architecture CPU mais une modification plus importante concerne l'ajout d'un cache pour les micro-ops dont étaient dépourvus ses précédents CPU, ce qui pouvait donner un avantage important au front-end des CPU Intel.

AMD communique peu de détails sur les buffers exploités par ce nouveau front-end mais indique que la fenêtre d'instructions pour le scheduler a été élargie de 75%, ce qui va également participer à faire progresser le taux d'IPC. AMD n'a cependant toujours pas clarifié quelle part de ce gain d'IPC concernera le mono-thread et indique que ces détails seront communiqués plus tard.

Pour accompagner ce renforcement du front-end, Zen se muscle également côté unité d'exécution. Contrairement à ce que fait Intel, AMD semble avoir conservé de Bulldozer une séparation entre l'ordonnancement des opérations sur les entiers et sur les flottants. Du côté des entiers on retrouve 6 ports d'exécution (4 ALU + 2 AGU) contre 4 précédemment (4 ALU/AGU). Du côté des flottants le schéma laisse entrevoir 2 FMUL et 2 FADD mais AMD n'en dit pas plus sur ce dont sont capables des unités d'exécutions. Dans un autre document, AMD parle cependant d'une largeur limitée à 128-bit pour son unité de calcul sur les flottants, un compromis adapté au marché visé selon le fabricant.

AMD a également fait progresser sa structure de caches. Le cache L1D est doublé et passe de 16 à 32 Ko. Le L1I redescend par contre à 64 Ko alors qu'il était monté à 96 Ko à partir de Piledriver, mais n'est plus partagé par 2 coeurs un sein d'un module. Le L2 est par contre réduit à 512 Ko par coeur alors que le L3 reste à 1 Mo par coeur, soit 8 Mo au total. Difficile de conclure à une nette évolution sur base de ces quelques informations simplifiées, mais AMD parle d'une bande passante par coeur qui pourrait aller jusqu'à être multipliée par 5.

Pour aller plus loin que quelques slides, AMD a fait une première demonstration de performances en comparant un CPU Summit Ridge, Zen 8 coeurs / 16 threads, à un CPU Broadwell-E Core i7 6900K. Les 2 puces étaient cadencées à 3 GHz et équipées d'une mémoire similaire. Sous Blender, qui profite pleinement du multi-threading, Zen était légèrement devant tout en consommant un petit peu moins selon AMD.

Une autre démonstration a été organisée sur une plateforme serveur 2P avec 2 CPU au nom de code Naples. Une manière pour AMD de confirmer officiellement la version 32 coeurs / 64 threads de Zen dont nous vous parlions il y a 6 mois. Ces CPU Naples sont prévus pour le second trimestre 2017. AMD précise en même temps avoir en quelque sorte mis de côté le développement de CPU ARM, estimant que ce marché n'a pas explosé comme prévu et que c'est du côté x86 qu'il y a le plus de potentiel.

Concernant la disponibilité des premiers CPU Zen, Summit Ridge, destinés à la plateforme AM4, AMD parle toujours du premier trimestre 2017 avec une possibilité de petits volumes fin 2016 si toutes les étoiles s'alignent. AMD ne communique rien en terme de fréquence ou encore de tarif, mais visiblement confiant dans ses prestations, AMD précise que Summit Ridge lui permettra de revenir à des niveaux de performances bien supérieurs à ce dont sont capables ses CPU actuels et donc de viser des segments tarifaires que la société a été forcée de déserter depuis de bien longues années. A noter qu'AMD indique, sans préciser de date, que l'architecture Zen sera ensuite suivie de Zen+ avec à la clef de nouvelles améliorations d'IPC.

Plus de détails devraient être communiqués la semaine prochaine à l'occasion du forum Hot Chips.

Vous pourrez retrouver la présentation complète ci-dessous :

 
 

Intel Custom Foundry prend une licence ARM !

Publié le 17/08/2016 à 16:25 par
Envoyer Imprimer

ARM l'a confirmé par un post de blog  : Intel Custom Foundry, l'activité fabrication tiers d'Intel, est désormais détentrice d'une licence ARM Artisan pour le 10nm !

Il faut rappeler qu'Intel est plutôt un cas à part dans le monde des semi-conducteurs, étant l'une des rares sociétés à disposer de ses propres usines, utilisées quasi uniquement pour la production de ses propres puces. La plupart des autres acteurs du marché ont migré vers la séparation de l'activité design d'un côté (on parle de sociétés fabless, c'est le cas dans le monde du GPU avec AMD et Nvidia), et de l'autre la fabrication dans des sociétés tierces spécialisées (on parle de foundry, la plus connue étant TSMC qui fabrique des puces pour de multiples clients).

Avec la difficulté de la mise au point des nouveaux process de fabrication, qui n'a fait qu'empirer ces dernières années, il est de plus en plus complexe pour une société à elle seule de justifier l'investissement nécessaire pour faire évoluer sans cesse ses usines. Qui plus est, la réduction de la taille des transistors fait que la capacité des usines augmente d'année en année, et qu'il faut disposer de très larges volumes de puces à produire, au risque de voir ses usines tourner à vide.

Un casse tête qui aura poussé plusieurs sociétés à se séparer de leurs usines (pour des raisons différentes) d'abord AMD en 2009 (créant GlobalFoundries) et plus récemment IBM (dont l'activité fabrication à été rachetée elle aussi par GlobalFoundries).

Depuis quelques années, en plus de fabriquer ses propres puces dans ses usines, Intel a décidé d'entrer très timidement, en 2010, sur le marché des fondeurs tiers en ouvrant son process à de petites sociétés qui n'étaient pas en concurrence directe avec ses produits (le premier client était Achronix, designer de FPGA en 22nm). D'autres clients ont suivi, principalement sur les FPGA, le client le plus connu d'Intel ayant été Altera... même si au final Intel aura décidé de racheter son client à la mi-2015 !

Pour Intel, la nécessité d'ouvrir ses usines est un casse tête. D'un côté, la société tente d'être présent sur tout les marchés, en déclinant le x86 - technologie "maison" sur laquelle la concurrence est limitée - à toutes les sauces et avec un soupçon de recyclage, que ce soit avec des produits serveurs spécialisés comme les Xeon Phi basés sur des Pentium pour leur première génération, ou les Quark dédiés à l'embarqué et utilisant une architecture de 486 datant d'une bonne vingtaine d'années !

Si l'envie de la société d'être présente sur tous les marchés est là, en pratique les succès ne sont pas systématiquement au rendez vous, Intel ayant par exemple massivement raté le marché des smartphones. Cumulé à la baisse continue des ventes sur le marché historique des PC, l'ouverture des usines à des clients tiers se dessine de plus en plus comme une nécessité pour Intel, même si l'avouer semble impossible à la société, qui continuait donc d'envoyer des signaux mitigés aux possibles futurs clients de son activité fabrication.

Avec l'annonce d'aujourd'hui, les choses sont - peut être - en train de changer puisque la prise de licence ARM par Intel est tout sauf anodine. Ce n'est pas la première fois qu'Intel fabriquera des SoC ARM, on l'avait vu avec Altera qui utilisait un core ARM dans un usage très spécifique.

La licence Artisan Physical IP  inclut en effet toutes les briques nécessaires pour la création de puces ARM de tout types. Il s'agit de tous les blocs de base avec des bibliothèques haute densité et haute performance de transistors logiques,et également tout le nécessaire pour les différents types de mémoire. La licence inclut surtout POP IP, qui est pour rappel l'idée qui fait le succès d'ARM : permettre l'utilisation de blocs interchangeables et compatibles pour créer des puces custom. Ainsi un client peut choisir d'utiliser des coeurs CPU dessinés par ARM (les gammes Cortex) ou créer ses propres coeurs (c'est le cas d'Apple et plus récemment de Nvidia), de choisir un GPU (que ce soit les Mali d'ARM, ou les populaires PowerVR d'Imagination Technologies), et également de choisir son fournisseur pour les interconnexions.

Concrètement, Intel va donc "porter" ces bibliothèques d'ARM aux particularités de son futur process 10 nm, ce qui permettra aux partenaires d'ARM de porter à leur tour - s'ils le souhaitent - leurs blocs POP IP. ARM et Intel travailleront conjointement pour le portage de deux futurs blocs CPU ARM Cortex-A (probablement un autre successeur 10nm de l'A72, voir l'annonce de l'A73 en 10nm lui aussi), la déclinaison que l'on retrouve dans les smartphones et tablettes.

Faut il y voir un virage pour Intel ? Fabriquer des puces ARM pour smartphones, ce qu'ils feront pour LG (nouveau client annoncé dans la foulée) va forcément à l'encontre des ambitions internes d'Intel d'imposer le x86 sur mobile. Car si un peu plus tôt dans l'année Intel avait décidé d'annuler sa nouvelle génération de SoC pour smartphones (Broxton et SoFIA), le constructeur continuait en interne à travailler sur les générations suivantes tout en essayant de développer dans l'intérim son activité modem (Intel aurait possiblement gagné le marché du modem du prochain iPhone). A l'heure où ARM augmente ses ambitions pour aller attaquer le marché juteux des serveurs, on peut se demander jusqu'où ira réellement l'ouverture d'Intel.


Un futur CPU ARMv8 24 coeurs de Qualcomm

En fabriquant des puces concurrentes, Intel s'ouvre à des comparaisons directes qui pourraient être assez défavorables à ses architectures x86, assez peu adaptées à la basse consommation. L'avantage supposé du process d'Intel, s'il existe, ne pourra plus jouer en la faveur de ses propres solutions pour compenser un éventuel déficit architectural. La structure de marges d'Intel, là aussi très différente de celle des fondeurs tiers, posera là aussi rapidement problème.

Qui plus est, en obtenant la licence Artisan d'ARM, Intel va devoir partager tous les détails techniques, y compris les plus secrets, de son process en ce qui concerne les règles et les dimensions exactes des transistors, ce qui va l'exposer là aussi à une comparaison directe avec les autres acteurs installés du milieu (comme TSMC et Samsung). Il faudra un peu de temps pour mesurer les conséquences concrètes de tout cela, car cet accord ne concerne que le 10nm, un process pour rappel en retard et qui n'est prévu chez Intel que pour la fin de l'année 2017 en version mobile. Les dernières nouvelles du 10nm, sur lequel Intel ne communique pas, n'étaient pour rappel pas particulièrement rassurantes avec l'arrivée possible sur sa roadmap de puces 14nm... pour 2018.

Microsoft capitule sur le support de Skylake

Publié le 16/08/2016 à 14:36 par
Envoyer Imprimer

En début d'année, Microsoft avait publié un billet de blog surprenant , indiquant que non seulement les futurs processeurs d'Intel et d'AMD ne seraient supportés pleinement que par Windows 10, mais qu'en prime les plate-formes Intel Skylake (la dernière génération en date de processeurs d'Intel) ne disposeraient d'un support sous Windows 7 (et 8.1) que jusqu'en juillet 2017 !

Quelque chose que nous avions interprété à l'époque comme une bien lourde tentative d'inciter les OEM, les revendeurs, et les utilisateurs, à passer à Windows 10. La firme de Redmond ayant été pour le moins obscure sur ce que cette limite supposait, sous entendant dans son billet que seules les failles de sécurité les plus critiques feraient l'objet de patch.

Rapidement, Microsoft est revenu en arrière une première fois, rajoutant une année de "support" et repoussant cette limite à juillet 2018.

Aujourd'hui, Microsoft revient en arrière une deuxième fois, abandonnant définitivement l'idée d'un support sélectif de Skylake. Un nouveau billet de blog  indique que Microsoft fournira "tous les patchs" pour les plate-formes Skylake jusqu'à la fin du support officiel de Windows 7 (14 janvier 2020) et 8.1 (10 janvier 2023). Microsoft crédite ce changement à son "partenariat fort" avec Intel qui s'occupera de la validation des patchs, et aussi à la demande de ses clients entreprise.

Microsoft continue cependant d'indiquer que les futures plate-formes d'Intel et d'AMD comme Kaby Lake et Bristol Ridge ne seront "supportés pleinement" que sous Windows 10. On ne sait pas encore ce que cela veut dire, il serait étonnant qu'Intel et AMD ne proposent pas, par exemple, de pilotes chipsets pour Windows 7 et 8.1 pour leur prochaine génération.

Cette capitulation de Microsoft n'est pas forcément surprenante étant donné la frilosité historique des entreprises à passer à une nouvelle version de Windows. Combiné à la non percée sur le marché des smartphones avec Windows 10 Mobile et malgré l'utilisation de techniques peu admissibles d'un point de vue moral  (et légal ) pour forcer les mises à jour vers Windows 10, la société de Redmond à du revenir en arrière  sur ses objectifs d'atteindre un milliard de machines sous Windows 10 d'ici 2018.

Les changements de politique de Microsoft en matière de vie privée posent également question, la société utilisant désormais abondamment la "télémétrie", et Microsoft se réservant le droit "d'accéder, transférer, communiquer et stocker" vos données personnelles dans une liste de cas relativement large  (voir la section complète Reasons We Share Personal Data pour plus de détails), incluant par exemple la protection de la propriété intellectuelle de Microsoft !

On notera cependant qu'une grande partie de la télémétrie a été déployée sous Windows 7 et 8.1 via des mises à jour Windows Update. Si l'on pouvait désactiver manuellement celles ci, nos confrères d'Ars Technica  indiquaient hier que Microsoft ne proposera plus la possibilité pour Windows 7 et 8.1 de télécharger et choisir individuellement les patchs à partir d'octobre, proposant uniquement des bundles. Dans un premier temps, cela ne concernera que les nouveaux patchs de sécurité mais toutes les mises à jour seront concernées à terme.

Top articles