Nehalem et innovations

[fefe]

Je crois qu'il va y'avoir qq'un qui va morfler chez Sun .

[DJ_DaMS]

Photos d'un Nehalem et de sa mobo : http://www.xtremesystems.org/forums/...d.php?t=178009
Et le cul : http://www.xtremesystems.org/forums/...d.php?t=177122

C'est vrai que du coup ça ressemble beaucoup à une carte pour Opteron.
Je me réjouis de voir les perfs. Ca va faire très mal à AMD qui du coup n'auras plus vraiment un plus dans le monde server (les controleurs mémoire des Opterons sont appréciés pour les machines qui ont un nombre très élevé d'I/O)

La question qui a rien à voir : c'est quoi le chip video? Rien qui ressemble à un Volari z7 (une daube infame), ou ATI ES1000 sur un bus PCI 32bits...

[PeGGaaSuSS]

C'est un proto Intel, ca doit être du Intel j'imagine...

[DJ_DaMS]

Jusqu'à présent, il n'y a pas de gma intégré dans les chipsets serveur d'Intel...

J'ai un serveur Intel en test, c'est un ATI ES1000 pour le vga... (donc de l'AMD au sain même d'une config full Intel)

[PeGGaaSuSS]

Arf, j'ai toujours cru que c'etait les constructeurs de mobo qui chopait des vieux chips (pas idiot, moin cher, plus fiable).
Quoi qu'en fait, si les mobos sont une section séparé des CPU/chipset (chez Intel j'entends), ils peuvent faire ce qu'ils veulent...
Les mobos Intel ont parfois des choix bizarre la ou ca aurait pu être du full Intel!

[Yasko]

Leak d'un bench de Nehalem sur SPEC fait par Sun :

image de http://www.matbe.com/actualites/imprimer/32471/

http://blogs.zdnet.com/Ou/?p=1025

[newbie06]

http://blogs.zdnet.com/Ou/?p=1025

Un truc me chiffonne (en dehors du fait des extrapolations faites pour obtenir les scores absolus par rapport aux scores relatifs du transparent de Sun) : le gars pretend qu'une partie du gain provient du SMT ; si c'est le cas, le score du Nehalem serait pour un 8 threads (SMT 2 x Nehalem EP 4 coeurs).

Si c'est bien le cas, on peut dire que cette comparaison ne tient plus la route.

[fefe]

Vu que le slides contient des comparaisons entre dual core et quad core, et donc compare la perf/socket, cela ne me semblerait pas anormal si ils comptaient SMT dans leurs chiffres (et ca expliquerait au moins en partie les perfs tres hautes que montre ce graphe).

[newbie06]

Et la consequence est : on ne peut rien deduire de cette comparaison sauf que c'est impressionnant pour un socket

[fefe]

Si tu consideres un efficacite du SMT a la Prescott =~ 20%, ca te donne dans les 130-140 a une frequence inconnue, qu'on peut estimer similaire aux autres membres de la famille core (meme si differente il est peu probable que ce ne soit pas marginal), c'est a dire toujours plus haut que le shangai montre dans les 120.

IMO ca n'a plus rien d'impressionant (ca reste bon). Apres pour ce qui est des conclusions a tirer ca depend de ce qui t'interresse. Si c'est les performances sur des jeux modernes de Nehalem, effectivement je doute que ce graphe puisse repondre a quoi que ce soit (par exemple le P4 etait tres bon a SPEC et ca ne se traduisait pas en un avantage sur les jeux).

[newbie06]

(par exemple le P4 etait tres bon a SPEC et ca ne se traduisait pas en un avantage sur les jeux).

Ce n'est pas necessairement une caracteristique de l'architecture, ca peut aussi venir d'un compilo tellement tune pour SPEC que la compilation du reste ne presente pas de bons resultats.

