Nehalem et innovations

**Lissyx** · 04/11/2008, 17h44

Envoyé par fefe

Si ton bench approche du TDP a la frequence stock tu pourras l'verclocker tout ce que tu veux sans gains visibles. Par contre vu que ce ne sera jamais le cas en pratique ca laisse un peu de marge.

En pratique suivant la qualite de la bin d'ou vient ton proc il sera plus ou moins pres de 130W en faisant tourner des programmes intensifs, donc au fur et a mesure que le process est rode et que la qualite augmente les proc bas de gamme se rapprocheront de plus en plus des haut de gamme en terme de frequence max qui donne des benefices.

En pratique ce n'est pas une mauvaise idee d'overclocker meme si les gains sur certains benchmarks sont 0%, en effet tous les programmes a la con qui sont moins intensifs et qui en temps normal seraient a 90W se retrouveront a 130W avec l'overclock + le controle de la PCU. Pour ceux qui etaient a 130W ca ne changera rien.

Au final la PCU est la feature de reve des overclockers, si ils pouvaient changer le TDP/courant pour lequel elle optimise. En effet, tu mets un bon gros ventilo+dissipateur qui peut encaisser 160W, tu dis a la PCU maintenant tu n'optimises plus pour 130 mais 160 et hop roule ma poule.

Le probleme est que c'est un peu plus complique que de juste limiter a n Watts, et que beaucoup de parametres des algos d'adaptation de frequence/voltage doivent etre hardcodes plutot que calcules au vol, ce qui empeche ce que je viens de decrire. Mais le concept de la PCU n'est pas l'ennemi de l'overclocker a mon avis bien au contraire, en effet ca permet d'avoir un overclock dynamique qui ne depasse jamais la capacite de dissipation, mais l'atteint meme sur des programmes assez peu intensifs (donc plus besoin de faire 3h de prime pour tester la stabilite).

Samuel parle dans son article d'un microcontrôleur pour le PCU, donc c'est peut-être techniquement flashable

**fofo** · 04/11/2008, 19h18

Envoyé par Foudge

Citation:
> Envoyé par newbie06

> Nan c'est les softeux qui sont betes : ils ont invente les boucles

Ils ont inventé les boucles car ils sont feignant. C'est le compilateur qui est bête : il pourrait dérouler les boucles

gcc -o3 ???

**Neo_13** · 04/11/2008, 19h23

Envoyé par Yasko

J'ai une collègue qui travaille exclusivement sur le test de perf, pourtant elle est plutôt technique.

fayke

**fefe** · 04/11/2008, 19h29

Envoyé par Lissyx

Samuel parle dans son article d'un microcontrôleur pour le PCU, donc c'est peut-être techniquement flashable

Ca l'est tres probablement, mais je doute qu'ils aient la place de mettre autre chose que des algos simples bases sur des lookup tables, calculees en utilisant les samples de plus mauvaises qualite possible (d'un point de vue leakage/power) qui finissent dans un bin donnee. Je suis certains qu'ils peuvent changer un peu l'algo car il n'y a aucun moyen d'etre sur de comment seront tous ces parametres avant d'avoir le silicone.

En revanche changer completement l'algo c'est une autre paire de manche. Dans micro-controleur il y a micro et donc forcement des capacites limitees. Bien entendu, tout comme le micro-code, je doute qu'ils laissent quiconque d'autre qu'eux y toucher et ca doit etre serieusement protege. On peut toujours rever, mais je pense qu'a moins qu'ils prevoient a la base l'archi de la PCU pour les overclockeurs et non juste pour leurs besoins ca ne va pas etre tres facile d'overclocker comme avant. De toutes facons pour les overclockeurs, il vaut toujours mieux attendre les compactions plutot que les nouvelles archis, elles montent generalement nettement mieux.

**newbie06** · 04/11/2008, 19h36

Alors comment ils ont fait les zygotos pour monter à 4.9 GHz, le détecteur de TDP aurait dû leur couper la chique, azote liquide ou pas non ?

**fefe** · 04/11/2008, 19h38

Oh ils etaient a 4.9GHz avec le process idle prenant 99% du temps probablement

. Si tu fais tourner par exemple une appli qui fait du pointer chasing vers la memoire, je suis certain que tu dois pouvoir overclocker super haut avant d'atteindre 130W. Plus serieusement, je ne sais pas quel pourcentage du TDP les tests CPU de 3DMark atteignent donc c'est difficile a dire (en fait je ne sais meme pas si ils sont multithreades

).
D'ailleurs quand le screen cpuz a ete pris le bench etait fini donc effectivement le processeur ne faisait tourner que le process idle a part cpuz et tu remarqueras que les scores changent pas vraiment avec la frequence affichee par cpuz (les frequences changent peu aussi

).

