Nehalem et innovations

**Neo_13** · 19/09/2007, 15h14

Voilà, c'est parti...

Nehalem :
- nouvelle architecture (détails à définir)
- IMC comme l'A64 (détails à définir)
- CSI (HT like - détails à définir)
- quad core natif (pour ce que ça change...)
- octo core pas natif du coup (?)
- 45nm
- retour de l'hyperthreading à 2 process par core

bip bip...

**fefe** · 19/09/2007, 15h45

Octo core natif base sur le core Nehalem aussi, mais pas encore presente, une demo a aussi ete faite d'un dual socket quad core.

**Neo_13** · 19/09/2007, 15h49

Ok... J'hésite entre éditer le premier post pour le tenir à jour, et continuer la discussion... Je vote continuer la discussion...

Quelqu'un a vu sur le net un jeu des 7erreurs :D entre CSI et HT ?

d'autre part, on sait déjà quelle ram prendra l'IMC ? DDR3 - DDR4 - DDR8 (pourquoi s'emmerder) - ECC - Registered - FB-DIMM ?

**Franck@x86** · 19/09/2007, 18h44

L'hyperthreading j'arrive pas trop à comprendre son intérêt sur une archi à pipeline court comme celle-ci, car mine de rien c'est une grosse source de conflits dans les L1.

Sur P4 le pipeline était tellement peu rempli par un thread que ça compensait les conflits de cache (et encore, pas toujours).
Et pour finir, il faut un OS capable de distinguer une unit logique d'une physique, cf le problème soulevé y'a qques temps sur ici même :
http://www.x86-secret.com/index.php?...=newsd&nid=850

Enfin j'imagine que si c'est prévu c'est que ça a un intérêt (méchamment j'allais ajouter "autre que commercial"

)

