Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 4 sur 5 PremièrePremière 12345 DernièreDernière
Affichage des résultats 91 à 120 sur 131
  1. #91
    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.
    Il me semblait pourtant que Bulldozer avait plus de capacité de décodage qu'Istanbul (tant qu'on reste en single thread) ?
    http://www.realworldtech.com/bulldozer/5/

  2. #92
    Citation Envoyé par newbie06 Voir le message
    Il me semblait pourtant que Bulldozer avait plus de capacité de décodage qu'Istanbul (tant qu'on reste en single thread) ?
    http://www.realworldtech.com/bulldozer/5/
    tant qu'on reste en single thread oui. Il y a 4 decodeurs qui peuvent pondre 1-2 Macro-ops par cycle contre 3 sur Istanbul, MAIS ces decodeurs bossent pour deux clusters. Donc en fait il y a 4 décodeurs là ou il y en avait 2x3=6 sur Istanbul.

  3. #93
    Citation Envoyé par Doc TB Voir le message
    tant qu'on reste en single thread oui. Il y a 4 decodeurs qui peuvent pondre 1-2 Macro-ops par cycle contre 3 sur Istanbul, MAIS ces decodeurs bossent pour deux clusters. Donc en fait il y a 4 décodeurs là ou il y en avait 2x3=6 sur Istanbul.
    OK, mais j'avais l'impression que le principal problème de BD était sa perf en single thread, qui donc ne serait pas due aux décodeurs eux-mêmes.

  4. #94
    Citation Envoyé par newbie06 Voir le message
    OK, mais j'avais l'impression que le principal problème de BD était sa perf en single thread, qui donc ne serait pas due aux décodeurs eux-mêmes.
    On ne peut pas dire que ce soit tellement la joie en multi-thread non plus. En pratique, un FX-8150 fait souvent un peu moins bien qu'un Core i7-2600K, malgré pas mal de transistors et 30 W de plus.

    Si j'ai bien compris, les décodeurs sont actuellement partagés par entrelacement vertical, i.e. dédiés au thread 0 au cycle n, au thread 1 au cycle n+1, etc. Ça doit poser problème pour certains workloads.
    Mon blog (absolument pas à jour) : Teχlog

  5. #95
    Petite précision : les décodeurs sont complètement doublés, ça passe à 2×4-wide, et non 2×3-wide comme on aurait pu le supposer.
    Mon blog (absolument pas à jour) : Teχlog

  6. #96
    Sur Steamroller ? Si c'est ça, c'est qu'ils mijotent une archi à 4 clusters par core...

  7. #97
    Citation Envoyé par Doc TB Voir le message
    Sur Steamroller ? Si c'est ça, c'est qu'ils mijotent une archi à 4 clusters par core...
    Oui sur Steamroller. Je ne sais pas ce qu'ils mijotent, s'ils passaient à 4 cores par module ça serait un retour à l'état actuel, un décodeur 4-wide par paire de cores, donc il s'agit peut-être simplement d'élargir un peu chaque core.
    Mon blog (absolument pas à jour) : Teχlog

  8. #98
    Citation Envoyé par Alexko Voir le message
    Petite précision : les décodeurs sont complètement doublés, ça passe à 2×4-wide, et non 2×3-wide comme on aurait pu le supposer.
    Qu'est-ce qui te fait dire ça ?

  9. #99

  10. #100
    Merde, quand en marchant dans la rue, ayant tout à coup l'impression d'être suivi, je me retourne et crois voir une ombre disparaître subitement, en fait je ne rêve pas ?
    Mon blog (absolument pas à jour) : Teχlog

  11. #101
    Citation Envoyé par Alexko Voir le message
    Merde, quand en marchant dans la rue, ayant tout à coup l'impression d'être suivi, je me retourne et crois voir une ombre disparaître subitement, en fait je ne rêve pas ?
    Tu veux dire que tu n'as pas encore compris qui j'étais sur S|A ?

  12. #102
    Citation Envoyé par newbie06 Voir le message
    Tu veux dire que tu n'as pas encore compris qui j'étais sur S|A ?
    Non mais si tu changes de pseudo sur tous les forums, c'est de la triche aussi…
    Mon blog (absolument pas à jour) : Teχlog

  13. #103
    Die shot d'un futur core AMD, probablement Excavator :

    Dernière modification par Alexko ; 01/06/2013 à 13h32.
    Mon blog (absolument pas à jour) : Teχlog

  14. #104

  15. #105
    Apparemment les FPU sont doublées (deux FMA de 256 bits par cycle) ce qui n'est pas prévu pour Steamroller, en plus de changements côté integer qui n'avaient pas été mentionnés non plus. Donc soit le design de Steamroller a considérablement changé depuis son annonce (ce qui ne me paraît pas possible, compte tenu du calendrier) soit c'est Excavator.
    Mon blog (absolument pas à jour) : Teχlog

  16. #106
    Je m'attendais pas à un dieshot d'Excavator si tôt.
    Ces 2 FPU 256bit seront toujours partagées ? Si non, avec le doublement du nombre de décodeurs dans Steamroller, ça va de plus en plus ressembler à un dualcore leur module

  17. #107
    Apparemment, oui. La meilleure référence est probablement ce post de Fellix, qui contient une image de comparaison avec Bulldozer et Piledriver, ainsi que les analyses de Hans de Vries et 3Dilettante : http://crazyworldofchips.blogspot.fr...ot-leaked.html

    Ils soupçonnent tous les deux un passage à 4 threads par module (vraisemblablement 2 threads par core).
    Mon blog (absolument pas à jour) : Teχlog

  18. #108
    Ce die shot ne semble pas tellement vous inspirer. Fefe, pas de réaction ?
    Mon blog (absolument pas à jour) : Teχlog

  19. #109
    C'est franchement pas facile de tirer des infos d'un die-shot. Même sur nos designs j'ai du mal alors pour un design concurrent je vais me taire

  20. #110
    Citation Envoyé par newbie06 Voir le message
    C'est franchement pas facile de tirer des infos d'un die-shot. Même sur nos designs j'ai du mal alors pour un design concurrent je vais me taire
    Hans de Vries semble y arriver assez bien. Pour moi ça tient carrément de la science occulte, mais bon… :D
    Mon blog (absolument pas à jour) : Teχlog

  21. #111
    Citation Envoyé par Alexko Voir le message
    Hans de Vries semble y arriver assez bien. Pour moi ça tient carrément de la science occulte, mais bon… :D
    Il donne cette impression en effet. Mais au final a-t-on la preuve qu'il ne se trompe pas ?

    Pour ce que j'en sais on peut parvenir a identifier certaines structures comme des RAM, on peut aussi identifier des regularites. Si on ajoute les infos donnees par les constructeurs sur les tailles de ces structures, des die-shots proprements identifies d'une generation precedente, on peut faire avancer l'identification des unites.

    De la a identifier les ressources de rename et dire qu'elles ont double, ou dire que les changements a la branch pred sont massifs, je me pose des questions.

    Desole, mais le doute cartesien l'emporte toujours chez moi

  22. #112
    Fefe il est deborde de boulot et reverse engineer un die shot correctement ca prend du temps .
    fefe - Dillon Y'Bon

  23. #113

  24. #114
    Bon, ben Kaveri est sorti. Bilan très résumé : + 7,5 % d'IPC en moyenne (HFR), avec quelques pointes autour de 30 % mais aussi des chutes, probablement à cause d'une latence mémoire qui augmente d'environ 30 % (!) pour des raisons qui ne sont pas franchement claires. Les fréquences chutent un peu entre 65 W et 95 W, la faute au process plutôt tuné pour la densité.
    Quelques données intéressantes ici : http://www.hardware.fr/articles/913-...ale-turbo.html
    Et là : http://techreport.com/review/25908/a...essor-reviewed

    Côté graphique c'est mieux, mais très limité par la bande passante. De gros progrès sous OpenCL, et mieux encore pour les applications HSA, lesquelles sont actuellement au nombre de… deux. :D Au final Kaveri n'améliore pas beaucoup la situation à 95~100 W (parfois pas du tout, ou même la détériore) mais c'est mieux à 65 W et encore mieux à 45 W. On est en droit d'espérer encore un peu plus sur les portables (15 à 35 W).

    Et un die shot tout pourri où on ne voit rien, pour la route :

    Mon blog (absolument pas à jour) : Teχlog

  25. #115
    Citation Envoyé par Alexko Voir le message
    De gros progrès sous OpenCL, et mieux encore pour les applications HSA, lesquelles sont actuellement au nombre de… deux. :D
    C'est pas juste des applications OpenCL 2.0 ? En tout cas, sur le repo source de LibreOffice y'a que de l'OpenCL pour accélérer Calc.

  26. #116
    Citation Envoyé par Alexko Voir le message
    Bon, ben Kaveri est sorti. Bilan très résumé : + 7,5 % d'IPC en moyenne (HFR) [...]
    Et tout ça grâce à 85% de transistors en plus !

  27. #117
    Citation Envoyé par newbie06 Voir le message
    C'est pas juste des applications OpenCL 2.0 ? En tout cas, sur le repo source de LibreOffice y'a que de l'OpenCL pour accélérer Calc.
    OpenCL 2.0 supporte l'espace mémoire virtuel unifié, donc je pense qu'il suffit d'utiliser OpenCL 2.0 pour tirer parti de HSA ; mais j'ai peut-être compris de travers.

    Citation Envoyé par Foudge Voir le message
    Et tout ça grâce à 85% de transistors en plus !
    L'essentiel est probablement parti dans le GPU.
    Mon blog (absolument pas à jour) : Teχlog

  28. #118
    Citation Envoyé par Alexko Voir le message
    OpenCL 2.0 supporte l'espace mémoire virtuel unifié, donc je pense qu'il suffit d'utiliser OpenCL 2.0 pour tirer parti de HSA ; mais j'ai peut-être compris de travers.
    Oui. Au détail près que le support d'OpenCL 2.0 est prévu pour Q1 2015 chez AMD. (Ça reste infiniment plus tôt que celui d'OpenCL 1.2 chez Nvidia. )

  29. #119
    Citation Envoyé par Møgluglu Voir le message
    Oui. Au détail près que le support d'OpenCL 2.0 est prévu pour Q1 2015 chez AMD. (Ça reste infiniment plus tôt que celui d'OpenCL 1.2 chez Nvidia. )
    Ah, bah du coup je sais pas comment LibreCalc fonctionne, alors. Mais ça a l'air d'être efficace. On doit être dans ce qu'on appelle la pratique.

    Sinon, vous avez une idée des causes de ça ?


    http://www.hardware.fr/articles/913-...ddr3-2400.html
    Citation Envoyé par HFR
    La première chose qui saute aux yeux est la latence mémoire qui est en forte hausse avec 18 à 20ns de plus sur Kaveri. Un chiffre très important que nous avons pu confirmer sur différent exemplaires et avec différentes cartes mères. En l'état il est difficile de connaitre la raison exacte de cette latence mémoire, même si il n'est pas exclu que des modifications nécessaires pour HSA soient en cause. D'après les développeurs de AIDA64, Kaveri perdrait entre autre beaucoup de temps sur les TLB miss, 35 à 40 cycles de plus que Richland. En pratique cette latence devrait avoir un impact non négligeable sur les performances CPU.
    Alors que pour Haswell :

    http://www.hardware.fr/articles/909-...e-memoire.html

    C'était déjà pas brillant pour Richland, mais l'écart avec Haswell est devenu énorme.
    Mon blog (absolument pas à jour) : Teχlog

  30. #120
    Premières slides sur Zen (à ma connaissance)

    Vu de haut ça fait un peu plus rêver que les dérivés de Bulldozer qu'on avait jusqu'ici. Au programme, SMT et uop-cache (6 uops/cycle, ce qui fait autant que chez Intel si mes souvenirs sont bons). Idem, 4 instructions par cycle au Decode, un peu réminiscent du bon vieux 4-1-1-1. Pendant la démo leur engineering sample était à 3GHz mais apparemment ils visent plus haut pour les versions finales. Rien n'est dit sur le Turbo.

    Sinon les parties INT et FP sont toujours séparées même si le(s) scheduler(s) serai(en)t 1.75x plus gros que sur Excavator. Un autre point intéressant, il n'y a que 2AGU (mais 4ALU) alors que le D-Cache supporte deux loads 128-bit et un store 128-bit par cycle. A voir dans le manuel d'optimisation quand il sera sorti.
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

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
  •