Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 9 sur 26 PremièrePremière 123456789101112131415161719 ... DernièreDernière
Affichage des résultats 241 à 270 sur 764
  1. #241
    Elle est bonne quand-même
    "La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24

  2. #242
    Le L1 à 4cycles, ça sent un peu sous les aisselles IMHO.
    Mes propos n'engagent personne, même pas moi.

  3. #243
    C'est peut-être une conséquence du passage à la 8T-SRAM, dont je ne pense pas qu'Intel soit l'inventeur d'ailleurs (référence au commentaire sur l'Atom).

  4. #244
    Vous oubliez HT
    fefe - Dillon Y'Bon

  5. #245
    Dans le sens où ça joue sur les latences, ou dans le sens où ça les masque ? Parce que dans le deuxième cas ok (quoiqu'en single thread on s'en fout) mais dans le premier je vois pas.

  6. #246
    Le SMT a un impact direct sur la latence, les ressources comme les Load buffers/Store buffers ont ete considerablement changees (comme explique dans l'article d'Anand), et il faut forcement de la logique pour garantir aucun deadlock entre les 2 threads, ou meme gerer les priorites entre les 2 threads, et l'envoi de donnees a qui il faut.
    Des que les ressources ne sont pas partagees de maniere completement thread-agnostic SMT a tendance a complexifier le controle de maniere non negligeable.
    Ca, combine a une amelioration du traitement des acces non alignes (demande du buffering et des rotators), un remodelage des TLB (qui sont sur le chemin du L1 chez Intel) et un passage du cache en Register File me semble tout a fait suffisant pour justifier 1 cycle .
    fefe - Dillon Y'Bon

  7. #247
    OK, donc la latence supplémentaire est due aux modifications du pipeline induites par le SMT, mais pas au L1 lui-même ?

  8. #248
    En general les cells 8T ne sont pas moins rapides que les cells 6T (les 8Tsont employees dans les bancs registres). Elles tiennent mieux la frequence aux bas voltages donc en pratique on pourrait presque dire qu'elles sont plus rapides (et plus grosses).
    A mon avis ca vient du SMT et un peu des modifs des TLBs, apres cela importe peu d'ou ca vient ils semblent savoir exactement combien ca leur a coute en performance, donc le choix n'a pas ete fait au hasard et il y avait forcement un retour sur investissement.
    fefe - Dillon Y'Bon

  9. #249
    Oui j'imagine qu'ils ont pas fait ça pour le plaisir de faire un truc plus lent ^^

    Sinon j'ai vu des tests dans lesquels Nehalem se montrait un peu moins rapide que Penryn dans les jeux, certains imputent ça à une plateforme pas tout à fait mature, d'autres à la différence de taille du cache, qu'en penses-tu ?

  10. #250
    Comme tous les changements d'architecture significatifs il y aura des cas ou a frequence egale l'ancienne sera plus rapide, mais en general isoles. Il y a eu des cas ou P4 allait plus vite que core2 mais on l'a vite oublie.

    Les applis qui etaient optimisees pour un gros cache rapide (donc qui etaient optimisees pour favoriser Intel vs AMD) vont souffrir le plus, mais modifier un algo blocke pour une taille de cache X ou Y n'est pas la mort etant donne que AMD et Intel ont toujours eu des tailles differente donc c'etait une flexibilite a avoir. Maintenant que les hierarchies de cache des 2 constructeurs se ressemblent beaucoup (surtout Shangai avec ses 6M de L3) ca devrait meme simplifier la tache d'optimisation (et de maniere generale probablement meme favoriser les possesseurs d'AMD).

    Il est possible que des plateformes soient immatures et que ca affecte les performances graphiques aussi, en effet le chemin vers les IO (le PCIe) a pas mal change avec le passage a QPI donc il est possible qu'ils aient des bugs la aussi, mais ca disparaitra a la release alors que les problemes de cache non.

    Finalement il y a HT, si le scheduleur de l'OS merde lors du scheduling des threads il y a de bonnes chances de perdre de la perf sur des applis a faible nombre de threads (donc les jeux par ex). Ca c'est plus dur a dire comment MS s'en sortira. Ce qui est certain c'est que si un thread de jeu passe sur un CPU avec un autre thread en HT au lieu que ce dernier soit sur un autre CPU les performances devraient etre legerement inferieures a Penryn ou pas mieux.
    Si cela se produit beaucoup, et c'est possible qu'a la release MS ne soit pas super pret (ca fait un moment que HT a disparu de leur radar donc je doute que Vista ait ete particulierement concu avec HT a l'esprit). Si c'est le cas tout les joueurs desactiveront HT et le probleme disparaitra.

    Conclusion, je ne pense pas qu'il y ait de glassjaws qui ne soient pas fixes relativement aisement, mais je doute qu'il n'y en ait pas (je connais peu de CPUs qui n'en aient pas eu, et tous ne comportaient que des modifs mineures).
    fefe - Dillon Y'Bon

  11. #251
    Ca serait tout de même une mauvaise surprise de la part de MS qu'il y ait encore des problèmes de scheduling de ce type dans ses OS. Pour le smithfield, le cas n'avait pas encore été rencontré, c'était la première fois que Windows tournait sur un environnement avec à la fois des CPU physiques et logiques (enfin la 1ère fois, c'était netburst en multi-CPU).
    On peut espérer que MS ait implémenté une solution suffisamment générique pour ne pas avoir à la changer (hors optimisations mineures) à chaque fois que le nombre de CPU augmente.
    Qu'il y ait 2 CPU physiques et 2 CPU logiques, ou 4+4, les règles de distribution de threads restent valables ?

  12. #252

  13. #253
    J'ai lu sur kikipedia que le chiffre 7 proviendrait d'un article de PC watch composé de 7 processeurs. Je pense qu'il doit y avoir une autre raison .

    Sinon, l'idée de faire disparaitre le MCH à terme (remplacé par un PCH) est assez énigmatique car l'éventuel GPU intégré sera mis sur le Ci7 package : simple coïncidence ou possible intégration du GPU on CPU die + tard ? (comme le fut Timna (GPU + MCH on-die)).

  14. #254
    Citation Envoyé par Childerik Voir le message
    J'ai lu sur kikipedia que le chiffre 7 proviendrait d'un article de PC watch composé de 7 processeurs. Je pense qu'il doit y avoir une autre raison .

    Sinon, l'idée de faire disparaitre le MCH à terme (remplacé par un PCH) est assez énigmatique car l'éventuel GPU intégré sera mis sur le Ci7 package : simple coïncidence ou possible intégration du GPU on CPU die + tard ? (comme le fut Timna (GPU + MCH on-die)).
    Après tout, AMD, avec Fusion, semble aussi parti dans cette voie ...

  15. #255
    Fusion a clairement la vocation de coupler un CPU et un GPU ("puissant"), alors que dans l'association Core i7 + GMA, je ne vois pas d'objectif pour une plate-forme 3D de la mort-qui-tue.

    En revanche, généraliser les SOD aux cartes mères ATX et mATX a clairement un intérêt : simplifier le design de ces dernières (pour faciliter davantage une miniaturisation et baisser les coûts).

  16. #256
    http://www.hardware.fr/articles/733-...l-nehalem.html

    Clap clap clap .

    Toujours aussi instructif le Franck .

    Un truc que je n'ai pas trop pigé avec QPI, c'est : le bus interne du CPU a-t-il une réelle existence ? Sa valeur est déterminée directement avec la division du lien QPI par le coefficient du CPU si j'ai bien compris ?

  17. #257
    Oui merci, et je remercie Fefe qui m'a corrigé plein de choses (pour ne pas dire plein de conneries, et c'est d'ailleurs pas dit qu'il en reste pas qques unes).

    La fréquence interne dépend-elle du QPI ? Grande question.
    A priori, non ! mais en pratique, quand on monte la freq CPU, le QPI augmente également... allez comprendre.

    Ca doit dépendre de l'implémentation je suppose.

  18. #258
    Roh, j'avais même pas vu que c'était Franck qui avait pondu ce dossier. Toutes mes félicitations parce que c'est quand même plutot clair malgré la complexité de la chose.

    Maintenant, cette histoire du TDP, ca a l'air tordu quand même, mais ca a l'air aussi très subtil comme principes de gestion des fréquences d'horloges.

    Je me dit qu'on voit aussi la puissance de prod d'Intel avec leur principe d'"uncore" variable et avec toutes les variations qu'ils envisagent.

  19. #259
    Tres interessant l'article, merci

    Maintenant on comprend pourquoi l'acces L1 passe de 3 a 4 cycles : suppression des micro-TLB...

  20. #260
    Tiens, une question toute simple à laquelle je n'ai pas trouvé de réponse :

    Sur les plateformes serveur "Gainstown", il semble qu'on aura 2 fois 6 slots DDR3. Très bien, mais que se passe-t-il si on ne monte qu'un cpu ? les slots sensés être reliés au contrôleur mémoire du cpu absent deviennent inutilisable ?

  21. #261
    oui, par contre l'inverse est possible : deux processeurs et un seul avec de la mémoire. L'autre accède à la mémoire en "remote".

  22. #262
    Pas de 2 eme cpu = pas de 2 eme controleur memoire = slots 6 a 11 inutilisables.
    fefe - Dillon Y'Bon

  23. #263
    Voilà une mauvaise nouvelle....

  24. #264
    Citation Envoyé par Stéphane.P Voir le message
    Voilà une mauvaise nouvelle....
    Tu comptais faire un upgrade avec tes 12 FB-Dimm ?

  25. #265
    Citation Envoyé par Childerik Voir le message
    Tu comptais faire un upgrade avec tes 12 FB-Dimm ?
    Héhé !! C'est plutôt le fait que les besoins de mes clients sont :

    - pas forcément beaucoup de ressources Cpu (un xeon quad suffit)
    - de la ram de la ram de la ram...

    Donc les stations sont souvent équipée d'un seul cpu.

    Par contre, je ne suis pas mécontent qu'on oublie la FB-Dimm.

  26. #266
    Sur 6 Dimm, tu peux quand même caser 24, voire jusqu'à 48 Go de ram si la Dimm supporte une barrette de 8 Go. C'est pas suffisant pour un seul Xeon ?

  27. #267
    Disons que si tu commences a blinder une machine de barettes de 8G, ce n'est pas le 2 eme CPU meme a 2000$ qui va vraiment te revenir cher... Qui plus est dans ces cas la tu mettras probablement des CPUs "bas" de gamme comme ca en avoir 2 ne sera pas trop couteux .
    Sinon AMD a le meme "probleme", on va dire que c'etait un avantage de la vieille architecture Intel avec FSB+chipset, mais je doute que beaucoup de monde aille se plaindre que c'etait mieux avant de ce cote la.
    fefe - Dillon Y'Bon

  28. #268
    Citation Envoyé par Article Franck@HFR
    Sur une architecture multi-cores, la relation inclusive amplifie ce défaut : sur les 8 Mo du L3, plus d'un Mo est occupé par les copies des caches L1 et L2. Mais elle présente également l'avantage de moins perturber les caches privés L1 et L2. Pourquoi ? car en cas d'échec du cache L3 (L3 miss), on est certain que cette donnée n'est pas dans les caches privés de chacun des cores (sinon elle se trouverait dans le L3 du fait de la relation inclusive), ce qui permet d'éviter la vérification et de déclencher immédiatement une requête de lecture en mémoire.
    Quand on recherche quelque chose dans la hiérarchie de cache, on ne fait pas forcement la recherche par niveau croissant ? (1, 2[, 3])

  29. #269
    Citation Envoyé par Yasko Voir le message
    Quand on recherche quelque chose dans la hiérarchie de cache, on ne fait pas forcement la recherche par niveau croissant ? (1, 2[, 3])
    Il parlait peut-être de requête cohérente ?

  30. #270
    Citation Envoyé par newbie06 Voir le message
    Il parlait peut-être de requête cohérente ?
    C'est a dire 95% du traffic sur un CPU normal (le reste etant les IO).

    A chaque fois qu'une requete coherente doit etre inseree dans le LLC tu dois evict quelque chose du LLC pour pouvoir l'inserer. Si tes caches sont strictement inclusifs tu sais quel cores ont demande cette donnee et tu as meme des chances de savoir si ils l'ont encore. Au lieu de devoir snoop tous les cores pour verifier si tu pouvais evict cette donnee tranquillement (<=> personne ne l'a modifiee dans son cache de niveau 1/2), tu ne le fais que si il y en a baesoin.

    Au final un cache inclusif te permet d'implementer un snoop filter pour quasiment rien. Dans le cas d'un cache non inclusif soit il te faut une copie des tags des autres caches pour verifier sans aller leur demander si ils ont une copie modifiee de la donnee, soit pour chaque eviction du LLC tu vas devoir faire un broadcast et leur demander si ils l'ont modifiee. Inutile de dire que la premiere option est couteuse en hardware, et la deuxieme couteuse en performance et power (on passe son temps a aller snooper tous les caches de la machine).

    Bien sur tout n'est pas rose avec un cache inclusif, cela cause des problemes d'invalidation mutuelle des cores, mais celles-ci sont au final moins pesantes pour l'architecture que de devoir supporter un traffic en snoop monstrueux a partir du moment ou il y a assez de cores (4 et +)

    Les invalidations muttuelles ressemblent a ca: Si tu as 4 CPU qui ont des miss vers le LLC, chacun ayant un cache a 8 voies, tu as une probabilite non negligeable que les acces de ceux-ci entrent en conflit. Si ils entrent en conflit (ils vont dans le meme set et l'associativite du LLC est < a la somme des associativite de chaque core) il va falloir evicter certaines donnees. Dans certains cas tu auras a evict une donnee qui est encore presente dans un core (deja tu sais lequel c'est donc cela ne prendra pas trop de temps a trouver). Tu vas me dire que la politique de remplacement dans le cache est LRU donc en general on va choisir pour eviction quelqu'un qui n'a pas ete accede depuis longtemps. Mais le fait qu'il n'ait pas ete accede depuis longtemps dans le LLC veut malheureusement souvent dire que un core passait son temps a faire des hits dessus dans son L1. Donc tu viens de reussir a creer une situation ou plusieurs cores passent leur temps a evict mutuellement des donnees tres utiles de leurs L1 respectifs.
    Bien entendu le systeme tent a se stabiliser dans une situation ou cela n'arrive pas car l'associativite du L3 n'est pas ridicule mais ca arrive alors que dans un cache non inclusif cela n'arrive pas.

    Mmm je ne suis pas sur que d'expliquer des phenomenes de coherence des caches comme ca a l'arrache va vraiment etre clair (dite moi si rien compris...)
    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
  •