Je m'excuse pour le titre , mais c'est souvent comme ça quand on présente un nouveau processeur en général !
Depuis pas mal d'années que je programme en assembleur que je m’amuse a tester un nombre incalculable de processeur et de machine. A force , j'ai eu ma vision du proc (et de l'ordinateur) "idéale".
Pas que mon idée naîtra un jour , mais disons que j'aimerais avoir l'avis de connaisseurs , je n'ai pas envie de créer une machine "fantaisiste" qui serait irréalisable. Le but est surtout de créer un émulateur pour pouvoir le tester avec au plus proche des contraintes réel, et savoir que mon idée est bonne (ou pas) me satisfera dans les deux grandement
J'explique un peu les termes : VLIW , un type d'architecture ,comme le CISC ou le RISC *OoO = Out of Order , technique d'optimisation de la pipeline "automatique" *in order , c'est le contraire , aucune optimisation et le compilo le gère lui même en partie. *superscalaire , technique pour exécuter plusieurs instructions en même temps (pour vulgariser en quelque ligne).
Alors mon idée est de faire un proc VLIW , et là ceux qui connaisse l'histoire de l'informatique font me dire "oulà , c'est casse gueule" , oui je suis pas le premier à avoir essayer Sony (avec l'Emotion Engine de la PS2 , le CELL avec la PS3) , Intel (avec la gamme Itanium) , ou même le fameux Transmeta (Crusoe et Efficeon) qu avait fait beaucoup parlé de lui à l'époque (notamment qu'il faisait de la conversion du x86 /VLIW à la volée ). Bref aucun a vraiment bien marché et tous ont eu le même point commun , un proc complexe à programmer ,et celui que je vais vous présenter ne fera pas exception , mais la différence c'est que de nos jours on a Clang et qu'il permet de faire du code intermédiaire suffisamment intéressant pour pouvoir à mon avis , le transformer et l'optimiser sur un proc plus "exotique".
Je répondrais à une question si on me dit "mais pourquoi ne pas utiliser RISC-V ?", eh ben parce que de un ,je veux pas faire du RISC , et secundu , le souci de faire du RISC-V à mon sens ,et que toute l'optimisation du proc ne fait pas partie de l'ISA , et je dirai qu'il est à mon avis peu probable qu'on aurait en open source un code Verilog ou VHDL avec de l'OoO plus performant que Intel ou AMD. Et bien sur ben je ne veux pas faire de OoO , et le in order superscalaire pour l'avoir fait sur de nombreux proc , me semble évident que ça ne sera pas la façon la plus performante pour faire un proc.
Alors pour revenir sur le proc , c'est un proc qui veut simplifier le design du proc au maximun , mais aussi d'atteindre au mieux les chiffres théorique , et pour cela les consoles de Sony donne une partie de la solution , il faut pouvoir précharger au cache en même temps que l’exécution (cela veut dire que le compilo ou le programmeur gère le cache). Et si c'est bien foutu , on peut éviter la plupart des "caches miss". Alors ici je parle de façon vulgariser , ça serait faux de parler de cache , en général on parle juste de mémoire SRAM interne ou de scrachpad. Et l'itanium était une bonne idée de pouvoir rendre le VLIW un peu plus "dynamique" , le soucis du VLIW qui est trop statique , c'est qu’on a tendance à mettre pas mal d'instruction "nop" et donc le cache en souffre pas mal. Donc j'ai fait en sorte qu'on puisse changer un peu le nombre d'instruction qu'on exécute en parallèle. Un autre point , c'est que une mémoire gérer par le programmeur ne peut pas gérer tout les cas ,donc j'ai inclus aussi une mémoire cache "normal" (bon je dis "normal" , mais c'est surtout que je ne veux pas qu'elle soit trop lente , même si cela veut dire réduire les optimisations qu'on puisse faire dessus).
Pour donner une image de ce que ça donne :
(et du coup c'est bien plus simple qu'un Intel ou AMD Zen 2 Superscalaire Out of Order) : https://en.wikichip.org/wiki/File:zen_2_core_diagram.svg
L'avantage de ce genre d'architecture c'est que ça réduit de beaucoup le nombre de transistor , ça simplifie beaucoup aussi sa conception , et donc on gagne aussi en terme de dissipation de chaleur et de watts consommé , tout en ayant (normalement ) des très bonnes perfs
J'ai mis ici 128Kio de SRAM parce que la façon de programmer sur ce genre de machine et de faire un double buffer. Je m'explique vous utilisez la moitié (64 Kio) , et pendant que vous faite vos calcul tranquille dessus , vous préchargez les donner suivante dans l'autre buffer ,sans que cela stop le CPU , donc comme ça ,vous perdez aucun temps pour vos calcul quand vous voulez lire la RAM (et ainsi de suite , vous switcher entre les deux buffers). tout cela se fait via un DMA (que j'ai pas préciser ici mais que le MMU est collé sur le DMA , vu que c'est le seul point d'entrée/sortie)
Pour la prédiction de branchement il n'y en n'a pas , comme le montre le graphisme , le branchement (ou un call/ret) se fait sur le decode , donc il se fait sur 1 cycle + 1 cycle de delay. Cette optimisation existe depuis longtemps , mais elle à été "abandonné" , parce qu'elle est complexe à mettre en place (surtout sur un x86 ou le decode se fait en plusieurs cycles ). C'est une optimisation qui ne peut se faire que sur un proc très "simple" (la plupart des processeurs MIPS ayant cette optimisation).
Pour la pipeline , je vise un truc en 2 + 4-8 stages :
IF : Fetch (load opcode Memory SRAM instruction)
ID : decode instruction / load register flag
RR : Read Register
EX : execution
MEM : L/S memory SRAM data
WB : write back ( write register)
loadm/storem 6+ cycle (rr,exe,mem,dma,---,edma) (memory DRAM)
loadc/storec 5 cycles (rr,exe,mem,mem,wb) (load/store cache)
load 4 cycle (rr,exe,mem,wb)
store 4 cycle (rr,exe,mem,nop)
all reg/imm-reg/reg 3 cycle (rr,exe,wb)
mul 4 cycle (rr,exe,exe,wb)
div 5 cycle (rr,div,div,div,wb)
float 5 cycle (rr,fexe,fexe,fexe,wb)
fdiv 8 cycles (rr,fdiv,fdiv,fdiv,fdiv,fdiv,fdiv,wb)
C'est un proc donc qui peut faire 2-4 instructions par cycles. Il peut switcher entre les deux (avec un delay du coup d'un cycle). Je ne veux pas faire plus , parce que de un , par expérience , si on fait plus , on va se trouver avec pas mal de "nop" , et secundo , j'ai assez du mal à voir comment on fait plus. Sur ce proc avec un delay en moyenne de 2-3 cycles pour les instructions les plus courantes , ça laisse 4-6 instructions (voir le double) à remplir , c'est assez énorme.
Je sais que les Intel et Ryzen peuvent avoir des pic de 4-5 IPC dans certain cas.
J'ai tenté de savoir combien ça prendrait en terme de transistor (et la forme du die) :
Le nombre me semble correct ,(même si je le compare avec le CELL qui avait je crois 200 ou 300MT par exemple ). Je n'explique pas forcément comment j'ai calculé en détails (une partie est calcul via tout simplement avec la photo du die des CPU existant, vu que certain photo montre où se trouve les unité de calcul , il suffit juste de faire un produit en croix ensuite par rapport à la ratio pixel/nombre de transistor). On est bien sur loin des milliard de transistor actuellement (je crois que les Ryzen 3600 6cores/12 threads fait 3800MT). Donc oui si avec 800MT , je peux avoir 16 cores , ça serait bien
Ah et je dirais que cela demandera sûrement de "refaire"un OS vu les caractéristiques spécifiques pour gérer un exécutable ici. J'avais écris rapidement la Memory Map de la future machine :
(oui vous voyez un truc étrange comme SSD RAM , je me demandais si ce n'était pas intéressant d'avoir un SSD comme RAM en plus, celui de la PS5 pouvait atteindre une vitesse de 5-8 Go/s , qui est la vitesse d'une DDR2--1066 ce qui n'est pas rien , ça demande que les programmes soit pensé pour utiliser c'est deux type de mémoire (RAM et SSD) ^^' ).
Effectivement mes questions sont : -est que ma pipeline est correct et réaliste ? -mon delay du VLIW réalisable ? (vu qu'aucun proc ne le fait vraiment) , je vois rien qui l'empeche , mais je suis pas concepteur de puce -le nombre de transistor correct ?
-quel fréquence on peut espérer ? (vu que la taille du scratchpad est assez gros , soit donc le réduire , ou le diviser par deux bloc distinct). -Une question sur le VLIW qui est : est ce que deux opcode puisse viser la même unité de calcul ?
Et si vous avez des idées d'améliorations n'hésitez pas ! (désolé pour le gros pavé).
ah et vous pouvez voir tout mes brouillon ici : https://github.com/Kannagi/Altair J'avais créer un assembleur , mais comme il était incorrect niveau opcode , je l'ai pas mis sur le Github, j'ai mis quand meme la version la plus actuelle niveau opcode. Je finaliserai le programme assembleur quand les opcode seront correct (et que je suis quasiment sur de ne pas le changer).
Mais oui je me rend compte que mes années de bas niveau et de micro-architecture des ordis fait en sorte que la plupart des gens (même programmeur ) n'y comprenne pas grand chose , j'ai fait de mon mieux pour vulgariser et pas entrer sur certain point technique.
Mais d'un coté ,je voulais pas non plus me faire passer par le gars ado "ouais je veux faire mon propre CPU qui est trop puissant , vous avez des tuto ?" , donc il fallait aussi que je montre que je sais de quoi je parle et les solutions que j'apporte. Qu'il y'a bien sur des alternatives sérieuses face à ARM , Intel/AMD (ou RISC-V ) en terme d'architectures et qu’elles sont à mon humble avis plus préférable.
Par contre ça demande de repartir un peu à zéro , c'est le gros soucis je pense que ce genre d'architecture vu que ça demande de faire un compilo dédié est pas des plus simples , et de faire un OS qui gère la particularité de ce proco.
Alors mon projet avance , j'ai fait pas mal de MAJ sur mon github depuis.
J'ai rajouté un programme assembleur (que j'ai pas créer de A à Z) , j'utilise VASM qui est un programme assembleur open source qui permet d'avoir des "plugins" pour rajouter des nouveaux. Cela permettra de tester la future VM avec un code assembleur. J'ai terminé 75 instructions (sur 120 a peu près ) , en gros j'ai pas mis le FPU + quelques autres instructions.
Alors j'ai regarder en travers parce qu'à la base je cherchait autre chose sur le net (LOL).
L'idée est bonne, par contre il y a pas mal d'aspects à prendre en considération quand on monte une architecture, la première de ces choses c'est "le besoin".
-> Pourquoi fabriquer ce proc (pédagogie, besoin précis, intérêt personnel, ...), pourquoi cette particularité est nécessaire (est-ce qu'il n'existe pas déjà une archi qui fait le boulot avec quelques modifs/accélérateurs à poser).
Ensuite, quand la question est répondu et que le projet est effectivement nécessaire (car ça représente du boulot!) il y a d'autres questions à se poser en fonction du domaine dans lequel tu vas l'utiliser (Fréquence de fonctionnement max, le cap MIPS/IPC, la latence que tu t'autorise) : par exemple sur du temps-réel, un proco ultra pipeliné avec grosse latence ça va faire mal au premier cache miss haha.
En dehors de ça, il faut pas oublier que l'augmentation du cache est une bonne idée si tu veux paliers aux miss, mais ça fait un cache plus long à parcourir, (idem pour les algo qui tournent, il y en a des très bon mais est-ce qu'ils correspondent au besoin ?), il faudra trouver un compromis efficace.
Ensuite si tous les choix sont fait et justifiés, il faut voir qu'en partant sur du superscalaire d'autres aspects sont à considérer. Exemple en dupliquant trop de fois ton bloc tu vas avoir des soucis de gestion des timings, d'augmentation du nombre de transistors (conso relié direct), et derrière c'est difficile de s'assurer que chacun de tes bloc soient "bien remplis" et qu'ils soient "toujours utile et nécessaires". Souvent avec un bloc de moins on s'en sort si l'archi est bien pensée (2-3 bloc en général).
Enfin bref, l'idée est sympa et je soutiens ta motivation ! Mais difficile de répondre aux questions sans un contexte clairement définit ^^. Juste mon conseil : bien faire le tour des choses avant d’enclencher du travail, c'est dommage quand on bosse sur un truc pendant 5ans alors qu'il y a mieux ailleurs (ça dépends de l'objectif de base; évidemment !!).
Ah et vu qu'un pro ça coute bonbon à produire (surtout si on en produit qu'un); tu peux check du côté des pro softcore et des implémentations sur asic/FPGA si tu veux le faire tourner (y-a pas mal de truc à faire là-dessus, accélération d'algo etc...).
Voilà voilà, bon courage pour cette archi !
EDIT : En fonction du contexte d'utilisation il faudra également considérer d'autres aspects de la conception comme la sécurité HW, je pense que actuellement on est pas mal en terme de performances et que le soucis est ailleurs :p.
Ca n'a pas de sens de parler de processeur idéal, comme le dit @TataGateau (excellent pseudo au passage) il faut un usecase. Tu vises du processeur pour PC ?
différence c'est que de nos jours on a Clang et qu'il permet de faire du code intermédiaire suffisamment intéressant pour pouvoir à mon avis , le transformer et l'optimiser sur un proc plus "exotique".
Et rien que pour ça... Non. Clang n'est pas prévu pour optimiser du code pour VLIW. Ça demande beaucoup beaucoup beaucoup de travail pour avoir du code optimisé.
- Edité par FantasMaths 23 février 2021 à 16:52:45
1)Pourquoi , parce que ce proc se veut une alternative à ceux existant avec donc un paradigme différent. (réduction de cout /transistor et de consommation, tout en augmentant les perfs ) 2) Oui je connais les contrainte de grosse pipeline et de cache miss , d'ailleurs le but de cette architecture et de palier à ces deux soucis 3)Si mes caches sont si gros ,ce n'est pas du cache à proprement parler , mais du Scratchpad Memory , donc pas d'algo spécifique pour les parcourir , l'adresse qu'on indique est l'adresse "réel" Et comme ce type de mémoire est facile à lire/écrire , je me suis permis d'en mettre beaucoup , d’ailleurs techniquement le concept de cache miss n'existe pas sur un Scratchpad Memory Le CELL avec une gravure de 90nm avait 256 ko et prenait 4-6 cycles (sur 3,2 Ghz donc ), moi je fais du 128ko , et sûrement avec une gravure bien plus fine
4) ah ah tu as lu de travers ,ce n'est pas un proc superscalire , mais VLIW 5) j'ai fait le tour des architectures depuis des années , pour cela que je propose celle ci
NT: pour la sécurité ,si on parle des failles de meltown/spectre et tout autre faille relative à OoO , c'est simple j'en ai aucune , vu que je ne gère ni le superscalaire , ni la prédiction de branchement , ni le out of order
Pour le proc "Idéal" heureusement que j'ai mis des guillemets Idéal pour moi , c'est déjà ça Ensuite ça dépend de ce qu'on appelle PC , mais je parlerais de processeur de bureau , il se veut pas compatible avec du x86
Je sais que Clang ne permet pas le VLIW , mais moi j'ai pas mal programmer sur des procs VLIW , et j'ai tout à fait confiance en moi d'avoir un backend efficace pour ce type de proc Mais on étudiant Clang , il fait déjà une grosse partie du boulot de l'optimisation Front-End , donc me reste le Back-end a faire diront nous
Ensuite pour optimiser mon proc , c'est beaucoup de travail , mais pas parce que c'est du VLIW (ça ça va encore ) , mais qu'il soit un proc hybride en terme de mémoire (cache /Scratpad) et effectivement qu'il soit in order.
Pour écrire un back efficace pour VLIW c'est très compliqué je maintiens, notamment pour savoir quand préfetcher la data (ce qui est vital dès la compilation du coup). La gestion du control flow devient de suite beaucoup plus compliquée (et écrire du vliw à la main c'est rigolo 5 minutes mais si tu veux passer sur des échelles de programme grand public type word tu vas vite déchanter). Plus globalement pour exploiter de l'ILP il te faut des instructions indépendantes, donc un moyen de gérer à la fois data et control flow. Itanium proposait plusieurs idées pour arriver à exploiter l'ilp au max, par exemple la predicated execution, le software pipelining, les speculative loads. Tout ça a été fait pour des raisons de performance, et si les ingénieurs d'Intel en sont arrivés à proposer ça c'est sûrement qu'ils avaient eu des problèmes de perf sans
Vu que tu veux garder un design simple tu vas aussi avoir des problèmes de code bloating sur tes boucles si tu veux les paralléliser (avec loop unrolling etc)
Ensuite tu as le problème de compatibilité du binaire qui n'est pas négligeable : si tu veux faire évoluer ton architecture tu dois recompiler pour chaque nouveau proc que tu sors, ce qui impose soit que le code source soit libre, soit que le vendeur compile les binaires pour chaque processeur (bonjour l'enfer). (ou alors du fais du bricolage type translation dynamique mais ça va à l'encontre de ton design visiblement).
Petite remarque pour la "SSD RAM", on appelle ça la swap c'est déjà présent sur tous les PC et MAC
Voilà quelques idées en vrac et mes souvenir de cours d'archi Je ne veux pas du tout te dissuader de t'investir dans ton projet mais surtout n'oublie pas de rester humble, il y a des équipes d'archi chevronnés avec des budgets faramineux qui s'y sont cassé les dents, c'est sûrement pour une raison
Tout ce que tu dis , je le sais bien J'ai pas mal programmé sur du VLIW , et je connais parfaitement les contraintes et soucis que cela pose pour optimiser ce type d'architectures (Je l'ai même indiqué en premier que je ne ferais pas exception ).
J'ai parlé de l'Itanium , de Transmeta , et du CELL sur ma page de présentation , 3 type de proc VLIW , et je l'ai est étudier pendant des années (et j'ai pas mal programmé sur les proc de sony entre autre , il y'a d’ailleurs pas mal de code /technique fait par des chercheurs ou des équipe de jeux vidéo pour optimiser ce type de proc).
Programmer sur un processeur Sony (Ps2 ou PS3) c'est effectivement rigolo 5 minutes , je le sais bien ,j'ai du optimiser pendant des mois certaines routine , rien de bien amusant donc et totalement contre productive dans un sens ( optimiser au final 100 - 1000 lignes de code) la ratio/temps est énorme , mais cela est du justement que tout est interdépendant ,donc obligé de reécrire à zero depuis le début. Mais c'est justement en regardant le code générer par clang , que je me suis dit "ah ben il met pas mal d'info pour optimiser ce que je faisais à la main pendant des mois"
Pour la compilation , le mieux c'est de proposer un bytecode et qu'on recompile pour chaque "type du proc".
"Petite remarque pour la "SSD RAM", on appelle ça la swap c'est déjà présent sur tous les PC et MAC " Euh non ,ce n'est pas ce que je veux faire , le swap utilise des I/O pour lire/écrire dessus , moi je veux quelque chose directement mappé en mémoire (mais c'est juste un idée , je met ça de coté pour le moment).
"mais surtout n'oublie pas de rester humble, il y a des équipes d'archi chevronnés avec des budgets faramineux qui s'y sont cassé les dents, c'est sûrement pour une raison " Oui je l'ai deja dit au début , les 3 se sont cassé les dents , (Sony/IBM//Intel) donc clairement pas des petits acteurs , j'ai pas dit que je suis meilleurs qu'eux , mais on parle d'architecture d'il y'a 15 ans , justement on prenant en compte ce qui n'a pas marché qu'on peut avancer et proposer des solutions "alternative"
Ca ne résout pas le problème de l'ILP limité : ton processeur a beau faire des opérations en parallèle, s'il n'y a pas d'opérations à réaliser en parallèle ça ne sert à rien et le bytecode ça ne résout pas le problème de binary compatibility.
Bref, tu peux y croire mais sans idées novatrices tu vas tomber sur les même problèmes que tu refuses de voir (mais qui vont arriver quand même)
Et tu ne proposes pas une solution alternative, tu proposes un design simple qui a été testé par des ingénieurs chevronnés
Je connaît toute ces problématiques (j'ai du codé sur une vingtaine d'architectures différentes en assembleur , que ça soit du simple in order , a du superscalaire in order /OoO ou du VLIW ) Mais oui je ne doute pas que je ne sais ce que je fais !
Le seul truc à retenir c'est fais le si ça t'amuse mais ne mets pas tes attentes trop hautes.
Tu vas vite te rendre compte que coder de l'assembleur ce n'est pas faire de l'architecture Mais bon j'acheterais ton processeur avec plaisir quand il marchera
EDIT: mon point du dessus est toujours valide et je suis à peu près sur que tu vas rapidement tomber dessus. Je m'emporte un peu mais tu manques un poil d'humilité à mes yeux (et tu ignores la moitie des messages) au passage.
- Edité par FantasMaths 23 février 2021 à 18:42:30
Il est clair que faire de l'assembleur ce n'est pas faire de l'architecture , mais que je connais suffisamment d'architecture différente pour connaitre a peu près toute les problématiques que tu cite. (Mais certaine ne sont clairement pas lié à une architecture particulier IPL chute aussi sur du x86 donc du Superscalaire OoO quand il y'a peu de chose à // ).
Je ne sais pas si ce que je fais m’amuse (et cela me prend beaucoup de temps ) , mais comme dit ,c'est juste un PoC que je fais de façon sérieuse et rigoureuse. Qu'appelle tu attentes trop hautes ? Si c'est pour faire un proc efficace , ça me semble évident d'avoir des attendes hautes. Effectivement tu peux penser que ce que je fais est inutile ,je le comprend ou qu'il est moins bon qu'un architecture plus "classique" , mais ce n'est pas mon avis. Mais je ne suis pas le seul à penser que le OoO est une mauvaise chose sur les procs actuel (même chez Intel )
La différence avec un VLIW c'est que tu monopolises un nombre fixé de coeurs, tu ne peux pas scheduler un autre process pendant tes nop. Donc le problème de l'ILP a un impact bien plus important quand tu fais du VLIW, et tu n'y couperas pas.
J'ajoute que la discussion m'intéresse beaucoup (sinon je n'y répondrai pas) mais tu sous-estimes la difficulté du projet (pour avoir une perf qui rivalise avec du x86 ultra optimisé depuis des années).
Et le out of order a bien ses inconvénients et c'est normal de tenter des approches alternatives (je trouve l'idée des VLIW très élégante aussi), mais à l'heure actuelle c'est ce qui marche pour les utilisations type PC (multiprocessing avec grande diversité de type de programmes).
Alors si tu parle du SMT/HyperThreading , oui je pourrais pas en faire , mais pour moi ce n'est pas un soucis , sur du superscalaire Out Of Order ,c'est une solution faite pour économiser surtout des transistors. Sur un proc comme le mien , faire du multi-core est bien plus facile (pour cela que le CELL proposait du 8 cores en 2005 pour 200 millions de transistors ).
Pour IPL à proprement parlé , je vois que tu te fixe beaucoup dessus , alors que chez moi c'est secondaire , la plus grosse optimisation actuelle se trouve sur les caches miss /gestion de la RAM , et j'ai vraiment le truc où j'ai le plus travailler sur mon proc , pas sur l'IPC La résolution des "nop" peut se faire aussi en multipliant le nombre d'ALU/LSU par exemple , ce qui est bien plus faisable actuellement. (tu prend un proc du type Transmeta ou Sony , les instructions était divisé par ALU/FPU , donc si tu fait pas de FPU , ben t'en rajoute pas mal de nop). Pareil pour l'Itanium qui obligé à avoir 128 bit /3 instructions minimun.
Donc je n'ai pas vocation/volonté de faire 15 instructions/cycle comme ce cher itanium
Mais c'est le cas aussi sur Intel/AMD , des que tu ne fais pas un mélange de FPU/ALU , ben l'IPC est moins important.
Le SMT, plus que d'économiser des transistors, ça évite de perdre des cycles.
Faire du multi-core ça n'est utile que si tu peux exploiter le parallélisme... Le bottleneck des processeurs VLIW n'était pas la gestion de mémoire mais bien l'ILP... Donc améliorer la mémoire sans améliorer l'ILP ça n'améliorera rien...
Ce n'est pas mon avis , j'avais réussi à avoir 2 instructions/cycle en continu sur du VLIW sur certain proc (avec peu de nop , je précise) , donc je ne suis pas inquiet la dessus Et je n'ai pas dit que je ne tente pas de le résoudre , mais que je vise 2-4 IPC dans un premier temps ,que effectivement je pense pas qu'on puisse aller vraiment plus haut avec du VLIW.
Il faut bien sur ensuite avoir le bon compilateur , c'est un gros taff , mais je pense que c'est faisable.
Mais je pense aussi que tu surestime l'IPL sur le x86 (qui est certes "important" , mais pas tant que ça ).
Et le VLIW n'a jamais réussi à attendre le niveau de parallélisation de x86 sans recourir à des techniques comme la predication/software pipeline etc. C'est pour ça que je me focalise dessus, c'est simplement factuel. A nouveau, tu t'en rendras très vite compte.
Factuellement , il n'y a pas eu beaucoup de VLIW moderne donc difficile à comparé. Sinon si on parle des début des années 2000 (ou il y'a eu le plus de VLIW qui voulait concurrencé du x86) , euh non , tu faisais largement mieux en terme d'IPC qu'un x86 (mais ça dépend des architectures celà dit , moi je parle sur ce que j'avais fait).
C'est vraiment que à partir des années 2010 que le x86 à pu avoir un IPC "meilleur" que du VLIW (des années 2000)
Pas besoin de m'en rendre compte , comme déjà dit , j'ai pas mal de bouteille derrière moi , je connais les avantages/inconvénient de chaque architecture, je sais que le mien n'est pas parfait non plus et qu'il n'aura pas un IPC du dernier Ryzen Zen 3
(déjà ILP != IPC je ne suis pas sûr que tu fasses la différence)
De l'IPC oui sur un process, mais pas au global avec plusieurs process qui tournent en parallèle... Bref tu ne lis qu'à moitié. Les VLIW étaient déjà à la traine il y a dix ans et tu proposes un design qui ne vise pas les problèmes qu'il avait déjà... Il y a des dizaines de papiers qui en parlent je te laisse chercher. EDIT : à force de répondre trop vite j'écris des conneries. C'est bien contre un single thread qu'on compare, et tu ne peux pas atteindre le nombre d'IPC (en tout cas les gens n'y arrivent pas donc HF)
Tant mieux si tu n'as pas mal de bouteille (parce que tu as codé en assembleur ?), n'hésite pas à aller toquer chez un designer de processeurs, peut être qu'ils sauront te convaincre mieux que moi.
- Edité par FantasMaths 23 février 2021 à 22:46:40
Ah ah non malheuresement de ce que j'avais lu , c'était un peu mort pour avoir ce genre de technologie , mais à voir ce que nous réserve le futur
- Edité par HelbaSama 24 février 2021 à 8:35:20
Une idée d'un nouveau processeur révolutionnaire !
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Le Tout est souvent plus grand que la somme de ses parties.