**newbie06** · 04/11/2008, 20h06

Envoyé par fefe

Plus serieusement, je ne sais pas quel pourcentage du TDP les tests CPU de 3DMark atteignent donc c'est difficile a dire (en fait je ne sais meme pas si ils sont multithreades

).

3DMark vantage est multi-threadé

D'ailleurs quand le screen cpuz a ete pris le bench etait fini donc effectivement le processeur ne faisait tourner que le process idle a part cpuz et tu remarqueras que les scores changent pas vraiment avec la frequence affichee par cpuz (les frequences changent peu aussi

).

Je ne vois pas la même chose que toi ; le CPU score donne ceci

29194 @4839.8
29624 @4901.0
29775 @4901.1
29565 @4872.0

Ca me paraît plutôt cohérent, non ?

Si on regarde chez Tom's Hardware par exemple (ref)
22080 @3600
23460 @3840

La corrélation entre ces chiffres et les précédents me paraît bonne.

La seule hypothèse que j'ai est qu'Intel a donné des chips spéciaux à ces monsieurs

**Doc TB** · 04/11/2008, 22h31

Envoyé par newbie06

La seule hypothèse que j'ai est qu'Intel a donné des chips spéciaux à ces monsieurs

Tu sais, j'ai des datasheets ou il y a marqué que les Core i7 "non-XE" seront bridés à BCLK (donc 133 MHz) + 2% max. là c'est la baise

**Childerik** · 04/11/2008, 22h38

Comment introduire en cachette une taxe spéciale sur le droit d'OC

**newbie06** · 04/11/2008, 23h03

Envoyé par Doc TB

Tu sais, j'ai des datasheets ou il y a marqué que les Core i7 "non-XE" seront bridés à BCLK (donc 133 MHz) + 2% max. là c'est la baise

Donc l'OC que tu as obtenu ne sera pas atteignable ? Ils reviennent en arrière maintenant qu'AMD est au tapis... Super

Perso, je n'OC jamais, j'aime pas ça, mais c'est un peu puant. Ou alors leur design tient pas la route ? Mais j'en doute.

PS - Ha ça y est j'ai compris ; si on suit le raisonnement de Childerik, ils foutent une taxe à l'OC ; avec tout le bénéf engrangé (ben ouai les kikoolol OC ils sont prêts à payer), ils vont pouvoir vendre à perte des SoC Atom pour mettre dans les téléphones portables et tuer ARM... Je ne peux pas m'étendre, la CIA tape à ma porte...

**Childerik** · 04/11/2008, 23h16

Envoyé par newbie06

PS - Ha ça y est j'ai compris ; si on suit le raisonnement de Childerik, ils foutent une taxe à l'OC ; avec tout le bénéf engrangé (ben ouai les kikoolol OC + les warr10rz chevronnés ils sont prêts à payer), ils vont pouvoir vendre à perte des SoC Atom pour mettre dans les téléphones portables et tuer ARM... Je ne peux pas m'étendre, la CIA tape à ma porte...

Rooooo, tu vois des chinois partout toi

.

**newbie06** · 05/11/2008, 11h20

Monde de merde : les carte-meres X58 n'ont pas de port serie, meme interne, sauf la MSI (non merci ; ca fait une alliteration). Comment je fais pour brancher une carte de dev la-dessus, hein (me parlez pas de port USB serie, ca chie ces trucs-la) ? Non, vraiment monde de merde

**Neo_13** · 05/11/2008, 11h27

T'as du mal regardé stout...

Envoyé par newbie06

Comment je fais pour brancher une carte de dev la-dessus, hein (me parlez pas de port USB serie, ca chie ces trucs-la) ? Non, vraiment monde de merde

Une carte atom, un pti telnet des familles et zou tu as ton port série over ip en plus...

**newbie06** · 05/11/2008, 11h32

Envoyé par Neo_13

T'as du mal regardé stout...

J'avoue, j'ai reduit la dose de cafeine, donc si tu vois autre chose que MSI avec un port serie ; Intel, ASUS et Gigabyte, c'est non

Une carte atom, un pti telnet des familles et zou tu as ton port série over ip en plus...

