Nehalem et innovations

**newbie06** · 09/12/2008, 23h20

Envoyé par Alexko

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 ?

C'est ce qu'a fait Sony sur la PS2 (et probablement pour la PS3, mais là je suis pas sûr). Sauf qu'ils utilisent de la XDR.

**Neo_13** · 09/12/2008, 23h21

Envoyé par Alexko

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 ?

PArce que la latence est CATASTROPHIQUE ?

**Yasko** · 09/12/2008, 23h52

Envoyé par Alexko

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 ?

Ca va un peu dans le sens de la stacked memory, parce que je ne pense pas qu'ils peuvent ajouter un bus mémoire externe supplémentaire, sans avoir des sockets à 1500 pins et des fabriquant de CM s'arrachant les cheveux pour router tout çe petit monde. Déjà le triple channel se fait assez sentir sur le cout des CM Bloomfield.

**Alexko** · 10/12/2008, 00h44

Envoyé par Neo_13

PArce que la latence est CATASTROPHIQUE ?

Je parle pas de remplacer la RAM standard, mais d'un complément pour les applications demandant une très grosse BP et pour lesquelles la latence importe peu. J'aurais tendance à penser que ces applications sont à peu près les mêmes que celles qui scalent bien sur des centaines de threads.

Bon évidemment, ça suppose un scheduling adéquat, mais si on le fait pour les cores, pourquoi pas la mémoire ?

**fefe** · 10/12/2008, 07h19

Envoyé par Neo_13

PArce que la latence est CATASTROPHIQUE ?

La GDDR a une tres bonne latence, les cartes graphiques une tres mauvaise, mais ce a cause de leurs pipelines interne et de leur controleur, pas de la GDDR. La latence d'acces en ns a de la GDDR est la meme que de la DDR de qualite comparable.

Mais la reponse a la question precedente peut se trouver dans la xbox-360: mettre de la DRAM rapide sur le die (aussi appele EDRAM). On y gagne en bande passante et en latence, mais ca coute bien cher

.

**fefe** · 10/12/2008, 07h24

Envoyé par Alexko

Je parle pas de remplacer la RAM standard, mais d'un complément pour les applications demandant une très grosse BP et pour lesquelles la latence importe peu. J'aurais tendance à penser que ces applications sont à peu près les mêmes que celles qui scalent bien sur des centaines de threads.

Bon évidemment, ça suppose un scheduling adéquat, mais si on le fait pour les cores, pourquoi pas la mémoire ?

Le probleme est que la GDDR n'a pas tant de bande passante en plus par pin que la DDR. En gros si tu as assez de pins pour 2 channels de DDR et tu mets 1 de DDR, 1 de GDDR, tu as multiplie ta bande passante par 1.5 par rapport a de la DDR. Pour un peu plus cher tu aurais pu mettre un 3 eme channel comme dans Nehalem. Le cout des pins vers la GDDR est meme plus eleve que vers la DDR, donc le surcout d avoir deux types de memoire connecte a ton CPU n'est pas vraiment amorti par les gains en bande passante.

Finalement le probleme est que cette GDDR ne beneficierait pas a la majorite des applications (ou alors il faut que tu m'explique comment tu repartirais les addresses physiques entre DDR et GDDR) alors que plus de channels de DDR standard le feraient. Ca revient cher pour de petits benefices, et cela ne correspond donc pas vraiment avec les decisions prises en general sur les CPUs.

**Alexko** · 10/12/2008, 08h49

Bizarrement dans ma tête la GDDR5 avait un prefetch double de celui de la DDR3, mais c'est 8 bits pour les deux donc effectivement la différence n'est pas si flagrante que ça. Du coup effectivement, un canal DDR supplémentaire est plus logique.

D'ailleurs ça sera intéressant de voir l'influence du troisième canal sur les Xeon Nehalem, on verra s'il y a effectivement un memory wall en dual-channel. Il me semble avoir lu quelque part que sur les Core i7 ça ne change pas grand chose dans la plupart des applications.

**fefe** · 10/12/2008, 09h11

Envoyé par Alexko

D'ailleurs ça sera intéressant de voir l'influence du troisième canal sur les Xeon Nehalem, on verra s'il y a effectivement un memory wall en dual-channel. Il me semble avoir lu quelque part que sur les Core i7 ça ne change pas grand chose dans la plupart des applications a moins de deux threads.

Tant que tu n'as pas au moins 2 threads tu n'arrives meme pas a saturer 2 channels sur les core i7 que j'ai vu. Vu que les applications ont tendance a faire autre chose que de transferer des donnees de la memoire, ca devrait etre surtout visible a 4+ threads et en multi-socket, a 1 et 2 threads en dehors des bench memoire je ne m'attends pas a quelque chose d'important.

**Yasko** · 10/12/2008, 10h13

Marc avait bien fait quelques tests sur Winrar (qui aime bien la bande passante) entre le dual et le triple channel, et le triple channel n'apportait aucun gain.

Le choix de Winrar n'était donc pas adapté ? Peut-être en faisant travailler plusieurs instances en parallèle ? (si on n'était pas déjà CPU-limited).

