Question con: Pipeline et tout ca.

**Yasko** · 18/02/2006, 11h31

Envoyé par Franck@x86

Envoyé par Yasko

Maintenant, il ne faut pas que compter que sur le multithread pour améliorer les perfs, y a un (proche ?) moment ou ca n'apportera plus rien (sauf donner raison à Moore ?).

En l'occurence il ne s'agit pas de la loi de Moore mais de la loi d'Amdahl

Je disais ça dans le sens où avec le multicore, on a un moyen facile (mais couteux) de respecter la loi de Moore pour un bon moment. Mais merci pour le lien, je ne connaissais pas cette loi.

**ylyad** · 18/02/2006, 11h39

Ca me parait assez logique (je ne connaissais pas Amdahl, merci Franck). Une fois que t'auras du Dual-Core partout, faudra bien revoir à réaccélérer ces cores, donc retour à des pipelines longs.

En plus, je suis pas spécialiste, mais les impacts en termes de développement semblent assez hallucinants. Je me trompe peut-être, mais c'est pas juste mono/multithread, non? Y a plein de cas où tu peux pas gagner, ou au mieux t'auras un gain avec 2 cores, mais en avoir 4 t'apportera rien, ou si peu que l'investissement pour optimiser à 4 (ou plus) est rédhibitoire. Déjà le boulot pour optimiser pour du multithread

uch:

Plus ca va, plus je vois bien l'intérêt grand public en termes d'utilisation d'avoir 2 cores, mais pas beaucoup plus, genre freeplayer quand je suis en train de jouer - cas où l'HT suffit pas. A propos, pour les benches, ca me semble plus réaliste qu'encoder en Divx pendant les jeux. Mais au-delà, je vois pas trop. Résultat: faudra bien revoir à remonter en fréquence.

**Neo_13** · 18/02/2006, 11h47

Envoyé par seb64

J'ai bien fait de dire "je peux me tromper".

Par contre le register renaming (avoir plus de registres que ce que prévoit l'architecture) ça ne date que du P4 (K7 pour AMD), avant ils utilisaient un reorder buffer (garder un historique des registres avec les valeurs à plusieurs moments) pour gérer les problèmes de manque de registres.

D'après Tanenbaum (Architecture de l'ordinateur) le p2 dispose de 40 registres int avec ROB

**Dandu** · 18/02/2006, 12h06

Envoyé par ylyad

Ca me parait assez logique (je ne connaissais pas Amdahl, merci Franck). Une fois que t'auras du Dual-Core partout, faudra bien revoir à réaccélérer ces cores, donc retour à des pipelines longs.

En plus, je suis pas spécialiste, mais les impacts en termes de développement semblent assez hallucinants. Je me trompe peut-être, mais c'est pas juste mono/multithread, non? Y a plein de cas où tu peux pas gagner, ou au mieux t'auras un gain avec 2 cores, mais en avoir 4 t'apportera rien, ou si peu que l'investissement pour optimiser à 4 (ou plus) est rédhibitoire. Déjà le boulot pour optimiser pour du multithread

uch:

Plus ca va, plus je vois bien l'intérêt grand public en termes d'utilisation d'avoir 2 cores, mais pas beaucoup plus, genre freeplayer quand je suis en train de jouer - cas où l'HT suffit pas. A propos, pour les benches, ca me semble plus réaliste qu'encoder en Divx pendant les jeux. Mais au-delà, je vois pas trop. Résultat: faudra bien revoir à remonter en fréquence.

4 core, on peut encore espérer du gain, on a pu le voir avec les derniers G5 chez Apple, qui utilise 4 processeurs. Le truc c'est qu'un programme qui tire partie de 2 core correctement (genre compression vidéo) tirera bien parti de 4 core. Mais pour les programmes qui utilise pas 2 core correctement, passer à 4 change rien.

On risque donc d'avoir quelques programmes qui verront leurs perfs augmenter (essentiellement la vidéo) et seront utilisé dans les benchs constructeurs, et le reste qui offira un gain en puissance marginal, ce qu'on "oubliera" de nous dire.

**jihef** · 18/02/2006, 12h56

Envoyé par Franck@x86

Envoyé par Yasko

Maintenant, il ne faut pas que compter que sur lui pour améliorer les perfs, y a un (proche ?) moment ou ca n'apportera plus rien (sauf donner raison à Moore ?).

En l'occurence il ne s'agit pas de la loi de Moore mais de la loi d'Amdahl :

Code:

