Alors Intel ou AMD ont 4 ALU (et je crois que Intel ont 5 ALU) et au total ils peuvent "théoriquement" faire du 12-16 instructions/cycles.
Pourtant si tu mesure, tu n'aura jamais 12-16 instructions/cycle.
Et même les 3 instructions/cycle qu'il arrivent à fournir sont pas fait de façon statique ! :)
Et donc c'est pas avec du simple VLIW que tu arrivera à faire 3 instructions/cycle.
(Je ne dis pas que tu peux pas en faire, mais le cas sera rare).
Alors un VLIW , c'est pas en général 8, et à vrai dire 8 instructions/cycles ,c'est totalement inutile (sauf pour un DSP et encore) , le VLIW de la PS3 (le CELL ) c'était 2 instructions/cycles.
Et J'avais vu que celui de Crusoe c'était 4 bref.
Le truc c'est que je viens d'écrire un article pour linuxfr qui expliquera tout cela , mais oui si j'ai envie je peux très bien faire 8 instructions/cycle, c'est pas très compliqué et je fumerais n'importe quel AMD et Intel dernière gen !
Si c'était aussi simple tout le monde le ferait ! :D
Non le truc c'est que tu n'extrairera jamais autant de parallélisme sur du code, j'avais lu un gars de chez IBM qui disait que sur le code de Linux il arrivait pas à extraire plus de 2 instructions/cycle.
Surtout que 8 instructions/cycle ,c'est peu probable , on considère que tu as 20% de code qui sert pour les boucles.
Donc techniquement les 8 instructions serait du code séquentiel.
Meme un simple code comme :
if (a == b)
return 1;
else
return 0;
Tu le rentrera jamais sur un bundle de 8 instructions/cycle ;)
Pour la montée en fréquence , c'est pas tant le soucis de son ISA ou de son architecture, mais je pense que son fetch élevé le ralentisser tout simplement dans la montée en fréquence.
Je pense qu'ils ont visé beaucoup trop haut pour l'itanium (faire du 6/9 instructions/cycle est complètement fou).
.
Alors il était quand même pensé pour du conditionnal move, mais ça gonflait un peu le nombre d'instructions, vu le nombre d'itinération à faire.
Le soucis des vecteurs variables risc v ,c'est que c'est bien pour des boucles d'instruction SIMD , regarde juste un peu les pratiques des instructions SIMD , leur cas sont bien plus différents que les exemples que RISC-V fasse.
De ce que j'ai compris, le gars a bien aimé les ordinateur sous cray et tente de refaire ça sur RISC-V, c'est cool , mais de là à dire que ça fait mieux que du SIMD bof.
Je pense personnellement que l'handicapera parce que souvent les instruction SIMD et non SIMD sont mélanger et surtout, ils sont pas forcément utilisé dans des boucles toute faite.
Un compilateur actuel peut te mettre du SIMD pour un simple bout de code sur du x86 ou de l'ARM (Neon).
Les vecteur RISC-V seront incapable de faire ça ,vu qu'ils sont pas pensé pour cela.
[^] # Re: altairx
Posté par Kannagichan . En réponse à la dépêche Entretien avec Kannagi à propos de NGDK. Évalué à 2.
Alors Intel ou AMD ont 4 ALU (et je crois que Intel ont 5 ALU) et au total ils peuvent "théoriquement" faire du 12-16 instructions/cycles.
Pourtant si tu mesure, tu n'aura jamais 12-16 instructions/cycle.
Et même les 3 instructions/cycle qu'il arrivent à fournir sont pas fait de façon statique ! :)
Et donc c'est pas avec du simple VLIW que tu arrivera à faire 3 instructions/cycle.
(Je ne dis pas que tu peux pas en faire, mais le cas sera rare).
Alors un VLIW , c'est pas en général 8, et à vrai dire 8 instructions/cycles ,c'est totalement inutile (sauf pour un DSP et encore) , le VLIW de la PS3 (le CELL ) c'était 2 instructions/cycles.
Et J'avais vu que celui de Crusoe c'était 4 bref.
Le truc c'est que je viens d'écrire un article pour linuxfr qui expliquera tout cela , mais oui si j'ai envie je peux très bien faire 8 instructions/cycle, c'est pas très compliqué et je fumerais n'importe quel AMD et Intel dernière gen !
Si c'était aussi simple tout le monde le ferait ! :D
Non le truc c'est que tu n'extrairera jamais autant de parallélisme sur du code, j'avais lu un gars de chez IBM qui disait que sur le code de Linux il arrivait pas à extraire plus de 2 instructions/cycle.
Surtout que 8 instructions/cycle ,c'est peu probable , on considère que tu as 20% de code qui sert pour les boucles.
Donc techniquement les 8 instructions serait du code séquentiel.
Meme un simple code comme :
if (a == b)
return 1;
else
return 0;
Tu le rentrera jamais sur un bundle de 8 instructions/cycle ;)
Pour la montée en fréquence , c'est pas tant le soucis de son ISA ou de son architecture, mais je pense que son fetch élevé le ralentisser tout simplement dans la montée en fréquence.
Je pense qu'ils ont visé beaucoup trop haut pour l'itanium (faire du 6/9 instructions/cycle est complètement fou).
.
Alors il était quand même pensé pour du conditionnal move, mais ça gonflait un peu le nombre d'instructions, vu le nombre d'itinération à faire.
Le soucis des vecteurs variables risc v ,c'est que c'est bien pour des boucles d'instruction SIMD , regarde juste un peu les pratiques des instructions SIMD , leur cas sont bien plus différents que les exemples que RISC-V fasse.
De ce que j'ai compris, le gars a bien aimé les ordinateur sous cray et tente de refaire ça sur RISC-V, c'est cool , mais de là à dire que ça fait mieux que du SIMD bof.
Je pense personnellement que l'handicapera parce que souvent les instruction SIMD et non SIMD sont mélanger et surtout, ils sont pas forcément utilisé dans des boucles toute faite.
Un compilateur actuel peut te mettre du SIMD pour un simple bout de code sur du x86 ou de l'ARM (Neon).
Les vecteur RISC-V seront incapable de faire ça ,vu qu'ils sont pas pensé pour cela.