(ou alors le pipeline n'est plus is court que ça :whistle: )

**Alexko** · 19/09/2007, 21h53

Je pense que l'article de RWT ne laisse plus beaucoup d'interrogations sur le CSI, même si je dois avouer qu'il y avait trop d'élec/physique pour moi et je n'ai pas tout lu. Et si on veut être précis ce n'est pas de l'HyperThreading mais du SMT, l'HT n'étant que l'implémentation du SMT au sein de NetBurst. Sa présence dans Nehalem est peut-être liée à une volonté de booster tout ce qui à trait à la virtualisation...

**Stéphane.P** · 20/09/2007, 09h59

J'espère qu'ils vont nous trouver un remplaçant à la FB-Dimm qui ne soit pas trop couteux.

**fefe** · 20/09/2007, 10h11

Et qui ne consomme pas 10W par barette...

**Stéphane.P** · 20/09/2007, 11h38

Envoyé par fefe

Et qui ne consomme pas 10W par barette...

:jap:
J'ai encore manqué de me bruler les doigts hier.

**Neo_13** · 11/10/2007, 08h35

Et si on commençait à envisager une DDRx-like en ZRAM histoire de gagner en densité, en dissipation, en fréquence et en latence. Apparement (avec ce que je sais des process, car je n'ai trouvé aucune infos spécifiques), le dev et la MaP seront coûteux, mais en prod, les coûts seront réduits (peut être même moins cher que la RAM actuelle, malgré le SOI obligatoire).

**fefe** · 11/10/2007, 09h39

Regarde du cote de la PCM

**jose99m** · 19/10/2007, 22h35

Envoyé par Franck@x86

L'hyperthreading j'arrive pas trop à comprendre son intérêt sur une archi à pipeline court comme celle-ci, car mine de rien c'est une grosse source de conflits dans les L1.

Cà existe depuis le POWER4 à 15 étages sur les entiers. Font ils çà pour le plaisir ?

**Alexko** · 20/10/2007, 09h40

Il s'agit plus probablement de mieux exploiter un pipeline très superscalaire, à mon humble avis. Le cache L1 pourrait gonfler un peu au passage, pour limiter les conflits.

**fefe** · 21/10/2007, 11h47

C'est dans le POWER 5 que IBM a introduit le SMT, pas dans le POWER 4 (http://en.wikipedia.org/wiki/IBM_POWER)
RMI XLR (MIPS) sorti en 2005 est SMT aussi avec un pipeline plutot court.

Sur un P4 l'interet du SMT etait de combler des bulles de pipeline essentiellement creees par les longues latences de la plupart des operations et le manque d'opportunites de speculation.
Dans un processeur a pipeline plus court, comme le signale Alexko le SMT sert plus a remplir des unites d'executions que l'OOO n'arrive pas a alimenter par manque de parallelisme d'instruction.

Gonfler le cache L1 signifie souvent en augmenter la latence et/ou en changer l'architecture de maniere significative. La methode souvent employee pour permettre d'avoir un L1 rapide et assez gros est d'avoir une associativite assez faible, ce qui ne va pas du tout avec la multiplication des threads dans le CPU (on se retrouve avec un cache plus gros certes, mais avec beaucoup plus de conflits). Disposer d'un cache un peu plus gros et rapide apres le L1 permet d'amortir les conflits dus au SMT, mais ca implique d'avoir 3 niveaux car les caches de plusieurs MB ne sont pas particulierement rapides.

**Alexko** · 21/10/2007, 12h00

Dans ce cas, que reste-t-il à Nehalem pour gérer les problèmes de conflits dans le L1 ?

**fefe** · 21/10/2007, 13h10

Garder une associativite "assez" elevee

**Alexko** · 21/10/2007, 14h36

Mais alors sans gonfler le L1 on se retrouve avec plus de conflits que sans SMT... et si on le gonfle on augmente la latence, ce qui est mauvais pour les performances en général, et single tread en particulier. Me trompé-je ?

**fefe** · 21/10/2007, 15h11

Tu ne te trompes pas, il est difficile de ne aps reduire la performance d'1thread donne quand on execute un autre thread SMT en meme temps.

De maniere generale toutes les ressources qui doivent etre partagees ont une taille apparente plus faible lors de l'execution SMT. L'avantage est que la performance n'augmente pas de maniere lineaire avec la taille de ces structures.
L'essentiel est que le partage d'une structure ne penalise pas plus que le partage d'une autre de maniere a ne pas creer de goulets d'etranglement (une partie des penalites associees au partages de buffer ne sont pas additives).

Si le SMT "apporte" 20% de performance, au final chacun des threads ne fonctionnera qu'a environ 60% de sa vitesse originale si il avait ete seul. Le partage du L1 n'etant qu'un des elements contribuant au ralentissement.

**Alexko** · 21/10/2007, 15h45

Donc si on prend un exemple concret, disons un rendu 3DS Max : sur un Quad Core w/ SMT 2-Way, il peut être plus judicieux d'utiliser 4 threads plutôt que 8 ? Si oui, ça ne simplifie pas la vie des développeurs...

**fefe** · 21/10/2007, 15h51

Non,
A supposer que ton scaling pour ajouter 1 core est de 1.8 et ton scaling pour ajouter un thread SMT est de 1.2
Perf a 4 threads : 3.6
Perf a 8 threads : 4.3

En revanche si tu as 1 thread de quake et N threads de 3DSmax, il vaut mieux ne faire tourner que 3 threads de 3DS max plutot que 7 parce que sinon ton quake va ralentir de maniere significative.

(bien entendu mes 1.8 et 1.2 sont hypothetiques, meme si plausibles).

**Alexko** · 21/10/2007, 15h53

OK je vois :jap:

**Fanche** · 22/10/2007, 08h17

Une petite question au passage sur le SMT sur une archi à pipeline long (genre HT sur p4 :D): en cas d'erreur de prédiction, est-ce que ça n'est pas encore plus pénalisant car il faut vider deux exécutions de l'unité de calcul?

et autre question (je sais, j'en profite): à partir du moment où on peut loger deux éxecutions dans un pipeline, pourquoi ne pas le faire? (mis à part les soucis de conflits de cache ou autre vu juste avant ce post) Je me demande si la longueur de pipeline est si importante que ça pour implémenter un HT. ou alors on peut mettre plus que deux éxecutions dans un pipeline (plutôt ça a déjà été fait?)?

**Childerik** · 22/10/2007, 10h48

Rien ne dit que l'erreur de prédiction frappe les deux instructions. Et quelque soit le nombre d'instructions qui occupe le pipeline, on mettra le même temps à vider 31 étages, non ? En fait, je n'en sait rien, mais j'imagine que ça doit fonctionner comme ça.

Normalement, le principe de l'HT, c'est d'occuper les étages inoccupés par une seconde instruction, en parallèle avec la première instruction, ce qui donne un gain de temps.

http://www.x86-secret.com/articles/cpu/3066/3066-4.htm

D'après l'article, tout irait bien dans le meilleur des mondes possibles si le programmeur prévoit la division de la mémoire cache pour éviter qu'une instruction nouvelle efface les données en cache d'une autre instruction et provoque ainsi une baisse des perf en SMT.

Mettre plus de deux instructions dans le pipeline compliquerait encore plus la situation : tu imagines une mémoire cache divisée par 4 ou par 8 par instruction ? Avec un L1 famélique sur Netburst de surcroît :D

**fefe** · 22/10/2007, 13h09

Fanche en cas d'erreur de prediction de branchement le flush ne s'applique qu'au flot d'instructions auquel le branch appartient. Le resultat est que quand un thread a des mauvaises predictions l'autre a plus de ressources.

Une des raisons pour ne pas le faire est que c'est complexe a implementer, et que chaque ressource doit etre partitionnee (statiquement ou dynamiquement). Le partitionnement statique coute plus de transistors (il te faut toujours un gros buffer si tu n as qu 1 thread) et le partitionnement dynamique t'amene a de nombreux scenarios de deadlock, livelock, et autres bugs qui demandent un design et une validation tres complexes.

**Fanche** · 22/10/2007, 13h09

effectivement, apparemment en cas d'erreur sur un thread, seul celui-ci est vidé du pipeline. Donc, mis à part les soucis de partage/conflits des caches et buffers, le nombre de threads dans le pipeline ne poserait pas de soucis.
Après j'ai l'impression qu'Intel mise surtout sur l'augmentation du cache L2, mais pourquoi ne pas augmenter plutôt le L1 (qui impliquerait, je pense, aussi une augmentation du cache L2)

**fefe** · 22/10/2007, 13h10

Tiens on a repondu en meme temps.

Pour gonfler le L1 cf ce que j'ai dit hier. Prescott a gonfle le L1 de Northwood mais ca ne s'est pas passe sans heurts (perte de perf a cause de la latence sur certaines applis)

**Fanche** · 22/10/2007, 13h17

oui effectivement je viens de relire, désolé... faudrait que je me fasse greffer quelques unités de sauvegarde de contexte dans le cerveau :D

**Yasko** · 22/10/2007, 14h47

Envoyé par fefe

Garder une associativite "assez" elevee

Ouais, full associative power !
C'était ma contribution après 1 mois de méditation sur l'associativité des caches. On peut dire que ca aura été profitable.

OK, je repars...

**fefe** · 22/10/2007, 15h22

disons que avec un cache fully associative la conso et le nombre de transistors necessaires augmentera du ratio (cout cellule CAM)/(cout cellule RAM), et la latence en prendra aussi un coup.
CAM = memoire addressable par contenu, wikipedia n'est pas tres detaille mais contient qq infos de base : http://en.wikipedia.org/wiki/Content_adressable_memory

**Yasko** · 23/10/2007, 11h00

OK pour la latence, par contre pour ce qui est du nombre de transistors et de la conso, on doit du coup pouvoir diminuer la taille du cache (ou ne pas l'augmenter) si on passe en fully associative.

Petite question subsidiaire sur le cache (désolé, je reviens à la charge, dans un topic différent (originellement, celui sur le K10 pour ceux qui essaient de suivre), mais toujours HS par rapport au topic :whistle

:
Pourquoi est-ce qu'on ne substitue pas les adresses de données du programme par des adresses en cache allouées lors du decode ?
Le cache serait fully associative (dans le sens ou l'on pourrait écrire n'importe ou) et l'on disposerait de l'adresse de la donnée dans le cache, ce qui permettrait d'y accéder rapidement (pas de recherche dans la line).

**Fanche** · 23/10/2007, 11h42

oui mais dans ce cas il faut faire une transcription d'adresse et stocker l'adresse dans le cache, c'est peut-être pas si avantageux que ça

Discussion: Nehalem et innovations

Outils de la discussion

Règles de messages