Nehalem et innovations

[Oxygen3]

Interressant.

Ca vaudrait le coup d'essayer de correler ca a ce qui se passe sur des plateformes AMD avec plusieur tailles et latences de cache/memoire: K8 en 90nm, en 65nm et Phenom (il n'y a pas a ma connaissance de core2 avec des caches suffisament petits pour obtenir qq chose d'interressant). Ca donne 3 points et cela permettrait d'isoler les caracteristiques du systeme memoire d'eventuels problemes de jeunesse de l'i7.

Y'a les celeron dual core E1200 (512ko de L2 cache)

Tu mets en // avec des 2Mo et des 6Mo ca devrait donner des résultats exploitables je pense

[PeGGaaSuSS]

Question conne, la quantité de mémoire supportée, elle vient bien du CPU ? Pas du chipset ou pire du BIOS de la mobo ?

Parce que Intel indique 8 Go sur la DX58SO, ASUS 12 Go sur ses cartes, MSI annonce 24 Go...

J'imagine que les deux premiers ont simplement pris les plus grosses barrettes disponibles jusqu'alors et multipliées par le nombre de bank mais de façon précise on sait combien Nehalem / Core i7 peut prendre en ram ? Et Nehalem / Xeon ?

[fefe]

Question conne, la quantité de mémoire supportée, elle vient bien du CPU ? Pas du chipset ou pire du BIOS de la mobo ?

C'est loin d'etre une question conne. Il y a de nombreux facteurs qui interviennent dans cette limite.
- quelle taille d'adressage physique est supporte par le CPU. En general ca ne devient un probleme que sur les plateformes serveurs, vu que tout le monde a au moins 36 bits.
- quel taille d'adressage physique le controleur memoire supporte (chipset ou cpu suivant les produits). Le nombre de bank/rank/etc... supportes par le controleur memoire en question. Ca te limite a un certain nombre de chips par channel.
- nombre de sticks supporte par la carte mere, et qualite du design de la carte mere. Depasser un certain nombre de puces par channel necessite un design de qualite afin de tenir ce que le controleur memoire peut supporter. Une partie est controle par la phase de test et d auto calibration du controleur memoire qui est conduite en collaboration avec le bios.

Parce que Intel indique 8*Go sur la DX58SO, ASUS 12 Go sur ses cartes, MSI annonce 24 Go...

J'imagine que les deux premiers ont simplement pris les plus grosses barrettes disponibles jusqu'alors et multipliées par le nombre de bank mais de façon précise on sait combien Nehalem / Core i7 peut prendre en ram ? Et Nehalem / Xeon ?

Donc tu peux avoir un design de carte mere qui te limite sur la capacite max. Il est fort probable que les clients ne supportent pas plus de 6 sticks de la plus haute capacite existante, et que les xeons soient prevus pour accepter 4 sticks par channel.

Il est peu probable que le core soit la limite, la combinaison controleur memoire/qualite du design de la carte mere est probablement le facteur limitant (certains constructeurs feront plus d'economies que d'autres ou ont des contraintes de qualite moindre).

[Stéphane.P]

La doc de la DX58SO indique un espace adressable de max 16Go.
J'ai mis le nez dans la doc du X58, mais c'est loin d'être trivial pour moi.

[Dandu]

Faut se méfier de la doc Intel, aussi.

Pour le GM965 (portable), ils indiquent 4 Go max. sauf que en pratique 8 Go fonctionnent.

[Marc]

La réponse officielle se trouve dans le datasheet de l'i7 et pas du X58

C'est 24 Go de mémoire, sur 6 DIMM.

Les puces d'une densité de 2 Gb sont supporté et donc les barrettes de 4 Go avec 16 puces, 4x6 = 24, tout roule donc

[Yasko]

/HS : Marc, tu as un souci avec ton lien hypertexte page 4 de ton article de ce jour.

Et dans ta news aussi
Waa, c'est la 10000ème d'ailleurs ! Champagne !

Les kits triples canaux sont disponibles chez tous les fabricants (103 à 298 € en 3 Go, 210 à 360 € en 6 Go), même si en pratique il faut rappeler que le très faible intérêt du triple canal s’estompe complètement dès la DDR3-1333, le double canal pouvant même être plus véloce du fait de latences inférieures au niveau du chipset.

Chipset, are you sure ?
Que vient faire le chipset avec la RAM ?

[PeGGaaSuSS]

After official release of Catalyst 8.11 last week, AMD today launches new Catalyst 8.11 Hotfix specially for Intel X58 platform. According to the remark, this Hotfix mainly enhances performance in Direct3D and OpenGL applications on X58 platform. These optimizations will be integrated into AMD’s official Catalyst 8.12 which is about to out next month. Other updates are similar to last Hotfix, including improving performance for STALKER: Clear Sky and FarCry2.