http&#58;//fr.wikipedia.org/wiki/Loi_d'Amdahl

(~&!@# de lien)

La courbe tend à s'aplatir avec l''augmentation du nb de CPUs, mais on peut jouer sur plusieurs paramètres, dont la proportion de code qui peut tourner de façon parallèle.

C'était une question de mon exam d'architecture avancée. ... et j'ai pas répondu.

**ylyad** · 18/02/2006, 14h20

Envoyé par dandu

4 core, on peut encore espérer du gain, on a pu le voir avec les derniers G5 chez Apple, qui utilise 4 processeurs. Le truc c'est qu'un programme qui tire partie de 2 core correctement (genre compression vidéo) tirera bien parti de 4 core. Mais pour les programmes qui utilise pas 2 core correctement, passer à 4 change rien.

On risque donc d'avoir quelques programmes qui verront leurs perfs augmenter (essentiellement la vidéo) et seront utilisé dans les benchs constructeurs, et le reste qui offira un gain en puissance marginal, ce qu'on "oubliera" de nous dire.

Oui, y a des cas... Mais là où j'ai un doute, c'est le côté évident de "un programme qui tire partie de 2 core correctement tirera bien parti de 4 core". Parce que il me semble me souvenir d'une interview (Carmack? mais ce qu'il disait ne s'appliquait pas forcément qu'aux jeux) expliquant que le multithreading n'était pas forcément la panacée: problèmes de synchro, de latences, d'attentes... et arriver à gérer ca sur 2 threads ne veut pas forcément dire gérer ca correctement au-délà.
Dans le cas de la video, ca me semble assez facile de décomposer les tâches au départ, de les traiter de manière indépendante, et des regrouper les résultats à la fin; mais ce principe est loin d'être applicable pour tout.

D'ailleurs, pour le côté parallèle, le GPU a une archi plus adaptée, non? Du coup, la prise en charge de ce genre de traitements par le GPU serait plus efficace que par le CPU.

A mon sens, le gain du multi-core va plus bénéficier au niveau global de l'ordinateur, soit deux applis pas forcément liées qui tournent en même temps, plutôt qu'à l'intérieur de la même appli.
Conséquences: primo, c'est le scheduler de l'OS qui est le point critique; secundo, la limite en nombre de cores va être vite atteinte.

Bon, c'est pas mon rayon non plus, donc y a sans doute des trucs que j'ai pas bien compris :D

**Franck@x86** · 18/02/2006, 14h26

Tiens comme par hasard dans le prochain PC Update (mars) y'a un article sur les optims dual/multi-cores :-)

Dans un jeu par exemple l'idée est de créer un thread par sous-système (IA, physique, collisions ...). Donc plus y'a de CPUs meilleure est la répartition, enfin ça me semble logique.

**Childerik** · 18/02/2006, 15h04

Envoyé par Franck@x86

Dans un jeu par exemple l'idée est de créer un thread par sous-système (IA, physique, collisions ...). Donc plus y'a de CPUs meilleure est la répartition, enfin ça me semble logique.

Ce n'était pas l'idée initiale du PPU ?

**Franck@x86** · 18/02/2006, 15h30

Non, le PPU prend en charge le moteur physique et les collisions. Donc PFD, forces, impulsions et tout le toutim. Il le fait rapidement (+ rapidement que le CPU), sûrement en parallèle en interne. La synchro avec le reste du moteur c'est pas son affaire.

**fefe** · 18/02/2006, 16h48

A propos des registres renommes et du reorder buffer vu qu'il semblerait qu'il y a un peu de confusion dans un post au dessus.

Tous les microprocesseurs supportant l'execution dans le desordre ont un ROB afin de garantir que l'execution du programme est conforme aux specifications du jeu d'instruction (qui garantit pour l'utilisateur que le programme se passera comme si tout avait ete execute dans l'ordre, l'un apres l'autre).
Les faults, les ecritures memoires et bien d'autres choses ont besoin de cette garantie donc tous les microprocesseurs OOO en ont un.

Apres pour les registres de renommage il y a plusieurs choix d'implementation.
En theorie si un microprocesseur a un rob de X entrees il peut garder X instructions au vol qui chacune genere un resultat au maximum. Donc au maximum tu pourras avoir X registres temporaires en supplement des registres de l'architecture (x86 dans notre cas).

L'implementation triviale est celle qu'a employe le P6, associer ces X registres temporaires aux X entrees du Rob 1<->1 ce qui facilite pas mal la logique en interne car le numero de l'instruction en interne est aussi le numero de son registre.

