Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 5 sur 9 PremièrePremière 123456789 DernièreDernière
Affichage des résultats 121 à 150 sur 267

Discussion: Micro-Architecture

  1. #121
    Citation Envoyé par fefe Voir le message
    C'est un cauchemard, et je suis dedans jusqu'aux oreilles.
    fefe fait de la fimulation sull-fistem
    fese sait de la simulafion full-fiftem
    fefe fait de la fimu...

    J'arrive pas à le dire...

  2. #122
    Je voudrais savoir si les chipset mono-processeur (X48, P35, P45....) possédaient un snoop filter ?


  3. #123
    Non, les seuls chipsets pour Intel dont je me souvienne qui aient eu des snoop filters sont les chipsets IBM pour les plateformes MP.

    Il n'y a pas d'interet a mettre un snoop filter sur un chipset de mono socket, il n'y a pas de snoop a filtrer qui y passent.
    fefe - Dillon Y'Bon

  4. #124

  5. #125
    Il pourrait y avoir un interet, mais a ma connaissance il n'y en a pas (un snoop filter ce n'est pas petit donc ca coute cher).
    fefe - Dillon Y'Bon

  6. #126
    Comme j'ai pas le courage de prendre la responsabilité de créer un topic "Bulldozer et innovations", je squatte ici.

    Il se murmure que Bulldozer pourrait être une archi clustered, avec 2 clusters d'ALU qui pourraient soit être utilisés ensemble par 1 seul thread, soit affectés chacun à un thread différent. Chaque cluster a ses propres registres, son propre scheduler, son propre L1...
    La FPU resterait partagée.

    Donc en gros ça revient à reconfigurer dynamiquement un core en deux cores d'IPC divisée par 2, et vice versa. Ou faire du SMT avec des unités dédiées.

    Je n'ai pas lu de littérature sur ce sujet, même si je sais qu'il y en a plein.
    J'imagine que c'est plus facile à mettre en place que du SMT, plus couteux et généralement plus efficace?
    La difficulté principale vient des dépendances entres clusters en mode monothread, et comment scheduler les instructions pour limiter ces dépendances, je suppose?
    (ou alors j'ai rien compris? )

  7. #127
    La seule chose simple a faire pour une archi clusterisee est de partager un frontend, et avoir 1 thread par cluster statiquement.
    Ca n'augmente pas l'IPC avec 1 seul thread, et ca a un cout et un gain intermediaire entre le dual core et le SMT.
    Augmenter l'IPC d'1 thread avec une machine clusterisee il y a beaucoup de litterature sur le sujet (par exemple jetez un oeuil sur les travaux de l'UPC Barcelona) mais obtenir 20% de performance en doublant la taille de la machine serait un succes magnifique face a la difficulte (quand on arrive a faire un truc aussi difficile il n'y a aucune raison de s'arreter la et ne pas faire SMT a mon avis).

    La principale difficulte du clustering pour 1 thread vient du fait qu'il faut predir sur quel cluster envoyer ses instructions afin d'eviter les penalites de bypass entre clusters (donc predire des chemins critiques en plein milieu d'une execution speculative). C'est pas facile, voir franchement difficile sur beaucoup d'applis classiques. Il y a eu au moins une archi clusterisee performante: l'alpha EV6 et pour une raison simple, ils avaient investi le hardware pour tout bypasser quasiment sans surcout donc n'avait pas a faire cette prediction. Le probleme est que c'est une methode tres couteuse (en pratique ce n'est pas fondamentalement different de design une archi 2x plus large non clusterisee et de la nommer "cluster").
    L'autre probleme fondamental des clusters est qu'on veut les implementer afin de reduire le nombre de port sur les structures de l'OOO et les registres. En effet on s'attend a ce que la taille de ces structures augmentent exponentiellement avec le nombre de port a partir du point ou on en est aujourd'hui (dans un K10 par ex). En pratique il y aura toujours un type tres fort en circuits qui trouvera une solution proche de lineaire en cout et qui ne te forcera pas a subir les horreurs de la prediction de chemin critique...

    Le clustering est une technique connue et etudiee sous toutes ses facettes depuis un bon moment (quand l'EV6 l'a implemente c'etait a la mode) et etrangement absent de nos microprocesseurs aujourd'hui. C'est tres certainement une voie pour ameliorer l'IPC de processeurs dont on ne sait plus quoi faire pour augmenter la performance. Ce n'est definitivement pas une solution simple pour eviter de faire du SMT et d'avoir un bon scaling multithread .

    Pour imaginer quelques autres difficultes du clustering imaginer:
    -ce qui se passe quand un branchement est mal predit et a des dependants des 2 cotes
    -ce qui se pache sur un cache miss quand on a schedule speculativement en pensant a un hit, mais sur le cluster oppose

    Ca devient tres fun pour les architectes (au sens propre), il y a vraiment beaucoup de boulot, et du boulot difficile.
    fefe - Dillon Y'Bon

  8. #128
    C'est intéressant tout ça. J'imagine que c'est à ça que faisaient maladroitement référence les rumeurs de "reverse HT" qui circulaient il y a quelques temps déjà. Du coup, je pense qu'on peut être à peu près sûr qu'AMD prépare quelque chose comme ça.

    Ça vient d'où l'info sur les clusters ?

    Edit : en cherchant d'où venaient les rumeurs sur le reverse-HT, j'ai trouvé d'abord une connerie de Theo Valich (pour changer) selon laquelle c'était une feature des A64 X2. Bref, passons.

    Mais y'a aussi ça, et Sam est à l'origine ! http://www.dvhardware.net/article10901.html Ça parle d'après-K8, donc ça colle avec Bulldozer.
    Dernière modification par Alexko ; 22/05/2009 à 00h36.

  9. #129
    Citation Envoyé par Alexko Voir le message
    Ça vient d'où l'info sur les clusters ?
    De vagues spéculations sur les brevets d'AMD :
    http://citavia.blog.de/

  10. #130
    Citation Envoyé par Møgluglu Voir le message
    De vagues spéculations sur les brevets d'AMD :
    http://citavia.blog.de/
    En même temps, le coup du cluster pourrait être un moyen d'augmenter l'IPC sans utiliser l'HT, même si c'est plus difficile (je suppose que l'HT doit être bien blindé au niveau propriété intellectuelle)

  11. #131
    Bah l'HT c'est jamais que du SMT, Intel n'a pas inventé grand chose donc je ne pense pas qu'il s'agisse d'un problème de propriété intellectuelle, surtout avec les accords de transfert technologique entre AMD et Intel, même si y'a de l'eau dans le gaz en ce moment. Ça serait plutôt le choix d'un compromis différent, tout simplement.

    Un brevet ça ne veut pas forcément dire grand chose, mais en attendant ça colle avec ça :



    La grosse augmentation des perfs en int relativement aux perfs FP semble cohérente avec un cluster d'ALU vs FPU partagée.

    Au passage, Magny-Cours est un peu bizarre. L'augmentation des perfs en FP par rapport à Istanbul est logique (2 fois plus de cores, fréquence inférieure) mais en int on a presque le double.

    Edit : me suis gourré de couleurs, j'ai rien dit.
    Dernière modification par Alexko ; 22/05/2009 à 15h05.

  12. #132
    Citation Envoyé par Alexko Voir le message
    Au passage, Magny-Cours est un peu bizarre. L'augmentation des perfs en FP par rapport à Istanbul est logique (2 fois plus de cores, fréquence inférieure) mais en int on a presque le double.
    En int ça fait 50% de plus, bien loin de 100%. Mais le doublement du nombre de coeurs doit avoir son importance autant que pour le FP, non ?

  13. #133
    Ah, ça devient dûr de se faire vieux
    http://forum.canardpc.com/showthread...97#post2056497

    ... Et daltonien
    (FP c'est la colonne de gauche plus sombre)

    (désolé Alexko, pas pu m'en empêcher...)

  14. #134
    Ah oui du coup quand on lit tout à l'envers, forcément ça marche beaucoup moins bien :D

    J'arrive même à ne plus comprendre des trucs que j'avais compris y'a pas longtemps, faut vraiment que je consulte, là (je sais pas exactement qui, mais il faut !).

  15. #135
    http://www.realworldtech.com/page.cf...2109003617&p=1

    C'est du lourd. Ca devient plus accessible ici : http://www.realworldtech.com/page.cf...109003617&p=11

    On peut probablement pas faire plus clair que le graph. Heureusement que GloFo a IBM pas loin...

  16. #136
    Comme d'hab chez RWT c'est très bon, même si honnêtement j'ai pas tout compris...

  17. #137
    Cool... Je lirais ça la semaine prochaine au taff.
    Suite à une suggestion, je vais utiliser cette signature pour des canards en manque de ranking pro. Ou des quotes idiots.

  18. #138
    Et c'est quoi le rapport avec la micro-architecture ?
    Ouai, j'ai chaud, ça m'énerve.

  19. #139
    Vive la Clim ! Le rapport avec la microarchitecture est indirect, mais pas tant que ca. Plus on avance, plus la microarchitecture prend en compte les parametres du process. En tunant les 2 ensemble au lieu de le faire separement, cela permet de grapiller quelques fractions de % qui deviennent importantes vu l'erosion actuelle des gains de performance (tant du cote process que du cote uarch).

    Bien entendu ce n'est accessible que si l'on sait sur quel process on va etre produit pendant le developpement de la microarchitecture...
    fefe - Dillon Y'Bon

  20. #140
    Citation Envoyé par newbie06 Voir le message
    Et c'est quoi le rapport avec la micro-architecture ?
    Ouai, j'ai chaud, ça m'énerve.
    Si je te disait aucun, mais y'a pas de topic process ça t'avancerait ?

  21. #141
    Bon, la il fait meilleur, j'ai la clim. Mais ouai je comprends toujours pas, faut creer un topic implementation/process

    @fefe: certes l'implementation influe sur le design, et le process aussi. Mais les boites qui font du design jusqu'a l'implementation, il en reste combien ? Une ou deux ? Si tu tunes trop fortement ton design pour un process particulier, tu ne pourras plus faire toc (ou tic je sais plus), si ?

    Les boites qui ne visent pas un process tres particulier et font du synthetisable se foutent un peu du process (j'ai dit "un peu"). Au pire il font contourner l'idiotie des outils de synthese... Mais ca concerne l'ecriture de tout petit modules, pas la micro-architecture en general.

  22. #142
    Citation Envoyé par newbie06 Voir le message
    @fefe: certes l'implementation influe sur le design, et le process aussi. Mais les boites qui font du design jusqu'a l'implementation, il en reste combien ? Une ou deux ? Si tu tunes trop fortement ton design pour un process particulier, tu ne pourras plus faire toc (ou tic je sais plus), si ?
    Ben, il faudra refaire un peu de design, pour s'adapter aux avantages et aux faiblesses du nouveau process. Même chez Intel qui a une politique ou évolution de process et de design sont bien séparés, un changement de process s'accompagne toujours maintenant de changements niveau µarch (voire même ISA, même ca c'est x86 inside ). Je crois me rappeler qu'il y a eu de purs die shrinks de par le passé, mais je ne sais plus quel était le dernier.
    Enfin, les 2 sont étroitement liés, dans la pratique ca doit d'ailleurs un peu compliqué parce que le designers ne disposent pas du process cible au moment de la conception. Ils simulent (les vils coquins) et doivent s'ajuster assez fréquemment en fonction des retours sur le process.

  23. #143
    Je change totalement de sujet, pasque j'y comprend rien à vos histoires de process.

    Les X86 modernes ont leurs registres en 128-bit, voire 256-bit avec AVX. (quid de Larrabee?)

    Vu qu'une grosse majorité des opérations travaille toujours sur 32-bit et parfois sur 64-bit, est-ce qu'il existe des optimisations pour le power? Genre désactiver dynamiquement des bouts de datapaths, réduire la largeur de certains ports sur le banc de registres?...

    Ou bien c'est juste pas rentable, pasque sinon autant faire des bancs de registres séparés?

    (Ma question s'applique aussi aux autres archis, ne soyons pas sectaires.)

  24. #144
    Citation Envoyé par Yasko Voir le message
    Ben, il faudra refaire un peu de design, pour s'adapter aux avantages et aux faiblesses du nouveau process. Même chez Intel qui a une politique ou évolution de process et de design sont bien séparés, un changement de process s'accompagne toujours maintenant de changements niveau µarch (voire même ISA, même ca c'est x86 inside ). Je crois me rappeler qu'il y a eu de purs die shrinks de par le passé, mais je ne sais plus quel était le dernier.
    Enfin, les 2 sont étroitement liés, dans la pratique ca doit d'ailleurs un peu compliqué parce que le designers ne disposent pas du process cible au moment de la conception. Ils simulent (les vils coquins) et doivent s'ajuster assez fréquemment en fonction des retours sur le process.
    Si je me souviens, les premiers Athlon en 130 nm, c'était du die shrink pur et c'était foireux :D

  25. #145
    Citation Envoyé par Møgluglu Voir le message
    Les X86 modernes ont leurs registres en 128-bit, voire 256-bit avec AVX. (quid de Larrabee?)
    512-bit.

    Vu qu'une grosse majorité des opérations travaille toujours sur 32-bit et parfois sur 64-bit, est-ce qu'il existe des optimisations pour le power? Genre désactiver dynamiquement des bouts de datapaths, réduire la largeur de certains ports sur le banc de registres?...

    Ou bien c'est juste pas rentable, pasque sinon autant faire des bancs de registres séparés?

    (Ma question s'applique aussi aux autres archis, ne soyons pas sectaires.)
    Les "autres" archis sont capables d'eteindre les unites FP et/ou SIMD a la volee, ainsi que les registres associes.

  26. #146
    Citation Envoyé par Møgluglu Voir le message
    Les X86 modernes ont leurs registres en 128-bit, voire 256-bit avec AVX. (quid de Larrabee?)
    Larrabee a ete annonce a 512 bits.

    Vu qu'une grosse majorité des opérations travaille toujours sur 32-bit et parfois sur 64-bit, est-ce qu'il existe des optimisations pour le power? Genre désactiver dynamiquement des bouts de datapaths, réduire la largeur de certains ports sur le banc de registres?...
    Tu as plusieurs bancs de registres sur un x86: le banc de registre "entier" et le banc de registre "flottant". Le premier fait 64 bits et le second fait 80bits pre-SSE, 128 bits pour SSEx, 256bits pour AVX.
    Ensuite suivant l'implementation de l'archi les schedulers ont des pointeurs vers ces bancs de registres ou ont une zone de stockage ou la donnee est ecrite avant d'etre retiree (la elle est copiee vers le banc de registre "architecturel").
    Dans les 2 cas, au moment du decodage de l'instruction tu connais la taille des donnees manipulees donc tu peux blocker l'horloge vers les parties inutilisees/non affectees de ces blocs. Ca n'elimine pas les courants de fuite, mais ca elimine le "idle power".
    Si tu regardes un peu de pres une photo de die, tu verras que souvent les unites et le stockage sont organises en plusieur banques histoire de ne controler l'horloge qu'a une granularite importante:
    Tes instructions sont 32 bits tu actives la banque "basse" et bloque l'horloge vers les banques hautes.

    Ou bien c'est juste pas rentable, pasque sinon autant faire des bancs de registres séparés?
    Les 2, tu separes les registres qui ont une utilisation differente, et tu fais des banques pour gerer la largeur de tes donnees.

    Pour eliminer aussi les courants de fuite il faut que tu introduises des "power gate" qui pour l'instant prennent trop de temps a commuter pour qu'elles puissent s'appliquer a ce que tu decris. Mais les technologies avancent, et ce genre de chose ne sont plus tres loin...

    ---------- Post ajouté à 20h46 ----------

    Citation Envoyé par newbie06 Voir le message
    512-bit.

    Les "autres" archis sont capables d'eteindre les unites FP et/ou SIMD a la volee, ainsi que les registres associes.
    Eteindre l'horloge ou le Vcc ? Je serais impressione par la presence de power gates qui s'active en quelques cycles.

    ---------- Post ajouté à 20h50 ----------

    Citation Envoyé par newbie06 Voir le message
    @fefe: certes l'implementation influe sur le design, et le process aussi. Mais les boites qui font du design jusqu'a l'implementation, il en reste combien ? Une ou deux ? Si tu tunes trop fortement ton design pour un process particulier, tu ne pourras plus faire toc (ou tic je sais plus), si ?
    Ca n'a une influence que si ton shrink est un shrink optique. Vu que pour la boite qui fait du tic-toc ca fait longtemps que les shrinks ne sont plus optiques, mais juste un design changeant moins de choses ca ne pose pas de problemes. Qui plus est les process d'un constructeur donne partagent beaucoup de caracteristiques d'un noeud a l'autre.

    Les boites qui ne visent pas un process tres particulier et font du synthetisable se foutent un peu du process (j'ai dit "un peu"). Au pire il font contourner l'idiotie des outils de synthese... Mais ca concerne l'ecriture de tout petit modules, pas la micro-architecture en general.
    Oui et obtiennent des circuits moins performants que si ils avaient pu tuner les 2 ensemble. Jusqu'a present ca ne faisait pas beaucoup de differences parce que les process etaient assez flexibles, mais a terme ca risque de commencer a devenir non negligeable...
    fefe - Dillon Y'Bon

  27. #147
    Citation Envoyé par fefe Voir le message
    Larrabee a ete annonce a 512 bits.
    Oui ça je savais , mais le sens de ma question mal formulée c'était est-ce que ce banc est/sera partagé avec le x86 traditionnel, et la réponse que j'ai retrouvée depuis c'est non, c'est/ça sera séparé entre 512-bit vecteur et 64-bit scalaire.

    Tu as plusieurs bancs de registres sur un x86: le banc de registre "entier" et le banc de registre "flottant". Le premier fait 64 bits et le second fait 80bits pre-SSE, 128 bits pour SSEx, 256bits pour AVX.
    Alors là je suis confusé.
    J'avais cru comprendre que sur K7 et successeurs, les registres (renommés) flottant+SSE et entiers étaient séparés, mais que sur P6 et dérivés ils étaient unifiés (avec un ROB+un banc de registres architecturaux).

    Ensuite suivant l'implementation de l'archi les schedulers ont des pointeurs vers ces bancs de registres ou ont une zone de stockage ou la donnee est ecrite avant d'etre retiree (la elle est copiee vers le banc de registre "architecturel").
    Ça correspond respectivement à la solution renommage et la solution ROB?

    Les 2, tu separes les registres qui ont une utilisation differente, et tu fais des banques pour gerer la largeur de tes donnees.
    OK, donc pour les instructions x86 en 32-bit je n'accède qu'à une banque 32-bit de mon banc 64-bit et je clock-gate le reste, de même pour les instructions SSE scalaires sur le banc 128/256-bit.
    Idem pour les unités de calcul.

    Pour les unités pipelinées, ça se fait de contrôler l'horloge indépendamment pour chaque étage, ou c'est uniquement à la granularité de l'unité? (j'ai pas regardé de die de très près...)

    Sinon merci ça répond à ma question, et en plus c'est la réponse que j'espérais.

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

    Alors là je suis confusé.
    J'avais cru comprendre que sur K7 et successeurs, les registres (renommés) flottant+SSE et entiers étaient séparés, mais que sur P6 et dérivés ils étaient unifiés (avec un ROB+un banc de registres architecturaux).
    Alors, ça, je suis presque sur que non...
    Suite à une suggestion, je vais utiliser cette signature pour des canards en manque de ranking pro. Ou des quotes idiots.

  29. #149
    Citation Envoyé par Møgluglu Voir le message
    Alors là je suis confusé.
    J'avais cru comprendre que sur K7 et successeurs, les registres (renommés) flottant+SSE et entiers étaient séparés, mais que sur P6 et dérivés ils étaient unifiés (avec un ROB+un banc de registres architecturaux).
    Ca depend ce que tu appelle banc de registre .
    Dans l'archi P6, ton banc de registre architectural separe chaque type de donnees, ton ROB et ta RS ont une zone de donnee partagee de 128bits chacun par banques de 32. De ce point de vue l'Architecture K7 et P4 sont plutot similaires.

    C'est un peu plus complique quand tu regardes a x87 bien sur parce que tu veux gater a 80 bits.
    fefe - Dillon Y'Bon

  30. #150

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
  •