C'est l'article qui lui monte à la tête !
Et y'aurait pas moyen d'avoir une version en ligne non censuree, genre 2 semaines apres la parution ?
Ou sinon un test comme d'hab et tant pis pour ceux qui comprennent pas, ils ont qu'à lire Clubic ? Non ? Arf, tant pis...
On se rabattra sur Frank en attendent Art, Xbit et RWT(Si ils font autre chose). (rebellions !!!)
We should treat all the trivial things of life seriously, and all the serious things of life with sincere and studied triviality.[Oscar wilde]
There is no such thing as a moral or an immoral book. Books are well written, or badly written. That is all.[Oscar wilde]
No artist is ever morbid. The artist can express everything.[Oscar wilde]
Dommage que Gainestown ne sort que début 2009, on aurait eu droit à des tests en environnement bi-xeons et voir le gain fulgurant apporté par le CSI
Et le cache de 4-6M a ~15 cycles remplace par un cache de 8M a 33-39 cycles ? Les jeux aiment les gros cache a faible latence, et ce n'est pas 256Ko et son retour de 15 an en arriere cote capacite qui aide (malgre sa latence raisonable).Envoyé par Doc TB;
Quand tu manipules un dataset de plusieurs megas, les 256Ko fourniront quelques hits, ce qui reduira un peu la bande passante au L3 mais l'essentiel du dataset mettra 33+ cycles a venir au lieu de ~15 cycles.
Pour ce qui est du "hop" supplementaire pour les applications graphiques, si c'est effectivement le cas, cela devrait etre recuperable via les drivers des cartes graphiques, en effet ils savent tres bien recouvrir de longues latences tant que la bande passante est la (et elle est la apparament). Ils sont probablement optimises aujourd'hui pour des latences un peu plus faibles.
Personellement je pense que le probleme est plus dans le cache que dans le Q(pi).
fefe - Dillon Y'Bon
D'ailleurs quand AMD est passé de l'Athlon XP à l'Athlon 64 avec son IMC et le cache L2 doublé (1 Mo vs 512 ko) les jeux en ont plutôt bénéficié qu'autre chose. À vrai dire même les versions avec 512 ko de L2 s'en sortaient pratiquement aussi bien.
Cela dit, sur le test de Matbe on voit qu'en augmentant la résolution des jeux, les Penryn passent devant les Nehalem. Je vois pas comment expliquer ça sinon par l'augmentation du traffic entre la mémoire et la carte graphique.
Dernière modification par Alexko ; 03/11/2008 à 11h48.
Moi j'ai une question assez simple ... (Mais la réponse je pense ne l'est pas ):
Il apparait qu'en mode X64, la génération Core2 ne fait pas de macros ops fusion, ce que fait le nouvel i7.
L'argument est donc utilisé ici ou là pour dire que les gains du 64 bits sont réduits à néant (ici par exemple, hein marc, tu tapes pas, hein).
Or, de ce que j'en comprends, ce n'est pas aussi systématique, et on serait plutôt de l'ordre de moins de 2% dans le pire des cas.
(par exemple: ici)
Alors ? Qu'en pensez vous, oh les dieux qui revent en macros ops ?
There are only 10 types of people in the world: Those who understand binary, and those who don't.
Un des problemes des instructions 64bits est qu'elles font systematiquement 1 octet de plus. Donc au final il faudra fetcher cet octet du IL1. La penalite dependra du code et la bande passante additionelle represente de 10 a 50% suivant le code (mais 15-20 est probablement une bonne approximation).
Que tu aies de la macro-fusion ou non rien ne changera cet impact qui ne peut etre compense que par une augmentation de la largeur du fetch.
Donc suivant les applications la bande passante de fetch aura un impact ou non. Dans celles ou ce n'est pas critique, la reduction d'instructions a executee liee a la macro-fusion amelioree apportera certainement des benefices (quelques pourcents a mon avis, il ne faut pas s'attendre a des miracles).
fefe - Dillon Y'Bon
Il ne faut pas oublier que l'évolution majeure de nehalem se sentira surtout en multi-socket, même si en mono-CPU, l'augmentation des performances est sensible pour des applications 4/8 threads.
Pour le cache, disons que c'est le gros 8 Mo unifié qui limite la casse dans les jeux. Même avec une latence médiocre. On conserve la même problématique que lors du passage northwood ---> prescott.
Bon, j'ai lu l'article de Marc, et il y a deux différences notables avec celui du Doc :
* Le coefficient multiplicateur du modèle EE : bloqué en montée ou pas ?
* Le nombre de lignes PCIE du X58 : 40 ou 36 ?
L'article de Clubic, c'est de la paraphrase du début jusqu'à la fin. Et de nombreuses étourderies.
Raté : le PIII Timna.Pour la seconde fois de son histoire (il faut remonter à une variante lointaine du i386 pour retrouver un tel cas de figure), Intel propose un processeur avec contrôleur mémoire intégré
Et la DDR3-1333 ?il faudra se contenter sur Core i7 de mémoire DDR3-1066 selon les spécifications officielles du fondeur
Ca c'est un truc qui reste scotché dans l'esprit populaire . En quoi un quad core non natif est-il en retard technologique avec un quad-core natif ?ladite architecture pèche sur de nombreux points avec des retards technologiques plus ou moins criants [...] ou encore à l'architecture quadri-cœurs non native
L'Atom est-il si transparent que ça ?Nehalem réintroduit en effet l'HyperThreading
On ne comprend pas tout là . Et c'est encore pire dans le chapitre suivant où tout est emmêlé.Sur Nehalem, chaque cœur dispose de sa propre mémoire cache de premier et second niveau, une mémoire naturellement non partagée
Il en sait quelque chose ?Il semblerait que Far Cry 2 n'apprécie guère l'HyperThreading
Dernière modification par Childerik ; 03/11/2008 à 16h55.
Il est dit 40 lignes dont 4 pour le bus DMI, ce qui fait qu'il en reste 36 exploitable. Donc je ne pense pas qu'ils se contredisent.
Ceci dit, le seul truc que je comprend pas, c'est pourquoi avoir 36 lignes exploitable de 3 manières : 1*16, 2*16 ou 4*32. Dans le meilleur des cas, ça fait 32
Utilité des 4 lignes non utilisée restante ?
Peut-être parce que l'évolution technologique a fait qu'Intel est passé du quad "non-natif" à une version plus évoluée/performante/autre_adjectif_positif appelé quad "natif".
Il n'est pas réellement tiré par les cheveux d'appeler la durée qu'il a fallu de passer d'un stade à l'autre de "retard" (sous-entendu par rapport à son concurrent qui est passé directement au stade "avancé").
Maintenant personne n'a dit que ce "retard technologique" avait un quelconque effet négatif, tant sur les perf, le cout de fabrication, la stratégie marketing ou autre. Ce fût sûrement même bien joué de la part d'Intel, ce qui lui a permis d'être en avance tout court.
Remplace le mot "naturellement" par "donc".
Effectivement, soit ils ont confondu avec COD4, soit il n'ont pas publié tous leur tests.
Moi ce qui m'a bien fait rire, c'est le test du bus QPI. Ils ont utilisé pour cela 2 tests mais aucun d'entre eux n'utilise réellement le bus QPI
Je m'attendais à ce qu'ils utilisent 1 jeu ou 2, voire un logiciel un peu spécial qui bourrinerait un peu la communication entre la RAM et la CG, mais non rien.
Bon, ça n'aurait sans doute rien changé à la conclusion, mais quand même...
-------------
Sinon, concernant le test de CPC, je n'ai pas fini de lire mais juste un petit détail à propos du tableau des latence/débit des instructions x86. J'ai d'abord cru à un vert=mieux et rouge=moins_bien avant de regarder en détail pour voir que vert=moins et rouge=plus. Et selon si c'est une latence ou un débit, c'est pas pareil. Du coup c'est difficile de se rendre compte d'un coup d'oeil s'il s'agit d'amélioration ou non.
D'autre part il y a une différence au niveau du CMP (32bit) : au lieu d'être noir il devrait être vert (même si je préfèrerais qu'il soit rouge ).
Je sais, c'est du détail, j'ai hésité à l'écrire ici.
Sinon pas mal le coup des cartes mères, ça résume pas mal la situation : Intel pour les tests, ASUS pour l'OC et MSI... à la poubelle. Bref, chacun à sa place
Dans l'article CPC, on parle du QPI qui causerait des légères baisses de perf. dans les jeux. Donc, chez Clubic, en quoi l'HT impacterait négativement les perf. du jeu ? Je veux bien le croire s'il y a une explication détaillée là-dessus . Bref, on ne va pas s'éterniser dessus ...
... comme MSI, cet article va à la poubelle . Ca sent trop le copier-coller d'toutes façons.
Je suis surement à coté de la plaque, mais ce que je comprends en lisant le paragraphe, c'est qu'au runtime les boucles seraient entièrement "déroulées", et que ce détecteur permettrait de re-détecter des instructions qui à l'origine étaient dans une boucle ?Envoyé par Doc
Parce que de la vision que j'avais, une boucle for par exemple était traduite en asm par un saut conditionnel sur une variable incrémentée à chaque tour (une traduction en boucle while en gros), mais à l'intérieur de cette boucle, ce sont toujours les mêmes instructions (physiquement j'entends), le contraire impliquerait que la boucle ait été déroulée ?
Ou est-ce que je me plante ? (dans la jugulaire).
Je me rappelle avoir déjà lu cette histoire de détecteur de boucle expliquée par Franck sur HFR, mais à l'époque je ne m'étais pas posé cette question. Faudrait que je retourne voir son explication.
y'a pas de déroulement, les instructions entre l'adresse de saut et l'instruction de saut sont simplement bufferisées (déjà que le buffer doit pas être super gros).
Par contre oui les instructions ne changent pas, mais les données si, et on se doute que c'est le facteur limitant de cette optimisation. D'ailleurs je suppose que l'optim de décodage du NHM est plus pour soulager le L1I qu'accélerer la boucle proprement dite ...
Une facon de gerer les boucles simples est de detecter les sauts arrieres conditionnels, ce qui ne necessite que la boucle n'ait pas ete entierement depliee. Si cette boucle n'est pas trop longue tu peux stocker les instructions ou les uop ou toute autre maniere de les representer dans une queue et ensuite te contenter de piocher dans cette queue sans mettre en oeuvre la Icache voir le decodeur.
En fait j'ai pas compris ou le Doc n'etait pas clair, donc je ne suis pas sur de t'avoir aide
Je pense aussi que c'est plutot pour le power. Une Iside ca consomme enormement pour etre efficace...
Dernière modification par newbie06 ; 03/11/2008 à 18h41. Motif: Fusion automatique
Tient je croyais que le FSB avait disparuil suffit de pousser un peu le FSB et tout ce passera bien
Étourderie (ou vulgarisation volontaire ?) je suppose, car quelques lignes plus bas vous parlez bien de "fréquence de base".
En attendant la nouvelle plateforme LGA1156 avec contrôleur PCIE intégré, fallait bien un bus pour relier le CPU au NBA quoi donc sert par exemple le bus QPI pour le grand public à part diminuer les performances ludiques ?
Plus sérieusement, cette baisse de perf dûe au QPI en lui-même n'est qu'une supposition (pourquoi pas l'HT ?), non ? Et pour être exact ce n'est pas réellement le QPI le responsable, mais le fait d'avoir éloigné la RAM de la CG. L'IMC serait donc le coupable ? Et on pourrait se faire la même remarque avec les A64/Phenom. Sont-ce réellement des CPU grand public ? A quoi sert leur lien HT sinon à réduire les perf dans les jeux ?
Mais tant mieux si Intel veut améliorer les choses en intégrant plus tard des liens PCIE dans le CPU. Curieux de voir ce que ça donnera niveau perf, surtout en multi-GPU.
Ah OK. En gros, même si on savait que les instructions seraient identiques à chaque itération, il fallait quand même aller les relire depuis le L1I. Là, on les copie dans un petit buffer proche des unités d'exécution.
Pour déterminer la taille de ce buffer, on pourrait faire des tests sur des boucles avec un nombre variable d'instructions identiques et voir à quel moment les perfs chutent ?
En fait, c'est que je n'avais pas compris l'intérêt de la chose, puisque les instructions étaient identiques.
Mais ce n'est pas parce qu'elle sont identiques que ca n'empêche qu'il faut quand même les relire.
Ils sont bêtes ces CPU...
Dernière modification par Yasko ; 03/11/2008 à 18h56. Motif: Fusion automatique
Le probleme est que si ton buffer est trop gros ca va bouffer du power (en general ces buffers sont implementes a coup de registres qui prennent plus de place et consomment plus que de la RAM [enfin il me semble, s'pas trop mon domaine ]). Donc on se contente de boucles assez petites. Maintenant pour tailler ce buffer, ca va dependre du type de benchmarks qu'on veut ameliorer.
Nan c'est les softeux qui sont betes : ils ont invente les bouclesIls sont bêtes ces CPU...
Les registres ce sont des cells 8T, la SRAM traditionelle 6T, mais vu la tendance a mettre du 8T partout dans les caches de bas niveau pour pouvoir descendre a des voltages plus faibles, au final ca ne change pas grand chose. Qui plus est une uop prend tres certainement nettement plus de bits a coder qu'une instruction x86 (le cisc ~= un encodage compact donc ce n'est pas vraiment le power de ce buffer qui compte.
Maintenant pourquoi un loop detector c'est bien:
Les decodeurs ont un debit donne, mais au mieux ils peuvent sortir 4 instructions par cycle, et en pratique plus le code sera foireux plus on s'approchera de 1. Si on garde les uops decodees dans un buffer, on peut les relire a 4/cycle sans aucun problemes, plus de contrainte de vitesse de decodage. Sur du code pouri avec des instructions un peu complexes c'est une augmentation de debit proche de 4x.
Le power... Fetch le IL1, trouver la longueur de l instruction predire les branchements et decoder ces instructions prend une quantite de power considerable sur un x86, le faire une fois plutot que n economise pas mal d'energie, mais ce n'est pas tout, les boucles correspondent generalement aux tests qui approchent le TDP, donc en gardant le frontend quasi eteint pendant des tests proches du TDP, on gagne aussi pas mal en max power. Qui dit reduction du max power dit possibilite de turbo plus vite, donc plus de perf.
Walla.
fefe - Dillon Y'Bon
Il y a quelque chose que je ne comprends pas.
On parle de codes pourris, et j'imagine qu'il y en a pas mal dans l'environnement x86, sinon pourquoi s'ingénier à les rendre plus rapides à traiter.
Qu'est-ce qui empêche un codeur de soigner son code ? Une contrainte énorme de temps ?
3 raisons :
- le budget.
- l'absence de tout ou partie du code.
- la flemme.
Dans le contexte de mon post precedent, code pourri = code avec des instructions qui prennent beaucoup de bytes (comme par exemple SSE4.1 et SSE4.2) ou du code employant des instructions complexes. Ce code n'est pas pourri du point de vue du programmeur, il peut meme etre assez tune (sauf pour les decodeurs).
Si le compilateur genere des instructions complexes parce que c'etait approprie pour le code en question (il se peut meme que ce soit la solution optimale d'un point de vue perf), le code n'en sera pas moins pourri du point de vue des decodeurs.
Bon il y a aussi les codes que personne ne veut reecrire dont parle Franck. Mais ceux la sont vraiment pourris.
fefe - Dillon Y'Bon