Nehalem et innovations

[ylyad]

fefe: OK pour ces arguments, mais dans ce cas-là, le limiter aux EE (en adaptant un peu le message et en élargissant un peu la gamme) reviendrait quasiment au même.

[fefe]

fefe: OK pour ces arguments, mais dans ce cas-là, le limiter aux EE (en adaptant un peu le message et en élargissant un peu la gamme) reviendrait quasiment au même.

Oui, et nous discutons sur une rumeur qui semble dire que seuls les produits derives de Bloomfield seraient overclockables (la version avec QPI) et pas les autres. Apres il faudra voir les gammes qui sont couvertes avec Bloomfield. Il est possible que la rumeur soit vraie et que cela se produise pour des raisons de differences techniques entre Bloomfield et les autres. Cela ne me semble pas etre une partition EE/le reste a premiere vue. Si la rumeur est fausse, de toutes facons l'overclocking sur Bloomfield sera different des autres plateformes Nehalem (QPI vs PCIe).

La raison aujourd'hui pour ne debloquer le multiplieur que sur le plus haut de gamme, est que la gamme de produit reste immunisee au remarquage de CPUs, mais ca n'empeche pas d'OC toute la gamme, meme si c'est un peu plus dur que sur un EE.

[Franck@x86]

ce qui est certain c'est que le Nehalem bénéficiera (soyons optimiste) d'une gestion assez inédite des fréquences et tension. Il semblerait que l'externalisation des FID/VID soit abandonnée, au profit d'une gestion orientée power. En gros, le processeur adapte lui-même fréquences (au pluriel car il y aura plusieurs plans de fréq) et tension en fonction du power visé.
C'est bien, mais ça veut aussi dire que le CPU contrôle désormais certains paramètres liés à l'o/c. Je ne serais pas étonné que toute augmentation de tension soit impossible, sous couvert de protection de la dissipation. Ca suffirait à limiter le potentiel d'o/c.

Je viens de discuter avec qqu'un de chez Asus, il semblerait que la rumeur ne soit pas complètement infondée quand même...

[fefe]

Je viens de discuter avec qqu'un de chez Asus, il semblerait que la rumeur ne soit pas complètement infondée quand même...

Je suis convaincu qu'il va y avoir des changements significatifs pour les overclockeurs lies aux changement de l'architecture systeme sur Nehalem, et si on considere l'etat actuel de l'overclocking sur CPU intel cela ne peut guere aller que dans le mauvais sens (le rendre plus difficile). Mais ca ne veut pas dire non plus que tout sera impossible.

[Oxygen3]

Maintenant j'y crois pas trop, l'o/c est devenu un tel enjeu commercial que ça reveindrait à se tirer une balle dans le pied. Eventuellement ça se concevrait si AMD était définitivement hors course, et ... euh ...

J'ai plus l'impression que le 'blocage' de l'O/C concerne comme toujours une mauvaise lecture par Fudzilla.

Tout comme AMD effectivement, le CPU va intégrer un PLL pour la génération du clock de la mémoire, et peut-être un second pour la génération du clock CPU.
Je penche plutot vers un mécanisme de blocage des deux PLL ensemble et/ou de contrôle que l'un fiat pas n'importe quoi.

La "limitation" de l'O/C serait a mon sens plutot une limitation de déconnage complet avec de la désynchro dans tous les sens et/ou de blocage d'un PLL pour les mécanismes d'i/o avec les autres puces sur une CM (en gros, un blocage de la fréquence du PCI-Ex ) vu que si tout le monde utilisait le PLL du CPU, ca deviendrait n'importe quoi

[Franck@x86]

On dirait bien qu'Intel souhaite segmenter le marché avec l'overclock en le réservant aux versions haut de gamme (Bloomfield 1366). La version Lynnfield 1160 serait ainsi privée de toute modif, mais ça reste au conditionnel car les intégrateurs ne l'ont pas encore eue en main.

[newbie06]

Score CPU 3dmark: http://forums.vr-zone.com/showthread.php?t=283772

[fefe]

32KB de L2 il semble que soit cpuz a un probleme soit la plateforme testee,,,,

[Foudge]

Ca va faire mal à AMD :
http://www.anandtech.com/cpuchipsets...oc.aspx?i=3326
Résumer en français : http://www.hardware.fr/news/lire/05-06-2008/

[newbie06]

Y'a au moins un bug dans l'article : vitesse sur x264 ; soit il a inverse les chiffres, soit le Nehalem est plus lent ; je penche pour la premiere hypothese

