Pour te répondre ,c'est un processeur généralise où son but est de réduire la surface,donc le coût tout en ayant de bonne performance, en gros de garder une bonne radio perf/prix/simplicité.
je ne vais pas répondre à ta deuxieme partie, parce que je suis d'accord avec toi.
Je répond au premier parce que tu semble pas avoir compris la solution qu'on m'a proposé.
On gros on me demande de faire une palette d'instruction.
Donc déjà une palette demande deux fetch, un pour lire l'index et le suivant le SPM.
Et cela pour compresser les instructions, l'idée n'est pas "idiote", mais mon intuition me dit que c'est une mauvaise idée, je doute qu'on trouve des pattern très semblable.
(et perso un compilateur est déjà compliqué à faire , j'ai pas forcément le temps de tester cette idée :p ).
Non rien n'a voir ,MMX et SSE sont des instructions SIMD.
Superscalaire ,c'est quand tu exécute plusieurs instructions, mais qui n'est pas spécifié par le compilateur.
VLIW c'est le contraire, tu exécute plusieurs instructions spécifié par le compilateur.
Le mélange des deux, c'est surtout pour gérer plusieurs cas, faudrait que j'écris des cas concret pour voir quel problématique je tente de résoudre.
Oui je suis d'accord actuellement l'AltairX n'a pas de faille MeltDown/Spectre.
L'évolution que je voulais mettre n'est pas de l’exécution spéculative, mais surtout que de pouvoir prefetch plus facilement et que le processeur se bloque pas systématique sur un cache miss (qu'il doit du i-cache ou d-cache).
Et c'est là toute la difficulté c'est que je veux faire ça sans faire de l'OoO.
Et surtout je voulais faire un léger réordonnanceur pour les cas plus "compliqué" a gérer, mais loin d’être un truc complexe.
De toute façon de base s'il doit sortir, ça serait dans sa version simplifié dans un premier temps.
Effectivement une solution serait de le proposer à des acteurs qui en ont besoin, que au grand public où on serait directement mis en concurrence avec le x86/ARM/RISC-V !
Cela serait trop complexe pour le compilateur,et on aurait une latence supplémentaire sur le fetch.
Je connais d'ailleurs très bien les palettes de couleurs pour les anciennes consoles parce que je code sur SNES en assembleur et j'ai fait aussi un SDK pour la Neo Geo.
(Mais je code aussi sur PS2 qui elle utilise encore des palette de couleurs).
L'idée qu'on m'avait dite était enfaîte que je ferait un ISA 64 bits pour les instruction plus rare ! :)
Oui, pour ça que je fais pas pas plus que 2 instructions/cycles
Sinon pour ton code, c'est un peu faux, on peut le faire sur 3 cycles (et ça demande pas une grosse implémentation):
A = B E = B
C = D E++
A += C D = E
Et je ne pense pas qu'un OoO fasse mieux ici, pour moi l'avantage d'un OoO est ailleurs.
Elle est sur son exécution spéculative (qui du coup permet un meilleur ILP), sur ces prefetch, sur pouvoir continuer a exécuter du code malgré un cache miss.
Sinon pour le reste un OoO n'apporte pas grand chose comparé à un in order (si le compilo fait son taff).
Alors je ne pense pas que tout faire statiquement soit la solution, pour cela que je voudrais améliorer mon proc pour gérer les 3 cas en haut (de façon différente , mais de le gérer quand même).
Je trouve que l'article est incomplet,il dit que les compilateurs sont pas assez performant parce qu'ils savent pas déplier une boucle.
Alors les compilateurs savent déplier une boucle mais je pense que cette optimisation à été fortement réduite, parce que cela augmente énormément la taille du binaire pour des gains relativement faible dans beaucoup de cas,un compilateur ne sait pas si ta boucle est faite 10,100,10 000 fois.
D'ailleurs son code C est tronqué ,quand il deplis il fait 8 fois, mais le compilateur comment il sait qu'il peut déplier 8 fois ?
Il sait pas du coup s'il doit déplier 8 fois, il va devoir générer beaucoup plus de code au cas où ça serait 10, ou 3, c'est pas des multiples de 8 mais il doit gérer ces cas là.
Bref juste pour dire que oui les compilateurs actuelles sont relativement bon, et donc je considère qu'ils ont fait fait désormais suffisamment de progrès pour qu'on puisse lui donner plus de taches.
Oui l'erreur de l'Itanium est la complexité de faire un compilo performant avec, mais je pense qu'il a brûler trop d'étape, il est parti direct avec 6 instructions/cycles ce qui est énorme, et surtout compliqué à optimiser.
Du coup les gains devait être minime, vu que forcément le I-cache devait pas mal souffrir et que l'IPC devait tourner autour de 2.
Tu as totalement raison.
Et pour être honnête c'est peut être ça, qui a fait que l'idée de mon processeur est resté dans ma tête durant des années sans jamais en parler ni le publier !
Ce qui me chagrine sur ton post ,c'est que ce n'est pas un processeur fait totalement pour le fun.
l'AltairX tente de résoudre un problème :
Le premier proposer des solutions pour abaisser les caches miss.
Le second proposer un processeur haute performante sans aller sur du SuperScalaire Out of Order, ce point est très important parce que le OoO, c'est un peu le boss final, soit on se dit que c'est la seule solution, et donc on se retrouvera toujours avec les mêmes leaders et aussi avec des processeurs qui chauffe beaucoup/consomme beaucoup/coûte cher.
Soit on arrive à proposer une architecture suffisamment bien pensé pour que le compilateur fasse le gros taff et donc allège le hardware et réduit sa consommation.
Et pour avoir la réponse, pas le choix faut mettre les mains dedans, je suis conscient que y'a beaucoup de chance que cela n'ira pas plus loin qu'un FPGA et au mieux une petite carte avec 2/3 entré/sortie.
C'est un peu compliqué,je l'explique un peu ma vision, mais grosso modo, j'aimerais faire un bufferqui stocke les instructions qui ne peuvent pas être exécuter tout de suite, comme ça on peut aller plus loin et exécuter les instructions à l'avance.
C'est assez empirique , mais comme l'AltairX actuelle peut traiter relativement facilement 1-2 instructions/cycle.
Donc le but c'est d’exécuter immédiatement les instruction à porté ,et exécuter les instructions plus loin en parallèle pour augmenter ILP.
Le truc c'est que je travaille sur algorithme et l'implémentation pour faire cela, je taff donc pour le moment avec un papier et un stylo pour avoir une vision plus précise pour faire ça.
Pour cela que j’en dit pas forcément plus , parce que je l'ai pas mis en place et que ce n'est pas finalisé, mais j'ai des brouillons et des idées, mais je veux que tout soit bien fait, donc je prend mon temps.
Le raisonnement est tout simplement la gestion des conversions,je m'explique.
Admettons qu'on fait des calcul en 8 bits (c'est relativement courant).
Si on fait 0xFF + 0x2 cela fait 0x101 , mais cela devrait faire 0x01 non ?
Ce que fait le MIPS (et RISC-V) c'est de faire un AND ensuite , si on renvoie cette valeur en int32 par exemple.
Du coup pour éviter de mettre des AND a chaque conversion de type, j'ai mis cette solution.
Pareil pour les décalage binaires, si on fait 0xFF+ 0x2 ça fait 0x101 , si on décale à droite, on fait quoi ? 0x80 ? alors que ça devrait faire zero. (toujours en 8 bits)
Du coup a part encore faire un AND…
On espérant que j'ai répondu pourquoi à ce choix "étrange" :)
L'avantage , c'est que tu peux mettre des intresics complètement "inventé" , vu qu'on peut ensuite l'implémenté comme en veut
"Intel arrive a avoir 3 ou 4 instructions par cycle, en ayant une pointe à plus de 12 !!"
Alors j'ai pas calculer leur pointe , 3-4 instructions/cycles c'est la moyenne,s'ils ont des pointes à 12, ça veut dire qu'il y'a de gros stall.
En gros si t'as 12 instructions/cycle à un moment et que la moyenne est de 3 , ça veut dire que t'as 3 cycles ou tu ne fais rien.
Et là on parle d'un Intel 10 eme gen minimun.
Du coup autant faire 3 instructions/cycle continu non ?
"Si tu as 4 lectures regitres tu peux avoir une des ALU à 4 entrée par exemple.
Ajouter un adder à un multiplieur ce n'est pas grand chose en taille non plus."
J'ai pas tout compris , mais je ne pense pas que l'espace commentaire (pour un article sur mon SDK sur la Neo Geo) soit aussi le plus adapté pour expliquer tout en détails.
ça m'arrivait d'en mesuré des plus long en -O3,donc pour les optimisations importantes, je met souvent des "attributes" pour mettre des optis spécifique à mes fonctions ,certaine s’optimise plus en -O2 d'autre en -O3.
Faire un ISA 64 bits, c'est déjà un peu le cas ,(pour faire des gros move immediate , pareil pour l'addition/immédiate etc).
Et j'avais pensé peut être le faire avec des SIMD.
Pour 3 instructions toujours à voir, mais le truc, c'est que ça me fait environ 20 bits par instructions, et j'ai 64 registres donc…
non seulement ça prendra pas toute les instructions , mais en plus je suis limité en instruction (bon pour voir sur RISC-V , c'est les instruction basique ADD/SUB et compagnie).
Mais ça me rajoute un décodage à rajouter en plus et un peu plus de Read/write register, du coup ben ça dépend du compilateur.
"Mais avec 4 lectures et 2 écritures de registres, tu peux faire ainsi 2 instructions classiques "
C'est ce que fait le CPU actuellement , il a 2 ALU ,2 FPU ,2 LSU , donc il peut exécuter les deux en // sans soucis.
Et avec le bypass, y'a pas de soucis de RAW/Stall/
Mais oui ,je sais que le bypass explicite est mauvais.
Mais dans tout les cas le VLIW est plutôt mauvais pour évoluer sans tout casser.
ça a son avantage et son inconvénient , on va dire.
Pour être honnête, je pense partir sur un VLIW 2 instruction/cycle boosté à mort (64 registre /bypass) etc etc , déjà c'est pas mal.
Vu que si on arrive à même avoir du 1-2 instructions cycle souvent , ben c'est déjà aussi bon qu'un Intel de 4700 par exemple ! :)
Et pour la suite partir sur un autre avec un ISA/et autre feature pas forcément compatible mais qui pourra monter à 3-4 instruction/cycles.
Et je le rappel que 3-4 instructions/cycle ,tu es bien meilleurs qu'un Intel et AMD ,si t'arrive a tenir ce rhytme d'instructions ;)
"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.
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.
Alors justement je trouve vraiment "mauvais" les vecteur façon RISC-V , et je pense au contraire que ça va vraiment plus causer de soucis qu'autre choses dans l'avenir.
Pas mal se plaint que c'est clairement pas adapté à la façon de comment les gens utilise les instruction SIMD et que souvent l'utilisation est bien plus "particulière".
Mais c'est une critique que je lis souvent : "le RISC-V manque d'un certain pragmatisme".
C'est écrit sur ma page de profil mon discord : Helba#2387 ;)
Alors faire un mode 64 bits 3 instruction pourquoi pas, mais si j'ai abandonné l'idée c'est que c'est très rare d'avoir 3 instructions/cycles et dans ce cas là , je préfère plutôt m'orienter vers un EPIC (qui mélange VLIW et superscalaire).
J'y ai pensé , mais que récemment (genre y'a une ou deux semaines !).
C'est une bonne idée surtout pour les additions multiples !
Surtout pour les immédiates qui était le gros soucis de mon CPU.
Du coup j'ai commencé à rajouté ces petits changements.
Et donc je pense de plus en plus de rajouter un ISA 64 bits vu que celà permet d'apporter un gros plus.
Surtout que plein d'idée me vient à l’esprit notamment aussi pour les instructions SIMD entre autre.
N'hésiter pas à me contacter par mail ou discord pour en parler plus précisément ! :)
Merci pour ton commentaire, et content que je ne suis pas le seul à avoir cet avis ;)
Du coup je pense soit de faire un nouveau interview ici sur mon processeur vu que celà semble intéresser du monde, soit d'en faire un article à voir ! :)
D'abord merci , et content ma critique du RISC-V est intéressante :)
Alors je n'en dit pas assez sur mon proco parce que le but était de parler de la Neo Geo.
J'aurais pu en parler sur Twitter, mais pas grand fan de twitter.
J'en parle plus ou moins souvent sur un Discord (le serveur NaN).
Du coup je pense soit de faire un nouveau interview ici sur mon processeur, soit d'en faire un article à voir ! :)
C'est un peu le défaut de la Neo Geo, on ne peut pas générer d'image avec, malgré que c'est un "monstre de la 2D", donc sur certain point elle peut faire moins qu'une SNES/Mega Drive.
# Les chiffres peuvent tout dire et rien dire
Posté par Kannagichan . En réponse à la dépêche Linux atteint pour la première fois 3% de part de marché sur les PC. Évalué à 2.
Dommage qu'on ne peut pas expliquer ces chiffres.
Qui sont les 68.15% de Windowsien ?
Par exemple si on regarde par continent , l'Europe , l'Afrique , l'amérique du Sud sont à plus de 70% de Windows.
Et seul l’Amérique sont vraiment en dessous (56%) et l’Asie avec 64%.
Voilà , pas pour dire que les stats sont faux , mais j'ai un peu du mal à les analyser.
[^] # Re: ISA belle a les yeux bleux, les yeux bleux ISA bella
Posté par Kannagichan . En réponse à la dépêche AltairX : le processeur du futur ?. Évalué à 3.
Merci pour ton commentaire.
Pour te répondre ,c'est un processeur généralise où son but est de réduire la surface,donc le coût tout en ayant de bonne performance, en gros de garder une bonne radio perf/prix/simplicité.
[^] # Re: "Palette d'instruction": solution au nombre limité d'instructions?
Posté par Kannagichan . En réponse à la dépêche AltairX : le processeur du futur ?. Évalué à 1. Dernière modification le 04 juillet 2023 à 20:05.
je ne vais pas répondre à ta deuxieme partie, parce que je suis d'accord avec toi.
Je répond au premier parce que tu semble pas avoir compris la solution qu'on m'a proposé.
On gros on me demande de faire une palette d'instruction.
Donc déjà une palette demande deux fetch, un pour lire l'index et le suivant le SPM.
Et cela pour compresser les instructions, l'idée n'est pas "idiote", mais mon intuition me dit que c'est une mauvaise idée, je doute qu'on trouve des pattern très semblable.
(et perso un compilateur est déjà compliqué à faire , j'ai pas forcément le temps de tester cette idée :p ).
[^] # Re: Ok, le hardware pourrait être fait, mais le software ?
Posté par Kannagichan . En réponse à la dépêche AltairX : le processeur du futur ?. Évalué à 3.
Non rien n'a voir ,MMX et SSE sont des instructions SIMD.
Superscalaire ,c'est quand tu exécute plusieurs instructions, mais qui n'est pas spécifié par le compilateur.
VLIW c'est le contraire, tu exécute plusieurs instructions spécifié par le compilateur.
Le mélange des deux, c'est surtout pour gérer plusieurs cas, faudrait que j'écris des cas concret pour voir quel problématique je tente de résoudre.
[^] # Re: Merci
Posté par Kannagichan . En réponse à la dépêche AltairX : le processeur du futur ?. Évalué à 2.
Oui je suis d'accord actuellement l'AltairX n'a pas de faille MeltDown/Spectre.
L'évolution que je voulais mettre n'est pas de l’exécution spéculative, mais surtout que de pouvoir prefetch plus facilement et que le processeur se bloque pas systématique sur un cache miss (qu'il doit du i-cache ou d-cache).
Et c'est là toute la difficulté c'est que je veux faire ça sans faire de l'OoO.
Et surtout je voulais faire un léger réordonnanceur pour les cas plus "compliqué" a gérer, mais loin d’être un truc complexe.
De toute façon de base s'il doit sortir, ça serait dans sa version simplifié dans un premier temps.
[^] # Re: maquettage ou prototype
Posté par Kannagichan . En réponse à la dépêche AltairX : le processeur du futur ?. Évalué à 2.
Si tu le met sur FPGA, tu peux donc le test et voir ces performance réels
Donc un prototype sur FPGA donne une idée oui de ce que ça donnerai,surtout si il entre sur un FPGA grand public.
[^] # Re: Débouchés?
Posté par Kannagichan . En réponse à la dépêche AltairX : le processeur du futur ?. Évalué à 4.
Merci pour ton commentaire.
Effectivement une solution serait de le proposer à des acteurs qui en ont besoin, que au grand public où on serait directement mis en concurrence avec le x86/ARM/RISC-V !
Le truc c'est à qui s'adresser ?
[^] # Re: "Palette d'instruction": solution au nombre limité d'instructions?
Posté par Kannagichan . En réponse à la dépêche AltairX : le processeur du futur ?. Évalué à 2.
Cela serait trop complexe pour le compilateur,et on aurait une latence supplémentaire sur le fetch.
Je connais d'ailleurs très bien les palettes de couleurs pour les anciennes consoles parce que je code sur SNES en assembleur et j'ai fait aussi un SDK pour la Neo Geo.
(Mais je code aussi sur PS2 qui elle utilise encore des palette de couleurs).
L'idée qu'on m'avait dite était enfaîte que je ferait un ISA 64 bits pour les instruction plus rare ! :)
Solution plus simple et moins contraignante ! :D
[^] # Re: Ok, le hardware pourrait être fait, mais le software ?
Posté par Kannagichan . En réponse à la dépêche AltairX : le processeur du futur ?. Évalué à 4. Dernière modification le 22 juin 2023 à 15:05.
Oui, pour ça que je fais pas pas plus que 2 instructions/cycles
Sinon pour ton code, c'est un peu faux, on peut le faire sur 3 cycles (et ça demande pas une grosse implémentation):
A = B E = B
C = D E++
A += C D = E
Et je ne pense pas qu'un OoO fasse mieux ici, pour moi l'avantage d'un OoO est ailleurs.
Elle est sur son exécution spéculative (qui du coup permet un meilleur ILP), sur ces prefetch, sur pouvoir continuer a exécuter du code malgré un cache miss.
Sinon pour le reste un OoO n'apporte pas grand chose comparé à un in order (si le compilo fait son taff).
Alors je ne pense pas que tout faire statiquement soit la solution, pour cela que je voudrais améliorer mon proc pour gérer les 3 cas en haut (de façon différente , mais de le gérer quand même).
[^] # Re: Ok, le hardware pourrait être fait, mais le software ?
Posté par Kannagichan . En réponse à la dépêche AltairX : le processeur du futur ?. Évalué à 3.
Je trouve que l'article est incomplet,il dit que les compilateurs sont pas assez performant parce qu'ils savent pas déplier une boucle.
Alors les compilateurs savent déplier une boucle mais je pense que cette optimisation à été fortement réduite, parce que cela augmente énormément la taille du binaire pour des gains relativement faible dans beaucoup de cas,un compilateur ne sait pas si ta boucle est faite 10,100,10 000 fois.
D'ailleurs son code C est tronqué ,quand il deplis il fait 8 fois, mais le compilateur comment il sait qu'il peut déplier 8 fois ?
Il sait pas du coup s'il doit déplier 8 fois, il va devoir générer beaucoup plus de code au cas où ça serait 10, ou 3, c'est pas des multiples de 8 mais il doit gérer ces cas là.
Bref juste pour dire que oui les compilateurs actuelles sont relativement bon, et donc je considère qu'ils ont fait fait désormais suffisamment de progrès pour qu'on puisse lui donner plus de taches.
Oui l'erreur de l'Itanium est la complexité de faire un compilo performant avec, mais je pense qu'il a brûler trop d'étape, il est parti direct avec 6 instructions/cycles ce qui est énorme, et surtout compliqué à optimiser.
Du coup les gains devait être minime, vu que forcément le I-cache devait pas mal souffrir et que l'IPC devait tourner autour de 2.
[^] # Re: Ok, le hardware pourrait être fait, mais le software ?
Posté par Kannagichan . En réponse à la dépêche AltairX : le processeur du futur ?. Évalué à 10.
Tu as totalement raison.
Et pour être honnête c'est peut être ça, qui a fait que l'idée de mon processeur est resté dans ma tête durant des années sans jamais en parler ni le publier !
Ce qui me chagrine sur ton post ,c'est que ce n'est pas un processeur fait totalement pour le fun.
l'AltairX tente de résoudre un problème :
Le premier proposer des solutions pour abaisser les caches miss.
Le second proposer un processeur haute performante sans aller sur du SuperScalaire Out of Order, ce point est très important parce que le OoO, c'est un peu le boss final, soit on se dit que c'est la seule solution, et donc on se retrouvera toujours avec les mêmes leaders et aussi avec des processeurs qui chauffe beaucoup/consomme beaucoup/coûte cher.
Soit on arrive à proposer une architecture suffisamment bien pensé pour que le compilateur fasse le gros taff et donc allège le hardware et réduit sa consommation.
Et pour avoir la réponse, pas le choix faut mettre les mains dedans, je suis conscient que y'a beaucoup de chance que cela n'ira pas plus loin qu'un FPGA et au mieux une petite carte avec 2/3 entré/sortie.
[^] # Re: Merci
Posté par Kannagichan . En réponse à la dépêche AltairX : le processeur du futur ?. Évalué à 5.
C'est un peu compliqué,je l'explique un peu ma vision, mais grosso modo, j'aimerais faire un bufferqui stocke les instructions qui ne peuvent pas être exécuter tout de suite, comme ça on peut aller plus loin et exécuter les instructions à l'avance.
C'est assez empirique , mais comme l'AltairX actuelle peut traiter relativement facilement 1-2 instructions/cycle.
Donc le but c'est d’exécuter immédiatement les instruction à porté ,et exécuter les instructions plus loin en parallèle pour augmenter ILP.
Le truc c'est que je travaille sur algorithme et l'implémentation pour faire cela, je taff donc pour le moment avec un papier et un stylo pour avoir une vision plus précise pour faire ça.
Pour cela que j’en dit pas forcément plus , parce que je l'ai pas mis en place et que ce n'est pas finalisé, mais j'ai des brouillons et des idées, mais je veux que tout soit bien fait, donc je prend mon temps.
[^] # Re: Champ de taille des opérations dans les instructions?
Posté par Kannagichan . En réponse à la dépêche AltairX : le processeur du futur ?. Évalué à 5. Dernière modification le 22 juin 2023 à 09:33.
Le raisonnement est tout simplement la gestion des conversions,je m'explique.
Admettons qu'on fait des calcul en 8 bits (c'est relativement courant).
Si on fait 0xFF + 0x2 cela fait 0x101 , mais cela devrait faire 0x01 non ?
Ce que fait le MIPS (et RISC-V) c'est de faire un AND ensuite , si on renvoie cette valeur en int32 par exemple.
Du coup pour éviter de mettre des AND a chaque conversion de type, j'ai mis cette solution.
Pareil pour les décalage binaires, si on fait 0xFF+ 0x2 ça fait 0x101 , si on décale à droite, on fait quoi ? 0x80 ? alors que ça devrait faire zero. (toujours en 8 bits)
Du coup a part encore faire un AND…
On espérant que j'ai répondu pourquoi à ce choix "étrange" :)
[^] # Re: altairx
Posté par Kannagichan . En réponse à la dépêche Entretien avec Kannagi à propos de NGDK. Évalué à 1.
Oh top !
J'adore le titre _^
[^] # Re: altairx
Posté par Kannagichan . En réponse à la dépêche Entretien avec Kannagi à propos de NGDK. Évalué à 1.
"Cela ne suffit pas quand un simple load te prend 80 cycles."
Si tu es un tel cas , je pense pas que le VLIW 8 instructions/cycle soit la solutions ;)
Ce qui permet d’exécuter autant c'est parce qu'il a un window + exécution dans le désordre.
"C'est pas faux. L'idée est d'avoir des unités de calcul qui ne se limite pas à 2 entrées."
Ok je comprend ! ;)
[^] # Re: altairx
Posté par Kannagichan . En réponse à la dépêche Entretien avec Kannagi à propos de NGDK. Évalué à 1.
"Tu peux aussi inventer un concept d'ISA compatible après re compilation mais avec des éléments d'architectures fixes."
Oui c'est mon idée en long terme !
Et j'y travaille , je l'ai mis ici :
https://docs.google.com/spreadsheets/d/19nOBbH_4KWaXxDSNA4JuZjaBble0VRrBxcVlEjTZ3iI/edit
L'avantage , c'est que tu peux mettre des intresics complètement "inventé" , vu qu'on peut ensuite l'implémenté comme en veut
"Intel arrive a avoir 3 ou 4 instructions par cycle, en ayant une pointe à plus de 12 !!"
Alors j'ai pas calculer leur pointe , 3-4 instructions/cycles c'est la moyenne,s'ils ont des pointes à 12, ça veut dire qu'il y'a de gros stall.
En gros si t'as 12 instructions/cycle à un moment et que la moyenne est de 3 , ça veut dire que t'as 3 cycles ou tu ne fais rien.
Et là on parle d'un Intel 10 eme gen minimun.
Du coup autant faire 3 instructions/cycle continu non ?
"Si tu as 4 lectures regitres tu peux avoir une des ALU à 4 entrée par exemple.
Ajouter un adder à un multiplieur ce n'est pas grand chose en taille non plus."
J'ai pas tout compris , mais je ne pense pas que l'espace commentaire (pour un article sur mon SDK sur la Neo Geo) soit aussi le plus adapté pour expliquer tout en détails.
[^] # Re: altairx
Posté par Kannagichan . En réponse à la dépêche Entretien avec Kannagi à propos de NGDK. Évalué à 1.
ça m'arrivait d'en mesuré des plus long en -O3,donc pour les optimisations importantes, je met souvent des "attributes" pour mettre des optis spécifique à mes fonctions ,certaine s’optimise plus en -O2 d'autre en -O3.
Faire un ISA 64 bits, c'est déjà un peu le cas ,(pour faire des gros move immediate , pareil pour l'addition/immédiate etc).
Et j'avais pensé peut être le faire avec des SIMD.
Pour 3 instructions toujours à voir, mais le truc, c'est que ça me fait environ 20 bits par instructions, et j'ai 64 registres donc…
non seulement ça prendra pas toute les instructions , mais en plus je suis limité en instruction (bon pour voir sur RISC-V , c'est les instruction basique ADD/SUB et compagnie).
Mais ça me rajoute un décodage à rajouter en plus et un peu plus de Read/write register, du coup ben ça dépend du compilateur.
"Mais avec 4 lectures et 2 écritures de registres, tu peux faire ainsi 2 instructions classiques "
C'est ce que fait le CPU actuellement , il a 2 ALU ,2 FPU ,2 LSU , donc il peut exécuter les deux en // sans soucis.
Et avec le bypass, y'a pas de soucis de RAW/Stall/
Mais oui ,je sais que le bypass explicite est mauvais.
Mais dans tout les cas le VLIW est plutôt mauvais pour évoluer sans tout casser.
ça a son avantage et son inconvénient , on va dire.
Pour être honnête, je pense partir sur un VLIW 2 instruction/cycle boosté à mort (64 registre /bypass) etc etc , déjà c'est pas mal.
Vu que si on arrive à même avoir du 1-2 instructions cycle souvent , ben c'est déjà aussi bon qu'un Intel de 4700 par exemple ! :)
Et pour la suite partir sur un autre avec un ISA/et autre feature pas forcément compatible mais qui pourra monter à 3-4 instruction/cycles.
Et je le rappel que 3-4 instructions/cycle ,tu es bien meilleurs qu'un Intel et AMD ,si t'arrive a tenir ce rhytme d'instructions ;)
[^] # 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.
[^] # 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.
[^] # Re: altairx
Posté par Kannagichan . En réponse à la dépêche Entretien avec Kannagi à propos de NGDK. Évalué à 1.
Alors justement je trouve vraiment "mauvais" les vecteur façon RISC-V , et je pense au contraire que ça va vraiment plus causer de soucis qu'autre choses dans l'avenir.
Pas mal se plaint que c'est clairement pas adapté à la façon de comment les gens utilise les instruction SIMD et que souvent l'utilisation est bien plus "particulière".
Mais c'est une critique que je lis souvent : "le RISC-V manque d'un certain pragmatisme".
C'est écrit sur ma page de profil mon discord : Helba#2387 ;)
Alors faire un mode 64 bits 3 instruction pourquoi pas, mais si j'ai abandonné l'idée c'est que c'est très rare d'avoir 3 instructions/cycles et dans ce cas là , je préfère plutôt m'orienter vers un EPIC (qui mélange VLIW et superscalaire).
[^] # Re: altairx
Posté par Kannagichan . En réponse à la dépêche Entretien avec Kannagi à propos de NGDK. Évalué à 1.
J'y ai pensé , mais que récemment (genre y'a une ou deux semaines !).
C'est une bonne idée surtout pour les additions multiples !
Surtout pour les immédiates qui était le gros soucis de mon CPU.
Du coup j'ai commencé à rajouté ces petits changements.
Et donc je pense de plus en plus de rajouter un ISA 64 bits vu que celà permet d'apporter un gros plus.
Surtout que plein d'idée me vient à l’esprit notamment aussi pour les instructions SIMD entre autre.
N'hésiter pas à me contacter par mail ou discord pour en parler plus précisément ! :)
[^] # Re: À propos du projet CPU
Posté par Kannagichan . En réponse à la dépêche Entretien avec Kannagi à propos de NGDK. Évalué à 5.
Merci pour ton commentaire, et content que je ne suis pas le seul à avoir cet avis ;)
Du coup je pense soit de faire un nouveau interview ici sur mon processeur vu que celà semble intéresser du monde, soit d'en faire un article à voir ! :)
[^] # Re: Quelques coquilles et interrogations
Posté par Kannagichan . En réponse à la dépêche Entretien avec Kannagi à propos de NGDK. Évalué à 3.
Oui, je suis un peu curieux des retours _^
D'abord merci , et content ma critique du RISC-V est intéressante :)
Alors je n'en dit pas assez sur mon proco parce que le but était de parler de la Neo Geo.
J'aurais pu en parler sur Twitter, mais pas grand fan de twitter.
J'en parle plus ou moins souvent sur un Discord (le serveur NaN).
Du coup je pense soit de faire un nouveau interview ici sur mon processeur, soit d'en faire un article à voir ! :)
[^] # Re: Quelques coquilles et interrogations
Posté par Kannagichan . En réponse à la dépêche Entretien avec Kannagi à propos de NGDK. Évalué à 5.
"Le PC-88 et PC-98 sont des ordinateurs, pas des processeurs."
Oui , il faudra le corrigé, c'est un lapsus de ma part ! ;)
[^] # Re: Quelques coquilles et interrogations
Posté par Kannagichan . En réponse à la dépêche Entretien avec Kannagi à propos de NGDK. Évalué à 5. Dernière modification le 25 mai 2023 à 19:08.
Tu as parfaitement répondu :)
C'est un peu le défaut de la Neo Geo, on ne peut pas générer d'image avec, malgré que c'est un "monstre de la 2D", donc sur certain point elle peut faire moins qu'une SNES/Mega Drive.