Non mais Atom, il lui faut une centrale nucleaire pour l'alimenter (je n'ose meme pas imaginer que tu voulais dire de s'en servir comme plateforme de dev

) ; j'utilise des cartes qui consomment 2W, mossieu

Et forcement ces cartes elles ont besoin du port serie pour acceder au boot monitor et flasher (pas de JTAG, trop cher).

**Wanou** · 05/11/2008, 11h35

Envoyé par newbie06

Monde de merde : les carte-meres X58 n'ont pas de port serie, meme interne, sauf la MSI (non merci ; ca fait une alliteration). Comment je fais pour brancher une carte de dev la-dessus, hein (me parlez pas de port USB serie, ca chie ces trucs-la) ? Non, vraiment monde de merde

Plusieurs solutions:
1) les cartes Pro (Moxa..) en PCIex ou PCI
2) les solutions en Sérial Over Ethernet. Ca marche bien, mais c'est pas donné.

**Neo_13** · 05/11/2008, 12h07

Envoyé par newbie06

J'avoue, j'ai reduit la dose de cafeine, donc si tu vois autre chose que MSI avec un port serie ; Intel, ASUS et Gigabyte, c'est non

Non mais Atom, il lui faut une centrale nucleaire pour l'alimenter (je n'ose meme pas imaginer que tu voulais dire de s'en servir comme plateforme de dev

) ; j'utilise des cartes qui consomment 2W, mossieu

Et forcement ces cartes elles ont besoin du port serie pour acceder au boot monitor et flasher (pas de JTAG, trop cher).

PAS DU TOUT TU COMPRENDS RIEN...

Tu dev sur ton PC, tu ftp vers la atom et par telnet tu envoie de la atom vers ta carte en série...

Avec un peu de scripting, je suis meme sûr que ça peux être automatisé...

**newbie06** · 05/11/2008, 12h13

Envoyé par Neo_13

PAS DU TOUT TU COMPRENDS RIEN...

Tu dev sur ton PC, tu ftp vers la atom et par telnet tu envoie de la atom vers ta carte en série...

Avec un peu de scripting, je suis meme sûr que ça peux être automatisé...

Ha y'est, locompris ! Mais c'est trop complique et pas securise ton truc ; donc je fous une carte Atom au cul de mon routeur, sur lequel mon serveur NFS et mon PC sont branches ; en SSH, je me connecte sur l'Atom (qui tourne Linux, bien entendu, je suis un pro) et je peux faire mumuse avec le port serie.

L'idee me plait. Mais ca ne plaira pas a mon ministre de l'amenagement du territoire qui est aussi accessoirement ministre du budget

Dommage ca me plait vraiment...

**Neo_13** · 05/11/2008, 13h42

Envoyé par newbie06

Ha y'est, locompris ! Mais c'est trop complique et pas securise ton truc ; donc je fous une carte Atom au cul de mon routeur, sur lequel mon serveur NFS et mon PC sont branches ; en SSH, je me connecte sur l'Atom (qui tourne Linux, bien entendu, je suis un pro) et je peux faire mumuse avec le port serie.

L'idee me plait. Mais ca ne plaira pas a mon ministre de l'amenagement du territoire qui est aussi accessoirement ministre du budget

Dommage ca me plait vraiment...

ben stu fais le transfert par ssh (Sftp) c'est secure...

Et puis çay sayske... Et ça bazarde définitvement le problème du port série (tant que la CM Atom vit, bien sur), pour l'ensemble du service.

**newbie06** · 05/11/2008, 14h00

Envoyé par Neo_13

ben stu fais le transfert par ssh (Sftp) c'est secure...

Oui mais c'est moins pratique que NFS, dont tout le monde sait a quel point il est securise

Et puis çay sayske... Et ça bazarde définitvement le problème du port série (tant que la CM Atom vit, bien sur), pour l'ensemble du service.

Ouai j'adore ! Et effet de bord sympathique : je pourrai benchmarker l'Atom avec des vrais trucs genre SPEC

**Tramb** · 05/11/2008, 15h09

C'est quand même dommage l'augmentation de la latence (et throughput) des divps, sqrtps et cie pour certaines classes d'applications, y'a pas mal de boucles qui sont limitées par ça.
(Et les reciprocal approximées ne sont pas toujours utilisables/utilisées)

**fefe** · 05/11/2008, 15h13

Ce sont surtout les SQRT qui ont morfle, le reste ne devrait pas trop se voir avec les ameliorations de l'OOO recouvrir 1 cycle ou 2 de plus sur un Div ca n'est pas la mort.

