Discussion :

[dourouc05]

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.

[Jipété]

Bonsoir,

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

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é]

un processeur c'est con comme une b*te

Yes yes,

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 ?

[chrtophe]

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.

[Jipété]

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 :

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.

[Mat.M]

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.

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.

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

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]

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 - Visualiser dans une fenêtre à part

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.

[tulipebleu]

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 - Visualiser dans une fenêtre à part

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é]

Voila, j'espère que c'est suffisamment clair comme cela.

Hé ben voilà !

Merci à tous, cependant, une dernière question... Quand tu dis

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 ?

[dourouc05]

je vois ça avec des cœurs de travail (chacun son instruction) et un main mechanism qui supervise tout ça

Ce ne sont pas vraiment des cœurs, plutôt des zones qui effectuent des opérations distinctes (tu peux additionner deux entiers dans une première zone, spécifique aux nombres entiers, puis deux nombres à virgule flottante, dans une autre zone qui ne sert qu'aux nombres à virgule flottante).

[Jipété]

Bonjour,

Ce ne sont pas vraiment des cœurs, plutôt des zones qui effectuent des opérations distinctes (tu peux additionner deux entiers dans une première zone, spécifique aux nombres entiers, puis deux nombres à virgule flottante, dans une autre zone qui ne sert qu'aux nombres à virgule flottante).

Tu sais quoi ? Tout ça me fait penser au couple xxx86/xxx87, ça nous ramène à presque 40 ans en arrière et si tulipebleu ne précise pas

Code pascal :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
var
  i,k: Float;
  j: Integer;

son exemple tombe à l'eau...

Et je retombe sur la problématique de base :

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.

• Si i est un Float et j un Integer, la condition "et s'il peut" n'a pas de sens et n'a pas lieu d'être, c'est géré en amont et chaque zone fait son taf, en parallèle ;
• Si i et j sont du même type, comment la zone dédiée concernée par ce type va-t-elle s'en sortir à part en attendant ?

Un peu comme à la pompe à essence quand tu vas faire le plein : bien obligé d'attendre que celui qui est devant ait payé avant de pouvoir remplir ton réservoir.
Alors oui, on peut gagner un poil de temps : pendant que l'un paye, l'autre peut, après s'être mis en position, ouvrir l'orifice de remplissage et y insérer le pistolet une fois celui-ci décroché.
Mais il faudra quand même attendre que le paiement soit effectué pour entendre le doux ronron de la pompe,

[foetus]

...

Tu n'as jamais fait d'assembleur et cela se voit

Un processeur a un pipeline qui va permettre de traiter des instructions (ADD, MUL, MOV, ...) en X opérations/ stages (entre 10 et 31)
Mais tous les stages ne sont pas utiles pour traiter une opération, et c'est pour cela qu'1 opération peut durer plus longtemps.

Pour faire un ADD (ajouter) c'est X opérations, pour faire un MUL (multiplier) c'est X opérations, ...

Mais depuis le Pentium 4, le processeur peut traiter plusieurs instructions en parallèle afin de remplir au mieux son pipeline : c'est l'hyper-threading
Pour la petite histoire, le Pentium 4 c'est minimum 20 stages et cela posait de gros problèmes de performance, surtout lorsque le processeur doit décharger/ recharger le pipeline.

Reprends l'exemple de Iradrille : le processeur doit traiter les points bleus dans l'ordre. Donc il faut qu'il attende de finir 1 pour faire la suivante.
Mais pour les points rouges, s'il n'est pas complet, il peut en exécuter 1 n'importe quand.
Et dans le meilleur des cas, il peut traiter 1 rouge et 1 bleu en même temps. Tu sens l'optimisation

Et l'autre chose que tu ne sais pas , c'est que le processeur ne traite que des entiers. C'est le coprocesseur qui traite des flottants. Donc parmi les stages, il a sûrement quelques stages pour communiquer avec le coprocesseur.

Et enfin pour les zones mémoires (c'est la mémoire cache) dont parle dourouc05 oublie parce qu'on va rentrer dans les notions de CISC/ RISC (<- IBM PowerPC et les MACs avant 2004).
Depuis 2006 (à peu près) x86 est un jeu CISC qui a évolué presque comme un RISC : ne me demande pas les détails

[Jipété]

Tu n'as jamais [fait] d'assembleur et cela se voit

Exact, j'aime bien les choses lisibles, (mais j'ai quand même joué, dans une vie antérieure, avec le jeu d'instruction du PDP8e, fort agréable).

Bon, j'ai un peu fouillé ce matin, je me suis retrouvé à lire ça
https://fr.wikipedia.org/wiki/Parall...(informatique)
puis à sauter là
https://fr.wikipedia.org/wiki/Algori...la_boulangerie
là,
https://fr.wikipedia.org/wiki/Programmation_concurrente
où j'ai découvert qu'il fallait absolument lire ce problème
https://fr.wikipedia.org/wiki/Therac-25
mais aussi
https://fr.wikipedia.org/wiki/Ray_tr...t_prospectives
qui explique bien (globalement !) ce qui me turlupinait :

En effet, cet algorithme se prête particulièrement bien au parallélisme, chaque point de l'image pouvant être calculé indépendamment des autres.

Avant, histoire de me rafraîchir les neurones, je m'étais farci
https://cs.stanford.edu/people/erobe...risc/risccisc/
et d'autres du même genre, au final ma conclusion est que pour que tout ça fonctionne, il faut une quantité de contrôles avant, autour, qui défraient l'entendement.
Me demande si c'est vraiment bien rentable.

Merci à tous et bon dimanche (ne zappez pas le Therac-25 !, qui m'a fait penser au docu sur le trou dans la couche d'ozone [hier soir sur Arte], où il fut bien expliqué que les premières mesures qui l'ont découvert ont été zappées car trop éloignées de ce qui avait été prévu comme dérives possibles ! Truc de ouf !)

[Pomalaix]

...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 !

[foetus]

au final ma conclusion est que pour que tout ça fonctionne, il faut une quantité de contrôles avant, autour, qui défraient l'entendement.
Me demande si c'est vraiment bien rentable.

Et oui Si tu t'intéresses aux failles Spectre/ Meltdown, c'est justement qu'Intel a fait sauter des tests lors d'une prédiction erronée pour des raisons de performance.

[hotcryx]

Mets un PRINT dans tes instructions et tu verras qu'il y a une dépendance.

[ijk-ref]

Bonjour, pourquoi le choix de "deux cent cinquante-six ou cinq cent douze bits" au lieu de "256 ou 512 bits" ? L'article n'avait pas assez de mots pour être accepté ?


Je fais cette remarque car personnellement la version alphabétique des nombres me demande un effort bien plus grand que la version numérique. Et en tant qu'informaticien qui se respecte je ne vois pas l'intérêt de complexifier quoique ce soit inutilement.


Mais si pour vous cela apporte bien une plus value j'aimerai bien la connaitre

[Jipété]

Bonjour, pourquoi le choix de "deux cent cinquante-six ou cinq cent douze bits" au lieu de "256 ou 512 bits" ? L'article n'avait pas assez de mots pour être accepté ?

C'est parce que l'auteur a une âme de poète (oui, dans les ouvrages de poésie on compose les nombres en lettres [règles de l'I.N.])

Mets un PRINT dans tes instructions et tu verras qu'il y a une dépendance.

Fais-nous une petite démo, qu'on capte bien.

Et oui Si tu t'intéresses aux failles Spectre/ Meltdown, c'est justement qu'Intel a fait sauter des tests lors d'une prédiction erronée pour des raisons de performance.

Toi qui l'as dit, . J'ai préféré laisser parler les qualifiés, moi, dans ce domaine je suis bien largué -- d'où mes questions de béotien.
Plus les choses que je n'arrive pas à concevoir qu'on puisse les mettre en prod' :
fait sauter des tests [...] pour des raisons de performance.
Et on va monter dans des bagnoles pilotées par des IAs codées comme ça ? Au secours, laissez-moi descendre !

"C'est de ça QUE j'ai besoin", ou bien "c'est CE dont j'ai besoin". Quelle misère, comme dit l'autre !

Oui, bon, ok, mais c'est à force de fréquenter des forums remplis de textes à l'orthographe plus qu'aléatoire : il me vient une écriture... quantique,

[Pomalaix]

... il me vient une écriture... quantique,

Arf !!