J'ai souvent eu des discussions sur icc vs gcc, des gens pretendant qu'icc etait largement superieur a gcc. J'imagine que sur SPEC icc baffe mechamment gcc. Mon experience est que les gains sont en general de quelques % ("quelques" < 5%) dans un sens ou l'autre (pour des programmes deja tunes niveau C).

[fefe]

icc est en general en avance pour la sortie d'optimisations correspondant aux archis des derniers microprocesseurs. La vectorisation SSE a ete disponible en premier sur icc dans mes souvenirs, mais aujourd'hui ce n'est plus un avantage parce que la majorite des compilateurs le font. L'architecture core/phenom n'a pas introduit de changements majeurs du point de vue du compilateur (par rapport a P6/banias/dothan/K8, il n'y a guere qu'a realigner le code pour des decodeurs 4-wide).
icc n'est pas vraiment meilleur que gcc sur les processeurs actuels, je suis d'accord, en pratique il est moins bon car il compile moins de codes que gcc (la compatibilite a ete amelioree mais ce n'est pas encore a 100%). Sur des benchmarks etablis il y a probablement un peu plus de tuning. gcc aussi est tune sur SPEC, mais je suppose qu'il y a tout de meme moins d'efforts faits que pour icc (AMD publie ses resultats SPEC en utilisant icc en general). Sur des gros codes j'ai vu 5 a 10% de perf pour icc avec PGO (rien de scientifique dans cette phrase), et l'effort necessaire a reussir a compiler ce code avec icc ne valait le coup que parce qu'on fait tourner des 10aines de milliers de process avec ce code.

Sinon , une fois mises de cote les optimisations specifiques des compilos pour SPEC, la plupart des programmes executes sur nos PC ont des caracteristiques tres differentes de SPEC. SPECFP rate a une tendance a etre limite par la bande passante memoire de la platforme alors que c'est le cas de tres peu d'applis client, SPECInt est a l'inverse extremement sensible a la prediction de branchement et a la taille du cache, bien plus que les jeux/encodeurs videos/logiciels de compression (peut etre autant que office, mais ce n'est pas comme si la performance sous office interessait encore grand monde).

[newbie06]

Puisque c'est le calme plat dans le secteur un petit lien :

http://www.anandtech.com/cpuchipsets...spx?i=3264&p=2

Reflexions apres lecture

[Franck@x86]

Première remarque à chaud : pkoi M. Anand prend-il des photos de son écran au lieu de faire des copies d'écran ?

[newbie06]

Première remarque à chaud : pkoi M. Anand prend-il des photos de son écran au lieu de faire des copies d'écran ?

Il y était, il se la pète

[Alexko]

Ça fait plus authentique

[Childerik]

C'est pour démontrer la puissance de son reflex 27 mégapixels avec supermacro premium

[PeGGaaSuSS]

Il avait oublié sa clef USB ?

[braoru]

Les slides : http://download.intel.com/pressroom/...efing_0308.pdf

Tic,Toc,blabla next....: http://www.intel.com/pressroom/archi...er_Nehalem.pdf

[Franck@x86]

Première CM Bloomfield :
http://www.xtremesystems.org/forums/...d.php?t=181181

[newbie06]

Les paris sont ouverts : http://realworldtech.com/forums/inde...88747&roomid=2

[newbie06]

Enfin des infos : http://www.realworldtech.com/include...719&mode=print

[fefe]

Il detaille un peu les relations d'inclusivite/non inclusivite entre les caches . C'est Franck qui va etre content.

[newbie06]

Il detaille un peu les relations d'inclusivite/non inclusivite entre les caches .

Ca sent l'optim à la normande :

The L2 cache is neither inclusive nor exclusive with respect to the L1D cache. Like the Core 2, Nehalem can transfer data between the private caches of two cores, although not at full transfer rates.

(Il est pas beau mon piège pour obtenir des infos ? ).

C'est Franck qui va etre content.

Il bosse chez Intel ?

[fefe]

Ca sent l'optim à la normande :

(Il est pas beau mon piège pour obtenir des infos ? ).

Il bosse chez Intel ?

