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 ?
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...)
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.
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 copiePar 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 ?
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.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...)
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.
fefe - Dillon Y'Bon
Intel Core i7 (Nehalem) : une architecture signée AMD ? par Fedy Abi-Chahla (= fefe ?)
http://www.presence-pc.com/tests/Cor...tecture-22817/
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 ?
Ceci dit, il y a quand même des coquilles en dehors des présentations de base.
Pour le L3, l'auteur ne connait visiblement pas les Itaniums et les Xeons Netburst.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 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).
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.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
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.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 !
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.
"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.
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
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.
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
Ça rame dans les jeux...
La faute au contrôleur mémoire qui s'éloigne autant du GPU qu'il s'approche du CPU?
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.
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
Elle approche le taped out :
http://downloadcenter.intel.com/Prod...=3018&lang=eng
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
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).
fefe - Dillon Y'Bon
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).
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).
fefe - Dillon Y'Bon
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.
fefe - Dillon Y'Bon