La guerre des jeux d'instructions aura-t-elle lieu?

Après RISC-V, le nouveau jeu d'instruction de Berkeley qui ne voulaient pas payer leur licence ARM, Agner Fog a commencé aussi à définir le successeur du x86, ForwardCom.

On se rappelle (ou pas) de son coup de gueule il y a quelques années contre les décisions à court terme qui ont mené à la fragmentation des extensions du x86 et de la saturation de son espace d'encodage.

Pour ne pas répéter les erreurs du passé, cette fois toutes les décisions sont prises par accord de consensus d'un comité d'experts en architecture, compilation et système composé d'Agner tout seul.

(Je suis gratuitement méchant, en vrai il tient aussi compte des commentaires des lecteurs de son blog.)

VLE. Merdique. Poubelle.

(J'economise mon temps en faisant un raccourci.)

C'est pas ce que j'aurais considéré comme le point le plus rédhibitoire de cet ISA (genre les instructions à 5 opérandes m'inquiètent plus) mais oui...

Si tu préfères on parle de MIPS sans les delay slots RISC-V. :)

Citation:

---

Envoyé par Møgluglu

Si tu préfères on parle de MIPS sans les delay slots RISC-V. :)

---

Ca pourrait être sympa. Il y a moyen d'avoir un résumé un peu impertinent, genre qu'on ne trouverait pas sur le site internet :ninja: . Est-ce un jeu d'instruction qui semble avoir le potentiel d'être performant ? Est ce que ça pourra vraiment révolutionner l'industrie microélec avec des cœurs et une suite d'outils open-source à terme ? Ou est ce que si ça prend un peu ils vont se manger plein de brevets dans les dents.

Citation:

---

Envoyé par Møgluglu

Si tu préfères on parle de MIPS sans les delay slots RISC-V. :)

---

C'est quoi ce bidule ? Encore une invention de chercheurs universitaires qui se croient plus malins que des ingenieurs de l'industrie ?

L'est beau mon troll, hein ?

Mais sinon ouai, je veux bien des avis sur RISC-V :)

- - - Mise à jour - - -

Citation:

---

Envoyé par weedkiller

Ca pourrait être sympa. Il y a moyen d'avoir un résumé un peu impertinent, genre qu'on ne trouverait pas sur le site internet :ninja: . Est-ce un jeu d'instruction qui semble avoir le potentiel d'être performant ?

---

Quasiment tous les jeux d'instruction generiques se valent quand tu montes en performance. C'est plus souvent ta micro-architecture qui importe.

D'un autre cote, le cout de validation n'est probablement pas le meme.

Citation:

---

Est ce que ça pourra vraiment révolutionner l'industrie microélec avec des cœurs et une suite d'outils open-source à terme ?

---

Difficile a dire. Si je peux me permettre un parallele un peu limite, est-ce que Linux a revolutionne le marche du desktop ?

Citation:

---

Ou est ce que si ça prend un peu ils vont se manger plein de brevets dans les dents.

---

Ca c'est quasiment certain ^_^

Comme tout le monde, j'ai écrit mon processeur RISC-V en RTL l'hiver dernier, donc j'ai eu l'occasion de regarder un peu.

