IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Tachyum : plus puissant qu'un Xeon, plus petit qu'ARM
Leur architecture Prodigy simplifie la conception des processeurs par le compilateur

Le , par dourouc05

129PARTAGES

14  0 
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.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Jipété
Expert éminent sénior https://www.developpez.com
Le 01/09/2018 à 1:05
Bonsoir,
Citation Envoyé par dourouc05 Voir le message
[...] 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,
3  1 
Avatar de foetus
Expert éminent sénior https://www.developpez.com
Le 01/09/2018 à 3:28
Citation Envoyé par Jipété Voir le message
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.
1  0 
Avatar de Jipété
Expert éminent sénior https://www.developpez.com
Le 01/09/2018 à 8:56
Citation Envoyé par foetus Voir le message
un processeur c'est con comme une b*te
Yes yes,

Citation Envoyé par foetus Voir le message
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 ?
2  1 
Avatar de Jipété
Expert éminent sénior https://www.developpez.com
Le 01/09/2018 à 12:21
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 :
Citation Envoyé par chrtophe Voir le message
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.
2  1 
Avatar de tulipebleu
Membre régulier https://www.developpez.com
Le 01/09/2018 à 23:10
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 : Sélectionner tout
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.
1  0 
Avatar de Jipété
Expert éminent sénior https://www.developpez.com
Le 02/09/2018 à 0:55
Citation Envoyé par tulipebleu Voir le message
Voila, j'espère que c'est suffisamment clair comme cela.
Hé ben voilà !

Merci à tous, cependant, une dernière question... Quand tu dis
Citation Envoyé par tulipebleu Voir le message
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 ?
1  0 
Avatar de Pomalaix
Rédacteur https://www.developpez.com
Le 02/09/2018 à 14:26
Citation Envoyé par Jipété Voir le message
...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 !
1  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 01/09/2018 à 10:52
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.
1  1 
Avatar de Mat.M
Expert éminent sénior https://www.developpez.com
Le 01/09/2018 à 12:58
Citation Envoyé par Jipété Voir le message
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.
Citation Envoyé par Jipété Voir le message

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.
Citation Envoyé par Jipété Voir le message

- [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

Citation Envoyé par Jipété Voir le message
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
0  0 
Avatar de Iradrille
Expert confirmé https://www.developpez.com
Le 01/09/2018 à 19:58
Citation Envoyé par Jipété  Voir le message
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 : Sélectionner tout
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.
0  0