Nehalem et innovations

[NitroG42]

Encore qques éléments sur le Nehalem :
http://www.hkepc.com/?id=568

Bon, je parle pas chinois, mais d'après ce que j'ai compris, ca a l'air assez sympa pour les serveurs quand même, surtout pour les serveurs multi-cpu, après je doute que les perfs soient aussi intéressante avec un seul proc.
Par contre 2009...
on a le temps de voir venir.

et là j'ai un petit fou-rire, "AMD 4x4".
aahaha.

[Yasko]

10-25% d'amélioration en single thread... C'est dans l'air du temps. le K10 est pile au milieu avec 17%.
Mais plutôt sur l'IPC ou plutôt sur la fréquence ?
Je me rappelle de rumeurs qui disaient que Nehalem serait un mix de Core2/Conroe et de Netburst (ce qui expliquerait le retour de l'HT ?). Si oui, ce serait plutôt la fréquence qui monterait ?

[Alexko]

J'aime bien le "Simultaneous SMT" :D

[fefe]

Merci a tous, oui j'etais en vacances

[Franck@x86]

http://www.xtremesystems.org/forums/...d.php?t=175737

Pas de bench hélas.
Il est intéressant de noter l'insertion des "petits" L2 entre les L1 et le gros L3 partagé entre les 4 cores.

[Foudge]

Si tu postes ce screen c'est que tu considères qu'il est crédible, je suppose. Rien qui pourrait penser que c'est un fake ?

[Alexko]

http://www.xtremesystems.org/forums/...d.php?t=175737

Pas de bench hélas.
Il est intéressant de noter l'insertion des "petits" L2 entre les L1 et le gros L3 partagé entre les 4 cores.

C'est vrai que cette hiérarchie est intéressante... pour ne pas dire surprenante. J'ai hâte de voir ce que ça donne en pratique.

[Neo_13]

http://www.xtremesystems.org/forums/...d.php?t=175737

Pas de bench hélas.
Il est intéressant de noter l'insertion des "petits" L2 entre les L1 et le gros L3 partagé entre les 4 cores.

je trouve que cette archi sent moins bon que très gros L2 partagé et pas de L3... Ils ont qu'à embaucher des magiciens pour gérer la latence.

[fefe]

je trouve que cette archi sent moins bon que très gros L2 partagé et pas de L3... Ils ont qu'à embaucher des magiciens pour gérer la latence.

Les magiciens a employer ne seraient pas pour la latence, mais pour la bande passante de ton L2 geant qui se prendrait les miss de 8 threads sur 32K*4 de cache L1. Les gros caches n'ont en general qu'un seul port d'acces, et si tu multiplies les ports d'acces ca a aussi une bonne tendance a multiplier la surface consommee et le power (et a ajouter un peu de latence).

J'oubliais, inserer un "petit" L2 entre L1 et L3 partage augmente la latence de ce L3 de maniere significative, sauf si les access sont faits en parallele (mais dans ce cas la il n'y a plus d'effet de reduction de bande passante vers le L3).

[Franck@x86]

Si tu postes ce screen c'est que tu considères qu'il est crédible, je suppose. Rien qui pourrait penser que c'est un fake ?

Non ce n'est pas un fake, mais cela ne veut pas dire que les infos affichées sont correctes. J'ai déjà eu confirmation que le L1D de 16Ko est un bug, la taille réelle est de 32Ko (mêmes L1 que le C2D donc). Les autres infos des caches sont correctes. La fréquence d'horloge semble également correcte (2133 MHz mesurés et 2.13GHz dans le name string). Quant au FSB, je ne peux pas dire, il semble cohérent avec le coeff et la fréquence interne, cela dit ça peut très bien être un bug.

je trouve que cette archi sent moins bon que très gros L2 partagé et pas de L3... Ils ont qu'à embaucher des magiciens pour gérer la latence.

Je cite Fefe :
"Quand un cache devient trop lent on a tendance a intercaler un cache plus petit et plus rapide avant celui-ci (cela devient donc un cache de niveau 2)."

Nehalem applique cette règle à la lettre.
A la différence du Phenom pour lequel AMD a ajouté un L3 derrière les L1 et L2 hérités de l'A64, le Nehalem s'est vu insérer le L2 entre des L1 qu'on sait rapides, et un L3 partagé entre quatre cores, avec toutes les conséquences que cela implique sur sa BP.

Ce choix ne me semble pas incohérent, loin s'en faut. Ma seule interrogation c'est le power, parce que tous ces caches ça doit pomper. Reste à déterminer si le L3 est "full speed"...

[Neo_13]

Les magiciens a employer ne seraient pas pour la latence, mais pour la bande passante de ton L2 geant qui se prendrait les miss de 8 threads sur 32K*4 de cache L1. Les gros caches n'ont en general qu'un seul port d'acces, et si tu multiplies les ports d'acces ca a aussi une bonne tendance a multiplier la surface consommee et le power (et a ajouter un peu de latence).

J'oubliais, inserer un "petit" L2 entre L1 et L3 partage augmente la latence de ce L3 de maniere significative, sauf si les access sont faits en parallele (mais dans ce cas la il n'y a plus d'effet de reduction de bande passante vers le L3).

et les probabilités que les accès se fassent en parallèle sur nehalem, vu le peu qu'on en sait aujourd'hui ? Elevé/moyenne/très faible ?

[Franck@x86]

et les probabilités que les accès se fassent en parallèle sur nehalem, vu le peu qu'on en sait aujourd'hui ? Elevé/moyenne/très faible ?

Non c'est un choix architectural, au sens que le NHM "serait" capable de tels accès parallèles.

[Neo_13]

oui quand je parlais de probabilités, c'est les probabilités qu'intel fasse ce choix selon l'estimation individuelle subjective de chacun.

Personnellement, j'en doute, car quelque part, ça fait une réserve de performances en cas de besoin (concurrents devenus performants par exemple)

[Franck@x86]

ah oui pardon j'ai compris de travers.

[fefe]

et les probabilités que les accès se fassent en parallèle sur nehalem, vu le peu qu'on en sait aujourd'hui ? Elevé/moyenne/très faible ?

Ca depend de ton application bien sur, mais une des proprietes fondamentales des acces memoire est qu'ils arrivent en burst et non pas de maniere uniforme (les prefetchers ne sont pas pour rien dans se phenomene).

Dans une platforme mono thread, on peut avoir un cache avec une bande passante raisonable (tous les L2 intel recents peuvent effectuer un lookup tous les 2 cycles), et quand un burst arrive on penalise la latence de maniere moderee: en effet le nombre de miss qu'un core peut emettre en parallele avant de stall est assez limite (<10). Donc avec un peu de buffering ton cache reussit a servir toutes ces requetes sans trop de problemes, avec une penalite de quelques cycles lorsque tu arrives a la fin du burst, mais vu qu'en general les requetes a la fin d'un burst sont des prefetch, cela a peu ou pas d'impact sur les performances.

Bien entendu la grande majorite du temps cette bande passante sera la pour rien... Maintenant, tu multiplies le nombre de thread par 8. Que se passe t'il ?

Tu as en moyenne largement la bande passante pour servir tes applis, enfin dans la majorite des applications, il y en a tout de meme un certain nombre ou tu commenceras a saturer, mais suffisament peu pour que en moyenne cela ne semble pas etre un probleme majeur.
Donc pourquoi ne pas partager ce cache entre plus de monde ? deja, il va falloir pouvoir bufferiser 8 fois plus de requetes (allez 4x si c'est du SMT et que la ressource qui permet de track les miss en parallele est partagee). Cela fait de gros (tres gros?) buffers. Qui plus est cela augmente aussi de maniere tres significative le temps d'attente des requetes, surtout quand un core arrive alors qu'un autre vient de remplir le buffer geant devant ton cache.

Tu peux decider d'implementer un mecanisme out-of-order dans ton buffer pour essayer de donner une plus grosse priorite a certaines requetes, mais pour ce faire tu dois sacrifier de la latence pour tout le monde, et aps mal de transistors.

Donc au final, meme si un tel L2 pourrait fournir en moyenne une bande passante apropriee, il va etre sature extremement frequement, des lors que les differents thread auront des burst proches les uns des autres dans le temps. En pratique c'est tres frequent (en opposition au cas assez rare ou la bande passante moyenne sera proche du pic), et ce surtout dans les applications orientees serveur, ou le taux d'echec dans le L1 est particulierement eleve, et les prefetcher particulierement efficaces a generer du traffic inutile (quand actifs). Sur les applications client c'est un peu plus rare, et si le core n'etait pas destine a etre integre a des clients et serveurs, le choix serait potentiellement plus discuttable (ca ne le rend pas mauvais pour autant).

Question consommation d'energie, le taux d'activite moyen des caches est generalement faible donc le power "actif" est assez limite, et dans le cas ou ce taux d'activite serait tres eleve, en pratique le reste du CPU passe son temps a attendre la memoire donc consomme peu (donc la somme power CPU + power cache reste faible).
Il reste donc juste ce qui est l'essentiel de la consommation d'un cache: le leakage. Ce leakage est proportionnel a la surface occupee (donc la taille de tes caches), a supposer que tous tes caches operent a meme frequence et voltages, 4x256k de L2 en supplement de 8M vont t'ajouter 13% de power de leakage, a supposer que la surface investie dans ces caches n'ait pas ete investie dans un 9eme MB. En revanche avoir a supporter moins de bande passante te permet potentiellement d'utiliser un L3 fonctionnant a une frequence plus basse et un voltage plus bas, ce qui a un effet non negligeable sur le leakage en question.

[Franck@x86]

4x256k de L2 en supplement de 8M vont t'ajouter 13% de power de leakage.

ça c'est de la précision !

Y'a donc de fortes chances que le L3 utilise une fréquence et une tension (et non pas un voltage ) différentes de celles du reste du CPU. Enfin ça semblerait logique, ne serait-ce que pour un meilleur contrôle de l'enveloppe thermique du CPU.

[fefe]

ça c'est de la précision !

1M/8M =12.5%

Et desole, mes reponses sont bourrees d'anglicismes...

Y'a donc de fortes chances que le L3 utilise une fréquence et une tension (et non pas un voltage ) différentes de celles du reste du CPU. Enfin ça semblerait logique, ne serait-ce que pour un meilleur contrôle de l'enveloppe thermique du CPU.

Si c'est le cas, cela coute de la latence supplementaire pour changer de domaine de frequence lors d'un acces au cache (et c'est une latence loin d'etre negligeable puisqu'intervenant 2x par acces).

[Neo_13]

merci fefe

[Yasko]

Ca depend de ton application bien sur, mais une des proprietes fondamentales des acces memoire est qu'ils arrivent en burst et non pas de maniere uniforme (les prefetchers ne sont pas pour rien dans ce phenomene).
[...]
Tu peux decider d'implementer un mecanisme out-of-order dans ton buffer pour essayer de donner une plus grosse priorite a certaines requetes, mais pour ce faire tu dois sacrifier de la latence pour tout le monde, et pas mal de transistors.

Pourquoi le prefetch génère t'il des pics ? Le mécanisme de découverte se fait par bloc, et non pas de manière continue dans le temps ? (en fonction de ce qui il y a dans le L1I ?).
Est-ce que la logique d'OOO/tri selon priorité dont tu parles à un niveau buffer ne devrait pas être de la responsabilité du prefetcher, de même que temporiser parfois afin d'éviter les "burst" ?
Surtout que comme tu dis, ce n'est "que" du prefetch. Les demandes de chargement liées à un miss sont-elles prioritaires (ca implique de pouvoir les reconnaitre).
(désolé hein, il doit y avoir un peu de tout et surtout du n'importe quoi... )

[fefe]

Un prefetcher a une periode pendant laquelle il detecte des patterns d'acces et une periode ou il envoie des prefetchs. Sachant que dans la majorite des cas il realise "trop tard" sur quelles adresses envoyer des prefetchs, le plus tot est le mieux, d'ou l'aspect burst des acces les aux prefetch.

Cis dessus je dis "trop tard", et c'est dans le sens ou "a l'heure" pour un prechargement veut dire que le core va demander la donnee une fois que le prefetcher l'a ramene dans un cache, et non pas pendant que le prefetch est en cours (dans ce cas la il ne masque qu'une partie de la latence). Si je veux essayer de me rapprocher de "a l'heure" il faut que je specule plus et que j'envoie des prefetch de plus en plus tot, donc lorsque j'ai detecte un pattern qui me laisse deviner le prochain acces j'envoie non pas un prechargement mais plusieurs pour tenter d'arriver plus en avance. Je viens de decrire la creation d'un burst .

Il y a d'autres raisons a l'aspect burst des acces memoire, les prefetcher etant surtout un amplificateur. Le premier est que malgre l'OOO dans le core et le "memory disambiguation" on a souvent des requetes memoires qui finissent par bloquer les autres load dans le pipeline d'etre traites. Lorsque cet acces (a longue latence) est servi, il debloque un groupe d'acces qui vont arriver en burst dans le sous systeme memoire, un de ces acces ayant de nouveau une grande chance d'en bloquer un paquet dans le pipeline.

C'est un peu comme l'effet acordeon dans les embouteillages...

Sinon les prefetchers sont deja "temporises" dans le sens ou les vraies requetes sont prioritaires sur les prefetch. En revanche il n'y a pas de raison d'attendre si on a predit qu'une adresse allait etre utilisee, la demander le plus tot possible est le mieux.

[Yasko]

OK merci.

Par contre, je ne suis pas sur d'avoir compris le lien entre le fait de prédire tôt et le nombre de préchargement.

Si je veux essayer de me rapprocher de "a l'heure" il faut que je specule plus et que j'envoie des prefetch de plus en plus tot, donc lorsque j'ai detecte un pattern qui me laisse deviner le prochain acces j'envoie non pas un prechargement mais plusieurs pour tenter d'arriver plus en avance.

C'est parce que :
- une fois détecté un pattern, celui-ci permet de connaitre d'un coup plusieurs chargements à venir, et du coup on envoie les préchargement tous ensemble afin d'avoir une latence minimale, ou
- parce que plus on fait la prédiction tôt, moins le pattern est précis, et plus on a de chargements hypothétiques et donc de préchargements à faire si on veut être sur de tomber juste

[fefe]

Les 2:
- le premier parce que un prefetcher va detecter un stream et donc lancer les prefetchs de ce stream
- le second parce que tu as multiples prefetchers par core et que chacun d'entre eux va essayer de predire les acces et multiplier les prefetch en esperant que l'un d'entre eux aura raison.

[Franck@x86]

Après explications de Fefe voici une traduction Fefe vers langage usuel

Partons donc de l'hypothèse que le NHM fût composé de 4 cores (8 threads avec SMT) et d'un gros L2 partagé entre les quatre cores. Dès lors qu'une majeure partie des 8 threads sollicite de façon soutenue le sous système de cache, se pose le problème au L2 de répondre à chacun le plus rapidement possible. La solution en première instance consiste à multiplier les ports d'accès au cache L2, càd de passer de 1 port à 2, ou mieux 4 ports. Impossible, car un cache à 4 ports aurait une surface entre 2 et 3x plus importante qu'un cache simple port.

D'où l'idée d'insérer des L2 pour éviter l'étranglement du L3. Comment ?
Supposons que chacun des L2 ait un taux d'échec de 50% (c'est beaucoup). Ca veut dire que 50% des requêtes sont gérées par le L2, et non par le L3. Ca le soulage donc de moitié les requêtes qui arrivent au L3. Si avec 1 port le cache partagé peut alimenter 2 cores sans pb, avec les L2 entre deux il peut en alimenter 4. Et ça c'est puissant.

Bon j'espère que c'est plus clair ainsi.

Pour les accès L2/L3 en parallèle : en fait ça ferait perdre tout l'intérêt de ce qui vient d'être expliqué, donc NHM ne le fait pas. Donc, la présence du L2 augmente quelque peu la latence d'accès au L3.

[fefe]

Merci Franck

[claneys]

merci frank et fefe.

[Doc TB]

D'où l'idée d'insérer des L2 pour éviter l'étranglement du L3. Comment ?
Supposons que chacun des L2 ait un taux d'échec de 50% (c'est beaucoup). Ca veut dire que 50% des requêtes sont gérées par le L2, et non par le L3. Ca le soulage donc de moitié les requêtes qui arrivent au L3. Si avec 1 port le cache partagé peut alimenter 2 cores sans pb, avec les L2 entre deux il peut en alimenter 4. Et ça c'est puissant.

Donc ça sent le 8 cores dual-die...

[fefe]

...

[Alexko]

Donc ça sent le 8 cores dual-die...

On ne change pas une équipe qui gagne...

[PeGGaaSuSS]

Photos d'un Nehalem et de sa mobo : http://www.xtremesystems.org/forums/...d.php?t=178009
Et le cul : http://www.xtremesystems.org/forums/...d.php?t=177122

[newbie06]

Un slide d'une presentation officielle : spec rate int/fp (Ref: Ace's hardware).
Comme d'habitude ca peut etre un fake.

[Warning : je ne connais pas grand-chose aux chips serveurs, donc je raconte sans doute des aneries.]

J'avoue ne pas bien comprendre (chiffres extraits un peu au pif du site SPEC) :

- la ref de 1 est donnee pour un 5160 ; c'est un dual core qu'on peut trouver en dual socket ; SPEC int rate dans les ~60 pour quatre coeurs et SPEC fp rate ~45

- le 5365 a un SPEC int rate dans les 60 pour 4 coeurs et dans les 115 pour 8; SPEC fp rate dans les 37 (4) et dans les 62

Or sur le slide ci-dessus, le 5365 serait 1,5 x plus rapide que le 5160. A nombre de coeur egal, ou en doublant le nombre de coeurs, je n'arrive pas a voir le rapport.

En tout cas les chiffres du Nehalem sont clairement en 8 coeurs.