Les reciprocal approximees ne valent plus vraiment le coup meme si ton code peut tolerer les 11 bits de precision. Elles sont un peu plus rapides mais occupent le mul et l'add, alors que le divider els laisse libre pour executer du code en parallele. Si ton code est completement serial les reciprocal approximees valent encore le coup, mais si tu as un ILP raisonable ce n'est plus vraiment le cas.

**Tramb** · 05/11/2008, 15h33

Envoyé par fefe

Ce sont surtout les SQRT qui ont morfle, le reste ne devrait pas trop se voir avec les ameliorations de l'OOO recouvrir 1 cycle ou 2 de plus sur un Div ca n'est pas la mort.

Tu m'intéresses là (comme d'hab j'ai envie de dire

).
Faut dérouler salement sa boucle quand même, pour être bien sûr que la lentence est correctement masquée, non?
Je dis ça parcequ'il est difficile (pour moi

) de savoir toujours quelles opérations vont staller.
Exemple:

Code:

l0:
    movaps xmm0, [eax]
    sqrtps xmm0, xmm0
    movaps [ecx], xmm0
    add    eax, 16
    add    ecx, 16
    jmp    l0 ; hum...

Il n'y a que en cas de LHS sur [eax] que ça sérialise la boucle? Ou est-il plus conservatif?
Ou si un store buffer est plein?
Et... etc...

(Du coup il me faut beaucoup de mesures pour optimiser une routine)

(Question purement rhétorique : pour les PPC qu'on utilise, la boucle C++ est déroulée quoiqu'il arrive, j'imagine que ça doit pas faire grand mal sur x86 d'expliciter...)

**fefe** · 05/11/2008, 16h20

Envoyé par Tramb

Tu m'intéresses là (comme d'hab j'ai envie de dire

).
Faut dérouler salement sa boucle quand même, pour être bien sûr que la lentence est correctement masquée, non?
Je dis ça parcequ'il est difficile (pour moi

) de savoir toujours quelles opérations vont staller.
Exemple:

Code:

l0:
    movaps xmm0, [eax]
    sqrtps xmm0, xmm0
    movaps [ecx], xmm0
    add    eax, 16
    add    ecx, 16
    jmp    l0 ; hum...

Il n'y a que en cas de LHS sur [eax] que ça sérialise la boucle? Ou est-il plus conservatif?
Ou si un store buffer est plein?
Et... etc...

(Du coup il me faut beaucoup de mesures pour optimiser une routine)

(Question purement rhétorique : pour les PPC qu'on utilise, la boucle C++ est déroulée quoiqu'il arrive, j'imagine que ça doit pas faire grand mal sur x86 d'expliciter...)

