Nehalem et innovations

**newbie06** · 22/09/2008, 10h45

Envoyé par fefe

C'est a dire 95% du traffic sur un CPU normal (le reste etant les IO).

Sur un CPU utilisant le modèle mémoire x86.
Sur ARM, par exemple, toutes les requêtes ne sont pas nécessairement cohérentes, on peut très bien avoir des zones non partagées.

Sinon, pour le reste c'était très clair

**Yasko** · 22/09/2008, 10h48

OK pour les mécanismes de conservation de la cohérence du cache. Je ne comprenais pas trop pourquoi pour une lecture normale en cache on aurait eu intérêt à demander en 1er au L3 (ou LLC, c'est ça ? Last Level Cache ?)

Par contre, comment l'inclusion permet elle de savoir à partir de la présence d'une donnée en cache de niveau n qu'elle est également présente dans en cache de niveau n-1, n-2, et dans quel(s) core(s) précisement ? ("Si tes caches sont strictement inclusifs tu sais quel cores ont demande cette donnee et tu as meme des chances de savoir si ils l'ont encore.")
Ce sont des flags/tags qui permettent de savoir ça ?

Envoyé par fefe

Tu vas me dire que la politique de remplacement dans le cache est LRU donc en general on va choisir pour eviction quelqu'un qui n'a pas ete accede depuis longtemps. Mais le fait qu'il n'ait pas ete accede depuis longtemps dans le LLC veut malheureusement souvent dire que un core passait son temps a faire des hits dessus dans son L1.

Une politique de remplacement ne travaille que sur un seul niveau de cache ? Si une donnée est accédée en L1, la même donnée dans les niveaux supérieurs de cache n'est pas taggée comme récemment accédée ?
Si ce n'est pas fait, je suppose que c'est parce que ca génèrerait un traffic énorme (une cohérence du LRU en gros...)

**fefe** · 22/09/2008, 10h49

Oui pardon, normal=x86 pour moi

.

**fefe** · 22/09/2008, 10h57

Envoyé par Yasko

OK pour les mécanismes de conservation de la cohérence du cache. Je ne comprenais pas trop pourquoi pour une lecture normale en cache on aurait eu intérêt à demander en 1er au L3 (ou LLC, c'est ça ? Last Level Cache ?)

Last Level Cache, Mid Level Cache, Data Cache Unit, Instruction Fetch Unit (LLC,MLC,DCU,IFU) sont les nom communement employes par Intel pour designer leurs hierarchies de cache.
Tu ne demandes jamais en premier au L3, tu demandes aux precedents niveaux, cela arrive au dernier niveau de cache que quand tu as des echecs. Il y a aussi le cas des ecritures coherentes, ou si tu n'as pas la donnee en mode exclusif dans ton L1 ou L2 il te faut demander l'ownership au L3 qui se chargera de verifier que personne d'autre n'a une copie modifiee.

Par contre, comment l'inclusion permet elle de savoir à partir de la présence d'une donnée en LLC qu'elle est également présente dans des niveaux inférieurs de cache, et dans quel(s) core(s) précisement ? ("Si tes caches sont strictement inclusifs tu sais quel cores ont demande cette donnee et tu as meme des chances de savoir si ils l'ont encore.")
Ce sont des flags/tags qui permettent de savoir ça ?

Tu associes a chaque ligne de cache un vecteur de bit qui dit quel CPU y a accede, donc tu sais qui en a potentiellement une copie

Une politique de remplacement ne travaille que sur un seul niveau de cache ? Si une donnée est accédée en L1, la même donnée dans les niveaux supérieurs de cache n'est pas taggée comme récemment accédée ?
Si ce n'est pas fait, je suppose que c'est parce que ca génèrerait un traffic énorme (une cohérence du LRU en gros...)

Bien sur, la politique de remplacement est locale a chaque cache, sinon il faudrait transmettre des informations entre niveaux de caches a la meme vitesse que les acces au precedent niveau, ce qui detruirait l'un des interets des caches qui est l'economie progressive de bande passante a chaque niveau.
Si le L1 repond a un hit, il va mettre a jour son LRU, mais ne dira rien a personne. Si il devait le dire au L2, il faudrait un lien qui a la meme bande passante que le L1 entre le L1 et le L2, et il faudrait un port dedie de mise a jour du LRU dans le L2 fonctionnant a la meme vitesse que le L1 (etc, etc si tu voulais le faire pour tous les niveaux de cache).
Ce n'est pas praticable, par contre rien n'empeche les caches d'envoyer de temps en temps quelques informations de LRU pour eviter que les niveaux superieurs ne vieillissent trop, mais je ne connais pas de constructeur qui a dit explicitement le faire, donc je doute qu'il y ait des implementations.

**Yasko** · 22/09/2008, 11h08

Ok merki.

**Foudge** · 25/09/2008, 12h33

Intel Core i7 (Nehalem) : une architecture signée AMD ? par Fedy Abi-Chahla (= fefe ?)
http://www.presence-pc.com/tests/Cor...tecture-22817/

**Franck@x86** · 25/09/2008, 13h35

C'est vrai que de Fedy à Fefe y'a qu'un pas, mais ce n'est pas lui.

Fefe bosse pas dans la presse info, en fait il est agent secret et a plusieurs fois sauvé le Monde (le vrai Monde, pas le journal).
Mais euh peut-être que je ne devais pas le dire ?

**fefe** · 25/09/2008, 13h56

Argh, je suis demasque !!!

**Doc TB** · 25/09/2008, 23h06

Envoyé par Foudge

Intel Core i7 (Nehalem) : une architecture signée AMD ? par Fedy Abi-Chahla (= fefe ?)
http://www.presence-pc.com/tests/Cor...tecture-22817/

Rarement vu autant de conneries concentrées au même endroit. Le mec n'a visiblement même pas lu les présentations de base.

**Lissyx** · 26/09/2008, 22h00

Envoyé par Doc TB

Rarement vu autant de conneries concentrées au même endroit. Le mec n'a visiblement même pas lu les présentations de base.

\o/

**Franck@x86** · 26/09/2008, 23h51

il plaisante, vous devriez le connaître depuis le temps

**Childerik** · 27/09/2008, 09h50

Ceci dit, il y a quand même des coquilles en dehors des présentations de base.

Au premier abord la description fait invariablement penser à l’architecture Barcelona (K10) d’AMD : quad core natif, 3 niveaux de cache, un contrôleur mémoire intégré et un système d’interconnexions point-à-point à très hautes performances pour communiquer avec les périphériques et d’autres CPU dans des configurations multi processeurs. Ceci prouve bien que les choix technologiques d’AMD n’étaient pas mauvais en soit, c’est juste l’implémentation qui en a été faîte qui ne s’est pas avéré suffisamment compétitive.

Pour le L3, l'auteur ne connait visiblement pas les Itaniums et les Xeons Netburst.

Pour le second argument souligné, on ne comprend pas de quoi il parle : si c'est l'Hyper-Transport introduit par le K8, ou bien le L3 introduit dans le K10. Une personne avisée devine qu'il fait référence à l'implémentation du L3, car l'Hyper-Transport ne souffrait en rien d'un manque de compétitivité vu que c'est grâce à ça qu'AMD a grignoté des PDM dans les serveurs.

Sinon, on ne voit toujours pas en quoi un x-core non-natif est handicapant en soi, surtout pour les applications multi-threadées. C'est un délire de jeunesse.

Enfin, le contrôleur mémoire intégré, c'est Intel qui l'a testé en premier (Timna).

C’est ainsi que le simultaneous multi-threading (SMT) déjà apparu avec le Pentium 4 Northwood sous le nom d’Hyper Threading signe son grand retour

Une fois de plus, l'auteur semble ignorer l'histoire des Xeons : c'est le Prestonia qui a introduit l'HT, en février 2002, bien avant le P4B 3.06.

Associé aux 4 cœurs physiques, certaines versions de Nehalem incorporant deuxdie sur un même package seront donc capables d’exécuter simultanément jusqu’à 16 threads !

C'est là que Sam explique pourquoi l'auteur n'a vraisemblablement pas lu la présentation de base : l'architecture est modulaire, ce qui signifie qu'on peut inclure davantage de cores sur le même die.

Pour le reste de l'article, c'est un peu mieux. Je ne suis pas suffisament qualifié pour dire s'il existe aussi des coquilles dedans, mais j'aime bien la façon didactique de présenter la partie la plus difficile du sujet.

**Doc TB** · 27/09/2008, 12h21

"Contrairement à ce que nous avions observé lors du passage du Core au Core 2, Intel n’a cette fois pas modifié en profondeur son front-end."

Tout le contenu de l'article est du copier/coller + paraphrase de la présentation sous NDA qu'a donné Ronak Singhal à Londres il y a deux semaines. Je le sais, j'y étais

Sauf que les interprétations qu'il en fait sont souvent foireuses. En fait, les points qui sont correct dans l'article sont ceux expliqué par Ronak. Les autres sont soit bâclés, soit foireux.

**elkoo** · 28/09/2008, 02h23

Envoyé par Doc TB

Tout le contenu de l'article est du copier/coller + paraphrase de la présentation sous NDA qu'a donné Ronak Singhal à Londres il y a deux semaines. Je le sais, j'y étais

Sauf que les interprétations qu'il en fait sont souvent foireuses. En fait, les points qui sont correct dans l'article sont ceux expliqué par Ronak. Les autres sont soit bâclés, soit foireux.

C'est bon doc t'es en bonne voie, plus qu'à passer le lien du thread à l'intéressé et tu met Boulon à distance dans la compet' du droit de réponse

Envoyé par Foudge

Intel Core i7 (Nehalem) : une architecture signée AMD ? par Fedy Abi-Chahla (= fefe ?)
http://www.presence-pc.com/tests/Cor...tecture-22817/

Du coup, faut que fefe le prenne comment?

Il faudrait vraiment faire une encyclopédie du hard, ça rendrait bien service aux canards apprentis prêt à gober toutes les bêtises que l'on peut croiser sur le web.

**Foudge** · 01/10/2008, 14h39

Intel next generation CPU Core i7 tested
http://en.hardspell.com/doc/showcont...35&pageid=3364

Là il n'y a rien de technique, c'est juste quelques bench

**Yasko** · 01/10/2008, 14h49

Ca dépote sur la RAM...

**Møgluglu** · 01/10/2008, 16h29

Ça rame dans les jeux...

La faute au contrôleur mémoire qui s'éloigne autant du GPU qu'il s'approche du CPU?

**Foudge** · 01/10/2008, 16h37

Je dirais plutôt que dans les jeux, le Nehalem excelle autant qu'avant (à fréquence égale), mais c'est une question de point de vue

Et je pense que c'est plutôt à cause du SMT (certaines ressources sont partagées de manière statiques), du L1 un peu moins bon et un accès au LLC moins bon à cause de l'ajout d'un petit L2 privé et d'une taille diminuée (on passe de 2*6Mo à 1*8Mo).
Pour moi l'IMC est plutôt qqch de bénéfique pour les jeux.

edit: en plus de ça, comme c'est dit dans l'article d'HFR, le Nehalem a plutôt été pensé/optimisé pour une utilisation serveur, là où l'archi Core avait parfois du mal, pas pour les jeux et autre applis grand public où ça tournait déjà de manière excellente.

**newbie06** · 01/10/2008, 17h25

Faut pas exagerer, on perd 10% en basse resolution ; qui joue encore en 1024x768 sans AA ?

Et puis il ne faut pas oublier que les drivers de carte graphique ont probablement besoin de pas mal de tuning car ca genere du code ces betes-la

**Childerik** · 26/10/2008, 21h22

Envoyé par PeGGaaSuSS

Design final de la SmackOver : http://www.pcinpact.com/actu/news/45...ver-DX58SO.htm

C'est con qu'il y'est que 4 ports DIMM quand les autres en ont 6 :
http://www.hardware.fr/news/9896/x58...abyte-msi.html

Elle approche le taped out :

http://downloadcenter.intel.com/Prod...=3018&lang=eng

**Stephane@Mat.be** · 26/10/2008, 22h04

je l'ai reçue mardi c'te carte

Pas eu le temps de la tester encore alors que je devrais me grouiller vu que le NDA a été avancé de 15 jours

**PeGGaaSuSS** · 27/10/2008, 00h03

Elle y était à la soirée Centrino 2. Le ventirad des Ci7 est bien bleu, il illuminait tout le boitier

**fefe** · 27/10/2008, 08h25

Cote memoire il y a toujours un truc bien bizarre, 16GBps /25GBps c'est carrement mauvais pour un controleur memoire quand tu stream des acces sequentiels. Bien entendu c'est mieux qu'avant mais ca renifle le probleme (pas necessairement dans le hard, ca peut etre le bench qui est pourri et utilise pas le bon type de donnees, mais c'est le 2 eme bench qui est dans ce cas).

**Childerik** · 27/10/2008, 08h34

Envoyé par fefe

Cote memoire il y a toujours un truc bien bizarre, 16GBps /25GBps c'est carrement mauvais pour un controleur memoire quand tu stream des acces sequentiels. Bien entendu c'est mieux qu'avant mais ca renifle le probleme (pas necessairement dans le hard, ca peut etre le bench qui est pourri et utilise pas le bon type de donnees, mais c'est le 2 eme bench qui est dans ce cas).