La partie de base (RV32I, jeu d'instruction entier niveau utilisateur), bah c'est propre, l'encodage est soigné, c'est trivial à décoder. C'est un MIPS dont les principaux problèmes ont été corrigés. Donc en disant que c'est MIPS sans les delay slots je caricature à peine.
La partie niveau kernel n'est pas encore finalisée, mais là aussi c'est très proche du MIPS après retour d'expérience et correction des principaux défauts.

Après, le reste... Alors l'idée de RISC-V, c'est un jeu d'instruction de base minimal et une myriade d'extensions autour, aussi bien officielles que custom.

Il y a quelques extensions déjà définies. Le flottant (RV32F), par exemple. Alors là j'espère pour eux que c'est un stagiaire qui a écrit la spec, parce que c'est complètement con. Ils ont repris ce qui semble être le jeu d'instruction flottant MIPS des années 1990, changé toutes les références de IEEE 754:1985 en IEEE 754:2008, et ajouté une instruction FMA par dessus.

Sur la forme, ça ne veut plus rien dire vu que le texte utilise la nomenclature de 1985 qui n'existe pas dans la norme de 2008 qu'il cite. (J'ai envisagé d'écrire une implémentation en flottant décimal et défendre qu'elle est conforme à la spec RV32F, vu que celle-ci ne mentionne nulle part en quelle base sont les flottants. Mais c'est beaucoup de boulot pour un troll.)

Sur le fond, c'est débile. Déjà, il manque un paquet d'opérations requises par la norme de 2008 et qui ne sont pas immédiates à implémenter en software, comme les arrondis à l'entier inférieur/supérieur/plus proche/plus vers zéro.
Mais surtout, depuis l'IBM RS/6000 en 1990, on sait que si on décide de mettre un FMA, alors il faut commencer par définir le FMA, et ensuite construire toutes les autres instructions pour qu'elles rentrent dans le moule du pipeline FMA. Ce qui est cool, c'est que dans la FPU, au lieu d'avoir un additionneur en n cycles, un multiplieur en m cycle, et une unité de division/racine carrée à latence variable qui est la seule unité non pipelinée du processeur, on n'a plus que des FMA pipelinés, avec éventuellement une sortie anticipée pour les opérations faciles. Ce qui est nettement plus simple à gérer dans le pipeline (bon, surtout en in-order).

Les divisions et les racine carrées, on les fait en software, et (à part si on est Intel pour se permettre de mettre un monstrueux diviseur hardware SRT en base 1024) avec un FMA et quelques instructions d'assist qui vont bien c'est plus rapide qu'en hard. Le FMA a été inventé en grande partie pour ça. ;)

Dans RV32F, l'instruction de division flottante est bien sûr obligatoire. Cool, une instruction déjà obsolète 25 ans avant d'être introduite à implémenter en microcode dans un processeur qui s'appelle "RISC".

Citation:

---

Envoyé par Møgluglu

Dans RV32F, l'instruction de division flottante est bien sûr obligatoire. Cool, une instruction déjà obsolète 25 ans avant d'être introduite à implémenter en microcode dans un processeur qui s'appelle "RISC".

---

C'est plus cher de trap et de le faire en soft ou de la microcoder :trollface:?
Si t'as un tout petit pipeline ça ne doit pas ajouter grand chose de le faire en software, si?
Et si t'as un gros pipeline, bah t'as de la place pour un gros diviseur. Pas de problèmes, que des solutions.

Oui mais si tu as un gros pipeline avec de la place pour un gros diviseur, c'est que tu as de la place pour des gros FMA aussi. Dans à peu près tous les cas tu as un meilleur débit en software vu que les FMA sont pipelinés. L'unité hardware permet juste d'avoir une latence un peu meilleure. Et encore, ça se joue à quelques cycles.

D'ailleurs les Power, les Itanium, et les GPU s'en sortent bien en division flottante sans diviseur hardware.

Dans ces cas là, quel intérêt vois-tu au gros diviseur hard de chez Intel, si le gain en latence est vraiment faible? Plus de parallélisme (on peut faire des FMAs et des divisions en même temps)?
Et finalement, est-ce qu'ils ne devraient pas microcoder leur division flottante (c'est CISC, ils ont le droit eux :p)?
Quelqu'un pour aller vérifier sur les die shots de Skylake et trouver le diviseur :ninja:?

Edit : Ou alors, est-ce qu'ils le gardent pour une raison obscure du style x87?

Oui le diviseur de Skylake est monstrueux. Je prétends qu'ils n'avaient pas le choix : c'était ça ou rien, vu qu'à la louche la division sur Skylake en soft est plus rapide qu'en hard sur Haswell, grâce au FMA en 4 cycles.
Je pense que le diviseur est surtout utile pour la division entière. Après, s'ils en mettent plein en parallèle pour faire des divisions en SIMD 512-bit, c'est qu'ils ont sûrement une bonne raison.

Pour la division en microcode, AMD l'a longtemps fait (sur le K7 et K8) avec des registres flottants étendus (genre ~87 bits), donc c'est faisable. Ils ont néanmoins fini par mettre un diviseur hardware dans Piledriver.

