Article HFR sur la memoire

[fefe]

l'article est ici et est interressant a lire car les donnees cachent des infos sur la microarchitecture interne des processeurs en question. En appliquant "little's law" et en connaissant la taille de la ligne de cache (64 octets) on peut en deduire le nombre de requetes en parallele dans la machine allant vers la memoire. Pour maintenir ces requetes chac core a besoin de buffers avec un nombre d'entrees correspondant pour contenir ces requetes. Ces buffers sont difficiles a maintnir pleins en permanence donc il en faut un peu plus qu'il n y a de requetes en parallele en moyenne.

Voila ce que ca donne sur les donnees de l'article (s'espere que c est ok de les reproduire ici, je censurerai si c'est un probleme)
Buf = Lat * bw / line_size

conf	Lat	Bw-pk	Bw-1T	Buf-pk	buf-use	Cores needed for saturation
980x	78.8	19.2	10.9	23.6	13.4	2
980x	75.5	19.2	11.1	22.7	13.1	2
980x	71.2	19.2	11.4	21.4	12.7	2
980x	68.8	25.6	12.4	27.5	13.3	3
980x	64.2	25.6	12.7	25.7	12.7	3
980x	60.2	25.6	13.1	24.1	12.3	2
980x	61.5	32.0	13.5	30.7	13.0	3
980x	58.6	32.0	13.8	29.3	12.6	3
980x	57.7	32.0	13.8	28.8	12.4	3
980x	57.6	38.4	14.1	34.6	12.7	3
980x	56.1	38.4	14.4	33.7	12.6	3
980x		38.4				
						
975x	79.3	19.2	11.2	23.8	13.9	2
975x	74.9	19.2	11.6	22.5	13.6	2
975x	70	19.2	12	21.0	13.1	2
975x	65.7	25.6	13.2	26.3	13.6	2
975x	62.3	25.6	13.5	24.9	13.1	2
975x	58.5	25.6	13.8	23.4	12.6	2
975x	58.9	32.0	14.5	29.4	13.3	3
975x	56.4	32.0	14.7	28.2	13.0	3
975x	55.2	32.0	14.7	27.6	12.7	3
975x	52.3	38.4	15.8	31.4	12.9	3
975x	50.1	38.4	17	30.1	13.3	3
975x		38.4				
						
AM3-1090T	67.6	12.8	6.5	13.5	6.9	2
AM3-1090T	64.7	12.8	6.7	12.9	6.8	2
AM3-1090T	61.5	12.8	6.9	12.3	6.6	2
AM3-1090T	58	17.1	7.6	15.5	6.9	3
AM3-1090T	55.6	17.1	7.8	14.8	6.8	3
AM3-1090T	52.6	17.1	8	14.0	6.6	3
AM3-1090T	51.4	21.3	8.5	17.1	6.8	3
AM3-1090T	49.8	21.3	8.7	16.6	6.8	3
AM3-1090T	47.5	21.3	8.9	15.8	6.6	3
AM3-1090T	48	25.6	9.1	19.2	6.8	3
AM3-1090T	45.8	25.6	9.3	18.3	6.7	3
AM3-1090T	44	25.6	9.5	17.6	6.5	3
						
AM3-965	75.3	12.8	6.2	15.1	7.3	3
AM3-966	72.2	12.8	6.4	14.4	7.2	2
AM3-967	68.6	12.8	6.6	13.7	7.1	2
AM3-968	64	17.1	7	17.1	7.0	3
AM3-969	61.4	17.1	7.2	16.4	6.9	3
AM3-970	58.8	17.1	7.5	15.7	6.9	3
AM3-971	55.3	21.3	8.1	18.4	7.0	3
AM3-972	54.1	21.3	8.2	18.0	6.9	3
AM3-973	52.2	21.3	8.3	17.4	6.8	3
AM3-974	51.8	25.6	8.6	20.7	7.0	3
AM3-975	50.2	25.6	8.8	20.1	6.9	3
AM3-976	48.7	25.6	9	19.5	6.8	3
						
860	67	12.8	11	13.4	11.5	2
860	63.9	12.8	11.3	12.8	11.3	2
860	60.6	12.8	11.5	12.1	10.9	2
860	55.5	17.1	13.8	14.8	12.0	2
860	54.7	17.1	14.2	14.6	12.1	2
860	53.3	17.1	14.5	14.2	12.1	2
860	52	21.3	15.7	17.3	12.8	2
860	50.1	21.3	16	16.7	12.5	2
860	48.4	21.3	16.5	16.1	12.5	2
860	47.6	25.6	17	19.0	12.6	2
860	46.4	25.6	17.4	18.6	12.6	2
860	44.9	25.6	17.5	18.0	12.3	2