Ce n'est pas la première fois qu'Everest peut se tromper. Il m'est arrivé de trouver du 4 Go/s sur P4C là où on devait s'attendre à 4,8 Go/s, toujours avec le même Everest à l'époque (c'était encore Aida32

).

L'immaturité du bench vis-à-vis du bus QPI peut jouer aussi. Il émule peut-être un classique DMI là où il n'y en a plus (problème de flag sur plate-forme Intel).

**fefe** · 27/10/2008, 08h53

Le QPI n'est pas sur le chemin vers la memoire sur cette machine, donc ne devrait pas avoir d'impact sur la bande passante memoire (par contre pour les problemes de perf dans les jeux, oui tout a fait possible).

**Doc TB** · 30/10/2008, 00h50

Je m'excuse par avance des honteux raccourcis que je suis en train de faire sur l'article Nehalem, mais malheureusement, c'était indisponible pour que la majorité puisse essayer de comprendre le truc.

**newbie06** · 30/10/2008, 08h25

Envoyé par Doc TB

Je m'excuse par avance des honteux raccourcis que je suis en train de faire sur l'article Nehalem, mais malheureusement, c'était indisponible pour que la majorité puisse essayer de comprendre le truc.

L'embargo est leve lundi ? Je suis presse de lire tout ca, meme si c'est edulcore