Citation:

---

Envoyé par Thamior

Dans ces cas là, quel intérêt vois-tu au gros diviseur hard de chez Intel, si le gain en latence est vraiment faible? Plus de parallélisme (on peut faire des FMAs et des divisions en même temps)?
Et finalement, est-ce qu'ils ne devraient pas microcoder leur division flottante (c'est CISC, ils ont le droit eux :p)?
Quelqu'un pour aller vérifier sur les die shots de Skylake et trouver le diviseur :ninja:?

Edit : Ou alors, est-ce qu'ils le gardent pour une raison obscure du style x87?

---

Tu peux soit bloquer presque tous tes cycles de dispatch FMA pendent un moment ou alors lancer une operation en parallele (sur du hardware qui fournit quelques cycles de pipeline pour avoir un debit meilleur qu'une operation completement bloquante). Le meme morceau de hardware peut aussi faire les SQRT avec peu de modifications. Tu n'occumes qu'une seule entree dans tes stations de reservation et ton reorder buffer et, bonus...
L'energie necessaire pour executer une division est beaucoup plus faible avec un radix divider (meme a radix eleve) que d'utiliser des FMA (en plus du fait que d'executer une operation consomme beaucoup moins d'energie que d'executer une sequence d'operations, juste du point de vue du controle).

Tu serais surpris de voir l'impact de performance de bloquer l'utilisation de ton FMA pendant si longtemps (dans un processeur moderne la quantite de hardware investit pour chaque 1% d'IPC commence a etre impressionante :))

Citation:

---

Envoyé par fefe

Tu serais surpris de voir l'impact de performance de bloquer l'utilisation de ton FMA pendant si longtemps (dans un processeur moderne la quantite de hardware investit pour chaque 1% d'IPC commence a etre impressionant :))

---

Pas encore assez pour coller de la prédiction de valeurs dans les CPUs :)

En dehors de 0 ou 1 il n'y a pas grand chose d'autre a predire qui rapporte vraiment, et il y a de nombreux endroits ou il y a deja effectivement de la prediction de valeur (0, -1 ou +1). Ce n'est pas necessairement fait de maniere explicite, mais c'est equivalent.
Soit dit en passant Willamette faisait de la prediction de valeur sur l'adder pour l'accelerer :). Les mauvaises predictions etant gerees par replay comme toutes les autres erreurs de speculation sur Willamette. Donc ca fait un moment qu'il y en a ;).

Je pensais plus à quelque chose de générique. Il y a certainement des workloads ou casser les chaînes de dépendances peut aider. Alors bien sûr une bonne prédiction n'apporte pas grand chose, mais si tu es rendu au point ou c'est la solution la moins chère pour avoir tes 1% d'IPC en plus...;).
Tu as des références sur les "nombreux endroits ou il y a déjà effectivement de la prédiction de valeur", ça m'intéresse. Ou alors c'est "juste" que la prédiction de branchement c'est des fois prédire un compare d'un registre avec 0 et donc de prédire si le registre vaut 0 ou autre chose...

Welcome back fefe ! Tu t'es donné le mot avec Baron sur le topic photo ?

Citation:

---

Envoyé par fefe

Tu peux soit bloquer presque tous tes cycles de dispatch FMA pendent un moment ou alors lancer une operation en parallele (sur du hardware qui fournit quelques cycles de pipeline pour avoir un debit meilleur qu'une operation completement bloquante). Le meme morceau de hardware peut aussi faire les SQRT avec peu de modifications. Tu n'occumes qu'une seule entree dans tes stations de reservation et ton reorder buffer et, bonus...
L'energie necessaire pour executer une division est beaucoup plus faible avec un radix divider (meme a radix eleve) que d'utiliser des FMA (en plus du fait que d'executer une operation consomme beaucoup moins d'energie que d'executer une sequence d'operations, juste du point de vue du controle).

Tu serais surpris de voir l'impact de performance de bloquer l'utilisation de ton FMA pendant si longtemps (dans un processeur moderne la quantite de hardware investit pour chaque 1% d'IPC commence a etre impressionante :))

---

Merci pour les explications. Oui, j'avoue que je trolle un peu en traitant l'unité de division d'obsolète.

J'aurais tendance à penser que c'est surtout sur les processeurs in-order (où on n'aime pas trop les opérations à latence variable) qu'on a intérêt à utiliser le FMA pour les divisions/racines carrées. Mais le Power 1 anéantit cette belle théorie. :)

Fun fact : Alpha est vivant :
https://github.com/THUHPGC/swDNN/blo...re_functions.S
... et dans le plus gros supercalculateur du monde qui plus est.

Alors les démentis officiels ont beau dire que le jeu d'instruction du SW26010 n'a rien à voir avec Alpha, il a quand-même un petit air de famille. Jusqu'au target utilisé pour configurer gcc : alphaev6-unknown-linux-gnu. :)

Excellent, Alpha est vivant :p

Le .set noreorder/noat au debut me rappelle mes premiers contacts avec le RISC sur un MIPS. Je n'ai plus jamais pu revenir sur du CISC. Enfin si, de temps en temps je dois regarder du x86 genere par QEMU et je pleure.

Ne nous emballons pas, ça reste un Cell avec des instructions dma, getc, getr et du code schedulé (et indenté !) à la main pour des SPE in-order à 2 voies avec un FMA en 7 cycles. Le Cell aussi est vivant. :)

Dommage qu'ils n'aient pas plutôt repris Tarentula, ça aurait eu de la gueule. :)

Citation:

---

Envoyé par Møgluglu

Ne nous emballons pas, ça reste un Cell avec des instructions dma, getc, getr et du code schedulé (et indenté !) à la main pour des SPE in-order à 2 voies avec un FMA en 7 cycles. Le Cell aussi est vivant. :)

