COMPTOIR
register

Composé par ————— —— 14663 vues

SiFive P650 : enfin le début de la montée en gamme du RISC-V ?

Alors que de nouvelles cartes graphiques chez NVIDIA approchent à grands pas, le caméléon n’est pas le seul à sortir de nouveaux produits. En effet, SiFive, une start-up mature (si tant est que cela puisse exister) proche d’Intel, vient de lancer un nouveau P650 à l’occasion du RISC-V Summit, (en ce moment à Las Vegas) un processeur dans la lignée des créations de la firme : utilisation du jeu d’instruction libre RISC-V, mais architecture maison de plus en plus haute-performance.

 

sifive riscv p650

Une présentation qui n’est pas sans rappeler les CPU Arm

 

Ce dernier membre de la famille est costaud : tournant en interne en 64-bit, il surpasserait de 50 % en matière de performance le P550, pourtant dévoilé en juin dernier. Pour cela, la fréquence maximale de 3,5 GHz est bien utile, atteinte grâce à une gravure en 7 nm (TSMC ?) ; tout comme les 32 Kio de L1-D, de L1-I et les 256 Kio de L2, tous privés. Un L3 partagé est également possible, pour une taille allant de 1 à 16 mégots. Au niveau du back-end, le pipeline supporte 4 instructions maximum en parallèle, répartie sur trois chemins d’exécutions possibles : mémoire, calcul entier et calcul flottant, dont l’agencement interne n’est pas encore communiqué.

 

Au niveau des puces intégrant ce nouveau design, il est question de SoC munis de 16 cœurs maximum. En outre, SiFive s’affiche comme dépassant un Cortex-A77 de chez Arm sur le plan du ratio performance/surface (sur des applications spécifiques, ne vous emballez pas) ; l’idée étant clairement de venir dans le futur s’attaquer au marché des serveurs avec des solutions de plus en plus proches du massivement multicœur. Pour quel succès en pratique ? L’avenir nous le dira, car, si le prix, encore inconnu, est un facteur de taille dans le choix d’une nouvelle infrastructure, la compatibilité logicielle l’est tout autant : un point sur lequel Arm, pourtant de taille respectable, n’est pas toujours au niveau. De quoi lever bien des défis pour le jeune RISC-V ! (Source : MiniMachines)

 

Par là pour toutes les informations !
Un poil avant ?

Bon plan • Ryzen 7 5800X à 344,99 €

Un peu plus tard ...

Bon plan • Tè vé ! la mémoire là ! (32 Go dès 116,99 €)

Les 25 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par Un ragoteur blond en Nouvelle-Aquitaine, le Vendredi 10 Décembre 2021 à 12h42  
par _m_ le Vendredi 10 Décembre 2021 à 11h12
Donc ce décodeur, c'est un peu le boulet que doivent se trainer les proc x86. Mais pour le reste, ils partent à peu près à égalité, pour faire des µArchi
Oui le reste de la µarch n'est pas trop impacté
 
Mais à te lire, je comprends donc que ce boulet n'est pas un petit problème, mais quelque chose d'assez pénalisant en ressources
Le plus pénalisant c'est le decodage de la taille d'instruction. En x86 les instructions font entre 1et 15 byte, il ya donc 15 tailles d'instructions possible.
Imaginons que tu veux decoder 2 instructions par cycle, decoder la 1ere instruction c'est simple. Mais pour decoder la 2eme tu dois trouver sa position d'origine qui depend de la place occupée par la 1ere instruction. Il y a donc 15 position possible pour la 2eme instruction.

Maintenant si tu veux decoder 6 instructions en parallele voila les positions possible des instructions:
Instr 1 : 0
Instr 2 : 1 à 16
Instr 3 : 2 à 31
Instr 4 : 3 à 46
Instr 5 : 4 à 61
Instr 6 : 5 à 76

En RISC-V avec 2 ou 4 byte comme seules tailles d'instruction possible:
Instr 1 : 0
Instr 2 : 2 ou 4
Instr 3 : 4, 6 ou 8
Instr 4 : 6, 8, 10 ou 12
Instr 5 : 8, 10, 12 ou 16
Instr 6 : 10, 12, 14, 16, 18 ou 20

Le circuit de "instruction size decode" sera beaucoup plus simple en RISC-V.
C'est probablement pour ça que les x86 sont limités à ~5 instr decodées par cycle depuis des annèes.
Intel a même des brevets sur des circuits pour faire de la prediction de taille d'instruction tellement c'est un probleme pour eux.
[/quote]Pourquoi x86 ne pourrait pas faire de même?[/quote]Mais ils font de la macro-op fusion. Par contre pour les tailles d'instruction ils sont contraint par leur ISA CISC
par _m_, le Vendredi 10 Décembre 2021 à 11h12  
En effet, ça doit être plus économique de faire cet agencement d'instructions une fois pour toute, au moment de la compil, plutôt que de les décoder perpétuellemen, à chaque exécution.
Donc ce décodeur, c'est un peu le boulet que doivent se trainer les proc x86. Mais pour le reste, ils partent à peu près à égalité, pour faire des µArchi convaincantes.

