Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
Page 1 sur 5 12345 DernièreDernière
Affichage des résultats 1 à 30 sur 131
  1. #1

  2. #2
    Impressionnant, un module de Bulldozer est capable d'utiliser 4 décodeurs en même temps pour passer la serpillière sur les Dispatch Group Buffers, ça va les nettoyer super vite !



    Hum… bon, je vais lire la suite.

  3. #3
    La blague sur les mops est nulle, tu sors .
    fefe - Dillon Y'Bon

  4. #4
    Un petit die shot :


    (ça n'apporte que peu d'info mais ça embellit un peu le topic )

    edit: c'est extrait de ce PDF
    Dernière modification par Foudge ; 02/09/2010 à 02h44.

  5. #5
    Euh, si, ça apporte de l'info... Là l'archi et la répartition sont flagrantes.

    Et parce qu'il faut bien aider les amis :
    La provence

  6. #6
    Je ne comprend même pas pourquoi les 4 modules ne sont pas identiques

    edit: + les zones floues, les défauts d'alignements, ça pue le Photoshop pour ne pas tout dévoiler, en espérant que ce n'est pas un vulgaire patchwork
    Dernière modification par Foudge ; 02/09/2010 à 02h42.

  7. #7
    Oui ça a été photoshoppé et flouté à la barbare… D'après John Fruehe, pas de "vrai" die shot avant le lancement.

  8. #8
    Je m'étais demandé hier soir si c'était mes yeux, l'alcool, la fatigue, ou la photo qu'était floue...

    Elle est nulle cette photo. Et les modules haut et bas sont vraiment très différents

    Et parce qu'il faut bien aider les amis :
    La provence

  9. #9
    Sinon, j'ai maté un peu Bobcat la (l'Atom Like). Je ne vois vraiment rien de formidable, ni même de nouveau la dedans. Ou alors il y a un truc qui m'échappe. Je veux bien que le marketing présente l'OOO comme une killer feature, mais faut pas déconner.

  10. #10
    De toute façon, comparé à l'Atom tout est killer.

  11. #11
    Citation Envoyé par newbie06 Voir le message
    De toute façon, comparé à l'Atom tout est killer.
    Attends d'avoir vu le super-K6 d'AMD

  12. #12
    Tu viens de ruiner les espoirs de beaucoup de monde.

  13. #13
    Bobcat vise le meilleur rapport perf/mm²/W possible, et en x86 je pense que ça doit être ce qui se fait de mieux de ce point de vue. Ça n'a rien de transcendant mais bon, le core ne fait que 4,6 mm², donc si ça atteint effectivement 80 % des performances d'un Athlon II, c'est pas mal du tout.

    J'en profite pour poser une question sur un truc qui me travaille un peu.

    Les unitées FMAC de Bulldozer sont censées être capables de faire un MUL, ou un ADD, ou un FMAC, mais j'ai l'impression à la lecture des différents articles sur Bulldozer, qu'elles sont incapables de faire un MUL + un ADD simultanément.

    Dans ma tête, une unité FMAC, ça doit ressembler à ça (c'est du paint, soyez cléments) :



    Si je ne m'abuse, avec la partie en noir, on peut faire soit un MUL, soit un ADD, soit un FMAC ; et il suffirait d'ajouter la partie en rouge pour pouvoir faire un MUL + un ADD en même temps.

    Serait-ce vraiment si coûteux ? Ou le problème est-il lié à la gestion de deux instructions en même temps ? Aux opérandes ? C'est peut-être une question un peu naïve mais bon…

  14. #14
    Je tente une réponse plus vague générale.

    Dans un FMA classique (disons de l'IBM RS/6000 à l'Itanium), tu n'as pas d'opérande D qui arrive : pour faire une addition tu transmets A à travers le multiplieur.
    Pour faire une multiplication tu transmets A*B à travers l'additionneur.
    Tu peux même avoir un jeu d'instructions qui n'a qu'une instruction FMA, et on multiplie par 1 ou on soustrait 0 pour faire des ADD et des MUL.
    Toutes les opérations passent par tout le pipeline et ont la même latence (avec un bypass éventuel qui réduit juste la conso).

    L'intérêt par rapport à un ADD et un MUL séparés ou cascadés, c'est que la latence est à peine plus grande que celle du MUL seul, et largement plus faible que celle d'un MUL suivi d'un ADD. En surface c'est kif-kif. En conso je sais pas.

    Ce qui coûte cher dans l'addition flottante c'est le shifter qui va aligner les mantisses. Pour la multiplication c'est le multiplieur proprement dit.
    Dans un FMA tu peux approximer très tôt l'exposant de A*B (c'est l'exposant de A + celui de B à 1 près), et commencer le shift en même temps que tu fais la multiplication. Donc tu recouvres le gros de la latence.

    Pour ce qui est de Bulldozer (d'après les rumeurs...), le FMA est un peu bâtard parce qu'il est construit avec un "bridge" entre un MUL et un ADD classique. Il prend donc bien un opérande D tel que tu le décris. Et de ce que je comprends, oui, il permet de faire un ADD et un MUL simultanément.
    C'est l'intérêt d'ailleurs : ils perdent en latence et en surface à la fois par rapport à un "vrai" FMA et par rapport à un ADD+MUL.
    Mais ils gardent le même débit qu'une FPU traditionnelle sur le code existant, tout en gérant l'instruction FMA.

    AMD ne s'attend pas à ce que les codes flottants se mettent à utiliser plein de FMA du jour au lendemain... Donc ils en font le minimum pour le supporter dans le jeu d'instruction. Un jour, ils décideront peut-être de remplacer le Bridged FMA par 2 FMA conventionnels, par exemple...

    Edit: bien sûr, tout ça est conditionné par le fait que le FMA de Bulldozer soit bien basé sur l'unité bridged-FMA de Quinnell... Rien n'exclut qu'ils aient décidé d'employer un FMA classique à la place.
    Dernière modification par Møgluglu ; 05/09/2010 à 00h06.

  15. #15
    Merci !

    J'avais pensé à zapper l'opérande D et à se contenter de faire (A × 1) + C, mais ça me paraissait pas terrible niveau power.

    Je posais la question parce que je lis ici et là qu'un module de Bulldozer aura un throughput inférieur à un core de Sandy Bridge, sauf si le FMA est utilisé sur BD. Il me semble que D. Kanter le dit dans son récent article, mais j'arrive plus à retrouver la citation exacte.

    Or, SB peut faire 1 MUL 256 bits + 1 ADD 256 bits par cycle, donc si un module de Bulldozer peut faire 2 × (1 MUL 128 + 1 ADD 128) ça revient au même, avec plus de macro-ops/µops, certes.

  16. #16
    Citation Envoyé par Alexko Voir le message
    Bobcat vise le meilleur rapport perf/mm²/W possible, et en x86 je pense que ça doit être ce qui se fait de mieux de ce point de vue. Ça n'a rien de transcendant mais bon, le core ne fait que 4,6 mm², donc si ça atteint effectivement 80 % des performances d'un Athlon II, c'est pas mal du tout.
    http://www.chip-architect.com/news/A...eview_Atom.jpg

  17. #17
    Citation Envoyé par Alexko Voir le message
    J'avais pensé à zapper l'opérande D et à se contenter de faire (A × 1) + C, mais ça me paraissait pas terrible niveau power.
    C'est toujours moins tant pire que de rajouter un opérande et un port de lecture dans le banc de registres...

    Sur un proco x86 la majorité de ton budget power va dans le fetch/décodage/ordonnancement/spéculation/etc. par instruction.
    Globalement, tu as intérêt à faire plus de travail par instruction (SIMD, fusion d'ops x86, FMA), même si tu tu retrouves à faire des calculs inutiles.
    (Sachant qu'on sait très bien faire du clock-gating sur les datapaths inutilisés.)

    Je posais la question parce que je lis ici et là qu'un module de Bulldozer aura un throughput inférieur à un core de Sandy Bridge, sauf si le FMA est utilisé sur BD. Il me semble que D. Kanter le dit dans son récent article, mais j'arrive plus à retrouver la citation exacte.
    Page 7, quand il dit que Bulldozer avec FMA > Bulldozer sans FMA?
    Citation Envoyé par DK
    The two FMAC units execute FADD and FMUL instructions, although this obviously leaves performance on the table compared to using the combined FMAC.
    Thank you Captain Obvious.

    Mais la comparaison avec SNB n'est pas très honnête. Si quelqu'un doit revectoriser son appli pour AVX, il peut aussi bien en faire une version avec FMA pour Bulldozer.

    Et dire "ouais mais un MUL+ADD est plus souple qu'un FMA, vu qu'on n'a pas toujours des chaînes multiplication-addition dépendantes", c'est oublier qu'un programme n'est pas juste un gros graphe de ADD et MUL flottants...
    Un FMA (surtout à 4 opérandes avec double négation gratuite comme chez AMD) est aussi bien plus puissant qu'un MUL suivi d'un ADD, et sa latence est plus faible.
    Tu peux certainement trouver plein d'applis qui brilleront avec un FMA (genre GMP).

    Donc si un cluster Bulldozer utilise des FMA conventionnels, sa perf crête sera la même qu'un core Sandy Bridge (qu'on se limite à SSE ou qu'on utilise les nouveaux jeux d'instructions). Après, tout dépend des applis.

    Intéressant... Au passage on voit même si on dit "intégrer un GPU dans le CPU", en surface c'est plutôt le contraire qui se passe...
    Edit: Anand donne Tegra 2 pour 49mm² dont 10% occupée par les A9 [sans L2?]. Autrement dit, un Bobcat = 2 Cortex A9.
    Dernière modification par Møgluglu ; 05/09/2010 à 12h03.

  18. #18
    Euh, pour les perfs d'une version dédiée SNB vs version dédiée BD, je dirais 3DNow! et je relance direct d'un AVX. Question de parts de marché. Et d'ICC. Et de manuels bleus, ...

    Et parce qu'il faut bien aider les amis :
    La provence

  19. #19
    Quel mauvais esprit. Non, cette fois-ci il y aura un disclaimer au milieu du contrat de licence d'icc qui dira que les perfs ne sont pas forcément optimales sur les proco concurrents, donc ça change tout.

    Mais bon, avant de penser à AVX/XOP faudrait déjà être arrêter le x87 et passer à SSE...

  20. #20
    Citation Envoyé par Møgluglu Voir le message
    Quel mauvais esprit. Non, cette fois-ci il y aura un disclaimer au milieu du contrat de licence d'icc qui dira que les perfs ne sont pas forcément optimales sur les proco concurrents, donc ça change tout.

    Mais bon, avant de penser à AVX/XOP faudrait déjà être arrêter le x87 et passer à SSE...
    C'est AMD qui a refoutu le x87 dans x64. On aurait pu imaginer une version d'x64 sans ça qui, à la compilation, bazarde tout en SSE de façon obligatoire.

    Et parce qu'il faut bien aider les amis :
    La provence

  21. #21
    Citation Envoyé par Neo_13 Voir le message
    On aurait pu imaginer une version d'x64 sans ça qui, à la compilation, bazarde tout en SSE de façon obligatoire.
    Ça s'appelle IA-64, ça.

    Comme c'est arrivé en premier, et grâce aux parts de marchés, à ICC et aux manuels bleus, euh... en fait non, ça a pas suffit contre x86 et x87.

  22. #22
    Oui j'ai vu ça, question perfs/mm² c'est clairement très prometteur. En ce qui concerne les perfs/W, par rapport à Atom, faut voir.

    Citation Envoyé par Møgluglu Voir le message
    C'est toujours moins tant pire que de rajouter un opérande et un port de lecture dans le banc de registres...

    Sur un proco x86 la majorité de ton budget power va dans le fetch/décodage/ordonnancement/spéculation/etc. par instruction.
    Globalement, tu as intérêt à faire plus de travail par instruction (SIMD, fusion d'ops x86, FMA), même si tu tu retrouves à faire des calculs inutiles.
    (Sachant qu'on sait très bien faire du clock-gating sur les datapaths inutilisés.)
    Intuitivement j'aurais pensé le contraire, mais vu comme ça, c'est logique.



    Citation Envoyé par Møgluglu Voir le message
    Page 7, quand il dit que Bulldozer avec FMA > Bulldozer sans FMA?

    Thank you Captain Obvious.
    Ça va dans ce sens, mais il me semble avoir lu une affirmation plus précise… ça devait pas être Kanter. Faut pas m'en vouloir, je suis un peu sénile.

    Citation Envoyé par Møgluglu Voir le message
    Mais la comparaison avec SNB n'est pas très honnête. Si quelqu'un doit revectoriser son appli pour AVX, il peut aussi bien en faire une version avec FMA pour Bulldozer.
    J'y crois pas des masses, mais on verra !

    Citation Envoyé par Møgluglu Voir le message
    Et dire "ouais mais un MUL+ADD est plus souple qu'un FMA, vu qu'on n'a pas toujours des chaînes multiplication-addition dépendantes", c'est oublier qu'un programme n'est pas juste un gros graphe de ADD et MUL flottants...
    Un FMA (surtout à 4 opérandes avec double négation gratuite comme chez AMD) est aussi bien plus puissant qu'un MUL suivi d'un ADD, et sa latence est plus faible.
    Tu peux certainement trouver plein d'applis qui brilleront avec un FMA (genre GMP).
    Double négation gratuite ? D'après Google, t'es le seul mec au monde à avoir employé cette expression… :D Enfin maintenant on est deux, mais moi je sais pas ce que ça veut dire.

    Citation Envoyé par Møgluglu Voir le message
    Intéressant... Au passage on voit même si on dit "intégrer un GPU dans le CPU", en surface c'est plutôt le contraire qui se passe...
    Edit: Anand donne Tegra 2 pour 49mm² dont 10% occupée par les A9 [sans L2?]. Autrement dit, un Bobcat = 2 Cortex A9.
    C'est à peu près pareil pour Llano, le die fait 225 mm², et chaque core fait un peu moins de 10 mm², et quelque chose comme 16~17 mm² avec le cache.

    Citation Envoyé par Neo_13 Voir le message
    C'est AMD qui a refoutu le x87 dans x64. On aurait pu imaginer une version d'x64 sans ça qui, à la compilation, bazarde tout en SSE de façon obligatoire.
    Les 3 ou 4 mecs qui utilisent les 80 bits de précision du x87 auraient râlé…

  23. #23
    Citation Envoyé par Alexko Voir le message
    Les 3 ou 4 mecs qui utilisent les 80 bits de précision du x87 auraient râlé…
    C'est d'ailleurs une des raisons pour laquelle Ms n'a pas retiré le x87 des Windows64 comme ils l'avaient envisagés au départ.

    @+, Arka



  24. #24
    Citation Envoyé par Møgluglu Voir le message
    Ça s'appelle IA-64, ça.

    Comme c'est arrivé en premier, et grâce aux parts de marchés, à ICC et aux manuels bleus, euh... en fait non, ça a pas suffit contre x86 et x87.
    Non, IA64 n'est pas x64.

    Et se passer, en mode 64bits de x87 pour faire du sse scalaire (sans préjudice à faire du x87 en mode 32bits), ça permettait de conserver la compatibilité binaire tout en se débarrassant du x87.

    Par contre, il y a les 7 mecs dans le monde qui utilise le 80bits qui auraient posé problème.

    Et parce qu'il faut bien aider les amis :
    La provence

  25. #25
    Citation Envoyé par Alexko Voir le message
    Double négation gratuite ? D'après Google, t'es le seul mec au monde à avoir employé cette expression… :D

    N'empêche, à une époque j'étais aussi le seul mec au monde à dire "Unfused Multiply-Add", maintenant il y a plein de gens qui l'emploient.

    Je voulais parler du fait que tu as des instructions pour faire tous les calculs de la forme ±a*b±c (VFMADDxx, VFMSUBxx, VFNMADDxx, VFNMSUBxx). Les 2 négations possibles dans l'expression sont gratuites.

    Citation Envoyé par Neo_13 Voir le message
    Et se passer, en mode 64bits de x87 pour faire du sse scalaire (sans préjudice à faire du x87 en mode 32bits), ça permettait de conserver la compatibilité binaire tout en se débarrassant du x87.
    En fait, je vois pas où est le problème. Il y a effectivement 17 personnes sur terre qui utilisent le x87 en mode 64-bit, mais quel est le tord qu'il font aux autres?
    Tous les compilos x64 que je connais génèrent du SSE par défaut (*). Il faut aller chercher dans des options de compil obscures pour faire autrement.

    Les programmes "legacy" qui utilisent le x87 sont juste des programmes compilés en 32-bit pour Windows. Parce que tu vas pas embrouiller les utilisateurs à choisir entre 2 versions alors que la version 32-bit tournera parfaitement sur les deux plates-formes IA-32 et x64.
    Interdire le x87 en x64 ne changerait rien à l'affaire.

    (*) À l'exception de certains bouts de MSVC semble-t-il, mais faut comprendre Microsoft en même temps : SSE est tellement une technologie de pointe qu'ils n'ont pas encore eu le temps de recompiler leur libm. Et c'est pas à cause du mode 80-bit, qui pour autant que je sache n'a jamais existé sous Windows.
    Dernière modification par Møgluglu ; 05/09/2010 à 17h32.

  26. #26
    Citation Envoyé par Møgluglu Voir le message

    N'empêche, à une époque j'étais aussi le seul mec au monde à dire "Unfused Multiply-Add", maintenant il y a plein de gens qui l'emploient.

    Je voulais parler du fait que tu as des instructions pour faire tous les calculs de la forme ±a*b±c (VFMADDxx, VFMSUBxx, VFNMADDxx, VFNMSUBxx). Les 2 négations possibles dans l'expression sont gratuites.
    OK ! Effectivement c'est pas mal…



    Citation Envoyé par Møgluglu Voir le message
    En fait, je vois pas où est le problème. Il y a effectivement 17 personnes sur terre qui utilisent le x87 en mode 64-bit, mais quel est le tord qu'il font aux autres?
    Tous les compilos x64 que je connais génèrent du SSE par défaut (*). Il faut aller chercher dans des options de compil obscures pour faire autrement.

    Les programmes "legacy" qui utilisent le x87 sont juste des programmes compilés en 32-bit pour Windows.
    *cough* NVIDIA *cough* PhysX *cough*

  27. #27
    Citation Envoyé par Møgluglu Voir le message
    Edit: Anand donne Tegra 2 pour 49mm² dont 10% occupée par les A9 [sans L2?]. Autrement dit, un Bobcat = 2 Cortex A9.
    http://dl.dropbox.com/u/232602/NV-40-T20-Blocks.png

    Attention ce sont des A9 sans les instructions SIMD (NEON). Avec SIMD, c'est bien plus gros.

  28. #28

    Pour une fois la version officielle est plus détaillée... :


    Attention ce sont des A9 sans les instructions SIMD (NEON). Avec SIMD, c'est bien plus gros.
    Donc peu à peu, ARM hi-end et x86 low-end, ça converge...

  29. #29
    Citation Envoyé par Møgluglu Voir le message
    Donc peu à peu, ARM hi-end et x86 low-end, ça converge...
    Bobcat n'est pas 100% synthétisable non plus

  30. #30
    Citation Envoyé par newbie06 Voir le message
    Bobcat n'est pas 100% synthétisable non plus
    C'est pourtant ce que semble prétendre AMD. Qu'est-ce qui n'est pas synthétisable?

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
  •