---

C'est encore plus sexy. Le pervers en moi trouvait le Cell trop rigolo ^_^

Citation:

---

Dommage qu'ils n'aient pas plutôt repris Tarentula, ça aurait eu de la gueule. :)

---

Je ne connaissais pas, ca avait l'air sympa aussi.

Western Digital met du RISC-V dans ses skeudurs.

Et en plus, ça y est, ils ont une idée du modèle mémoire pour RISC-V : les deux mon capitaine !

Citation:

---

In order to find a compromise, defined RVTSO (strong) and RVWMO (weak).

• Both are multi-copy atomic. This means cores are allowed to peek at stores they have issues as long as they haven’t been observed by anyone else and is much simpler to reason about than the Power and ARMv7 memory models (Drole de façon de définir multi-copy atomic...:huh:).
  

• The base RISC-V memory model is RVWMO (software must assume this if it wants to be portable). It’s important to note that a hardware implementation meeting the RVWMO specification could be more conservative (stronger). Additional have the Ztso extension for RVTSO, which software might target.

• RVWMO and RVTSO differ in the degree of memory access reordering they permit at the point of global visibility. In RVTSO, only store-to-load reordering can be observed. In RVWMO, most memory accesses can be reordered freely unless synchronized via .sq, .rl and/or fences.

---

Évidemment. Quoi du mieux qu'un standard que deux standards ? :facepalm:
(Surtout quand l'un des deux c'est "on fait comme x86, finalement c'est pas mal x86".)

Krste qui joue à celui qui a le plus gros workshop : "The CARRV RISC-V workshop at MICRO was even better attended than the machine learning workshop."
Tu m'étonnes, qu'est-ce qu'il était chiant ce tuto deep learning. En plus il faisait beau ce jour-là. :ninja:

Je note aussi que le seul mec qui développait un processeur out-of-order open source se barre dans une startup. Pour faire des many-core vectoriels pour le deep learning comme tout le monde. :emo:

Vous l'attendiez tous depuis la mise au rebut de votre Cray 1, voici quelques infos sur le Meilleur jeu d'instructions vectoriel de tous les temps™ par Asanović et Espasa :
https://content.riscv.org/wp-content...asaVEXT-v4.pdf
En tout cas, ça doit être le premier jeu d'instruction à introduire le concept de typage un peu dynamique mais pas trop non plus.

Seymour aurait été fier.

Seymour aurait été fier ? Je dois pas avoir la référence :sad:

https://en.wikipedia.org/wiki/Seymour_Cray :)