Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
Page 3 sur 5 PremièrePremière 12345 DernièreDernière
Affichage des résultats 61 à 90 sur 131
  1. #61
    AMD a-t-il vraiment l'intention de se faire de l'argent avec Zambezi sur le marché grand public ? Pour moi il mise avant tout sur ses APU : Llano, puis Trinity (APU qui sera équipé de 2 modules "BD enhanced" et d'un IGP).
    Zambezi c'est vraiment histoire de proposer qqch de plus perf que Llano, mais c'est je pense avant tout destiné aux serveurs où il n'y aura pas de problème de marge.

  2. #62
    Citation Envoyé par Foudge Voir le message
    Zambezi c'est vraiment histoire de proposer qqch de plus perf que Llano, mais c'est je pense avant tout destiné aux serveurs où il n'y aura pas de problème de marge.
    Si j'ai bien compris (je me perds dans les noms), Zambezi est la version desktop, tandis qu'Interlagos est la version serveur. J'ai bon ?

  3. #63
    Citation Envoyé par newbie06 Voir le message
    Si j'ai bien compris (je me perds dans les noms), Zambezi est la version desktop, tandis qu'Interlagos est la version serveur. J'ai bon ?
    En fait Interlagos est un CPU équipé de 2 die de Valencia, qui est l'équivalent serveur de Zambezi.
    J'ai utilisé 'Zambezi' pour désigner le die de 315mm² doté de 4 modules BD, j'avoue avoir utilisé ce terme de manière approximative

  4. #64
    Citation Envoyé par Foudge Voir le message
    AMD a-t-il vraiment l'intention de se faire de l'argent avec Zambezi sur le marché grand public ? Pour moi il mise avant tout sur ses APU : Llano, puis Trinity (APU qui sera équipé de 2 modules "BD enhanced" et d'un IGP).
    Zambezi c'est vraiment histoire de proposer qqch de plus perf que Llano, mais c'est je pense avant tout destiné aux serveurs où il n'y aura pas de problème de marge.
    Je suis plutot d'accord avec toi, ce qui veut dire qu'il est dans leur interet d'en vendre le moins possible en dehors du marche serveur (vu qu'ils sont limites par la capacite de production de GF). Si ils ne veulent pas en vendre trop, il leur suffit de les vendre pour un peu trop cher. Le probleme est que les prix annonces sont assez bas. Si ces bas prix sont "chers" ca donne de mauvais presages sur les perfs du produit, si ils sont attractifs ca n'a pas vraiment de sens.

    Apres avoir montre un OC a 8.4GHz on pourrait s'attendre a ce qu'ils vendent le haut de gamme a un tarif eleve non ? Ca devrait attirer au moins quelques enthousiastes non ?

    Tout ca ne reste que du domaine de la rumeur donc ca peut tout a fait etre de la desinfo organisee. Wait and see.
    fefe - Dillon Y'Bon

  5. #65
    Sans compter qu'ils ont annoncé la fin de la commercialisation des Phenom II X6 d'ici la fin de l'année, pour pas faire d'ombre aux FX-4/6/8 j'imagine. C'est vrai qu'ils ont l'air de vouloir vendre au mieux leur AMD FX, pourtant j'ai pas l'impression que ce soit dans leur intérêt. Ceci dit t'as raison, W&S.

  6. #66

  7. #67
    Alors, on apprend que :
    - Le FX-8150 a les mêmes perfs que l'i7 980X dans les benchs GPU-limited.
    - Quand on l'overclocke de 30%, on gagne jusqu'à 30% de perf.
    - Des fois il va même 10% plus vite que le Phenom II.
    - Le FMA en hard c'est plus rapide qu'en soft.
    - Avec 2 fois plus de « cores », on va de 10 à 20% plus vite qu'Intel sur les applis multithreadées.
    - Avec du Crossfire X - Eyefinity en 7680x1600 on arrive à saturer la bande passante PCIe du Core i5.

    Ah ouais quand-même… Là ça craint.

  8. #68
    Citation Envoyé par Møgluglu Voir le message
    Alors, on apprend que :
    - Le FX-8150 a les mêmes perfs que l'i7 980X dans les benchs GPU-limited.
    - Quand on l'overclocke de 30%, on gagne jusqu'à 30% de perf.
    - Des fois il va même 10% plus vite que le Phenom II.
    - Le FMA en hard c'est plus rapide qu'en soft.
    - Avec 2 fois plus de « cores », on va de 10 à 20% plus vite qu'Intel sur les applis multithreadées.

    Ah ouais quand-même… Là ça craint.
    C'est à peu près ce que je me suis dit, oui.

    Mais heureusement, il prend la tête en Eyfinity ! Youhou !
    Mon blog (absolument pas à jour) : Teχlog

  9. #69
    J'ai ninja-édité pour rajouter Eyefinity.
    Ah et puis AES va plus vite en hard sur AMD qu'en soft sur AMD.

  10. #70
    On peut esperer que leur controle de l'info est bon et que ce qui ne leake avant la release n'est que des evidences qui n'aident en rien la competition a se preparer. Enfin on peut esperer pour AMD.
    fefe - Dillon Y'Bon

  11. #71
    Un peu plus prometteur côté serveur, enfin disons que 2,5 GHz avec les 16 cores, c'est pas trop mal : http://citavia.blog.de/2011/09/24/ei...aked-11911716/

    Et surtout, Turbo fait son entrée sur Opteron, avec une belle amplitude (jusqu'à 1 GHz).
    Mon blog (absolument pas à jour) : Teχlog

  12. #72
    Une amplitude de turbo importante signifie juste que leur coeur consomme beaucoup par rapport au TDP du socket.
    La frequence max est generalement determinee par la vitesse maximale a laquelle le coeur le plus lent peut tourner. La frequence TDP est determinee comme etant la frequence maximale a laquelle les applications multicore les plus lourdes peuvent fonctionner tout en restant dans l'enveloppe TDP.
    Une faible marge de turbo indique 2 choses au choix:
    -le core consomme peu par rapport a l'enveloppe TDP
    -quelqu'un dans un departement marketing a decide de castrer artificiellement les perfs de ce produit.

    Si je veux plus d'1GHz d'amplitude sur un de ces opterons il me suffit de prendre le meme silicone et de le specifier pour une enveloppe TDP plus faible.
    fefe - Dillon Y'Bon

  13. #73
    Quelques post intéressant de The Mad/Doc_TB sur HFR. Un nouveau scoop à propos de Piledriver ?

    A propos d'un schémas montrant un thread pouvant utiliser toute les ressources dans une configuration CMT :
    Non. Le schéma la, c'est celui de l'Alpha [21264]. Et c'est la tout le probleme. Selon moi (mode subjectif, mais basé tout de même sur des sources internes), c'est ce qu'AMD a cherché à faire dans Bulldozer. MAIS, pour une raison ou une autre, même si le hardware est la, il ne fonctionne pas en pratique. C'est pourquoi on a vu les projections d'AMD en termes de performances s’effondrer entre mi-2010 et mi-2011. La communication inter-cluster ne fonctionne pas alors qu'elle était prévue au design de l'architecture.
    Ça dépend pour quelles raisons AMD n'a pas pu l'activer à temps, mais si ils y arrivent dans un nouveau stepping, ce serait un joli coup. Le hardware de l'HT était présent dés le P4 Willamette de 2000. Pourtant, il n'a été activé que bien plus tard, quand Intel a réussi a le faire fonctionner (à peu prés) correctement. Il est fort possible qu'AMD y parvienne aussi dans un "Enhanced Bulldozer"... Je n'ai rien dit :D

  14. #74
    Move elimination pour Bulldozer : http://forums.anandtech.com/showpost...0&postcount=98
    Mon blog (absolument pas à jour) : Teχlog

  15. #75
    Ce sont juste pour les mov registre-registre. Ce n'est pas aprticulierement rare ce qui fait le mov elimination une bonne feature. Les benefices sont multiples:
    -latence 0 pour les instructions consommant le nouveau registre
    -moins d'energtie depensee a dupliquer une donnee, le mov elimination utilise generalement un nouvel alias pour la donnee qui reste physiquement dans le meme registre
    -debit d'instruction augmente dans le backend, vu qu'il n'y a plus besoin d'executer le mov il ne prend plus de ports d'execution ni de ports sur le banc de registre.
    Cote inconvenients:
    -c'est complique a gerer dans la table d'alias
    -ca ne reduit pas la bande passante du frontend qui est le point qui tres souvent limite le debit max d'une architecture.

    Bref c'est une tres bonne idee... mineure. L'impact de perf typique sur un code raisonablement bien ecrit sera de l'ordre de quelques %. On peut bien sur trouver du code ou ca aide plus, mais en general il aurait ete possible de reecrire ce code pour qu'il soit plus rapide meme sans mov-elimination.
    fefe - Dillon Y'Bon

  16. #76
    Merci pour les précisions ! Pendant que j'y suis, une mini-review, apparemment publiée trop tôt par erreur : http://translate.google.nl/translate...x-8150&act=url
    Mon blog (absolument pas à jour) : Teχlog

  17. #77
    Citation Envoyé par fefe Voir le message
    Bref c'est une tres bonne idee... mineure. L'impact de perf typique sur un code raisonablement bien ecrit sera de l'ordre de quelques %.
    Quelques pourcents c'est pas mal quand même au niveau de perf où se trouvent les x86. D'ailleurs Ivy Bridge a un truc similaire il me semble, non ?

    On peut bien sur trouver du code ou ca aide plus, mais en general il aurait ete possible de reecrire ce code pour qu'il soit plus rapide meme sans mov-elimination.
    Arrête, on dirait les gens de chez moi qui arrêtent pas de dire que les programmeurs et les compilateurs n'ont qu'à pas faire de la merde si les gens veulent de bonnes performances

  18. #78
    Sois dit en passant, quand on a du move-elimination, ca n'apporte rien d'avoir 4 operandes au lieu de 3 sur le FMA , a part de rendre le decodeur plus complexe...
    fefe - Dillon Y'Bon

  19. #79
    Catastrophe !

    Pour les feignants : par rapport à Thuban (Phenom X6) : plus du double de transistors, consommation plus élevée, nouveau process tout neuf pour… 6,9 % de mieux dans les applications bien multithreadées et… 2 % de moins dans les jeux ! C'est à se demander pourquoi ils l'ont sorti au lieu de continuer à vendre du Ph.X6, probablement moins cher à produire.

    Il reste à voir ce que ça donne sur serveur, mais là c'est franchement nul.
    Mon blog (absolument pas à jour) : Teχlog

  20. #80
    Pour le moment il est juste annoncé...

    Un petit Phenom II en 32 nm aurait été sympa au final !

  21. #81
    Heureusement, il y a encore Charlie pour chanter les louanges de Bulldozer avec force mauvaise foi, jeux de mots calamiteux (quoi que "Glewing together", j'aurais pu la faire) et de "c'est génial mais j'ai pas le droit de vous le dire".

    C'est dans l'adversité qu'on reconnait ses amis.

    Citation Envoyé par fefe Voir le message
    Sois dit en passant, quand on a du move-elimination, ca n'apporte rien d'avoir 4 operandes au lieu de 3 sur le FMA , a part de rendre le decodeur plus complexe...
    Du coup, on imagine d'autant mieux la tronche qu'ont tiré les ingés d'AMD quand Intel est repassé de FMA4 à FMA3...

  22. #82
    D'ailleurs, je me demande si la petite danse du FMA qu'Intel nous a faite n'avait pas pour unique but de mettre AMD dans la merde.
    Mon blog (absolument pas à jour) : Teχlog

  23. #83
    Faut pas rever , c'est vraiment 2 fois plus la merde a decoder un FMA4 qu'un FMA3 en x86, et cf mon commentaire sur le move elimination. N'importe quel flemmard choisirait FMA3 au lieu de FMA4 a implementer . Je doute qu'il y ait des avantages visibles dans beaucoup de codes, donc au final on se demande plutot pourquoi ils n'ont pas fait FMA3...
    fefe - Dillon Y'Bon

  24. #84
    Et vu qu'AMD va supporter le FMA3 dès Piledriver, autant dire que leur FMA4 est mort-né.

    edit: après vérif, le FMA4 sera toujours supporté par Piledriver, mais c'est pas ça qui va changer grand chose à son adoption

  25. #85
    VIA a aussi son propre FMA4 (et FMA3) depuis le Nano. C'est eux qui ont du le plus se marrer dans l'histoire (mais jaune, parce que niveau échec Nano n'a pas grand-chose à envier à Bulldozer...)

  26. #86
    Citation Envoyé par fefe Voir le message
    Faut pas rever , c'est vraiment 2 fois plus la merde a decoder un FMA4 qu'un FMA3 en x86, et cf mon commentaire sur le move elimination. N'importe quel flemmard choisirait FMA3 au lieu de FMA4 a implementer . Je doute qu'il y ait des avantages visibles dans beaucoup de codes, donc au final on se demande plutot pourquoi ils n'ont pas fait FMA3...
    Probablement parce qu'Intel avait d'abord déclaré vouloir faire un FMA4. Ou alors j'ai pas tout compris ?
    Mon blog (absolument pas à jour) : Teχlog

  27. #87

  28. #88
    Ils booste les decoder ? Quelle suprise...

    C'est clair que vu la régression par rapport aux K10, c'était un monstrueux goulet d’étranglement. Pas sur que ça suffise. Je me demande s'ils ne vont pas finir par coller un deuxieme prefetcher, un 2e L1-I et d'autres BTB ;D

  29. #89
    Citation Envoyé par Doc TB Voir le message
    Ils booste les decoder ? Quelle suprise...

    C'est clair que vu la régression par rapport aux K10, c'était un monstrueux goulet d’étranglement. Pas sur que ça suffise.
    Ça dépend un peu de ce qu'on entend par « suffire ». S'il s'agit de rattraper Ivy Bridge (sans parler de Haswell) en termes de performances/W/mm², je pense que c'est mort, mais s'il s'agit d'apporter une plus grosse amélioration à Piledriver qu'Haswell n'apportera à Ivy Bridge, je pense que ça devrait aller, et même assez largement (à moins qu'Intel ait un super lapin dans son chapeau). Je pense que l'important pour AMD n'est pas tant de faire aussi bien qu'Intel, mais de réduire l'écart, parce que ça revient à améliorer leur position compétitive.

    Citation Envoyé par Doc TB Voir le message
    Je me demande s'ils ne vont pas finir par coller un deuxieme prefetcher, un 2e L1-I et d'autres BTB ;D
    Eheh j'avoue que ça m'a aussi traversé l'esprit… :D
    Mon blog (absolument pas à jour) : Teχlog

  30. #90
    En terme de performance/W, Haswell risque de faire trés fort. Pas en faisant exploser les perfs, mais en diminuant significativement la consommation via un "bond" technique relativement important. Dans le cas de Bulldozer & cie, même s'ils arrivent à feeder leur machines correctement, il reste le probleme de concept : si les dev font de la merde en chiant leur threading, ca ne donne pas grand chose. Pour l'avenir, je sent arriver gros comme une baraque une unité de load/store dans le bloc FP et la fusion des scheduler en un seul. Ce sera la fin du CMT, mais après tout, je ne sais pas si l'idée (ou du moins l'implémentation) fut particulièrement heureuse.

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
  •