C'est simple a faire et on est garanti que l'on ne manquera jamais de registres, ce sera toujours la taille du rob le facteur limitant.

En revanche prevoire pour le pire des cas est en general assez couteux, en effet en gros 1/4 des instructions ne generent pas de resultat dans un registre (branchements et store par exemple), donc on peut en fait avoir 3/4X registres et tres bien s'en sortir. Cela pose le probleme de numerotations, et il faut pour cela garder une table de renommage des registres (le numero de registre != numero de sequence). En plus de cette table il faut etre capable de restaurer l'etat de la machine avant un mauvais branchement donc il faut etre capable de faire des rollback sur la table de renommage (alors qu'en cas de stockage dans le rob il suffit de revenir dans le rob a l'instruction qui a cree le probleme de speculation). C'est cette derniere methode que P4 utilise ainsi que le K7/K8.

Donc pour revenir au commentaire d'origine, le P6 a des registres de renommage, le fait qu'ils soient joints au ROB n'est qu'une astuce algorithmique/architecturelle.

Voila c'etait mon 1/4 d'heure registres de renommage.

**Yasko** · 18/02/2006, 18h12

Tu sais pourquoi ce choix sur P4 - K7/K8 ?
Pourquoi ne pas avoir systématiquement un registre temporaire pour chaque élément du ROB si c'est plus compliqué autrement ?
Quel est l'intêret de cette économie de quelques registres ?

**Childerik** · 18/02/2006, 21h29

Envoyé par Franck@x86

Non, le PPU prend en charge le moteur physique et les collisions. Donc PFD, forces, impulsions et tout le toutim. Il le fait rapidement (+ rapidement que le CPU), sûrement en parallèle en interne. La synchro avec le reste du moteur c'est pas son affaire.

Si je comprends bien, le PPU serait au GPU ce qu'était le coprocesseur 487 face au 486 et antécédents ??? Enfin de façon très imagée hein.

**fefe** · 18/02/2006, 22h23

Envoyé par Yasko

Tu sais pourquoi ce choix sur P4 - K7/K8 ?
Pourquoi ne pas avoir systématiquement un registre temporaire pour chaque élément du ROB si c'est plus compliqué autrement ?
Quel est l'intêret de cette économie de quelques registres ?

Le RoB du P6 faisait 20 entrees quand il a ete concu, la difference entre 16 et 20 registres est quelque peu negligeable, le P4 avec un RoB de 128 entrees la difference devient plus importante et avoir une table de renommage commence a couter moins cher en power et en surface.
A priori ce n'est pas cette raison qui les a pousse a employer cette methode mais plus le fait que le P4 et le K7 sont des machines "clusterisees" afin d'atteindre de hautes frequences, c'est a dire que les ports de dispatch sont separes pour l'entier la memoire et le FP. Cette clusterisation est faite en general pour essayer d'eviter d'avoir un point central d'ou tout part et tout revient comme le RoB et la RS du P6. Tu as donc des registres qui ont moins de ports en lecture ecriture, qui sont separes par type d'unites de calcul et localises juste a cote (avec de petits schedulers d instructions qui ne contiennent que les pointeurs vers les registres au lieu de la donnee en elle meme comme dans la RS), au lieu d'une RS centrale, et d'un ROB qui au final du a la quantite de ports de lecture/ecriture deviennent assez limites en taille.

La frequence montant les grosses structures centrales et loin des unites d'execution deviennent ingerables (il y a plein de choses qui doivent etre a tout pris finies en 1 cycle) et on doit changer tout ca pour obtenir des structures distribuees plus simples, localisees la ou il y en a besoin, mais au cout d'algorithmes d'allocation/desallocation/recuperation de prediction complexes (mais pipelinables en plusieurs cycles).

Le K7 a ete concu en prevoyant des frequences legerement plus elevees que le P6, le P4 encore plus, et les 2 visaient une machine OOO capable de garder plus d'instructions au vol. Au moment ou ils ont pris la decision d'abandonner RoB/RS centralise je pense qu'il n'y avait pas le choix car ils n'auraient jamais reussi a monter en frequence aussi vite.

Aujourd'hui la course a la frequence s'est arrete dans le mur du power, et les mecanismes simples d'hier peuvent redevenir interressants car avec les technos de gravages actuelles, peu importe si tu es limite a 2.5GHz quand la machine qui est concue pour tourner a 5GHz tourne a 3.6GHz (et donc a des performances lamentables).

La version simple avec les donnees dans le ROB est aussi assez limitee quand a son avenir, en effet pas mal de mecanismes (futuristes pour l'instant) d'optimisations sont plus a l'aise lorsqu'il manipulent des pointeurs vers les registres que la donnee elle meme (cf par exemple des articles sur le memory renaming).

J'espere que je reponds a ta question.

**Yasko** · 18/02/2006, 22h53

Ok. Thx

**Franck@x86** · 18/02/2006, 23h12

quel bordel un CPU sans déconner

(ça c'est une remarque stérile de samedi soir)

**fefe** · 19/02/2006, 21h20

Envoyé par Franck@x86

quel bordel un CPU sans déconner

(ça c'est une remarque stérile de samedi soir)

Mais non c'est fun

.

Heureusement qu'on n'a pas attaque une discussions sur replay, parce que la tu aurais ete dans le vrai

.

**hellskey** · 20/02/2006, 21h57

comme on évoque la loie de G Amdahl sur du parallelisme et ces limites
Quelqu'un pourrait il expliqué celle de gustafson
http://arxiv.org/ftp/cs/papers/0209/0209029.pdf

J'utilise un autre cours sur l'architecture systéme qui pourrait vous interesser. Je sais qu'il y en en bcps sur le net mais celui ci est tres progressif.
http://meseec.ce.rit.edu/.

Mon expérience c'est que un tés bon cpu ne remplace pas un trés bon compilateur

**fefe** · 21/02/2006, 11h42

Envoyé par hellskey

Mon expérience c'est que un tés bon cpu ne remplace pas un trés bon compilateur

Mon experience me dit surtout que rien ne vaut un algorithme bien pense et bien code, et que le reste est un probleme secondaire.

**hellskey** · 21/02/2006, 18h35

slt,
certainement, un bon algo à la base, c'est déja pas mal. Mais comme on ne va pas réecrire ts les pgm , il nous reste le premier élèment commun: le compilateur.
J'ai pas trouvé de topics sur les compilateurs. Cela interesse qq ?

**Neo_13** · 21/02/2006, 19h16

pourquoipas...

**Franck@x86** · 21/02/2006, 20h09

Tiens ça me rappelle un vieux débat sur onversity.

http://www.onversity.net/cgi-bin/progcafe/cafetted.cgi?Eudo=bgteob&For=onversity&Cat=article s&Dom=informat&Inti=Langage+C+$3a+l$27optimisation +de+code&Numfor=00000838&Tri=date&LigQ=0&LigR=0&Di c=informat&Rload=a&Numquest=00000577&Sujet=Optimis ation+algorithmique+$3f$3f

(record du monde du lien le + long)

**Neo_13** · 21/02/2006, 21h34

mouais... onversity ...

**Marc** · 23/02/2006, 02h51

Envoyé par Franck@x86

Y'a jamais eu de second core caché non activé dans le Prescott !
L'inflation du nombre de transistors vient de l'augmentation de la longueur du pipeline, ce qui a complexifié le design de certaines étapes (l'OOO notamment, comme je l'explique dans le mag).
Avec le Prescott Intel a aussi du abandonner ses fameuses ALU "double speed", et pour obtenir la même vitesse de traitement a transformé chaque ALU 2x en deux ALUs 1x. Ce qui explique que le die montre qquechose ressemblant à deux cores, mais il ne s'agit pas de ça du tout.

Comme je le dis dans l'article on reviendra forcément à des très longs pipelines, c'est juste une question de temps. On peut voir le P4 comme un précurseur, tout dépend du point de vue !

Hannnn c'était bien ca alors ?

En février 2004 je parlais de l'hypothèse de l'abandon des fast alu remplacées par le double d'alu normale personne m'a cru omnibulé par l'hypothèse plus sexy ...

(bon ok, j'ai pas argumenté pendant deux ans non plus mais bon :D )

**eponge** · 23/02/2006, 22h38

j'ai achete le mag. j'ai decouvert le OOO, et les pipelines longs, va falloir que intel trouve une pirouette marketing pour revenir plus tard a ces pipelines longs ( du genre : "on maitrise plus mieux")

**Childerik** · 23/02/2006, 23h37

Envoyé par eponge

j'ai achete le mag. j'ai decouvert le OOO, et les pipelines longs, va falloir que intel trouve une pirouette marketing pour revenir plus tard a ces pipelines longs ( du genre : "on maitrise plus mieux")

Ridgefield/Wolfdale ?

Discussion: Question con: Pipeline et tout ca.

Outils de la discussion

Règles de messages