Le deroulage de boucle sur x86 moderne c'est a manipuler avec moderation. Dans tous les cas il faut faire attention quand on deroule plus que la contenance du LSD (loop stream detector) de l'archi pour laquelle tu optimises. Bien sur si ta boucle demarre plus grosse que le buffer en question, tu peux y aller. Si elle demarre plus petit cela va dependre de comment s'en sortent les decodeurs par rapport a l'OOO.
Si tu conserves exactement les memes chaines de dependance sur du code SSE entre la version deroulee et la version non deroulee, tu ne devrais pas avoir d'amelioration liees au deroulage a moins d'aller chercher des instructions independantes a la main a une distance de plus de ~30 instructions avec ton deroulage (ce qui n'est pas le cas dans ton exemple).

Effectivement ton eax est renomme, et le movaps de l'iteration n+1 peut etre lance au cycle d'apres de celui de l'iteration n dans ton cas, boucle deroulee ou non.

Si ton code comporte un mix de 2xlat_op_lente en add ou mul (avec meme nombre d'add et mul)/ op_lente et quetes couples muladd ne sont pas en dependance serie tu peux recouvrir completement la latence de ton operation lente jusqu'a une centaine de cycles (elle ne te coutera aucune latence). Ton exemple est 100% limite par ton sqrt (moins 2 cycles d'overlap entre 2 sqrt successifs dans mes souvenirs).
En pratique il est rare d'absorber 100% de la latence des div/sqrt car quand on en fait dans un bloc de code, on a tendance a en faire beaucoup d'affilee mixe avec peu d'autres instructions dans la meme boucle donc ce qui se passe au final est que la latence de ta boucle est egale a celle des div/sqrt et tout le reste passe en parallele et ne te coute rien (encore une fois a moins d'avoir une dependance serie pour laquelle l'ooo ne peut rien).

Pour le store buffer, que tu deroules ou non ca change rien, il sera plein apres le meme nombre de store en attente.

Les PPC n'ont pas de problemes de debit de decodage comme les x86, tant que ton appli n'a pas de problemes de taille de code, il vaut mieux derouler. De plus les PPC ont un OOO assez peu profond en comparaison aux x86 modernes donc iront chercher du parallelisme nettement moins loin, et souvent n'atteindront pas l'iteration suivante des que ta boucle a un peu de contenu, donc il vaut mieux lui macher le travail. Au final tu as beaucoup plus de regs 32bits pour tous tes compteurs ce qui rend la prog facile sur le PPC alors que sur le x86 tu arrives vite a cours de registres si tu codes en IA32 (le CPU arrrive rarement a cours de registres virtuels, sur les archis P6 en fait ca n'arrive jamais vu que tu en as autant que la taille de ton ROB )

Je ne suis pas sur d'etre clair, dis moi...

**Tramb** · 05/11/2008, 16h38

Ok merci pour tes précisions, (et c'est assez clair, à part 2/3 trucs mais il faudra que je lise ça à tête reposée=.

En fait je fais du code "blended", je peux pas me permettre d'optimiser pour tous les parfums d'x86, c'est pour ça que si ce que je fais d'explicite pour la version PPC n'a pas d'impact ou un impact mineur sur la version x86, en général ça reste comme ça.

**fefe** · 05/11/2008, 17h13

Dans le cas de code "blended" tu peux mettre une regle simple qui ne deroule pas les boucles plus que le LSD des x86 recents peut contenir, si la version non deroulee tenait. Ca te garantit a peu pres de ne pas penaliser le x86 par tes optims PPC, apres c'est probablement un peu trop strict et risque de tuer pas mal de tes optims PPC (dans ce cas la ca devient inutile comme regle).

**bill_baroud** · 05/11/2008, 23h00

Yay, Dark Shikari, un des dev de X264 a publié son patch nehalem :D
Va falloir refaire le bench :P

http://forum.doom9.org/showthread.php?t=142542
http://i38.tinypic.com/161nvdh.png

**Doc TB** · 05/11/2008, 23h56

Envoyé par bill_baroud

Yay, Dark Shikari, un des dev de X264 a publié son patch nehalem :D
Va falloir refaire le bench :P

http://forum.doom9.org/showthread.php?t=142542
http://i38.tinypic.com/161nvdh.png

Ouai, je l'intégrerais dans la comparo de CPU. CEci dit, on voit bien les pertes sur les sqrt sur son graphique la.

**Franck@x86** · 06/11/2008, 00h14

Envoyé par fefe

Ce sont surtout les SQRT qui ont morfle, le reste ne devrait pas trop se voir avec les ameliorations de l'OOO recouvrir 1 cycle ou 2 de plus sur un Div ca n'est pas la mort.

cela dit c'est bizarre, intel a pas mal communiqué sur le nouveau diviseur du Penryn avec graphes à l'appui et tout le toutim, et voilà qu'ils font un (petit) pas en arrière sur NHM.

Mettons tout ceci en application dans un code qui ne fait que normaliser des vecteurs (1/SQRT), et crions au scandale du NHM qui ralentit les jeux 3D !

**Childerik** · 06/11/2008, 09h52

Envoyé par Franck@x86

cela dit c'est bizarre, intel a pas mal communiqué sur le nouveau diviseur du Penryn avec graphes à l'appui et tout le toutim, et voilà qu'ils font un (petit) pas en arrière sur NHM.

Mettons tout ceci en application dans un code qui ne fait que normaliser des vecteurs (1/SQRT), et crions au scandale du NHM qui ralentit les jeux 3D !

J'avais évoqué cette question dans le topic de l'article, mais bon, ça n'a tiqué aucun canard apparement

.

Pour le ralentissement dans les jeux, on s'en tape un peu, c'est pas flagrant du tout et puis les 2 MB de cache supplémentaires compensent.

**newbie06** · 06/11/2008, 13h20

Envoyé par Childerik

Pour le ralentissement dans les jeux, on s'en tape un peu, c'est pas flagrant du tout et puis les 2 MB de cache supplémentaires compensent.

Tu voulais dire les 4 Mo de moins ? Parce que les quadri-coeurs non i7 et un peu performants ils ont 12 Mo de cache L2.

Discussion: Nehalem et innovations

Outils de la discussion

Règles de messages