En tout cas, impressionnant ! Esperons que d'ici 2009 la DDR3 aura suffisamment baisse

[Alexko]

Ca va faire mal à AMD :
http://www.anandtech.com/cpuchipsets...oc.aspx?i=3326
Résumer en français : http://www.hardware.fr/news/lire/05-06-2008/

C'est vrai que... wow.

Newbie => Non y'a pas de problème, le graphique est en FPS !

[newbie06]

Trop fort, il vient de corriger le bug x264, les barres etaient inversees...
Et puis si tu me crois pas, lis les commentaires

[Alexko]

Ah ok, j'ai vu que la bonne version, moi

[Franck@x86]

Esperons que d'ici 2009 la DDR3 aura suffisamment baisse

Je viens de visiter qques sites et les prix ont déjà pas mal baissé.

Tu peux trouver 2 Go de DDR3 PC10600 pour une 100aine d'euros, et pas de la noname :

http://www.materiel.net/ctl/PC_de_bu...d_Edition.html

ou encore

http://www.materiel.net/ctl/PC_de_bu...PC8500_NQ.html

Ca devient abordable, même si bon les vitesses vont encore beaucoup augmenter.

[fefe]

A priori ce sont tous des benchs ou HT est on, donc l'augmentation de perf sans HT sur ces tests est probablement entre 10 et 30%.

Ca en reste assez joli, surtout que le power a tendance a descendre avec les steppings (cf Penryn), et meme sans ca ils ne partent aps d'une mauvaise situation.

[newbie06]

A priori ce sont tous des benchs ou HT est on, donc l'augmentation de perf sans HT sur ces tests est probablement entre 10 et 30%.

J'ai surtout ete impressionne par la bande passante et les perfs des caches, et la je ne pense pas que le HT joue. Le reste je m'en tape, c'est du Windows et c'est pas recompile

Je viens de visiter qques sites et les prix ont déjà pas mal baissé.

Ha oui en effet, donc d'ici 2009 ca devrait devenir franchement interessant !

[fefe]

Bof 13GB/s quand la RAM peut en debiter 24 ? C'est loin de m'impressioner... Quant a la latence memoire, ils ne comparent pas a un C2Q avec un FSB a 1600 et de la DDR2 avec de bons timings... Donc la latence du Penryn est tres conservative.

En revanche la DDR1066 qu'ils ont utilisee n'est pas demente non plus donc NHM n'est pas super avantage non plus.

[fefe]

Autre chose Anand en extase devant un cache de 8M avec 39 cycles de latence je ne comprends pas.

Penryn 6M 15 clocks, Conroe 4M 14 clocks, un core 2 avec 8M de cache aurait probablement fait 16 clocks. Maintenant oui c'est un L3, le L2 qu'ils ajoutent fait 11 clocks.
11+16 ca donne 27 chez moi (en pratique il y a possiblite d'avoir au moins 3 ou 4 cycles recouverts donc a peu pres n'importe quelle latence entre 25 et 30 cycles me semble raisonable pour un L3 de 8M.

39 ? Non, ce n'est pas bon. Et ce n'est pas parce que le L3 du Phenom est pire que ca rend la latence bonne.
Bien entendu il est probable que comme pour le Phenom le cache soit sur un different domaine de frequence et de voltage, ce qui force des latences supplementaires pour passer de l'un a l'autre. 10-14 clocks pour ca (changer de domaine de clock/voltage) me semble un peu haut mais apres tout peut etre que je suis trop exigeant ?

[newbie06]

Ils ne se seraient pas aussi laisse un peu de marge pour augmenter la taille de cache sans avoir a changer les latences ?

Et puis oui tu es trop exigeant, je prefere voir en terme d'evolution.
(mode parano) Et le marketing d'Intel aussi, donc ils se donnent de la marge pour sortir un truc encore mieux a peu de frais (peu de frais d'engineering mais plein de frais pour les clients)

[Yasko]

Et puis oui tu es trop exigeant, je prefere voir en terme d'evolution.
(mode parano) Et le marketing d'Intel aussi, donc ils se donnent de la marge pour sortir un truc encore mieux a peu de frais (peu de frais d'engineering mais plein de frais pour les clients)

C'est aussi ce que se demande Anand dans sa conclusion : qu'est-ce qu'Intel va pouvoir nous trouver pour son prochain tock avec Sandy Bridge, pour arriver à garder ce rythme.
C'est quand le prochain coup qu'ils déçoivent ? (question que doit se poser AMD...)