The Hotfix applies to Windows XP 32bit/64bit and Vista 32bit/64bit OS. It can be downloaded by clicking the link below.

The catalyst applies to the following configurations:

Radeon™ HD 4800 series
Radeon™ HD 4600 series
Radeon™ HD 4500 series
Radeon™ HD 4300 series
Radeon™ HD 3800 series
Radeon™ HD 3600 series
Radeon™ HD 3400 series
Radeon™ HD 2900 series
Radeon™ HD 2600 series
Radeon™ HD 2400 series

http://support.ati.com/ics/support/d...estionID=38664

[Marc]

/HS : Marc, tu as un souci avec ton lien hypertexte page 4 de ton article de ce jour.

Et dans ta news aussi
Waa, c'est la 10000ème d'ailleurs ! Champagne !



Chipset, are you sure ?
Que vient faire le chipset avec la RAM ?

Barf, paie tes vieux automatismes tx

[Marc]

http://support.ati.com/ics/support/d...estionID=38664

C'est la même page que pour les 8.10 mais MAJ
C'est le même numéro de driver
C'est indiqué 8.10 dans le panneau de contrôle une fois installés

[Stéphane.P]

C'est HS, mais voici ce que je viens de lire dans le manuel du bios d'une carte mère X58 de Supermicro :

DIMM Pitch
This is the physical space between each DIMM module. Each step is in
1/1000 of an inch. The default is [400]. Press "+" or "-" on your keyboard
to change this value.

[Møgluglu]

Oui, ça commande un servo-moteur sous les slots DIMM piloté par SMBus. C'est un système mis en place en collaboration avec Corsair pour permettre l'augmentation de la largeur des dissipateurs au delà des specs JEDEC.
Pour le moment il faut le régler à la main dans le bios, mais ça sera bientôt pris en charge par les profils EPP2.

[Franck@x86]

il était temps.

"pitch, ô ma pitch, lorsque tu souris euh ..."

[PeGGaaSuSS]

Sur le nom de code de la SmackOver

And the codename? "Our legal guys wouldn't let us call it ‘Butt-kicker'," he revealed. Fair enough.

http://channel.hexus.net/content/ite...m=16356&page=3

[newbie06]

Des resultats officiels SPEC2006 ont ete postes. Ils sont bons

[PeGGaaSuSS]

A propos du pseudo soucis de TLB sur les Core i7 qu'on à vu sur certains sites :
http://techreport.com/discussions.x/15979

Circuler y'a rien à voir en gros.

[Alexko]

C'est encore Fudzilla qui fait une montagne à partir de rien du tout, n'ayant probablement pas compris de quoi il s'agissait...

[Foudge]

Fuad a vu "TLB" dans la liste des errata du Nehalem, alors il y a vu de quoi faire une news à sensation.

[PeGGaaSuSS]

Pas plus de 16 cores ?

http://arstechnica.com/news.ars/post...pointless.html

[Yasko]

Mouais, ça doit dépendre grandement du type de core et de son IPC. Sans préciser sur quoi est faite l'étude, le 16 sort un peu de leur chapeau.
Je suppose que Intel réussira à sortir un LRB à 16+ cores, qui scale de manière décente.

[fefe]

Oui mais non, tout depend du nombre de channels de memoire que tu es pret a mettre sur un socket (+ de pin = + cher).

Il y a des systemes multi socket de plus de 16 cores aujourd'hui et ils y arrivent tres bien, il est possible sans trop de problemes hormis le cout de doubler la quantite d'IO sur un processeur classique, ce que les GPUs font d'ailleurs. Un CPU a en general 128bits d'IO pour 200-250mm^2 alors qu'un GPU en aura probablement 256. Ces memes GPUs ont deja nettement plus de 16 cores et pas mal de monde arrive a les exploiter pour des applications qui ne sont pas juste de la rasterisation.

Donc bon, ces articles sur le memory wall je les lis depuis 15 ans et on n'y est pas encore. Ca devient plus cher oui, la vitesse a laquelle les technos progressent diminue, mais le mur n'est pas pour demain...

Voila

PS: c'est ma maniere de dire "BS"

[Oxygen3]

Oui mais non, tout depend du nombre de channels de memoire que tu es pret a mettre sur un socket (+ de pin = + cher).

Il y a des systemes multi socket de plus de 16 cores aujourd'hui et ils y arrivent tres bien, il est possible sans trop de problemes hormis le cout de doubler la quantite d'IO sur un processeur classique, ce que les GPUs font d'ailleurs. Un CPU a en general 128bits d'IO pour 200-250mm^2 alors qu'un GPU en aura probablement 256. Ces memes GPUs ont deja nettement plus de 16 cores et pas mal de monde arrive a les exploiter pour des applications qui ne sont pas juste de la rasterisation.

Donc bon, ces articles sur le memory wall je les lis depuis 15 ans et on n'y est pas encore. Ca devient plus cher oui, la vitesse a laquelle les technos progressent diminue, mais le mur n'est pas pour demain...

