Le 06/05/2021 à 12h 46

seboss666 a dit:

Tiens alors que les libristes sont quasi en extase devant un Risc-V, je serai curieux de voir les chercheurs se pencher dessus (parce que je suis pas super fan de la fragmentation de l’univers ARM, qui a eu aussi droit à quelques surprises autour de la prédiction de branche si je ne m’abuse)

Le RISC-V aura forcément les mêmes faille que Intel/AMD (Et ARM) pour les hautes performances.
Il faudrait partir sur des techno complètement différente (comme Itanium ou le CELL) qui n’ont pas de faille Spectre et qui était destiné pour les hautes perf , mais c’est mon avis personnels :)

Le 06/05/2021 à 06h 36

seboss666 a dit:

Ouais donc en gros, faut virer tous les caches des CPU et basta. Et la prédiction aussi, sans parler de l’hyperthreading/SMT. Comme ça plus de problème. Et les devs retournent apprendre à coder autrement qu’avec le front sur le clavier pour nous faire des programmes qui n’ont pas besoin de 4 fois la puissance d’une PS5 pour faire un jeu de mots croisés.

Où qu’on part sur de nouvelle architecture de processeurs ;)

Le 05/05/2021 à 22h 17

Pour répondre aux titres “Encore une faille dans les processeurs AMD et Intel… ça ne s’arrête jamais ?”
Ben non pour ça que la faille s’appelle Spectre parce qu’elle risque de hanté pendant longtemps les procs qui ont ce genre d’optimisation.

Le 09/04/2021 à 08h 04

(quote:1866126:brice.wernet)
Mais les ARM ont vite déçu, les PPC aussi…

Oui , mais bon l’OoO est très complexe aussi

Disons que le câblage va favoriser une certaine suite d’instructions, l’étage de réorganisation est censé produire ces suites le plus possible. Si on multiplie ces suites précablées, on se rapproche d’un VLIW.

Oui , on peut en interne le gérer comme cela , mais cela ne veut pas vraiment dire qu’ils ont l’avantage du VLIW , vu que c’est qu’une petite partie du OoO le dispatch.

Je parlais surtout sur la façon de programmer - isoler des boucles dont on sait qu’elles ont une certaine durée. Et c’est une réflexion qui date de fin des années 90 en fait, en regardant le bytecode java et le fait qu’on s’énerve à le coller sur des machines à registres. Google a réglé le problème je crois en faisant un bytecode à registres.

Ben justement ,le CELL est un proc à registres donc pas sur que cela soit ta “façon de programmer”.
j’ai programmer sur ce genre de proc , et la façon de programmer et comme je l’ai dit , faut juste le voir comem un ARM mais que tu indique par bloc de deux instructions et que t’as pas de cache , le but du CELL est d’éviter au maximun les caches miss ;)
(Et il est VLIW in order pour réduire au maximun le nombre de transistor).

Le 09/04/2021 à 07h 21

(quote:1866111:brice.wernet)
Quand à la “pureté” du RISC: c’est bien parce que l’idée ne résout pas tout et de loin que les ARM/PowerPC n’arrivent sur le devant de la scène que maintenant: depuis le début des années 90, la révolution RISC n’a pas réussi réellement à faire des machines aussi performantes que les CISC, sauf Apple M1… Qui embarque plus de transistors que les x86.

Non , ce n’est pas la raison pour laquelle les procs “RISC” était en retrait , juste que faire un out of order efficace est très complexe, et seul Intel/AMD y arriverai.
Par contre les procs RISC faisait mieux à leur début (les PowerPC était meilleur que la gamme des Pentium ).

D’après ce que j’ai lu, il a une ISA RISC, mais il ressemble plus à une espèce de VLIW en interne (mais on ne peut que spéculer). Quelques articles d’il y a quelques années comparaient des RISC à décodage multiple à du VLIW car en réorganisant “de force” les instructions, on pouvait exécuter des “cascades d’instructions” avec moins de cycle qu’il n’y a d’instructions, bloc par bloc.

Bah , non ça ne fait pas du VLIW en interne :)
Après la comparaison est tout simplement que le VLIW peut être vu comme une version manuelle du Superscalaire , mais en interne , y’a de grosse différence entre eux.

C’est un autre façon de penser, plus proche du Cell de la PS3 en fait. Grosses tâches à alimenter. Un peut comme un GPU, mais au lieu de registres, des déplacement sur une ligne plus ou moins grande. Ca peut coller avec du bytecode Java, puisqu’il déclare d’avance les espaces nécessaires pour une fonction. Mais mon passé fortran parle :)

Le CELL n’était pas novateur , vu que le CELL était une copie parfaite de la … PS2 ou plus précisément de l’Emotion engine.

Sinon tu as mal compris le CELL (qui est pour ma part on va dire ma vision du CPU moderne), il n’avait pas de gros registre , il avait des registres de 128 bits au grand max.
C’est un proc relativement basique (donc qui utilise des registres et des instructions très proche d’un RISC ), la seule différence était qu’il était VLIW et qu’il n’avait pas de mémoire cache (mais un scratchpad memory) , et que donc c’était au programmeur de gérer cette mémoire , et la méthode pour bien l’utiliser était de précharger à l’avance les données (et pas forcément les fonctions , mais aussi et surtout les datas ).

Le 08/04/2021 à 16h 27

(quote:1865957:brice.wernet)
Attention, les ISA ne sont qu’une façade pour les micro instructions derrières. Entre les renommages de registre, le out of order et le prédictif, c’est un peu une soupe derrière ce qu’on voit en assembleur. Et ça date du PPC, en RISC.

Cela n’empêche pas que le x86 est pourri , et même pour du superscalaire Out of order , il est handicapant.
Voilà quelque point où un processeur RISC à l’avantage comparé à un x86 :

-le décodage , il est bien plus rapide sur le RISC ce qui fait que la pipeline sur ARM est bien plus courte , et donc moins besoin d’avoir un out of order “efficace”

-on peut décodé plus d’instruction par cycle (c’est le cas du Apple M1 qui décode 8 instructions , contre 4 contre Intel et AMD) et ça ni Intel ni AMD n’arrivera à monté plus à cause du x86 justement :)

-moins de registre signifie que le x86 tape plus souvent sur le cache que sur les registres et comme l’accès au cache est bien plus long…

Par ailleurs, moi je vois plutôt une ISA différente, avec au lieu de registre des lignes de cache de plusieurs dizaines d’octets. Là on peut se lâcher sur le calcul matriciel.

Belle idée , mais non , si tu as un registre de 64 octets , ça poserais pas mal de soucis (et globalement un accès relativement long , même en register).
Et les load/store ont souffrirait , vu qu’en général on préfère unifié le load/store , cela veut dire qu’on aura un ralentissement du load/store pour tout , et donc un load 8 bits serait donc aussi long que le load 64 octets.