**fefe** · 30/10/2008, 08h51

Envoyé par Doc TB

Je m'excuse par avance des honteux raccourcis que je suis en train de faire sur l'article Nehalem, mais malheureusement, c'était indisponible pour que la majorité puisse essayer de comprendre le truc.

Ok il te reste 1 option :
- mettre des * dans l'article a chaque racourcis honteux
- ouvrir un topic ici qui explique pourquoi chaque * est un racourcis honteux (un peu comme les encadres tres techniques de certains de tes articles precedents).

De cette maniere tu garde ta credibilite

, tu ne perds pas les non specialistes, et potentiellement tu eduques quelques curieux. En plus pour les explications du forum je suis sur que tu n'auras meme pas a tout faire et que certains s'en chargeront

.

Si c'est trop de boulot de mettre des ancres dans les passages appropries de l'article, de toutes facons je suis certain qu'on ecrira qq chose ici pour expliquer a quel point ce journal est un scandale.

**Yasko** · 30/10/2008, 09h44

Envoyé par newbie06

Je suis presse de lire tout ca, meme si c'est edulcore

Non, quadcore.

**Foudge** · 30/10/2008, 11h32

Envoyé par Doc TB

Je m'excuse par avance des honteux raccourcis que je suis en train de faire sur l'article Nehalem, mais malheureusement, c'était indisponible pour que la majorité puisse essayer de comprendre le truc.

Indisponible ? Et ce sera disponible quand ?

Discussion: Nehalem et innovations

Outils de la discussion

Règles de messages