**fefe** · 10/12/2008, 12h08

Winrar aime la bande passante, mais nettement moins que des memcopy ou autres stream-triad

, et nettement moins que des applications scientifiques. Marc n'aime pas SPEC (et ses arguments sont bons pour son contexte) et il y a pluesieurs benchs dans SPECFP qui consomment facilement 2 a 3x plus que winrar. Les benchs server comme specjbb ou TPC* ont des tests qui sont tres intensifs cote bande passante memoire aussi et qui au dela de 2 threads devraient montrer des benefices importants avec le 3 eme channel.

De maniere generale la pression des applications desktop (jeux compris) sur la bande passante memoire est assez faible compare aux applications serveur et de calcul scientifique.

PS: le choix de winrar etait adapte, c'est le test qu'il tourne qui consomme le plus a ma connaissance, mais multiplier les instances pourraient montrer un benefice aux 3 channels mais en soit cela n'a aucun interet parce que personne ne va s'amuser a tourner plusieurs instances de winrar

.

**PeGGaaSuSS** · 10/12/2008, 13h16

Envoyé par fefe

PS: le choix de winrar etait adapte, c'est le test qu'il tourne qui consomme le plus a ma connaissance, mais multiplier les instances pourraient montrer un benefice aux 3 channels mais en soit cela n'a aucun interet parce que personne ne va s'amuser a tourner plusieurs instances de winrar

.

Heu, j'aurai dit le contraire, et la autant des fois c'est moi qui est une utilisation bizarre, autant la je sais que je suis loin d'être le seul.

**lordmagnum** · 10/12/2008, 13h29

Le cache L3 du Nehalem est commun aux 4 Cores ? donc 1*8 mo.
ou un L3 pour deux Cores ? donc 2*4 mo.

**Yasko** · 10/12/2008, 13h43

Commun aux 4 cores. NHM a ses 4 cores uni en seul die. (la nativité mec

)

**fefe** · 10/12/2008, 13h54

Envoyé par PeGGaaSuSS

Heu, j'aurai dit le contraire, et la autant des fois c'est moi qui est une utilisation bizarre, autant la je sais que je suis loin d'être le seul.

Tu fais tourner plusieurs winrar en parallele ?

**Foudge** · 10/12/2008, 14h30

Il me semble que WinRAR est multithread/optimisé_multicore depuis la version 3.70
Du coup ça me parait un peu articificiel de faire du multi-instance (sans compter que dans la vraie vie, personne ou presque le fait) alors que le soft est à la fois consommateur de BP mais également multithread (autant de thread que de processeurs logiques ?).

**PeGGaaSuSS** · 10/12/2008, 14h32

En permanence ouais, que ce soit le truc le plus basique (drivers) ou des trucs plus gros. Enfin j'ai rarement qu'un seul fichier compressé à décompressé à la fois. A la limite quand tu n'a qu'un disque dur c'est pas forcement la meilleure idée, mais dès que t'en a plus (+) qu'un...

**fefe** · 10/12/2008, 14h41

Je me suis mal exprime. Je parlais de multi instance au cas ou le multithreading de winrar ne serait pas super efficace, bien entendu tout le monde fait tourner winrar en meme temps que d'autres applications, je parlais juste de winrar+d'autres winrar.

**PeGGaaSuSS** · 10/12/2008, 15h32

Oui, moi aussi je parle bien de plusieurs instances de WinRAR, et pour les gains du multithreading dans l'application même, je l'ai pas désactivé depuis que ca existe, mais j'avait pas remarqué des gains transcendants avant/après son apparition.