Non mais il aime les histoires de cache inculsif exculsif .

C'est pas de l'optim a la Normande c'est de l'optim a la Corse! Quand tu evicte qq chose du L2 du core 2 il ne va pas aller s'emmerder a snooper/invalider les L1 qui pourraient avoir une copie pour maintenir l'inclusion.

[Neo_13]

Non mais il aime les histoires de cache inculsif exculsif .

C'est pas de l'optim a la Normande c'est de l'optim a la Corse! Quand tu evicte qq chose du L2 du core 2 il ne va pas aller s'emmerder a snooper/invalider les L1 qui pourraient avoir une copie pour maintenir l'inclusion.

et pour la cohérence ?

Si 'autre core a besoin de l'info il faut qu'il tape en ram c'est ça ?

[fefe]

et pour la cohérence ?

Si 'autre core a besoin de l'info il faut qu'il tape en ram c'est ça ?

Le probleme de la methode corse est que ca force a snoop a chaque lookup du L2. Tu ne vas pas rechercher la donnee en RAM mais dans le bon cache. Par contre tu consommes bcp de bande passante a snoop.

[fefe]

http://www.tgdaily.com/content/view/36758/135/

Plus de CPUs pour remplacer le GPU ? Mmm ca ressemble a du marketing agressif...

[newbie06]

Ouai et ça a du faire plaisir aux équipes qui bossent sur Larrabee

[Alice]

http://www.tgdaily.com/content/view/36758/135/

Plus de CPUs pour remplacer le GPU ? Mmm ca ressemble a du marketing agressif...

Même si c'est pas mal de marketing, je suis assez d'accord avec Fosner. DirectX/OpenGL sont vraiment devenu complexes et se détachent de plus en plus d'un modèle de programmation cohérent. Ca ressemble de plus en plus a un amat de solutions ad'hoc!

Cette semaine une vidéo à fait parler d'elle en illustrant les fonctionnalité apportés par DirectX10.1. Une des ces fonctionnalités utilisées à outrance est le rendu vers plusieurs cube map. Vas y que je te rajoute ça avec toute sa spec et qd ça peut être utilisé ou non, avec quel filtrage, quel état du pipeline, quel antialiasing, quel support est requis etc. Bref une fonctionnalité qui peut paraitre bien étrange pour quelqu'un qui code sur CPU (en se détachant de la spec des API) puisque lui il n'a pas eu l'idée qu'une Cube map ça devait être particulier (pour lui tout est un void*). La seule notion que je conaisse qui se rapproche de cette prog moins contrainte sont les Buffer Object d'OpenGL. (Un buffer object peut stocker n'importe quoi, Pixels, Textures, paramètres, Vertex etc.)

Bref tout ça pour dire que la prog sur CPU est qd même bien plus simple/souple. Par exemple, sur CPU, la notion de shader à la DX/OGL n'a pas lieu d'être en l'état puisque tout est programmable (Naïvement sur CPU, un shader = code ou milieu d'un boucle for). Le seul avantage des shader ala API graphique, c'est leur modèle de prog parallèle vraiment puissant (puisqu'invisible).

Puisque le GPU tend vers le calcul de plus en plus général et que le CPU tend à pouvoir accélérer du graphique ça ne me semble pas idiot de penser qu'a terme tout ça va s'unifier et qu'on aura donc plus d'API obscure ni de Proc dédié.

Sweeney soulignait dernièrement que le rendu soft était sans doute l'avenir (vu qu'il le dit depuis bientôt 5 ans ça atténue son impact). Je pense qu'il n'a pas forcément tord et qu'à terme, les CPU avec de plus en plus de cores vont pouvoir être utilisés pour avoir des très bonnes perfs en rendu soft et ce sans les limitations des API. Il faut bien comprendre que le rendu sur CPU n'a aucune limitation conceptuelle. Pas besoin d'attendre le matos et la spec qui va avec pour pouvoir profiter de tel ou tel algo.