Developpez.com - Rubrique Hardware

Le Club des Développeurs et IT Pro

Tachyum : plus puissant qu'un Xeon, plus petit qu'ARM

Leur architecture Prodigy simplifie la conception des processeurs par le compilateur

Le 2018-08-31 23:56:37, par dourouc05, Responsable Qt & Livres
Le marché des superordinateurs est en pleine évolution. Il y a peu, on ne parlait que d’Intel et de ses Xeon. Puis sont venues les expériences avec ARM. AMD s’est relancé dans la course avec ses Epyc. Maintenant, Tachyum vient annoncer ses processeurs Prodigy, pour donner un nouveau coup de fouet : soixante-quatre cœurs par puce (contre vingt-huit chez Intel, trente-deux chez AMD), huit canaux de mémoire (comme AMD, contre seulement six chez Intel). Ils ne sont pas encore prêts pour le déploiement — on espère les voir sur le marché en 2020. Il n’empêche qu’ils ont de quoi surprendre : ils utilisent une conception radicalement différente, toutes les instructions étant forcément exécutées dans l’ordre dans lequel elles arrivent au processeur (alors qu’Intel et AMD les réordonnent pour utiliser au maximum tout le processeur, sans faire attendre certaines parties inutilement).


Les Prodigy disposent de leur propre jeu d’instructions, ce qui leur permet de faire table rase Intel étant poings et mains liées par la rétrocompatibilité, par exemple. Le compilateur doit être spécifiquement pensé pour l’architecture : si le processeur ne réordonne pas les instructions, c’est parce qu’il attend que le compilateur s’en charge. À cette fin, Tachyum a d’abord développé un compilateur selon cette contrainte (un dérivé de GCC 7.2, pour le moment), puis seulement un processeur qui en bénéficie.

Cette conception permet de réduire l’utilisation de transistors sur la puce — chaque cœur est ainsi beaucoup plus petit et peut être plus efficace (notamment parce que l’information a moins de distance à parcourir). Ainsi, sur moins de trois cents millimètres carrés (les Xeon montent jusque sept cents), Tachyum arrive à embarquer soixante-quatre cœurs, huit canaux de mémoire ECC (gérant la DDR4 et la DDR5), deux canaux supplémentaires pour de la mémoire à très haut débit HBM3, septante-deux canaux PCIe 5, deux ports Ethernet 400 Gb/s. En d’autres termes, les entrées-sorties de ces processeurs sont hors normes ! Ils seront fabriqués par TSMC sur son processus à 7 nm.


Plusieurs versions de ces puces sont prévues, en coupant les fonctionnalités non nécessaires selon les charges de travail à exécuter. Cela permet ainsi d’augmenter la densité, donc de réduire les coûts pour les utilisateurs.


L’architecture en elle-même n’est pas très différente de ce qui se fait dans le reste de l’industrie. Chaque cœur dispose de trente-deux registres de soixante-quatre bits pour des entiers, trente-deux registres vectoriels de deux cent cinquante-six ou cinq cent douze bits, sept registres de masques. À chaque coup d’horloge, un cœur peut charger deux valeurs en mémoire, effectuer deux opérations de multiplication-addition, une écriture en mémoire, un incrément d’adresse, un branchement. En moyenne, cela lui permet donc d’effectuer 1,72 instruction — huit microopérations par cycle.

Tout ceci n’est possible que grâce aux annotations écrites par le compilateur, qui groupe explicitement des instructions par paquets de quatre à seize octets. Toute l’exécution spéculative est aussi gérée par le compilateur, ce qui évite de perdre des transistors pour ce faire — et de créer des failles, accessoirement.