Pour revenir à ce dont on parlais, je parle donc bien de plusieurs instances de WinRAR sur plusieurs fichiers différents. Je voit vraiment pas ce que sa de fantastique... A part sur des fichiers énormes et unique (genre un seul fichier de 10 Go compressé) ou la ça commence à devenir dur et tu perds plus que tu gagne.

Multitask anyone ?

**Foudge** · 10/12/2008, 16h07

Multitask oui, mais sur WinRAR ça m'est jamais arrivé et j'ai jamais vu.
Sur les petits fichiers, la durée est tellement courte que les compression se chevauchent pas ou très peu. Et sur les grosses compressions, c'est hard quand t'en lances une autre en même temps, sauf si, coïncidence, l'autre compression est sur un autre disque physique. Du coup t'attends ou tu fais autre chose (non non, pas un scan AV ou une defrag

).

**Oxygen3** · 10/12/2008, 17h01

Envoyé par Foudge

Du coup t'attends ou tu fais autre chose (non non, pas un scan AV ou une defrag

).

Je rejoints Peggassus, tu fais autre chose, donc tu vas ranger ton disque, et tu relances d'autres compressions

**newbie06** · 16/12/2008, 20h33

On dirait que Nehalem marche bien

Résultats SAP : http://www.anandtech.com/weblog/showpost.aspx?i=532

**fefe** · 17/12/2008, 08h35

QPI rend les serveurs a base de Nehalem finalement aussi scalable que la plateforme AMD. HT donne un avantage non negligeable dans toutes les applis a tres faible IPC. Reste a attendre les benchs de plateformes vendues pour pouvoir vraiment comparer.

Le marche des multi-sockets redevient competitif

.

**ylyad** · 17/12/2008, 09h41

Envoyé par newbie06

On dirait que Nehalem marche bien

Résultats SAP : http://www.anandtech.com/weblog/showpost.aspx?i=532

Si ça se confirme, je vois depuis mon bureau qui est déjà en train de préparer

Spoiler Alert!

sa liste au Père Noël

C'est quand même un sacré bond en performances, sur une appli où les problèmes de performance sont un sujet de préoccupation (quasi) constant et où gagner ou perdre 2 secondes sur une transaction peut vous faire changer d'employeur...
(bon, évidemment, le bench est fait sur du standard, ce qu'aucune boite n'a installé

)

**newbie06** · 17/12/2008, 14h33

Autres resultats de scaling : http://www.mersenneforum.org/showpos...2&postcount=14
C'est sur du code de criblage pour factorisation. En single socket, il semblerait que le K10 scale mieux que le i7.

**fefe** · 17/12/2008, 16h17

Oui mais ils partent de 2x moins de performance si je lis le graphe correctement (donc la memoire nettement moins chargee entre autre). Il est tres facile d'avoir un bon scaling en partant d'une basse performance (CF le scaling SMT de Atom).

**newbie06** · 17/12/2008, 16h53

Envoyé par fefe

Oui mais ils partent de 2x moins de performance si je lis le graphe correctement (donc la memoire nettement moins chargee entre autre). Il est tres facile d'avoir un bon scaling en partant d'une basse performance (CF le scaling SMT de Atom).

Certes, mais la je pense que c'est difficile a dire, il faudrait analyser plus finement le programme. Vu les chiffres de bande passante utilisee annonces dans le poste, il ne s'agit pas d'un probleme de memoire. Bon il a ptet mesure avec les pieds aussi

**Alexko** · 17/12/2008, 21h56

Suffirait de tester avec un Nehalem underclocké...

**newbie06** · 18/12/2008, 00h20

Envoyé par Alexko

Suffirait de tester avec un Nehalem underclocké...

Plutôt en baissant la vitesse du contrôleur mémoire, on peut le faire maintenant non ?

**fefe** · 18/12/2008, 08h27

Suffit de mettre de la DDR3 pourrie

et ce sur 1 channel...

**newbie06** · 18/12/2008, 09h55

Si quelqu'un a acces a des machines Nehalem et/ou K10, qu'il me fasse signe et je regarderai plus en detail ce programme. Ha oui, faut que ca tourne avec un vrai OS

Discussion: Nehalem et innovations

Outils de la discussion

Règles de messages