"2, 3 ou 4 instructions, c'est plus LIW. Cela n'est pas vraiment "very large"."
La définition est valide pour tout les processeurs faisant plus que un, le CELL est VLIW , le crusoe aussi, même s'il ne font que 2 et 4 respectivement.
Si les DSP font bien plus, c'est parce qu'ils traitent des données bien particuliers.
C'est un peu le soucis des processeurs généraliste, un VLIW à 8 est overkill.
A la base mon processeur était pensé pour du 4 instructions, pourquoi j'ai abandonné cette idée ?
Parce que comme je te l'ai dit, sur du code, c'est compliqué d'extraire autant de parallélisme.
Donc ce que tu dis j'y ai pensé , mais j'ai abandonné l'idée pourquoi ?
Parce que de un ,j'ai pas de compilateur qui fournit 4 instructions/cycle,donc pourquoi le mettre , surtout que cela complexifierai pas mal de chose :
Je dois faire beaucoup de Multiplexing
Mon read/write register est doublé
Je dois mettre plus d'unité de calcul
-je dois fetch plus
-aucun gain sur les conditions (qui représente quand même 25% du code)
La fabrication de processeur, c'est pas rajouter et dire "ça va ,plus c'est gros , plus ça passe" , je suis pas Intel et je ne pourrais pas graver un gros processeur,donc je dois choisir un truc "raisonnable", et intéressante.
Et donc sur 2 instructions, non seulement le processeur est simpliste, mais en plus le compilateur le gère parfaitement bien.
Alors je pourrais le faire évolué par la suite à un bundle de 4, le processeur est pensé pour ,vu que de base j'étais parti sur ça (j'ai fait 4 -> 2 pour être exact).
Mais comme faire 4 instructions par bundle complexifierai un peu le processeur, je me suis dit autant partir sur quelque chose de plus efficace, de gérer 2 instructions statiquement et 2 dynamiquement.
Je pourrais pas forcément tout expliqué en détails ici de ce choix , mais pour moi , c'est complètement illusoire de penser gérer tout les cas de façon purement statique (et pourtant j'étais persuadé que y'avait moyen).
Alors je ne suis pas vraiment fermé à un 3 instructions/64 bits , mais faudra faire une analyse du compilateur et voir quand il peut en fournir et avec quel pattern d'instruction.
"Tu peux augmenter l'ilp en faisant des instructions étudiées pour diminuer les dépendances read after write."
Alors mon processeur peut éviter le RAW assez simplement, parce que les bypass sont explicite ;)
Pour cela aussi que 2 instructions/cycle est parfaitement gérer, parce que les RAW sont facilement évitable sur mon proc.
Et sinon les dépliages de 16 sont une abération, si tu regarde les optis -O2 est souvent bien plus efficace que le -O3.
Si tu déplie la moindre boucle, tu gonfle le nombre d'instruction ,donc le i-cache en souffre, et si la boucle n'est pas assez grosse, le gain est négatif.
Alors oui ,en VLIW t'as pas trop le choix de partir sur ce point là , mais comme mon but est de trouver d'autre solution aussi, je trouve cela dommage de déplier une boucle de 16 alors que avec quelque info donné sur le processeur,il peut le faire tout seul comme un grand :)
Voilà mais j'expliquerai vraiment tout ça en détails sur un prochain article.
[^] # Re: altairx
Posté par Kannagichan . En réponse à la dépêche Entretien avec Kannagi à propos de NGDK. Évalué à 1. Dernière modification le 29 mai 2023 à 14:04.
"2, 3 ou 4 instructions, c'est plus LIW. Cela n'est pas vraiment "very large"."
La définition est valide pour tout les processeurs faisant plus que un, le CELL est VLIW , le crusoe aussi, même s'il ne font que 2 et 4 respectivement.
Si les DSP font bien plus, c'est parce qu'ils traitent des données bien particuliers.
C'est un peu le soucis des processeurs généraliste, un VLIW à 8 est overkill.
A la base mon processeur était pensé pour du 4 instructions, pourquoi j'ai abandonné cette idée ?
Parce que comme je te l'ai dit, sur du code, c'est compliqué d'extraire autant de parallélisme.
Donc ce que tu dis j'y ai pensé , mais j'ai abandonné l'idée pourquoi ?
Parce que de un ,j'ai pas de compilateur qui fournit 4 instructions/cycle,donc pourquoi le mettre , surtout que cela complexifierai pas mal de chose :
Je dois faire beaucoup de Multiplexing
Mon read/write register est doublé
Je dois mettre plus d'unité de calcul
-je dois fetch plus
-aucun gain sur les conditions (qui représente quand même 25% du code)
La fabrication de processeur, c'est pas rajouter et dire "ça va ,plus c'est gros , plus ça passe" , je suis pas Intel et je ne pourrais pas graver un gros processeur,donc je dois choisir un truc "raisonnable", et intéressante.
Et donc sur 2 instructions, non seulement le processeur est simpliste, mais en plus le compilateur le gère parfaitement bien.
Alors je pourrais le faire évolué par la suite à un bundle de 4, le processeur est pensé pour ,vu que de base j'étais parti sur ça (j'ai fait 4 -> 2 pour être exact).
Mais comme faire 4 instructions par bundle complexifierai un peu le processeur, je me suis dit autant partir sur quelque chose de plus efficace, de gérer 2 instructions statiquement et 2 dynamiquement.
Je pourrais pas forcément tout expliqué en détails ici de ce choix , mais pour moi , c'est complètement illusoire de penser gérer tout les cas de façon purement statique (et pourtant j'étais persuadé que y'avait moyen).
Alors je ne suis pas vraiment fermé à un 3 instructions/64 bits , mais faudra faire une analyse du compilateur et voir quand il peut en fournir et avec quel pattern d'instruction.
"Tu peux augmenter l'ilp en faisant des instructions étudiées pour diminuer les dépendances read after write."
Alors mon processeur peut éviter le RAW assez simplement, parce que les bypass sont explicite ;)
Pour cela aussi que 2 instructions/cycle est parfaitement gérer, parce que les RAW sont facilement évitable sur mon proc.
Et sinon les dépliages de 16 sont une abération, si tu regarde les optis -O2 est souvent bien plus efficace que le -O3.
Si tu déplie la moindre boucle, tu gonfle le nombre d'instruction ,donc le i-cache en souffre, et si la boucle n'est pas assez grosse, le gain est négatif.
Alors oui ,en VLIW t'as pas trop le choix de partir sur ce point là , mais comme mon but est de trouver d'autre solution aussi, je trouve cela dommage de déplier une boucle de 16 alors que avec quelque info donné sur le processeur,il peut le faire tout seul comme un grand :)
Voilà mais j'expliquerai vraiment tout ça en détails sur un prochain article.