Edit :
Ah, on me répond "Atom" dans mon oreillette.

[Childerik]

C'est quand le prochain coup qu'ils déçoivent ? (question que doit se poser AMD...)

Jamais : AMD et Via auront coulé d'ici là . Ou ils se seront reconverti à temps dans les puces pour périphériques sideshow

[fefe]

Bon, je viens de faire un peu de maths (Little's law pour ceux qui connaissent) et je crois que je comprends ce qui se passe pour la bande passante. La question fondamentale est est-ce que Everest utilise des streaming read vers un espace write combine pour leur test de bande passante en lecture ou non.

Si oui alors les prefetchers ne trigger pas et il y a gachis de bande passante pour les plateformes qui sont limites par les fill buffers (buffers qui track les requetes en cours vers la memoire). Dans le cas de Penryn ca ne se voit pas trop parce que le FSB devient vite un probleme, dans le cas de Nehalem, pas de FSB qui limite donc ce sont les buffers qui limitent.

Sur les plateformes a FSB utiliser des read qui peuvent etre reordonnes (vers WC space) permet d'augmenter la bande passante parce qu'on utilise mieux le FSB, quand on enleve le FSB ils deviennent plus problematiques qu'autre chose.

Bref, sur des reads normaux je m'attends a au moins 17GB/s avec un thread sur cette plateforme et 22-24 GB/s avec 2 threads.

Si je me trompes sur l'histoire du bench, alors Nehalem sux vraiment pour la bande passante memoire.

Je laisse qui le veut traduire mon Mandarin vers qq chose de plus interpretable.

[Yasko]

Je laisse qui le veut traduire mon Mandarin vers qq chose de plus interpretable.

OK, pas de problème.

Je viens de procéder à quelques savants calculs (la loi du Petit pour ceux qui la connaissent) et je crois avoir identifié la source du problème de la bande passante. La question fondamentale est de savoir si Everest utilise des lecture en flux vers un espace d'écriture combinée pour leur test de bande passante en lecture, ou non.

Si oui, alors les préchargements ne se déclenchent pas et il y a gâchis de bande passante pour les plateformes limitées par les registres de remplissage (registres qui suivent les requêtes en cours vers la mémoire). Dans le cas de Penryn, cela ne se voit pas trop parce que le bus devient vite un problème, dans le cas de Nehalem, pas de bus qui limite, donc ce sont les registres qui limitent.

Sur les plateformes utilisant un bus limité, utiliser des lectures qui peuvent être réordonnées (vers l'espace toilette) permet d'augmenter la bande passante parce qu'on utilise mieux le bus. Quand on enlève le bus ils deviennent plus problématiques qu'autre chose.

Bref, sur des lectures normales je m'attends a au moins 17GB/s avec un fil sur cette plateforme et 22-24 GB/s avec 2 fils.

Si je me trompe sur l'histoire du banc, alors Nehalem est vraiment décevant pour la bande passante mémoire.


Voila, je pense que c'est bien plus clair comme ça.

De rien.

(et désolé de pourrir ce topic)

Edit :
Ah, je crois que je suis battu par Google. J'ai tenté une traduction français vers anglais vers français, le résultat est au delà de toute espérance. Je ne vous le colle pas ici parce que ca risque de faire beaucoup de flood pour un seul post, mais je vous mets la conclusion quand même, qui a elle seule mérite le détour :

Si je tubes sur l'histoire de la magistrature, puis Nehalem sux vraiment pour la bande passante mémoire.

[fefe]

Adopte...

[newbie06]

T'as oublie de traduire les GB/s. Tres decevant...

[Neo_13]

Et puis l'histoire du chiotte au lieu de Write combine...

[Foudge]

J'ai bien aimé aussi l'espace toilette

[Yasko]

Oui, il ne manquait plus que quelques flush
(=> chasse d'eau)

[Alexko]

J'ai bien aimé aussi l'espace toilette

Pareil, je m'y attendais vraiment pas à celle-là :D

[Yasko]

Le pire pour AMD dans cette histoire, c'est qu'au final entre Conroe et Nehalem, avec assez peu de modifications au niveau µarch (ce qui est probablement le plus complexe, comparé à la conception d'un contrôleur mémoire, d'un bus point à point, etc), Intel parvient à un +30%, alors qu'entre K8 et K10, avec 4 ans de développement quasiment exclusivement sur sa µarch, AMD ne parvient qu'à la moitié, +15%.