La lecture est assez aisee. On se rend vite compte que les processeurs Intel ont au moins 14 buffers par core (probablement 16) et les processeurs AMD en ont au moins 7 (probablement 8). Ceci explique l'avantage en bande passante des Intel sur les AMD tant qu'un seul core est actif. Avec seulement 8 buffers un core ne peut pas saturer la bande passante memoire. Au final il faut plus de cores pour saturer la memoire, mais vu que le nombre necessaire reste de 3 pour AMD et 2 pour Intel sur la plupart des plateformes testees par HFR, au final cela ne pose pas de probleme particulier pour saturer la bande passante quand les 4 cores sont actifs.

Quand on jette un oeil aux chiffres de perf multithreadees, AMD a encore un desavantage (mais nettement moins flagrant) qui dans ce cas ne peut provenir du buffering dans chaque core, mais plus probablement de l'architecture du controleur memoire lui meme.

Quant a ces 8 buffers vs 16, il est plus que probable que la presence de plus de buffers dans les archi Intel vient du fait que leurs prefetcher sont generalement plus agressifs et qu'ils ont plus d'espace pour stocker les prechargements en cours (il est peu probable que les 16 requetes soient des L1 miss).

[Møgluglu]

Très beau. J'applaudis.

[fefe]

Ce genre d'analyse est faisable sur beaucoup de parametres de la microarchitecture, mais je n'ai guere vu que ixbt le faire (l'article geant sur P4). Bon d'un autre cote je comprends que ca n'interresse pas grand monde .

[Alexko]

Sympa !

Par simple curiosité, ça a quel coût (transistors ou mm², power…) environ ces buffers ? Si c'est lié aux prefetchers, y'a une chance qu'on voit 16 buffers par modules sur Bulldozer ?

[fefe]

Le cout est tres dependant des autres fonctions qu'ils servent. En general c'est la file d'attente dans laquelle le cache met les echecs en cours pour pouvoir continuer a traiter des hits. Bien entendu apres traduction d'adresse de chaque acces au cache il faut comparer avec les addresses de tous les acces en cours suivis par ce buffer. Ce qui veut dire qu'en general ce sont des CAM, donc des structures couteuses. Il faut aussi un certain nombre de ports d'acces car le cache d'instruction doit aussi verifier qu'il n'y a pas conflit, de meme que le port de store et le ou les ports de load. C'est aussi le meilleur endroit pour localiser les prefetchers a detection de stream ce qui demande encore des ports d'acces supplementaires (en lecture pour la detection de stream et en ecriture pour pouvoir y placer des prefetch).
Au final une CAM a beaucoup de ports est tres chere et difficile a construire de grande taille tout en faisant le tout en 1 cycle (ce type d'operations ne se prete pas bien du tout au pipelining). Ca explique la relative petite taille en terme de nombre d'entrees de ces buffers sur chaque core par rapports a d'autres comme le ROB ou les schedulers.

Il me semblerait raisonable que chaque module Bulldozer ait 8 entrees, etant donne que leur approche semble etre de garder la micro architecture des modules simple et de juste les multiplier. Les agrandir me semble plutot contraire a la philosophie de design qu'AMD semble avoir suivi pour Bulldozer.

Une autre remarque, ces structures ne sont pas necessairement monolithiques, avoir une seule queue qui traite le tout simplifie la microarchitecture grandement mais limite la taille sauf emploi de circuiterie exotique couteuse (en terme d'efforts de design, de power, de surface et de risque de disfonctionnement etant donne l'absence d'integration de la validation de ce type de circuits aux outils classiques). Il est donc possible qu'Intel utilise une hierarchie de queues et qu'AMD se contente d'une seule, et ca expliquerait la difference de nombre d'entrees d'un facteur 2.
Le probleme au final est que pour permettre a un core de saturer la bande passante memoire grandissante des systemes actuels, il faut soit augmenter une structure tres compliquee, soit reduire la latence memoire. On peut aussi decider que l'on ne saturera la memoire qu'a l'aide de plusieurs core ce qui semble etre l'approche d'AMD.

[Alexko]

Le cout est tres dependant des autres fonctions […]

OK, merci !

Il me semblerait raisonable que chaque module Bulldozer ait 8 entrees, etant donne que leur approche semble etre de garder la micro architecture des modules simple et de juste les multiplier. Les agrandir me semble plutot contraire a la philosophie de design qu'AMD semble avoir suivi pour Bulldozer.

Une autre remarque, ces structures ne sont pas necessairement monolithiques, avoir une seule queue qui traite le tout simplifie la microarchitecture grandement mais limite la taille sauf emploi de circuiterie exotique couteuse (en terme d'efforts de design, de power, de surface et de risque de disfonctionnement etant donne l'absence d'integration de la validation de ce type de circuits aux outils classiques). Il est donc possible qu'Intel utilise une hierarchie de queues et qu'AMD se contente d'une seule, et ca expliquerait la difference de nombre d'entrees d'un facteur 2.
Le probleme au final est que pour permettre a un core de saturer la bande passante memoire grandissante des systemes actuels, il faut soit augmenter une structure tres compliquee, soit reduire la latence memoire. On peut aussi decider que l'on ne saturera la memoire qu'a l'aide de plusieurs core ce qui semble etre l'approche d'AMD.

Du coup ça ne ferait que 4 entrées par core sur Bulldozer (1 module = 2 "cores" dans la terminologie d'AMD). D'un autre côté, y'a vraiment beaucoup de workloads capables de saturer 2 canaux DDR3 sur 1 ou 2 threads ?

Ou plutôt, y'a vraiment beaucoup de workloads capables de saturer 2 canaux DDR3 sur 1 ou 2 threads et qui ne soient pas "facilement" scalables sur plus de threads ?

[fefe]

Pardon j ai inverse core et module donc 16/module

PS: encore une terminologie ridicule de marketing... Pourquoi ne pas dire 1 core, 2 clusters...

[Alexko]

Pardon j ai inverse core et module donc 16/module

PS: encore une terminologie ridicule de marketing... Pourquoi ne pas dire 1 core, 2 clusters...

Ils ne disent pas "1 core et 2 modules" parce que "2 cores" ça fait mieux ! :D

Du coup avec 16 entrées par modules, ça devrait permettre à un seul core (donc thread) de saturer la BP, puisque cette ressource du module devrait être partagée dynamiquement.

[fefe]

Non, a l'inverse, les unites de chargement rangement et les DL1 sont partitionnes statiquement de ce qui a ete montre, donc chaque core ne serait pas capable de saturer la bande passante memoire, mais un module le serait. Ces buffers stockent les echecs L1 et vu que les L1 ne sont pas unifies par module, ces queues seront partitionnees statiquement.

Certes le L2 est unifie, mais si tu as une queue au niveau du L2 la seule chose que tu peux ajouter dans ta queue unifiee en plus des echecs L1 (qui doivent etre trackes par L1) est un prechargement.

On verra bien a la sortie mais je parierais pour une bande passante comparable par core Bulldozer que sur un Phenom actuel.

[hellsing]

Sympa !

Par simple curiosité, ça a quel coût (transistors ou mm², power…) environ ces buffers ? Si c'est lié aux prefetchers, y'a une chance qu'on voit 16 buffers par modules sur Bulldozer ?

Assez dur de répondre:
ça dépend du standard de sortie (LVDS, CML ou autre truc proprio), de la charge derriere (si le buffer est à l autre bout de la puce y a de la perte etc).

En général c'est assez petiot pour des buffer interne, c'est basé sur des inverseurs CMOS (un Pmos en haut, un nmos en bas et basta) et c'est tout petiot et bouffe quedal.

[Møgluglu]

Je crois que fefe emploie le mot "buffer" au sens logiciel de mémoire tampon FIFO, plutôt qu'au sens électronique d'amplificateur de signal.

[hellsing]

Ouai surement, mais dans mon domaine le buffer sert à plein de chose : il amplifie le signal et donc le rend plus carré (super pratique pour transformer une sinusoide en carré), il implique un délai (souvent faible) qui peut s'avérer utile (en chainant plein de buffer on obtient grand délai).

Pour fefe c'est plus une D-FF (D flip flop), mais dans tous les cas c'est petiot (10µm*10µm max)

[fefe]

Ces buffers (et la logique de contrôle associée) sont suffisament gros pour être visibles sur un die a l oeil nu quand on sait ou chercher.

[Alexko]

Non, a l'inverse, les unites de chargement rangement et les DL1 sont partitionnes statiquement de ce qui a ete montre, donc chaque core ne serait pas capable de saturer la bande passante memoire, mais un module le serait. Ces buffers stockent les echecs L1 et vu que les L1 ne sont pas unifies par module, ces queues seront partitionnees statiquement.

Certes le L2 est unifie, mais si tu as une queue au niveau du L2 la seule chose que tu peux ajouter dans ta queue unifiee en plus des echecs L1 (qui doivent etre trackes par L1) est un prechargement.

On verra bien a la sortie mais je parierais pour une bande passante comparable par core Bulldozer que sur un Phenom actuel.

OK merci. Donc grosso modo, aucun changement à prévoir de ce côté.

[Møgluglu]

L'article a été mis à jour avec Sandy Bridge. J'ai la flemme d'aller réclamer les chiffres complets, mais juste sur le min/max ça donne :

conf	Lat	Bw-pk	Bw-1T	Buf-pk	buf-use	Cores needed for saturation	
2600K	78.8	12.0	10.7	14.8	13.2	2
	38.4	30.5	22.8	18.3	13.7	2
						
2500K	79.0	12.1	10.7	14.9	13.2	2
	39.0	30.9	22.4	18.8	13.7	2

Donc pas de différence notable de ce côté-là par rapport à Nehalem/Westmere, sinon un prefetch un peu plus efficace (?).

[fefe]

Oui.