Une autre idée derrière Prodigy est d’exploiter le processeur à fond, tout le temps. Selon les simulations actuelles, un cœur Prodigy passerait moins de vingt pour cent de son temps à attendre que des données à traiter arrivent (par rapport à la moitié du temps pour la défunte architecture Itanium d’Intel, basée sur des principes similaires, où le compilateur devait effectuer une bonne partie du travail). De même, dans un centre informatique moderne, la plupart des processeurs sont rarement utilisés : un tiers du temps chez Amazon EC, quarante pour-cent du temps chez Facebook. Le reste du temps, les processeurs consomment, mais n’effectuent aucun calcul, alors qu’ils pourraient être utilisés pour des tâches d’apprentissage automatique.

Sources : Kleiner Supercomputer-Chip soll Intels Xeons schlagen, Hot Chips 2018: Tachyum Prodigy CPU Live Blog.
  Discussion forum
20 commentaires
  • Jipété
    Expert éminent sénior
    Bonsoir,
    Envoyé par dourouc05
    [...] ils utilisent une conception radicalement différente, toutes les instructions étant forcément exécutées dans l’ordre dans lequel elles arrivent au processeur (alors qu’Intel et AMD les réordonnent pour utiliser au maximum tout le processeur, sans faire attendre certaines parties inutilement).
    N'arrivant toujours pas à comprendre ce concept (mis en gras), j'aimerais bien un exemple avec des mots simples.
    Comment peut-on réordonner des instructions qui ont été mises dans un ordre bien précis pour exécuter un boulot bien défini ?
    Comment pourrait-on lancer le redimensionnement d'une image tant que le fichier n'a pas été ouvert puis au moins analysé ?
    Un truc m'échappe...
    Merci,
  • foetus
    Expert éminent sénior
    Envoyé par Jipété
    Comment pourrait-on lancer le redimensionnement d'une image tant que le fichier n'a pas été ouvert puis au moins analysé ?
    Un truc m'échappe...
    Parce que tu raisonnes beaucoup trop haut niveau : un processeur c'est con comme une b*te et il ne sait faire que des additions, multiplications, déplacement/ accès mémoire ou cache (+ 2-3 autres choses aussi triviales, je suis resté au i386 et on est au i786 )

    Et je soupçonne que le processeur au moins fait le truc ultra classique qu'on rencontre très très souvent : il réorganise/ groupe/ met en cache toutes les lectures s'il n'y a pas d'écriture puisqu'il n'y a pas de modifications de la valeur.
  • Jipété
    Expert éminent sénior
    Envoyé par foetus
    un processeur c'est con comme une b*te
    Yes yes,

    Envoyé par foetus
    le truc ultra classique qu'on rencontre très très souvent : il réorganise/ groupe/ met en cache toutes les lectures s'il n'y a pas d'écriture puisqu'il n'y a pas de modifications de la valeur.
    Tu peux détailler, please ?, parce que si c'est là que ça se passe, c'est là-dessus qu'il me faut des mots simples comme à un gamin de 10 ans.

    Car si j'essaie de comprendre, tout seul dans mon coin, ça donne ça :
    - [il] met en cache toutes les lectures, rien de nouveau sous le soleil, c'est de la bête mise en cache sans réorganisation aucune, un simple mécanisme hardware.
    - [il] groupe quoi ? Les lectures de bytes en integers ? Ça va prendre la même place et ça obligera à dégrouper pour les calculs futurs. Quel intérêt ?
    - il réorganise quoi ? Les lectures ? Selon quels critères ?
  • Jipété
    Expert éminent sénior
    Salut, chrtophe,

    et merci de ta participation. On se rapproche...
    J'ai tout bien compris (c'est évident, donc pas compliqué à comprendre, en théorie), mais ce que j'ai besoin, c'est d'un exemple concret, IRL, de ça :
    Envoyé par chrtophe
    Pour le x86 par exemple, le processeur peut réordonner les instructions c'est à dire changer l'ordre d’exécution de celles-ci si cela lui permet d'optimiser l’exécution globale. Ceci ne se fera que si cette opération ne change pas le résultat final (ex: que les deux instructions réordonnées ne soient pas dépendantes l'une de l'autre -> non dépendance de l'utilisation d'opérations ou de registres)
    Je code depuis suffisamment longtemps en Pascal pour bien me rendre compte que je ne vois pas du tout où il pourrait y avoir des instructions indépendantes des instructions précédentes : à partir du moment où on clique sur "Fais-le !", tout s'enchaîne en une mécanique inexorable, et je n'arrive pas à concevoir un exemple où ça pourrait ne pas être le cas, et c'est de ça dont j'ai besoin.
  • tulipebleu
    Membre régulier
    Bonjour Jipété,

    Je reconnais que c'est un peu compliqué à comprendre pourquoi 2 instructions peuvent fonctionner dans un ordre différent.
    Par exemple, suppose que tu as le programme suivant en Pascal :
    Code :
    1
    2
    3
    4
    5
    i := i+1;
    j := j+6;
    k := k+7;
    k := i+j+k;
    La première instruction ne dépends pas de la 2eme instruction (tu pourrais les inverser).

    Et bien le CPU, va commencer à exécuter la 1ere instruction (i:=i+1), et s'il peut, vas exécuter la 2eme instruction (j:=j+6) immédiatement, sans attendre que la 1ere instruction soit finie d'être exécutée.
    Après, supposons que la 2eme instruction finisse de s’exécuter avant la 1ere, et bien il va commencer à exécuter la 3eme instruction (k:=k+7) alors que la 1ere instruction n'est pas terminée.

    Pour la 4eme instruction (k:=i+j+k), par contre, il va devoir attendre que les 3 premières instructions soient terminées, car il a besoin des valeurs de i, j et k.

    Voila, j'espère que c'est suffisamment claire comme cela.
  • Jipété
    Expert éminent sénior
    Envoyé par tulipebleu
    Voila, j'espère que c'est suffisamment clair comme cela.
    Hé ben voilà !

    Merci à tous, cependant, une dernière question... Quand tu dis
    Envoyé par tulipebleu
    Et bien, le CPU va commencer à exécuter la 1ere instruction (i:=i+1), et s'il peut, va exécuter la 2eme instruction (j:=j+6) immédiatement, sans attendre que la 1ere instruction soit finie d'être exécutée.
    Après, supposons que la 2eme instruction finisse de s’exécuter avant la 1ere, et bien il va commencer à exécuter la 3eme instruction (k:=k+7) alors que la 1ere instruction n'est pas terminée.

    Pour la 4eme instruction (k:=i+j+k), par contre, il va devoir attendre que les 3 premières instructions soient terminées, car il a besoin des valeurs de i, j et k.
    Tous ces bouts que j'ai mis en gras masquent une réalité plus profonde et je vois ça avec des cœurs de travail (chacun son instruction) et un main mechanism qui supervise tout ça, pour l'attente de la dernière ligne entre autre.
    Correct ?
  • Pomalaix
    Rédacteur
    Envoyé par Jipété
    ...c'est de ça dont j'ai besoin.
    "C'est de ça QUE j'ai besoin", ou bien "c'est CE dont j'ai besoin". Quelle misère, comme dit l'autre !
  • chrtophe
    Responsable Systèmes
    En gros, tu peux voir un programme comme une suite séquentielle d'instructions simples (comme indiqué, déplacement de la mémoire vers les registres du processeurs et vice-versa, calculs).

    Un processeur moderne est pipeliné, il va exécuter plusieurs instructions en même temps sur plusieurs étages, un peu comme une chaine de fabrication de voiture ou plusieurs voitures sont en cours de montage dans la chaine, chaque voiture étant monté dans un ordre précis. Le blocage à un poste bloque la chaine. (dans un CPU, attente fin de traitement pour continuer).

    Pour le x86 par exemple, le processeur peut réordonner les instructions c'est à dire changer l'ordre d’exécution de celles-ci si cela lui permet d'optimiser l’exécution globale. Ceci ne se fera que si cette opération ne change pas le résultat final (ex: que les deux instructions réordonnées ne soient pas dépendantes l'une de l'autre -> non dépendance de l'utilisation d'opérations ou de registres)

    Certains processeurs intègrent ce mécanisme, d'autres non. Quand le processeur ne comporte pas ce type de fonctionnalité, le compilateur peut le faire. Je pense que selon le cas de figure, c'est moins efficace, le compilateur ne pouvant avoir une vue en temps réel d’exécution. Par contre, ne pas avoir cette fonctionnalité dans le CPU simplifie son architecture. architecture simplifiée=moins de transistors=CPU plus petit->place pour des cœurs supplémentaires par exemple.
  • Mat.M
    Expert éminent sénior
    Envoyé par Jipété
    Tu peux détailler, please ?, parce que si c'est là que ça se passe, c'est là-dessus qu'il me faut des mots simples comme à un gamin de 10 ans.
    je pense que Foetus veut aborder la technique du cache prefetching.
    Comme l'écris Foetus oui chaque processeur traite instruction assembleur par instruction.
    Envoyé par Jipété

    Car si j'essaie de comprendre, tout seul dans mon coin, ça donne ça :
    il ne faut pas parler de lecture mais plutôt de traitement d'instructions par le CPU.
    Les instructions et les données sont lues sur le bus de données au sein du CPU
    Ensuite si le CPU voit une instruction du genre MOV AX,10h ( pour tout ce qui est i386) le CPU sait qu'il faut mettre dans l'accumulateur la valeur 10h.
    Envoyé par Jipété

    - [il] met en cache toutes les lectures, rien de nouveau sous le soleil, c'est de la bête mise en cache sans réorganisation aucune, un simple mécanisme hardware.
    non ce n'est pas de la bête réorganisation car d'une part selon les instructions assembleur il y en a qui consomment plus de cycles d'horloge que d'autres.
    Par exemple si on fait PUSH AX ou XOR AX,nAX cela consomme moins qu'un FDIV ( division en virgule flottante ) de cycles d'horloges ( toujours en i386).
    Tout cela peut se trouver certainement dans la doc d'Intel ou du processeur considéré, c'est selon.

    Ensuite il faut organiser le parallélisme de l'exécution des instructions toujours en fonction des cycles d'horloge.
    Parce que le problème c'est qu'on est dans une architecture n coeurs...donc il faut que les traitements soient parallèles en temps d'exécution

    Envoyé par Jipété
    je ne vois pas du tout où il pourrait y avoir des instructions indépendantes des instructions précédentes :
    Au niveau du CPU il y a des instructions qui sont dépendantes les unes des autres ou non.
    Une instruction comme MOV AX,valeur est codée donc sur plusieurs octets.
    Il y a d'autres instructions du CPU qui parfois sont indépendantes et donc codées sur un octet.
    Cependant s'il n'y a pas de cohérence entre un octet et l'autre qui suit ça entraine un plantage
  • Iradrille
    Expert confirmé
    Envoyé par Jipété 
    Je code depuis suffisamment longtemps en Pascal pour bien me rendre compte que je ne vois pas du tout où il pourrait y avoir des instructions indépendantes des instructions précédentes : à partir du moment où on clique sur "Fais-le !", tout s'enchaîne en une mécanique inexorable, et je n'arrive pas à concevoir un exemple où ça pourrait ne pas être le cas, et c'est de ça dont j'ai besoin.

    Hello,

    un exemple concret : le traditionnel Hello world en c++ (compilé en debug / x86).


    L'ordre des 3 instructions en rouge n'a aucune importance, et dans une moindre mesure c'est pareil pour celles en bleu (tant qu'elles restent dans le même ordre, on peut les mélanger avec les rouges).
    Code asm :
    1
    2
    3
    4
    5
    6
    mov         eax,0CCCCCCCCh   
    mov         ecx,30h   
    push        ebx   
    push        esi   
    push        edi   
    lea         edi[ebp-0C0h]
    Donnerait un résultat équivalent.

    Maintenant un cpu ne travaille pas avec ces instructions directement, il les décompose en micro instructions qui elles sont réordonnées, mais le principe reste le même.