Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 11 sur 26 PremièrePremière ... 34567891011121314151617181921 ... DernièreDernière
Affichage des résultats 301 à 330 sur 764
  1. #301
    C'est l'article qui lui monte à la tête !

  2. #302
    Citation Envoyé par Doc TB Voir le message
    Je m'excuse par avance des honteux raccourcis que je suis en train de faire sur l'article Nehalem, mais malheureusement, c'était indisponible pour que la majorité puisse essayer de comprendre le truc.
    Ce journal est un scandale.
    Mes propos n'engagent personne, même pas moi.

  3. #303
    Et y'aurait pas moyen d'avoir une version en ligne non censuree, genre 2 semaines apres la parution ?

  4. #304
    Je vote pour aussi. Une version avec les explications !

  5. #305
    Citation Envoyé par newbie06 Voir le message
    Et y'aurait pas moyen d'avoir une version en ligne non censuree, genre 2 semaines apres la parution ?
    Ca me parait difficile. Déjà là, j'en chie pour terminer les tests de base à temps et je me vois mal recommencer le tout en plus complexe la semaine prochaine. Ceci dit, bon, vous inquiétez pas hein, je vais pas non plus vous sortir un test avec un superpi et tchao bon soir

  6. #306
    Ou sinon un test comme d'hab et tant pis pour ceux qui comprennent pas, ils ont qu'à lire Clubic ? Non ? Arf, tant pis...

  7. #307
    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]

  8. #308
    Citation Envoyé par Alexko Voir le message
    Ou sinon un test comme d'hab et tant pis pour ceux qui comprennent pas, ils ont qu'à lire Clubic ? Non ? Arf, tant pis...
    Je doute qu'il y en ai beaucoup qui comprenne les 6 premières pages, c'est déjà bon signe, non ?

  9. #309
    Citation Envoyé par Doc TB Voir le message
    Ca me parait difficile. Déjà là, j'en chie pour terminer les tests de base à temps et je me vois mal recommencer le tout en plus complexe la semaine prochaine. Ceci dit, bon, vous inquiétez pas hein, je vais pas non plus vous sortir un test avec un superpi et tchao bon soir

    Tu vas te contenter de CPUMark99

  10. #310
    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

  11. #311
    Citation Envoyé par Doc TB Voir le message
    Je doute qu'il y en ai beaucoup qui comprenne les 6 premières pages, c'est déjà bon signe, non ?
    C'est marrant, parce que hors contexte, cette phrase serait très étrange. Pourtant oui, c'est plutôt bon signe :D

  12. #312
    Citation Envoyé par Doc TB;
    Dans tous les cas, le Core i7 ne se distingue pas vraiment des Core 2 dans le domaine ludique. Alors, à qui la faute ? Probablement au bus QPI. En effet, celui-ci provoque un saut supplémentaire pour transférer des données de la mémoire centrale à la carte graphique. Du schéma classique Mémoire <-> Northbridge <-> PCI Express, on tombe maintenant dans le schéma Mémoire <-> CPU <-> QPI <-> PCI Express, ce qui induit une latence supplémentaire, au point de parfois de ralentir le CPU par rapport à la génération précédente.
    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).
    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

  13. #313
    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.

  14. #314
    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.

  15. #315
    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

  16. #316
    Citation Envoyé par fefe Voir le message
    Personellement je pense que le probleme est plus dans le cache que dans le Q(pi).
    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.

    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é
    Raté : le PIII Timna.

    il faudra se contenter sur Core i7 de mémoire DDR3-1066 selon les spécifications officielles du fondeur
    Et la DDR3-1333 ?

    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
    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 ?

    Nehalem réintroduit en effet l'HyperThreading
    L'Atom est-il si transparent que ça ?

    Sur Nehalem, chaque cœur dispose de sa propre mémoire cache de premier et second niveau, une mémoire naturellement non partagée
    On ne comprend pas tout là . Et c'est encore pire dans le chapitre suivant où tout est emmêlé.

    Il semblerait que Far Cry 2 n'apprécie guère l'HyperThreading
    Il en sait quelque chose ?
    Dernière modification par Childerik ; 03/11/2008 à 16h55.

  17. #317
    Citation Envoyé par Childerik Voir le message
    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 ?
    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 ?

    Citation Envoyé par Childerik Voir le message
    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 ?
    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.

    Citation Envoyé par Childerik Voir le message
    On ne comprend pas tout là . Et c'est encore pire dans le chapitre suivant où tout est emmêlé.
    Remplace le mot "naturellement" par "donc".

    Citation Envoyé par Childerik Voir le message
    Il en sait quelque chose ?
    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

  18. #318
    Citation Envoyé par Foudge Voir le message
    Effectivement, soit ils ont confondu avec COD4, soit il n'ont pas publié tous leur tests.
    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.

  19. #319
    Citation Envoyé par Doc
    La dernière amélioration provient d’un autre procédé, lui aussi présent sur Core 2, conçu pour améliorer l’efficacité : le détecteur de boucle. Prenons le cas d’une boucle ou les mêmes opérations sont répétées plusieurs dizaines, centaines ou milliers de fois. Sur Core 2, la boucle était détectée en hardware et le front-end supprimait les étapes de prédictions de branchement et de récupération des instructions (fetch) à chaque « tour » dans la boucle. Des opérations inutiles puisque le principe même d’une boucle est d’utiliser les mêmes instructions. Sur Nehalem, le détecteur de boucle va encore plus loin puisqu’il est désormais placé après la dernière étape du front-end, c'est-à-dire le décodage des instructions x86 en µops.
    En conséquence, lorsqu’une boucle est détectée, les instructions qu’elle utilise ne sont plus ni récupérées du cache, ni prédites ni décodées. Ceci amène un gain en performances et en consommation d’énergie puisque les unités de décodages sont moins sollicitées.
    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 ?
    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.

  20. #320
    Citation Envoyé par Yasko Voir le message
    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 ?
    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 ...

  21. #321
    Citation Envoyé par Yasko Voir le message
    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 ?
    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.
    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

    Citation Envoyé par Franck@x86 Voir le message
    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 ...
    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

  22. #322
    il suffit de pousser un peu le FSB et tout ce passera bien
    Tient je croyais que le FSB avait disparu
    Étourderie (ou vulgarisation volontaire ?) je suppose, car quelques lignes plus bas vous parlez bien de "fréquence de base".

    A quoi donc sert par exemple le bus QPI pour le grand public à part diminuer les performances ludiques ?
    En attendant la nouvelle plateforme LGA1156 avec contrôleur PCIE intégré, fallait bien un bus pour relier le CPU au NB
    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.

  23. #323
    Citation Envoyé par Franck@x86 Voir le message
    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 ...
    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 ?

    Citation Envoyé par newbie06 Voir le message
    En fait j'ai pas compris ou le Doc n'etait pas clair, donc je ne suis pas sur de t'avoir aide
    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

  24. #324
    Citation Envoyé par Yasko Voir le message
    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 ?
    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.

    Ils sont bêtes ces CPU...
    Nan c'est les softeux qui sont betes : ils ont invente les boucles

  25. #325
    Citation Envoyé par newbie06 Voir le message
    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

  26. #326
    Citation Envoyé par Foudge Voir le message
    Ils ont inventé les boucles car ils sont feignant. C'est le compilateur qui est bête : il pourrait dérouler les boucles
    Faudrait supprimer les compilateurs, et filer directement le code source au hardware, qui se débrouille avec ce qu'il a.

  27. #327
    Citation Envoyé par newbie06 Voir le message
    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.
    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

  28. #328
    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 ?

  29. #329
    3 raisons :
    - le budget.
    - l'absence de tout ou partie du code.
    - la flemme.

  30. #330
    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

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •