Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 1 sur 3 123 DernièreDernière
Affichage des résultats 1 à 30 sur 61
  1. #1
    Bon, c'est peut-être un peu tôt pour lancer ce thread, mais y'a déjà pas mal de spéculation sur Bulldozer, en particulier ici. Ça parle de cluster-based mutli-threading, etc.

    La dernière entrée a attiré mon attention : gestion d'énergie fine. Très séduisant en théorie, mais en pratique ça me paraît être un énorme merdier a gérer.

    En attendant, voici ce que l'on sait de Bulldozer :
    — 6 à 8 cores par die sur un modèle présumé monolithique, 12 à 16 cores sur un modèle présumé MCM ;
    — sortie prévue H2'2011 ;
    — gravure en 32 nm SOI chez GlobalFoundries.

  2. #2
    Il y aurait aussi une version en 40nm de prévue avec GPU DX11+UVD 3.0, pour Netbooks :



    Un CPU AMD pas fondu par GlobalFoundries? (TSMC?)
    C'est pour mieux concurrencer les SoC Atom?

    À moins que ce ne soit juste un MCM comme Arrandale.

  3. #3
    Hum je sais pas, d'après Wikipedia :
    Module 2 is in a transition period, converting from 200-mm to 300-mm wafer production for 55 nm and 40 nm for use in chipsets, GPUs, and future 32-nm bulk silicon.
    Donc c'est peut-être GlobalFoundries. C'est un APU à base de Bobcat donc c'est probablement sur un process LP...

  4. #4
    http://www.anandtech.com/cpuchipsets...oc.aspx?i=3673

    C'est l'AMD analyst day, pas mal d'infos vont filtrer...
    fefe - Dillon Y'Bon

  5. #5

  6. #6
    Question de noob : pas de L1 pour la FMAC, ça veut dire que ya plus de 40cycles de pipeline ?
    Mes propos n'engagent personne, même pas moi.

  7. #7
    Hu hu, c'est un transparent pour expliquer en gros, tu ne peux pas deduire grand-chose

  8. #8
    AMD admet que la gestion de la mémoire sur trois canaux sur le Nahelem c'était une bonne idée : du coup le Bulldozer sera quadra-canal.
    Et DDR3 uniquement.
    (http://www.v3.co.uk/v3/news/2252935/...low-cost-power)

    Est-ce pour cette raison qu'AMD prépare, pour le grand public, un socket AM3 r2 ?

  9. #9
    Citation Envoyé par Narm Voir le message
    AMD admet que la gestion de la mémoire sur trois canaux sur le Nahelem c'était une bonne idée : du coup le Bulldozer sera quadra-canal.
    Et DDR3 uniquement.
    (http://www.v3.co.uk/v3/news/2252935/...low-cost-power)

    Est-ce pour cette raison qu'AMD prépare, pour le grand public, un socket AM3 r2 ?
    Le socket G34 pour serveurs permet d'avoir 4 canaux, mais sur desktop je ne suis pas sûr qu'il en soit de même.
    Dernière modification par Alexko ; 12/11/2009 à 13h06.

  10. #10
    Citation Envoyé par newbie06 Voir le message
    Hu hu, c'est un transparent pour expliquer en gros, tu ne peux pas deduire grand-chose
    Surtout que "128-bit FMAC" ça veut rien dire. Surtout après tout ce cirque sur le nombre d'opérandes du FMA...

    C'est 2 unités qui font chacune 2 FMA FP64 ou 4 FMA FP32. Ça fait 5 ou 6 cycles typiquement...

    D'autres dessins et slides :
    http://pc.watch.impress.co.jp/docs/c...12_328392.html

  11. #11
    Pourquoi pas de L1 pour le FMA ?

    ---------- Post ajouté à 14h21 ----------

    Parce qu'il tape dans le L1 des copains... Vla le cauchemar de prédicteur.
    Mes propos n'engagent personne, même pas moi.

  12. #12
    Un L1 dedie pour les FMA serait un cauchemard a cote de mettre ta donnee dans le cache d'ou vient ton pointeur d'instruction. Si tu avais un cache dedie, il faudrait le snoop a chaque acces aux autres L1, donc en gros il faudrait 3x la bande passante d'un L1 actuel...
    Dernière modification par fefe ; 12/11/2009 à 20h17.
    fefe - Dillon Y'Bon

  13. #13
    Bonjour,

    De ce que je comprend de cette architecture, c'est qu'elle semble vraiment nouvelle et ne ressemble plus vraiment à l'architecture K7/K8 et ça c'est plutôt une bonne chose je trouve.

    AMD aurait rassemblé "deux cores classiques" et unifié le tout sous un même cache L1I + les étapes de fetching et décodage. Les FMAC étant partagé entre les deux clusters et unifié au niveau des caches L1D également

    Maintenant j'ai quelques questions,

    Concernant l'intégration et le budget transistors :

    Je ne doutes pas de l'efficacité en performance néanmoins quel gain (en surface comme en transistors) peut obtenir AMD en partageant différentes structures comme les caches L1I entre plusieurs "clusters" et également pour la logique utilisée dans les étages de Fetching et Decode ? J'avais cru comprendre également qu'avoir un cache partagé influait énormément sur les performances (surtout pour un L1) mais aussi sur la conception (complexité et structures de caches notamment).

    Concernant le mutlithreading :

    je me souviens vaguement d'une histoire de "Speculative Multithreading" ou "reverse HT" permettant d'augmenter les performances d'une application monothreadée en "émulant" l'existence d'un processeur logique sur n cores physiques. Ce genre d'architecture favorisant les partages de ressources, ne semblerait elle pas la plus appropriée pour utiliser cette technologie ? D'ailleurs est ce une réalité ou une légende urbaine ?
    "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

  14. #14
    Le L2 + L1 + le fronted representent a peu pres la moitie de la surface du core. Un peu plus en fait mais le fait de les partager entre 2 threads va forcement les faire grossir un peu: demande de bande passante plus elevee, mecanismes pour eviter deadlocks et pollution mutuelle etc...
    Les FMAC sont partages, mais il y en a 2, donc ca sera plus gros que d'en avoir 1 par core (mais plus performant). Si je considere l'impact neutre, on arive a un gain de surface de 25% par thread hardware (hors L3) par comparaison a une duplication bete (le multicore). Soit un cout de 1.5x pour le 2 eme thread.
    Ca reste plus couteux que les 5 a 10% annonces par Intel pour le HT, mais bien entendu ca devrait etre plus performant.

    La grande question est de savoir si les instructions d'1 thread peuvent aller sur les 2 cluster. A mon avis non: sinon ils n'auraient pas explicite que la FPU etait partagee. Ca veut dire que pour les applis entieres la perf n'est pas amelioree par rapport a 1 core, mais pour les applis flottantes chaque thread a maintenant acces a 2FMA.

    La performance flottante a 1 thread devrait etre boostee de maniere significative. La performance entiere juste un peu, en effet les ameliorations qu'ils ont du faire au frontend pour supporter 2 clusters devraient ameliorer un peu la eprf dans le cas d'1 seul thread (a moins qu'ils aient choisi l'option simple d'alterner le fetch entre les 2 threads enquel cas le gain serait nul, voir negatif).

    Quel sera le gain en multithreading en comparaison avec HT ? Difficile a dire. Ils payent toutes les memes penalites de partage de frontend et de cache, et elles sont non negligeables, mais n'ont pas celles de partage des unites de calcul et buffers d'ordonnancement.

    Si je devais m'avancer, je dirais ~1.5x perf pour 1.5x surface d'1 core (le ratio est certainement superieur a 1, je suis quasiment sur qu'ils n'auraient jamais produit quelque chose avec un ratio <1:1) contre 1.2x perf a 1.1x surface pour le HT d'Intel.

    HT est il meilleur ? En moyenne et probablement, mais les clusters ne devraient pas exhiber trop de cas (ou pas du tout) ou on perd de la perf a cause du 2 eme thread (seules les applis frontend ou cache limited risque d'etre dans ce cas).
    En FP les ameliorations beneficient directement aux applis non threadees ou lorsqu'un thread est entier l'autre FP (HT aussi pour le 2 eme cas mais dans une moindre mesure).

    La ou je vois un avantage important a leur methode est d'un point de vu complexite de realisation. La validation de mecanismes speculatifs dans le desordre avec 2 threads en concurrence dynamique est extremement difficile. Dans leur cas rien de tout ca n'est partage, seuls les blocs ou l'execution est ordonnee sont partages (la FPU ne compte pas, je doute qu'ils partagent les bancs de registres, partager une unite de calcul sans etat n'est pas difficile) ce qui devrait simplifier le probleme de maniere significative.

    Dans le monde des serveurs ou HT marche tres bien ils avaient un desavantage important de densite de threads et ils viennent de compenser l'essentiel de ce desavantage.

    Cote power l'analyse est plus difficile. Vu qu'ils dupliquent beaucoup de ressources ils vont payer beaucoup plus cher en courants de fuite, mais auront moins de probleme de densite thermique: leurs unites seront certainement moins utilisees que dans le cas de HT. Quoi que . Le FMA est generalement une des zones les plus chaudes des dies, et je vois un gros potentiel pour la chauffer dans un core comme ca .
    fefe - Dillon Y'Bon

  15. #15
    Citation Envoyé par fefe Voir le message
    Dans le monde des serveurs ou HT marche tres bien ils avaient un desavantage important de densite de threads et ils viennent de compenser l'essentiel de ce desavantage.

    Cote power l'analyse est plus difficile. Vu qu'ils dupliquent beaucoup de ressources ils vont payer beaucoup plus cher en courants de fuite, mais auront moins de probleme de densite thermique: leurs unites seront certainement moins utilisees que dans le cas de HT. Quoi que . Le FMA est generalement une des zones les plus chaudes des dies, et je vois un gros potentiel pour la chauffer dans un core comme ca .
    Merci Fefe pour ces réponses, malgré les couts suplémentaires engendrés par l'HT et en considérant l'architecture Bulldozer est ce que cela serait déraisonable pour AMD d'implémenter une technologie similaire (ou même un Switch On Event Multithreading comme sur Niagara & co) ?

    La consommation et le leakage comme tu viens de le dire seront probablement important néanmoins je me pose des questions quant à leur gestion de l'énergie, que peut on attendre d'elle et a quel niveau de l'architecture (granularité) et d'une manière plus générale quels sont les efforts qu'il reste à faire dans ce domaine ?
    Dernière modification par EPIC ; 14/11/2009 à 18h28.
    "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

  16. #16
    Je pense que si AMD n'a pas fait de HT c'est que le cout de la validation a ete juge trop important ou trop risque pour eux. Intel a mis quasiment 10 ans pour avoir un HT au point (Dans Willamette ca ne marchait pas, dans Northwood a peine, dans Prescott ca marchait mais avec plein de programmes qui ralentissaient, Nehalem a finalement une implementation assez solide). Intel a des ressources enttement plus importantes que AMD, et AMD a probablement choisi le clustering comme alternative a HT, pas en supplement. Ils travaillent peut etre dessus mais j'en doute.

    SOEMT est tres bon juste pour les serveurs. Je doute qu'ils le fassent sauf le jour ou ils developpent un coeur juste pour les serveurs.

    Plus ca va plus la granularite du power management reduit. Tu arretes la clock dans des petits blocs des qu'ils ne sont pas actifs. Pour le leakage tu as des power gate de plus en plus rapides qui je pense devraient etre capable d'eteindre un cluster si necessaire, et bien entendu un coeur.

    Eteindre un cluster semble etre une tres bonne idee vu que le temps de demarrage /arret devrait etre faible: tu n'as besoin que de sauver tes registres, pas de flush tes caches.
    Si c'est le cas, quand tu auras 1 seul thread tu ne payeras pas le leakage pour le 2 eme cluster, tu payeras juste le leakage supplementaire pour le support du clustering (ce qui a grossi dans le frontend et les caches et la FP). Au final cette taxe devrait etre inferieure ou egale a la taxe leakage de HT.

    D'un point de vue efficacite, je dirais qu'ils devraient etre equivalent a un processeur HT si ils font tourner un thread, et un peu moins bons si ils font tourner 2 threads.

    Bien entendu les power gates ont un cout, en surface et en power.
    fefe - Dillon Y'Bon

  17. #17
    Name: redpriest (nospam@nospam.com) 11/16/09

    My information is better than NDA; it's internal

    The FPU is not "weak"; also the diagram is really a broad brush overview of the architecture which skips many important functional details. I can't really get into more specifics.

  18. #18
    Faible est une notion relative . Je suppose qu'il veut dire que leur score FSPEC rate est eleve, linpack, probablement moins interessant comparativement... (mais je n ai pas dit faible !)
    fefe - Dillon Y'Bon

  19. #19
    Quelques news de chez Anand sur Bulldozer:

    We will discuss this core in more detail but here are some extra tidbits we managed to find out:

    • Two integer clusters share fetch and decode logic but have their own dedicated Instruction and Data cache
    • Integer clusters can not be shared between threads: integer cores act like a Chip Multi Processing (CMP) CPU.
    • The extra integer core (schedulers, D-cache and pipelines) adds only 5% die space
    • L1-caches are similar to Barcelona/Shanghai (64 KB 2-way? Not confirmed)
    • Up to 4 modules share a L3-cache and Northbridge
    • Two times 4 Bulldozer modules (2 x 8 "cores" or 16 cores) are about 60 to 80% faster than the twelve core Opteron 6100 CPU in SPECInt_rate.

    With Bulldozer, AMD finally seems to have designed an aggressive integer core. Since the introduction of the Intel Woodcrest in 2006, Intel’s CPUs have been offering superior integer crunching performance per core. Since integer performance determines the performance of 90-95% of the server application out there, this is a big deal.

  20. #20
    Et un peu de spéculation sur l'implémentation des FPU chez Dresdenboy : http://citavia.blog.de/2009/11/23/so...ation-7441398/

  21. #21
    Le papier est intéressant. Il le serait encore plus s'ils se comparaient à un design de FMA moderne et pas celui du RS/6000 d'il y a 20 ans.

    Ils paient un certain coût en latence, surface et conso sur les opérations FMA, mais conservent une latence correcte sur les add et mul.
    Après il faut voir comment ils arrivent à pipeliner ça avec le contrôle associé (y'a des bypass dans tous les sens).
    Et comment ils appliquent ça au cas du x86 : 1xadd ou 1xmul en 80-bit, 2xFMA 64-bit ou 4xFMA 32-bit, sans gâcher de hardware, et en gardant une latence raisonnable dans chaque cas...

  22. #22
    je viens de trouver ça sur le site Real World Technologie

    "According to John Fruehe on the AMDZone forum, adding the second core to the Bulldozer unit takes only 5% of supplemental silicon surface."
    ça me laisse un peu dubitatif pour le coup surtout si buldozer intrègre un cache dédié pour chaque cluster...
    "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

  23. #23
    Au-dessus il y a écrit :

    The extra integer core (schedulers, D-cache and pipelines) adds only 5% die space
    Sur le lien dresden boy, au-dessus aussi :

    one of Bulldozer's L1 data caches (one per integer core/cluster) could be just 8 KiB in size.
    Donc pourquoi pas ?

  24. #24
    En même temps Johan De Gelas a aussi dit, suite à une interview avec John Fruehe : " L1-caches are similar to Barcelona/Shanghai (64 KB 2-way? Not confirmed)"

    http://it.anandtech.com/IT/showdoc.aspx?i=3681&p=3

    Et c'est "not confirmed" parce que : "The limitation of the L1 cache is really tied more to my understanding than anything else. Johan asked if there were any changes and I said not that I am aware of. There may be changes, but I am not aware of them, and we have not revealed any details."

    http://www.semiaccurate.com/forums/s...6&postcount=18

  25. #25
    Citation Envoyé par newbie06 Voir le message
    Au-dessus il y a écrit :



    Sur le lien dresden boy, au-dessus aussi :



    Donc pourquoi pas ?
    8 KB, effectivemenent si ça se confirme ça représente 8 fois moins que ce qu'un core K7/K8/K10 disposait, sans parler du fait qu'un Integer cluster ne semble pas valoir (en nombre de pipeline) un core K10, mais je trouve ça quand même très optimiste où alors c'est un sacré tour de force, bon je sais qu'il y a eut des mecs qui touchaient leur bille en matière d'optimisation je pense notament au core Palomino (Athlon XP), mais est ce que AMD disposent encore de telles équipes ?
    "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

  26. #26
    Citation Envoyé par Alexko Voir le message
    En même temps Johan De Gelas a aussi dit, suite à une interview avec John Fruehe : " L1-caches are similar to Barcelona/Shanghai (64 KB 2-way? Not confirmed)"

    http://it.anandtech.com/IT/showdoc.aspx?i=3681&p=3

    Et c'est "not confirmed" parce que : "The limitation of the L1 cache is really tied more to my understanding than anything else. Johan asked if there were any changes and I said not that I am aware of. There may be changes, but I am not aware of them, and we have not revealed any details."

    http://www.semiaccurate.com/forums/s...6&postcount=18
    ouais ou alors ils ont décider de nous faire une archi avec des caches I/D de taille différentes comme sur les PPC à une certaine époque, mais la question que je me pose, qu'est qu'il est le plus facile de cacher, la latence du cache d'instructions ou de celui des datas ?
    "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

  27. #27
    Il est tres difficile de cacher la latence d'un cache d'instruction. Les seuls mecanismes sont d'ameliorer la prediction de branchement (qui predit quelle ligne de cache fetch a l'avance) et d'ajouter des threads. La prediction de branchement est tres difficile a ameliorer pour un cout raisonable, augmenter les threads SMT, a priori ils ne font pas...

    La latence des caches de donnees est compensee par les mecanismes d'OOO (trouver des instructions a lancer en parallele) et de speculation sur les adresses et de prechargement. Les caches de donnees sont passes de 1 a 2, 3 ,4 voir 5 clocks de latence quasiment sans penalite de performance visible. Augmenter le nombre de threads aide aussi.
    Masquer la latence d'un cache de donnees est generalement plus simple et moins couteux qu'un cache d'instruction sur les archis modernes.
    fefe - Dillon Y'Bon

  28. #28
    Des caches L1-D de 8 ko, ça serait surprenant, mais une sorte de trace-cache de 8 ko, pourquoi pas ?

  29. #29
    Citation Envoyé par Alexko Voir le message
    Des caches L1-D de 8 ko, ça serait surprenant, mais une sorte de trace-cache de 8 ko, pourquoi pas ?
    Le trace-cache était une nécessité dans le cas de Netburst à cause de la profondeur de son pipeline, l'utilisation d'une techno similaire pourrait peut-être nous indiqué que le pipeline de Bulldozer pourrait excéder celui de K10 et de Nehalem après tout en considérant les clusters ils me semblent bien moins larges que tout ce qu'on a pu voir avant.

    Bon j'y crois pas trop mais ça serait marant un truc comme ça, une espère de chainon manquant entre les procs multicores et les ceux à haute fréquence. Après pour l'efficacité je dis pas...
    "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

  30. #30
    Il y a d'autres benefices au trace cache que juste reduire la penalite de branchement. Au lieu de decoder les instructions a chaque fetch du cache d'instruction, elles sont deja decodees ce qui economise l'energie du decodage. Qui plus est charger un grand nombre d'instruction en parallele est beaucoup plus simple quand on n'a pas a les decoder. Finalement les branchements sont deja predits et les traces arrangees de maniere a ce qu'il n'y ait aucune bulle (un peu comme si les branchements n'avaient jamais existe) ce qui accelere aussi l'execution.
    Finalement une reduction de la profondeur du pipeline ne fait de mal a personne. C'est evidement critique quand une mauvaise prediction coute 21 cycles (Willamette) ou 30 cycles (Prescott), mais les CPUs x86 actuels sont dans les 13-15 cycles ce qui est deja assez long... donc economiser 2-3 etages de pipeline ne fait pas de mal...
    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
  •