Voila

PS: c'est ma maniere de dire "BS"

Il y'a aussi après la question de savoir si on arrivera à avoir des algo divisables en plus de 16, ainsi que des I/O disque qui arriveront à suivre
Et j'en doute très fort.

Quand on voit l'inutilité (toute relative) des Xeons hexacore en quad socket, on peut effectivement dire que pour l'instant les 16 cores et plus, c'est useless

[fefe]

Les I/O on sait faire ca scalable depuis longtemps. Le Raid ce n'est pas si cher que ca, et les raids de SSD offrent un joli futur en terme d'IO/s.

Bien entendu, pour faire du Word on peut deja discuter de l'utilite d'un second core , en fait pour pas mal de choses meme.

[Neo_13]

Il y'a aussi après la question de savoir si on arrivera à avoir des algo divisables en plus de 16, ainsi que des I/O disque qui arriveront à suivre
Et j'en doute très fort.

Quand on voit l'inutilité (toute relative) des Xeons hexacore en quad socket, on peut effectivement dire que pour l'instant les 16 cores et plus, c'est useless

c'est surement parce que c'est useless que SGI a dev des systèmes 1024 sockets potentiellement quadcore... (je parle bien d'un seul OS pour 1024 sockets et non d'un cluster)

[newbie06]

c'est surement parce que c'est useless que SGI a dev des systèmes 1024 sockets potentiellement quadcore... (je parle bien d'un seul OS pour 1024 sockets et non d'un cluster)

Je n'ai trouvé que du 512 sockets dual core Itanium avec une instance de Linux (http://www.sgi.com/products/servers/altix/4000). Bon ça fait quand même 1024 coeurs avec jusqu'à 128 TB de RAM globalement partagée

[Yasko]

512 sockets pour du SMP, c'est déjà pas mal.
Avec Tukwila (NUMA), le nombre va peut-être monter.

[Neo_13]

Je n'ai trouvé que du 512 sockets dual core Itanium avec une instance de Linux (http://www.sgi.com/products/servers/altix/4000). Bon ça fait quand même 1024 coeurs avec jusqu'à 128 TB de RAM globalement partagée

Il me semble qu'ils ont fait une version spéciale du bazar pour un des supercalculateur... Néanmoins 512sockets, ça fait déjà un bout...

[newbie06]

Il me semble qu'ils ont fait une version spéciale du bazar pour un des supercalculateur... Néanmoins 512sockets, ça fait déjà un bout...

Oui c'est tres impressionnant. Mais ce que je trouve encore plus etonnant c'est que Linux parvienne a faire tourner tout ca, j'etais reste sur l'idee que Linux ne scalait pas bien, ce n'est visiblement plus le cas (et je parie que SGI n'est pas etranger a cette amelioration).

[Neo_13]

Oui c'est tres impressionnant. Mais ce que je trouve encore plus etonnant c'est que Linux parvienne a faire tourner tout ca, j'etais reste sur l'idee que Linux ne scalait pas bien, ce n'est visiblement plus le cas (et je parie que SGI n'est pas etranger a cette amelioration).

Oui, c'est SGI qui s'est tapé le taff, précisément pour sa magnifique archi based on itanium.

[Alexko]

Pas plus de 16 cores ?

http://arstechnica.com/news.ars/post...pointless.html

D'habitude j'aime bien les articles de Jon Stokes, mais pour le coup je trouve que c'est un peu n'importe quoi. À vrai dire, la course aux cores est peut-être même une aubaine au niveau de la mémoire puisque ça remplace la course aux GHz, donc on n'a plus le problème de l'éloignement constant de la mémoire par rapport au CPU en nombre de cycles.

La seule raison pour laquelle il pourrait effectivement ne pas être judicieux d'avoir plus de 16 "gros" cores (type Nehalem ou Shanghai) c'est que pour les exploiter correctement, il faut être capable de scaler jusqu'à 16 voire 32~64 threads (SMT 2~4-way). Or si un problème peut scaler sur autant de threads, y'a de bonnes chances qu'il scale aussi bien sur plusieurs centaines de threads, auquel cas il est probablement plus rentable de le faire tourner sur une puce massivement parrallèle, type GPU ou Larrabee.

Quel intérêt d'avoir un CPU 32-core à 500 € si le même CPU 8-core à 150 € fait mieux avec l'aide d'une carte graphique à 150 € ? À mon avis, c'est ça le gros défi à relever pour Intel et AMD, et c'est pas étonnant que le premier lance Larrabee en 2009 quand le second prépare son offensive "Fusion".

D'ailleurs, quitte à prendre un virage un peu "GPU", pourquoi ne pas utiliser une petite quantité de GDDR sur un gros bus, en plus de la RAM classique si vraiment il y a un déficit de bande-passante ?