Mais à te lire, je comprends donc que ce boulet n'est pas un petit problème, mais quelque chose d'assez pénalisant en ressources (transistors et temps de cycles, peut-être pas totalement masqué à 100% (en // du reste)?).
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes le Vendredi 10 Décembre 2021 à 07h13
La macro-op fusion est elle très peu coûteuse, d'ailleurs elle ne se fait pas exactement au décodage, mais juste en amont dans les FIFO d'instructions en attente d'être décodé, à un moment ou on ne fait rien d'autre;
Pourquoi x86 ne pourrait pas faire de même? Choix des designers ou mur technique? A priori il suffit juste de chercher dans un dico les µOP correspondantes à chaque instructions x86, non? Ou bien il y a du travail contextuel plus complexe, en fonction des instructions alentours?
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Vendredi 10 Décembre 2021 à 07h13  
par _m_ le Jeudi 09 Décembre 2021 à 19h07
N'importe qui peut se retrouver devant
(mais ça c'est mon avis, ni fanboy-CISC, ni fanboy-RISC )
Oui et non, si on se limite a cela le RISC et le CISC ont le même potentiel.

Mais le RISC a de sérieux avantages:
L'encodage des instructions est plus simple donc les décodeurs occupent moins de surface et consomment moins d'énergie;
La macro-op fusion est elle très peu coûteuse, d'ailleurs elle ne se fait pas exactement au décodage, mais juste en amont dans les FIFO d'instructions en attente d'être décodé, à un moment ou on ne fait rien d'autre;
En plus, comme le RISC mise plutôt sur des instructions de taille fixe (ou alors un nombre très limité de tailles d'instructions) alors le décodage de la taille des instructions est beaucoup plus simple, et donc durant un cycle on peut décoder beaucoup plus d'instruction en parallèle.
par _m_, le Jeudi 09 Décembre 2021 à 19h07  
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes le Mercredi 08 Décembre 2021 à 13h19
Le point important c'est que la macro-op fusion ça permet au RISC-V de rattraper les CISC en terme "densité sémantique des instructions" (j'ai inventé le terme là :troll. C'est à dire que en CISC les instructions ont une sémantique plus développé/large ce qui laisse plus de liberté au coeur pour l'exécuter comme il veut.
Et en RISC on peut imiter cela avec la macro-op fusion car on construit des sortes de "super-instructions" composés de plusieurs instructions RISC classique.
C'était un peu l'idée que je m'en faisais. Maintenant je peux poser un nom là-dessus, la macro-op fusion

Les Zens et Machin-Coves sont CISC, le M1 est RISC, mais mon avis est que ce n'est pas pour autant que l'un est forcément meilleur que l'autre, ou l'autre, condamné à resté toujours derrière. Car pour les premiers, c'est le décodeur qui fait tout le boulot, pour fabriquer du RISC-Like en interne, tandis que pour le second, tous le boulot est relégué au compilateur, qui doit fabriquer du CISC-Like. J'y vois deux approches convergentes.
L'important, c'est ce que chacun fait de son architecture. N'importe qui peut se retrouver devant
(mais ça c'est mon avis, ni fanboy-CISC, ni fanboy-RISC )
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Mercredi 08 Décembre 2021 à 13h19  
par _m_ le Mercredi 08 Décembre 2021 à 11h49
Est-ce que j'ai juste en disant que finalement, ces 'macro-op fusions', ne concerneraient essentiellement que les archi RISC (ARM, RISC-V, ...)?
Là ou tu as juste c'est que ces optimisations sont effectivement beaucoup plus intéressantes sur les archi de type RISC que sur les archi de type CISC. Mais cela ne veux pas dire que les archi CISC n'en font pas du tout. Par exemple x86 en utilise pour les jump conditionnels, mais c'est presque le seul cas d'utilisation.
 
Parce que les machines CISC (x86) c'est leur décodeur interne qui s'occupent de ça, lorsqu'elles traduisent les macro-instructions x86 en micro-instructions Intel ou AMD (et je crois que c'est ce qu'a voulu pointer Zentoo, lorsqu'il a parlé d'archi "µOP based" pour les x86 modernes)
Je comprend bien, mais tout ceci dérive juste du fait que x86 est du CISC et une uarch superscalaire. Donc oui en CISC le décodeur fait plus de taf, et en particulier il découpe une instruction en beaucoup plus de µOP en moyenne.

Le point important c'est que la macro-op fusion ça permet au RISC-V de rattraper les CISC en terme "densité sémantique des instructions" (j'ai inventé le terme là :troll. C'est à dire que en CISC les instructions ont une sémantique plus développé/large ce qui laisse plus de liberté au coeur pour l'exécuter comme il veut.
Et en RISC on peut imiter cela avec la macro-op fusion car on construit des sortes de "super-instructions" composés de plusieurs instructions RISC classique.

Si tu check le papier que j'ai linké il montre qu'ils arrivent en moyenne en RISC-V à avoir autant (voir moins) de µOP généré que x86, même si le code RISC-V est composé de plus d'instruction que le code x86.
par _m_, le Mercredi 08 Décembre 2021 à 11h49  
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes le Mardi 07 Décembre 2021 à 22h18
Merci pour cet exemple concret.

Est-ce que j'ai juste en disant que finalement, ces 'macro-op fusions', ne concerneraient essentiellement que les archi RISC (ARM, RISC-V, ...)? Parce que les machines CISC (x86), elles en fait, c'est leur décodeur interne qui s'occupent de ça, lorsqu'elles traduisent les macro-instructions x86 en micro-instructions Intel ou AMD (et je crois que c'est ce qu'a voulu pointer Zentoo, lorsqu'il a parlé d'archi "µOP based" pour les x86 modernes).
Tandis qu'avec ARM, ce taff en renvient au compilateur (j'avais justement eu une discussion intéressante sur cette différence, avec quelqu'un d'autre du Comptoir, récemment).
C'est correct? Si c'est le cas, je pense avoir enfin saisie ce qu'était ces macro-op fusion Merci pour tes explications.
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Mardi 07 Décembre 2021 à 22h22  
je precise : Par "Mais il ne peut pas faire mieux" je veux dire en ce basant juste sur le Machine Model sans autre optimisation.

D'où l'explication en suite de comment et pourquoi le CPU fait de la macro-op fusion (au moment du decodage) en plus de faire du scheduling.
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Mardi 07 Décembre 2021 à 22h18  
 
les compilo si ils ont une connaissance des heuristiques de ordonnanceurs, ils peuvent essayer d'organiser le code, afin de faciliter la vie du sheduler CPU
C'est une très bonne description de l'utilité du Machine Model. Mais il ne peut pas faire mieux

Si tu veux un exemple concret de macro-op fusion:
En RISC-V il y a une instruction Load (pour lire dans la mémoire) "LD $rd, $rs, 0" avec la semantique:
$rd <= mem[$rs]

$rd c'est le registre de destination où sera placé le résultat
$rs c'est le registre source qui contient l'adresse

En gros ça va chercher le contenu de la mémoire à l'adresse $rs et ça le met dans rd.

Mais il n'existe pas de Load "indexé" qui aurait la sémantique:
$rd <= mem[$rs1 + $rs2]

C'est à dire un Load avec une adresse de base $rs1 et un index $rs2. C'est utile pour accéder a un tableau quand on ecrit: array[index]
Si on veut le faire en RISC-V on est obligé d'écrire 2 instruction, un ADD puis un Load:
ADD $r3, $r1, $r2
LD $r4, $r3, 0

C'est pas optimal, et ça le processeur il peut pas vraiment l'optimiser, il ne peut pas fusionner les 2 instructions en un µOP car ça demanderait des µOP qui sont capable d'écrire 2 registres ($r3, $r4).
Mais si on ecrit ce petit bout de code comme ça:
ADD $rd, $rs1, $rs2
LD $rd, $rd, 0

Alors là il n'y a plus qu'un seul registre de destination, ça peut tenir dans une µOP. Donc ce que font les constructeurs de CPU RISC-V c'est qu'ils ajoutent un bout de circuit dans le decodeur qui détecte quand le code contient EXACTEMENT ce pattern. Si il le détecte, il génère la µOP. Et il ne détecte que ça ! Ce n'est pas le scheduler qui fait ce travail c'est le decoder.

Si tu veux plus de détail il y a une publication
par _m_, le Mardi 07 Décembre 2021 à 21h24  
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes le Mardi 07 Décembre 2021 à 20h01
Le Machine Model il sert à déterminer dans quel ordre mettre les instructions et quelles instructions utiliser ensemble pour exploiter efficacement les unités.[ ... ] La macro-op fusion ... C'est vraiment des patterns d'instructions spécifiques et détecté par le CPU.
Le compilo peut mettre les instructions dans l'ordre qu'il souhaites, ce n'est pas pour autant qu'il aura la garantie que le CPU les exécutera dans cet ordre-là.
L'image que j'en avais, c'est que c'est l'ordonnanceur du CPU (et d'autant plus si il est out-of-order) qui va analyser la file d'instructions et venir piocher celles qui peut exécuter (en fonction des unités disponibles) et si il le peut, les réorganiser entre-elles, si il voit que certains enchainement seraient plus efficace dans un autre ordre, tout en garantissant un résultat identique. C'est juste?
Et j'imagine, les compilo, si ils ont une connaissance des heuristiques qui animent ces ordonnanceurs, ils peuvent essayer d'organiser leur propre codes, afin de faciliter la vie de ces sheduler CPU, en leur permettant de repérer plus facilement les optimisations qu'ils peuvent faire. Toujours juste? Et ça serait ça, le macro-op fusion? Ou on est de nouveau dans du Machine Model?
C'est vrai que j'avais pas conscience qu'il s'agissait de 2 niveaux de génération de code différent. Je mélangeais les deux, à force d'associer ensemble les idées que je lisais à gauche et à droite.
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Mardi 07 Décembre 2021 à 20h01  
par _m_ le Mardi 07 Décembre 2021 à 19h13
Alors j'ai mal dû comprendre ce que tu pointais par "macro-op fusion".

C'était quand il disait (...) que j'ai compris que les compilateurs optimisaient des petits bouts de codes entiers, spécifiquement pour chaque archi, plutôt que des instructions isolés (pas forcément pour le patch en question, mais d'une manière générale).
Ok, désolé je n'ai pas été claire effectivement. Le Machine Model il sert à déterminer dans quel ordre mettre les instructions et quelles instructions utiliser ensemble pour exploiter efficacement les unités. Mais cela n'implique pas de fusion, il existe plusieurs instructions (ou groupe d'instructions) qui peuvent avoir le même effet. Choisir la meilleure suite d'instructions pour faire une opération est aussi le boulot du compiler.
Et les 2 liens de news de Nicolas parlent bien de cela.

La macro-op fusion cela peut sembler proche, mais cela ne se fait pas au même niveau dans le compiler ni dans le CPU, et le mécanisme est différent. C'est vraiment des patterns d'instructions spécifiques et détecté par le CPU. Et simplement je voulais prendre cette exemple plutôt que le Machine Model car pour le Machine Model on a vraiment des outils tout pour le gérer un peu automatiquement, et donc RISC-V va en profiter plutot directement. Alors que la macro-op fusion il faut écrire un bout de code vraiment spécialisé pour RISC-V.
par _m_, le Mardi 07 Décembre 2021 à 19h13  
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes le Mardi 07 Décembre 2021 à 18h50
Alors j'ai mal dû comprendre ce que tu pointais par "macro-op fusion".

C'était quand il disait
 
certaines séquences d'instructions sont connues pour être spécifiquement plus véloces ou, au contraire, à éviter absolument d'un point de vue des performances.
que j'ai compris que les compilateurs optimisaient des petits bouts de codes entiers, spécifiquement pour chaque archi, plutôt que des instructions isolés (pas forcément pour le patch en question, mais d'une manière générale).
Ici aussi ils en parlaient.
un grand lien tout pourri

Mais donc, ça n'a rien à voir avec le micro-op fusion que toi tu parlais?
Ça se situe entre les deux?

 
Cependant je n'ai que donné un rapide coup d'oeil de 30s au commit, et je ne suis pas un spécialiste de la compile.
C'est déjà beaucoup, merci de t'être donnée cette peine et de partager ton savoir
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Mardi 07 Décembre 2021 à 18h50  
par _m_ le Mardi 07 Décembre 2021 à 18h34
Des explications de Nicolas donnés ici, j'avais compris que les travaux des AMD/Intel consistaient justement en ces "macro-op fusion". Non? Tu penses qu'il s'agit plutôt de la caractérisation d'instructions élémentaires?
Dans la news que tu cites je ne vois pas de mention de la fusion, et dans les sources du commit je ne vois pas non plus de mention de la fusion. Et il semble plutôt clair que ce commit ajoute un nouveau modèle machine en reprécisant les latences de chaque unité et le nombre d'unité.

Cependant je n'ai que donné un rapide coup d'oeil de 30s au commit, et je ne suis pas un spécialiste de la compile. Mais le coeur de mon propos n'était pas de dire que AMD/Intel n'ajoutais jamais de nouvelle macro-fusion a leur uarch. Simplement ils le font rarement et quand ils le font c'est un travail différent que de entrer un autre modèle machine.

Pour RISC-V ce travail n'est pas encore là. L'ajout au compiler n'est pas forcement si complexe que cela (j'exagère un peu dans mon dernier message), et certain ont déjà commencé le travail. Mais le problème c'est que la liste des fusions possible et de leur gain n'est pas encore bien fixé pour RISC-V. Ils ont publié un papier sur une liste de fusion assez simple, et SiFive a breveté d'autres fusions plus avancé. Mais on manque encore d'étude du sujet je pense. La maturité ici n'est pas à gagner que sur le compiler