Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 1 sur 2 12 DernièreDernière
Affichage des résultats 1 à 30 sur 47

Discussion: Evolution du K8

  1. #1
    On parle pas mal en ce moment des K8G et K8L...

    Il semble qu'il y ait des modifications importantes. Qu'en est-il ?

    D'autre part, un certain nombre de modifications ressemblent aux améliorations du conroe... Ils font pas BE commun quand même t1cable: ?
    Mes propos n'engagent personne, même pas moi.

  2. #2
    Je suppose (j'espère) que notre Sam va nous pondre une jolie analyse de tout ça !

  3. #3
    K8L = K8 + ((merom - yonah) - 4wide fetch/retire) + 1an.

    , et j'attends les commentaires de Sam aussi
    fefe - Dillon Y'Bon

  4. #4
    Y'a aussi 4 liens HT3 au lieu de 3 HT2.

    En passant Intel reconait que le controlleur memoire intégré c'est bien pour les perfs.(http://www.matbe.com/actualites/1359...n-point-a-amd/)

    Par contre l'A64 n'est pas le premier à avoir fait ca, y'a eu le DEC Alpha avant.
    "si tout le monde s'etait dit "pour quoi faire ?" je pense qu'on tournerait encore sur 8086. Si tant est qu'on ait l'electricite ... " Franck@X86
    If all goes well will Dell sell Cells?
    <°)))><

  5. #5
    il me semble que rev G c'est juste la rev F en 65nm. Elle est censée apporter d'autres modifs ?

  6. #6
    Si cela était connu depuis l'introduction des Ahtlon 64 qui furent les premiers CPU à intégrer le contrôleur mémoire,
    DEC EV7, puis Intel timna, puis AMD K8. AMD n'est pas le premier avec un controleur memoire integre a son CPU (ni meme x86), juste le seul a le vendre .

    Un tel aveu confirme également que le géant des semi-conducteurs prévoit d'implémenter une telle modification dans ses prochaines puces
    .

    Une telle analyse est un peu rapide et simpliste. Si la seule raison de faire des CPU etait d'obtenir la performance maximum, elle serait probablement valide. En revanche le fait d'avoir un controleur memoire non integre offre de nombreux avantages autres: les plateformes sont plus flexibles, s'adaptent plus rapidement aux nouveux types de memoire, coute moins cher car fait dans un procede de fabrication plus ancien et plus rentable, et est tres pratique pour les solutions avec GPU integre.

    Donc, Intel sait faire depuis avant AMD vu qu'ils ont produit (et non commercialise) un cpu x86 avec controleur memoire integre avant le K8, mais Intel ne l'a jamais vendu jusqu'a maintenant, probablement parce que la performance additionnelle ne valait pas l'investissement a leurs yeux. Il est tres probable que la performance ajoutee par un controleur memoire integre soit plus important dans un cas de figure ou Intel est moins performant qu'AMD, en effet le gain en performance permettrait de gagner des parts de marche. Dans le cas de figure ou Intel a une position dominante sur le marche, ajouter encore un peu plus de performance n'a quasiment aucun benefice donc devient tres peu probable.

    Conclusion: on ne peut pas interpreter le fait que quelqu'un admette que 2+2 fasse 4... Un controleur memoire integre ne peut qu'ameliorer la latence et la bande passante memoire, est-ce une revelation de dire que cela gagne de la performance, et un signe pour l'avenir ?
    fefe - Dillon Y'Bon

  7. #7
    Les dernières news parlent d'une généralisation du cache à 512Ko... (sauf Opteron et FX). D'après Marc d'hfr, le gain lors du passage de 512Ko à 1Mo varie de 0,7% à 6,5% selon les applis.
    Hors une chose à laquelle on ne pense pas (ou du moins on n'en parle pas) c'est qu'on est tjs en 32bits. Qu'en sera-t-il lors du passage "généralisé" au 64bits? Les 512Ko ne risquent-ils pas d'êtres insuffisants?

  8. #8
    Citation Envoyé par Franck@x86
    il me semble que rev G c'est juste la rev F en 65nm. Elle est censée apporter d'autres modifs ?
    ils annoncent par exemple le SSE sur 128bits (comme sur Conroe) et un équivalent au memory disambiguation, et autres détails du genre... En gros, le K8L serait un "double" K8G...
    Mes propos n'engagent personne, même pas moi.

  9. #9
    Citation Envoyé par DJ_DaMS
    Hors une chose à laquelle on ne pense pas (ou du moins on n'en parle pas) c'est qu'on est tjs en 32bits. Qu'en sera-t-il lors du passage "généralisé" au 64bits? Les 512Ko ne risquent-ils pas d'êtres insuffisants?
    En x86-64, ce qui change en C/C++ c'est la taille des pointeurs qui passent à 64bits au lieu de 32, les entiers eux font toujours 32bits. Donc à moins de manipuler des forêts de pointeurs, la taille des données d'un programme ne devrait pas trop changer.
    Reste la taille du code. Comme on est dans le monde merveilleux du x86, on a des opcodes de taille variable, et non pas fixés sur 32 ou 64bits. De ce côté, pas non plus de raison de doubler la taille.

  10. #10
    Et il y a moins de "bidouille" de registres vu qu'il y en a 8 de plus, donc code plus court...
    Mes propos n'engagent personne, même pas moi.

  11. #11
    Citation Envoyé par Neo_13
    ils annoncent par exemple le SSE sur 128bits (comme sur Conroe) et un équivalent au memory disambiguation, et autres détails du genre... En gros, le K8L serait un "double" K8G...
    Euh ... le K8 rev G c'est juste un die shrink aux dernières news, il me semble.

  12. #12
    Vu sur http://www.presence-pc.com/actualite...tecture-17551/

    "Hans De Vries, vient de publier sur le site Chip Architect, une carte de l’architecture K8L. On y voit quatre décodeurs d’instructions, une interface 256 bit pour le cache L1, et des unités de prédiction de branchement plus importante, bref cette architecture serait plus large que celle des K8. Nous notons aussi l’absence de ZRAM, pourtant annoncé comme adopté par AMD[...]"

  13. #13
    ce genre de rumeur :http://129.15.202.185/athlon_rev_g/wtf_mates.html

    La ZRAM, si elle n'a qu'un seul transistor, c'est probablement qu'elle se sert de la couche SOI comme condensateur (hypothèse)... Ca devient donc de la DRAM... avec rafraichissement obligatoire ! C'est pas génant pour du cache on die ?
    Mes propos n'engagent personne, même pas moi.

  14. #14
    Citation Envoyé par fefe
    Un controleur memoire integre ne peut qu'ameliorer la latence et la bande passante memoire, est-ce une revelation de dire que cela gagne de la performance, et un signe pour l'avenir ?
    Le principal intérêt c'est le SMP.

  15. #15
    Citation Envoyé par jose99m
    Le principal intérêt c'est le SMP.
    Personne n'a jamais eu besoin d'un controleur memoire integre pour construire des systemes SMP, ni meme des systemes SMP qui scalent tres bien.

    Les interconnections entres processeurs et de disposer de suffisament de controleurs pour avoir une bande passante importante sont ce qui compte et sont idependants de l'integration du controleur memoire.

    C'est un amalgame qui a ete fait parce que les systemes a base de K8 scalent bien en SMP, mais tout le monde semble oublier qu'il y a beaucoup d'autres systemes qui scalent jusqu'a plusieurs 100aines de processeurs en SMP sans controleur memoire integre.
    fefe - Dillon Y'Bon

  16. #16
    sgi avec les itanium2 par exemple, même si ça s'apparente pas mal à du NUMA, il n'y a pas de contrôleur intégré.

    D'autre part, il semble qu'il y ait des problèmes avec le ht actuel à partir de 8cpu à cause de la cohérence des caches qui encombre le bus (mais j'ai bien dit "il semble" puisque ça manque d'info officiel là dessus)
    Mes propos n'engagent personne, même pas moi.

  17. #17
    Le contrôlleur mémoire intégré c'est bien quand on a un prefetch moisi (demi troll)

  18. #18
    C'est surtout quand on est pas capable de faire des chipsets corrects soi-même.

    c'est gênant quand même quand un société qui fait des cartes graphiques vous bat sur votre propre terrain.

    Hop, on met le contrôleur dans le CPU : plus de comparaison de perfs, donc plus de polémiques.

  19. #19
    Citation Envoyé par dandu
    C'est surtout quand on est pas capable de faire des chipsets corrects soi-même.

    c'est gênant quand même quand un société qui fait des cartes graphiques vous bat sur votre propre terrain.

    Hop, on met le contrôleur dans le CPU : plus de comparaison de perfs, donc plus de polémiques.
    A part la situation des débuts avec l'AMD 750 qui pouvait poser des problèmes de compatibilité, l'AMD 760, quoique faiblement diffusé, était plutot efficace, mais moins riche en fonctions que les best sellers de l'époque (débuts du nforce et via kt333 en tête). Par contre on peut pas lui reprocher de gros soucis de stabilité. AMD a jamais voulu faire de chipset à part pour lancer ses plateformes, ce qui peut être considéré comme un choix comme un autre pour un "petit" fondeur. Je crois pas que ca changerait énormément la donne pour les plateformes desktop ou serveurs une solution 100% AMD (trop tard, toute le monde a pris le pli d'aller se fournir ailleurs de toutes façons). Par contre, pour les portables, la rumeur de rachat d'ATI prend plus de sens pour offrir une plateforme "centrino like" avec solution graphique intégrée et tout le toutim.

    Si on regarde actuellement le marché pro particulièrement, c'est Broadcom qui raffle la mise pour AMD (je sais même pas si ils se sont cassé le baigneur à sortir un successeur au 8000), et ca reste Serverworks (toujours Broadcom donc) la référence pour les plateformes Intel, et non Intel lui même depuis des lustres.

    Les marges de performances dans tout ca ? à peu près peanuts depuis pas mal de temps quand même (dual chanel et compagnie sur K7, c'est pas spécialement l'explosion des performances non plus...).

  20. #20
    http://www.theinquirer.net/?article=32589

    l'anti-HT serait bien une réaliité...
    "We can't wait twenty years to achieve a 1000 fold increase in PlayStation performance : Moore's Law is too slow for us"
    Shin'ichi Okamoto-Chief Technical Officer Sony Computer Entertainment Corporation

  21. #21
    Citation Envoyé par EPIC
    http://www.theinquirer.net/?article=32589

    l'anti-HT serait bien une réaliité...
    Et en gros ca fais quoi?

  22. #22
    Citation Envoyé par voxel
    Et en gros ca fais quoi?
    Bah ce dont sam parlait l'autre fois dans sa news, un HT inversé.

    On fait croire à l'OS au dessus qu'il y a un seul core, et en hardware on dispatche entre les cores.

  23. #23
    Citation Envoyé par Lissyx
    Bah ce dont sam parlait l'autre fois dans sa news, un HT inversé.

    On fait croire à l'OS au dessus qu'il y a un seul core, et en hardware on dispatche entre les cores.
    ok merci

    Mais personne n a encore pu evaluer la gain en perf ?

  24. #24
    Citation Envoyé par voxel
    ok merci

    Mais personne n a encore pu evaluer la gain en perf ?
    Si :

    De nombreux articles de recherche traitent du speculative-multi-threading (les mots cles sont multiscalar/spmt/dmt/imt/skip ahead multithreading)... Un coup de google ou de citeseer devraient te donner bien plus de reponses que je ne pourrai en formuler dans une reponse rapide. Les gains potentiels ne sont pas du tout de l'ordre de n-times n etant le nombre de cores, mais variables suivant les caracteristiques de l'application et des gains compris entre 1+(n-1)/2 et 1+(n-1)/5 sont probablement possibles.

    http://www.google.com/search?q=specu...multithreading
    De fefe Ici : http://forum.x86-secret.com/showthread.php?t=4544

    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]

  25. #25

  26. #26
    Rho la flemme de traduire...:D En gros ca parle de quoi?

  27. #27
    Citation Envoyé par voxel
    Rho la flemme de traduire...:D En gros ca parle de quoi?
    :D :D
    Keyboard error or no keyboard present
    Press F1 to continue, or DEL to enter setup

  28. #28
    Pour les feignasses :

    C'est assez intéressant, ça explique bien le speculative-multi-threading. En gros le problème est de donner a manger aux différents core/cpu pour un programme qui n'est pas paralélisé.

    Si on a un gros calcul qui prends du temps et si on a besoin du résultat pour continuer ça bloque "tout le système" en attendant ce résultat. Si j'ai bien compris, l'idée est de donner à calculer la suite du code a un autre core qui branle rien. Le principal problème est surtout de deviner les données qui seront utilisées dans le prochain bloc. (J'imagine que l'expériance acquise sur les prédictions de branchement seront très utiles) Si on s'est pas trompé on aura réussi à paraléliser du code, sinon on tournera au moins aussi vite qu'avant.

    D'après le papier il faudra que le compilateur détermine à l'avance les zones de codes succeptibles d'être exploitées de cette manière. Le hardware sera évidement aussi de la partie. J'imagine que le système serait aussi très éfficasse quand il y a des saut conditionnels a l'issue du calcul, si on a deux cores de libre on peut fait les deux calculs futurs et avoir le résultat tout de suite.

  29. #29

  30. #30
    et personne n'a encore envisagé de faire calculer la meme chose aux deux cores, pour vérifier le validité des résultats (comme avec les xeons mp et les itanium2 en smp) ?
    Mes propos n'engagent personne, même pas moi.

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
  •