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

Discussion: Micro-Architecture

  1. #211
    Citation Envoyé par newbie06 Voir le message
    Tu es sûr que tu as bien lu ? nVidia utilise des émulateurs Palladium, et ce n'est pas du Intel dedans, mais des circuits spécialisés genre FPGA ; bon, il faut une workstation en front-end, mais c'est un détail.
    Je pensais surtout à VIA et leurs Core i7. Pour une boîte qui fait des CPU x86 c'est un peu la honte (même si c'est rationnellement le bon choix). Je me doute un peu que NVIDIA ne va pas utiliser des GPU pour la simulation (encore que...)

    Tu peux considérer tes émulateurs comme une grosse grille de FPGA. Mais si tu parles de FPGA genre une carte Virtex que tu colles dans ton PC, ça ne va pas le faire : va vraiment simuler précisément le comportement d'une RAM avec ; essaye de débugger ton RTL avec. Pas facile Les FPGA ont une utilité pour faire des tests rapides de micro-architecture (hors accès RAM), ou en phase de validation fonctionnelle (où tu te fous des timings et/ou de debugger la f.cking équation que t'as merdée).
    Tu dois pouvoir rajouter une couche d'abstraction, en dissociant le temps FPGA du temps simulé, comme on fait en soft ? C'est d'ailleurs en gros ce que fait Cadence avec leur "simulation acceleration", non ?
    Qu'est-ce qui empêche d'intégrer le contrôleur DRAM pour diriger le timing ? (Même pas besoin de faire passer les vraies données à travers, c'est juste pour le contrôle.)

  2. #212
    Citation Envoyé par Møgluglu Voir le message
    Je pensais surtout à VIA et leurs Core i7. Pour une boîte qui fait des CPU x86 c'est un peu la honte (même si c'est rationnellement le bon choix). Je me doute un peu que NVIDIA ne va pas utiliser des GPU pour la simulation (encore que...)
    Apparemment il y a des articles de recherche sur la simulation RTL sur GPU. Je ne sais pas si ça a déjà été industrialisé et surtout quelles sont les limites, notamment en terme de quantité de mémoire requise pour un gros design.

    Tu dois pouvoir rajouter une couche d'abstraction, en dissociant le temps FPGA du temps simulé, comme on fait en soft ? C'est d'ailleurs en gros ce que fait Cadence avec leur "simulation acceleration", non ?
    Qu'est-ce qui empêche d'intégrer le contrôleur DRAM pour diriger le timing ? (Même pas besoin de faire passer les vraies données à travers, c'est juste pour le contrôle.)
    Je me suis mal exprimé, désolé Ca n'est évidemment pas impossible de simuler de la DRAM et son contrôleur, ni même d'ailleurs d'obtenir un peu de visibilité, mais il faut le faire, et si tu as des besoins non couverts par quelque chose d'existant, ça veut dire développer ton propre RTL et le valider. Peut-être de telles IP sont-elles proposées par des vendeurs, mais en tout cas, je n'en ai jamais vu ; j'ai croisé des bidules qui font du buffering de transferts pour simuler de la latence, c'est tout (y'a surement autre chose, je parle juste de ce que j'ai vu).

    Ce que je voulais surtout pointer du doigt, c'est qu'il y a un très large spectre d'outils pour la simulation en général, et que certains sont plus ou moins adaptés à certaines tâches. Pour en revenir à VIA et à nVidia, tu peux très bien booter un OS en simulation RTL soft ou sur un émulateur ; une des ces deux solutions est juste inefficace Et réciproquement, quand tu lances des milliers de test de validation.

    Enfin bon, je ne suis pas un spécialiste du RTL et de sa simulation, je suis un gros fan de la simulation fonctionnelle pour l'analyse des propriétés des programmes, c'est de la simu, mais ça n'a plus rien à voir

  3. #213
    Les emulateurs ca sert surtout a la phase de validation du projet, ca te permet d'avoir un chip A0 revenant de la fab qui n'a que des bugs dans les circuits analogiques ou des problemes avec le process. Tu fais tourner ca pendant les derniers mois avant le tapeout, en general avant tu n'as pas assez de RTL fonctionnel pour le faire. Ca te permet aussi de developper et debug ton firmware et autres fonctions bas niveau implementees en soft. Dans les phases anterieures du projet tu fais de la simulation de RTL sur des farms de serveurs x86, et avant ca tu fais de la simulation de plus haut niveau (simulateur cycle a cycle qui tourne a quelques kilohertz, simulateurs moins precis target vers une analyse sur des periodes plus longues...).

    Bref tu ne peux pas faire un processeur sans une ferme de calcul. Surtout pour la derniere etape: les 2 semaines que ca prend a faire le rendu des masques a partir du RTL...
    fefe - Dillon Y'Bon

  4. #214
    Citation Envoyé par fefe Voir le message
    Bref tu ne peux pas faire un processeur sans une ferme de calcul. Surtout pour la derniere etape: les 2 semaines que ca prend a faire le rendu des masques a partir du RTL...
    Y'a plus qu'Intel comme concepteur de processeur à être concerné par cette phase, non ?

  5. #215
    IBM aussi
    fefe - Dillon Y'Bon

  6. #216
    Je sais que ce n'est pas forcément le meilleur endroit pour poser cette question, mais on ne sait jamais : il y a des gens qui ont utilisé CACTI ici ? (L'outil de modélisation de caches de HP Labs.) Et qui ont réussi à obtenir des résultats pas totalement aberrants ?

    À chaque fois que j'essaie de m'en servir j'obtiens des résultats fortement improbables. Par exemple avec l'interface web en mode simplifié :
    http://quid.hpl.hp.com:9081/cacti/index.y

    Cache size: 16384
    Line size: 64
    Associativity: 2
    # banks: 1
    Node: 45
    J'obtiens 0.371 mm² et 0.068 nJ par lecture.

    Maintenant je change juste la taille des lignes de cache à 128 octets, et j'obtiens 1.267 mm² et 0.256 nJ, plus de 3 fois plus.

    C'est juste un exemple mais ça me fait toujours des trucs comme ça. J'ai l'impression qu'il craque complètement dès qu'on lui demande de faire des mémoires très larges et peu profondes.

    Est-ce que c'est juste CACTI qui n'est pas prévu pour ça, où il y a une raison physique derrière ?
    Je me doute bien qu'il y a un surcoût à vouloir faire une SRAM de 64 × 2048 bits plutôt que 128 × 1024, mais quand ça fait plus que doubler la surface et la conso c'est inquiétant...

  7. #217
    La fois ou j'ai tente de l'utiliser, passer un cache de 512 Ko a 1 Mo, les autres params restant identiques, ne changeait quasiment rien ni a la surface, ni au temps d'acces. Je me suis dit que je ne savais pas utiliser l'outil, et j'ai laisse tomber.

    Pour ton cas, je me demande si le pb ne vient pas du nombre de banks. Tu veux vraiment une bank de 1024 bits ?

  8. #218
    Citation Envoyé par newbie06 Voir le message
    La fois ou j'ai tente de l'utiliser, passer un cache de 512 Ko a 1 Mo, les autres params restant identiques, ne changeait quasiment rien ni a la surface, ni au temps d'acces. Je me suis dit que je ne savais pas utiliser l'outil, et j'ai laisse tomber.
    C'est exactement ce qui m'arrive à chaque fois. Je laisse tomber, puis au bout de quelques mois, à force de lire des papiers qui donnent plein de résultats de surface/conso avec, je me dis que ça ne doit pas être si compliqué et je réessaie.
    Et j'obtiens n'importe quoi, j'essaie de comprendre pourquoi en comparant les statistiques et en lisant les rapports de recherche d'HP, puis ça me donne mal à la tête et j'abandonne jusqu'à la prochaine fois.

    Pour ton cas, je me demande si le pb ne vient pas du nombre de banks. Tu veux vraiment une bank de 1024 bits ?
    De mes expériences précédentes, j'ai retenu qu'il ne fallait surtout pas jouer avec le nombre de banks et le laisser toujours à 1, sous peine d'avoir une explosion exponentielle de la surface.
    En théorie il divise les banks en subbanks, en mats puis en subarrays en faisant de l'optimisation multi-critère sous contrainte, donc si tu lui demande une bank de 1MB il devrait te la diviser en petits rectangles de la façon qui va bien.

    Moi je veux juste une mémoire de 16 KB depuis laquelle je puisse lire 1024 bits par cycle…

  9. #219
    Je ne sais pas utiliser CACTI, mais de toutes facons ca ne te penaliseras pas trop vu la marge d'erreur de l'outil en pratique (tres facile a dire sans le connaitre vu la difference de densite de SRAM entre 2 competiteurs au meme noeud de process)...Deja, sais tu si tu veux baser ta memoire sur des cells de type small signal array ou des register files ? Vu la capacite et bande passante que tu suggeres, des RF seraient probablement plus appropriees, et de base c'est nettement plus gros (et je ne crois pas que CACTI sache faire ca)...

    Apres je sais ca fait mieux de citer dans un papier un outil faux mais que tout le monde utilise...
    fefe - Dillon Y'Bon

  10. #220
    OK. Oui, apparemment CACTI est plutôt conçu pour les gros caches de dernier niveau optimisés densité, donc ils proposent des cells exotiques genre eDRAM, mais pas de RF.

    Citation Envoyé par fefe Voir le message
    Apres je sais ca fait mieux de citer dans un papier un outil faux mais que tout le monde utilise...
    Certainement. Surtout quand les auteurs de l'outil sont dans le PC de la conf dans laquelle tu soumets. Mais je n'en suis pas encore arrivé à ce niveau de malhonnêteté intellectuelle (ça viendra).

    Déjà que ça me fait criser à chaque fois que je lis un papier qui donne des "résultats" de conso avec 4 chiffres significatifs.
    Heureusement pour les auteurs c'est en général pas moi qui suis chargé de la review du papier...

  11. #221
    Citation Envoyé par Møgluglu Voir le message
    Déjà que ça me fait criser à chaque fois que je lis un papier qui donne des "résultats" de conso avec 4 chiffres significatifs.
    C'est possible, mais il faut mini une page de texte en intro pour lister les conditions (temperature, quel die dans la distribution, modele de VR/loadline...
    Dans nos outils pre-silicon de projection de power on a des facteurs multiplicatifs empiriques (mesures sur les generations precedentes) des courants de fuite qui sont proches de 2...

    L'autre option c'est d'utiliser des kW comme unite de mesure.
    fefe - Dillon Y'Bon

  12. #222
    Les "résultats" auxquels je pense, c'est même pas des mesures, et le protocole expérimental c'est "on a lancé l'outil d'estimation de power Synopsys/Mentor/Cadence". Et encore ça c'est quand ils ont pris la peine d'écrire le RTL.
    Même les résultats du même outil ont des gros écarts entre eux. Je suppose que c'est du au place & route qui a un comportement cahotique.

    Mais en info/EE ça ne gêne personne de montrer une courbre toute en dents de scie qui pourrait être la fonction random pour conclure "les résultats montrent que la config avec n=17, alpha=2.358 et z=42, elle est vachement mieux que celle où zeta est négatif".

    (aigris de la recherche, bonjour)

  13. #223
    Citation Envoyé par fefe Voir le message
    L'autre option c'est d'utiliser des kW comme unite de mesure.
    J'adore

    Là où je bosse, tous les outils EDA d'estimation de power présentent un énorme défaut : il faut être sûr que le fondeur est capable de caractériser correctement son process. Et la réalité fait très très peur. Les différences de facteur 2 ou plus sont monnaie courante. Pour garder sa santé mentale, il est souvent préférable de se contenter d'espérer que si le power estimé baisse, il baissera aussi dans la vraie vie, et que donc on est sur la bonne voie...

  14. #224
    Oui ca fait un an que je bosse sur la modelisation et la caracterisation du process pour l integrer dans l'analyse de perf et c'est vraiment difficile.
    Les facteurs 2 en question parr apport a un modele purement theorique sont monnaie courante mais en general il y a moyen d'integrer des donnees experimentales venant de test chips pour reduire la marge d'erreur finale de maniere significative.

    Apres ce n'est pas systematique loin de la que quand tu reduis le power dans tes outils bases sur des modeles theoriques que ca reduise vraiment le power au final. Ca reste vrai dans la majorite des cas, mais des fois on a de sacre surprises...

    Quand tu melanges le tout avec du power management dynamique, ca devient un joli cocktail...
    fefe - Dillon Y'Bon

  15. #225
    Presentation d'Haswell sur RWT

    Je ne sais pas si je ne suis pas en train de developper une allergie, mais je trouve la premiere page degoulinante de fanboism Intel, avec tous ces superlatifs...

    Le reste de l'article reste interessant, et c'est un tres joli chip, probablement mon prochain

  16. #226
    Il aurait du se passer des adjectifs "superb", "tremendous", ... ca n'apporte aucune info en dehors d'un jugement bien trop entousiaste sur un processeur qu'il n'a pas encore teste...
    fefe - Dillon Y'Bon

  17. #227
    Citation Envoyé par fefe Voir le message
    Il aurait du se passer des adjectifs "superb", "tremendous", ... ca n'apporte aucune info en dehors d'un jugement bien trop entousiaste sur un processeur qu'il n'a pas encore teste...
    J'ai tiqué sur ces mots, ça me rassure que ça ne choque pas que moi.

    N'empêche que toutes ces ressources matérielles, ça me laisse rêveur, on doit pouvoir faire un Cortex-A9 Phi avec tout ça

  18. #228
    Le truc rigolo c'est de regarder une photo de die et de se rendre compte que le core lui meme ne represente plus grand chose en % .
    fefe - Dillon Y'Bon

  19. #229
    Je suis à la recherche d'informations sur les différents types de SRAM (4T, 6T, 8T…) : leur implémentation physique, les avantages et inconvénients de chaque type, pourquoi l'une consomme plus que l'autre, etc. Vous auriez une idée d'où je pourrais trouver ça ?
    Mon blog (absolument pas à jour) : Teχlog

  20. #230
    4T le plus dense, mais consommation continue
    6T pas de consommation continue
    8T aucune idée
    Mes propos n'engagent personne, même pas moi.

  21. #231

  22. #232
    Merci, après un bref coup d'œil, ça a l'air d'être précisément le genre d'infos que je cherchais. Je vais regarder ça plus en détails.
    Mon blog (absolument pas à jour) : Teχlog

  23. #233
    Une bouteille à la mer

    J'ai remarqué dans la doc sur les compteurs de perfs que depuis Ivy Bridge on a "MOVE_ELIMINATION.INT_NOT_ELIMINATED" qui compte "the number of integer Move Elimination candidate uops that were not eliminated".
    Ôtez moi d'un doute si vous le pouvez, mis à part le fait que le processeur ne serait capable d'avoir uniquement n (n << #registers physiques) registres partagés par plusieurs instructions en même temps, quelle pourrait-être la raison pour laquelle un move ne serait pas éliminé mais candidat à l'élimination?

    Alors oui y'a des cas pourris où on aimerait peut-être ne pas virer le move, mais je ne suis pas sûr qu'on puisse garantir leurs détections au moment où on doit prendre la décision d'éliminer le move ou pas.
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  24. #234
    Bon, auto réponse, d'après ce brevet, il y a des chances qu'en effet, le nombre de registres partagés en vol soit limités. Plus qu'à microbencher pour savoir combien
    Bon après rien n'est garanti mais j'ai quand même de fortes suspicions.
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  25. #235
    J'ai pas de réponse, mais si en passant tu trouves des infos sur le renommage des instructions AVX-512 masquées dans Skylake et Knights Landing, ça m'intéresse.

    Non, il y a pas de rapport direct avec la move elimination, mais je ne vois pas comment on peut éviter des perfs totalement dégueulasses (i.e. ≤ à Knights Ferry) sur du code masqué sans une forme de "blend-elimination" pour casser les chaînes de fausses dépendances. Je suis curieux de savoir s'ils ont une arme secrète pour ça.

  26. #236
    Je n'ai pas spécialement d'informations là-dessus, et moi je ne fais pas des choses bizarres comme ça

    Sauf que si vu que j'ai une question sur SSE/AVX...

    Vu qu'il est conseillé de faire vzeroupper avant de passer de code AVX vers du vieux SSE, et vu la définition de ADDPS par exemple (qui merge la partie haute de ymm, mais pas VADDPS), je suppose qu'il y a un bit dans la rename map qui dit si la partie haute d'un registre ymm est à zéro ou non. Si oui et qu'on fait du vieux SSE, tout va bien, sinon, il faut merge.

    Moi ce qui m'intéresse ce sont les instructions scalaires. En SSE/AVX, elles ne touchent pas la partie haute de xmm (même quand on opère sur ymm, donc que ce soit VEX ou legacy).

    Du coup si je fais un VADDSS ymm1 = ymm2 + ymm3, ça donne

    Code:
    ymm1[31:0] = ymm2[31:0] + ymm3[31:0]
    ymm1[127:32] = ymm2[127:32] 
    ymm1[255:128] = 0
    Et même chose si c'est encodé en legacy, juste que ymm1[255:128] ne sera même pas mis à 0. Donc même si la partie haute de ymm est mise à 0 en VEX, dans les deux cas il y a une dépendance sur la partie haute d'un xmm source.

    Mon problème, c'est que je suis un peu sceptique sur la nécessité de sortir 256/512 bits (Legacy) ou 128 bits (VEX) pour merge le résultat avec la partie haute du résultat précédent alors que je calcule un résultat sur 32 bits.

    Une façon de faire serait de découper un registre architectural ymm en plusieurs registres architecturaux: ymm[VMAX:0], ymm[127:0], ymm[63:0] et ymm[31:0], dans la rename map, et injecter des merge de temps en temps (ça doit ressembler aux partial writes pour les registres general purpose), mais ça commence à ressembler à une usine à gaz.

    Après peut-être que sortir 256 bits pour calculer 32 bits c'est pas si cher payé (j'ai comme un doute, mais bon, c'est pas vraiment ma spécialité d'un autre côté). Bref, si quelqu'un à un pointeur où un commentaire, je prends
    Dernière modification par Thamior ; 19/10/2015 à 18h54.
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  27. #237
    Bonne question.
    Est-ce qu'il y a des pénalités à exécuter des instructions packed derrière des instructions scalaires ? Le merge doit avoir un coût visible. Et si on renomme séparément la partie haute et la partie basse sans jamais faire de merge, c'est la logique de wakeup qui va être compliquée.

    Au passage, la gestion des dépendances partielles AVX avec vzeroupper et compagnie a changé sous Skylake.
    http://www.intel.com/content/dam/www...ion-manual.pdf Section 11.3 :
    The Skylake microarchitecture implements a different state machine than prior generations to manage the YMM state transition associated with mixing SSE and AVX instructions. It no longer saves the entire upper YMM state when executing an SSE instruction when in “Modified and Unsaved” state, but saves the upper bits of individual register. As a result, mixing SSE and AVX instructions will experience a penalty associated with partial register dependency of the destination registers being used and additional blend operation on the upper bits of the destination registers.
    Bonne nouvelle : fini les pénalités de 100 cycles quand tu as oublié un vzeroupper dans un coin. Maintenant il est capable d'insérer juste une instruction blend qui va bien. Je ne sais pas si ça s'applique aux dépendances partielles scalaire-vecteur, mais ils ont visiblement changé un truc sur les dépendances partielles.

  28. #238
    Il n'y a pas l'air d'y avoir de pénalité non...Et le guide dit que même quand on veut copier 32/64 bits (registre à registre), il vaut mieux utiliser MOVAPS/MOVAPD/MOVDQA. Les deux suggèrent qu'il n'y a bien qu'un registre physique alloué par registre architectural xmm. Du coup le tradeoff c'est faire des blends (et avoir plus de state à checkpointer si la rename map a plusieurs registres physiques par registre xmm) vs. toujours balader 128 bits sur les bus alors qu'on fait du scalaire. Enfin j'ai peut-être oublié quelque chose

    L'autre alternative, à la limite, c'est de faire comme pour la move elimination des MOVZX : Si tu ne fais que du scalaire, alors tu as fait un MOVSD depuis la mémoire (resp. MOVSS) qui a mis à 0 xmm[127:63] (resp. xmm[127:31]). Ça peut mettre un bit à 1 dans la rename map pour ce registre xmm, et tant que tu ne fais pas du packed, tu le propages, et les unités fonctionnelles ne sortent que 64 bits (resp. 32 bits). Dès que tu commences à mixer packed et scalar (ou changer de précision mais là tu fais des choses bizarres), ça lit juste les 128 bits à chaque fois. Le truc c'est que ça contredit un peu ce que dit le manuel plus haut (utiliser des instructions packed pour faire des copies de registres).

    Pour les dépendances partielles entre ymm et xmm dans Skylake, je suppose qu'au lieu d'avoir deux bits pour "l'état AVX", il y a deux bits par registre ymm, maintenant. Mais en fait, j'avais pas suivi que jusqu'ici, c'était tout le state AVX qui était sauvegardé quand on passait de AVX à SSE. Je suppose que ça explique la pénalité de 100+ cycles

    Enfin, on sent les extensions d'ISA par dessus les extensions d'ISA
    La question sous-jacente c'est si la définition même de SSE/AVX permet de faire de la prédiction de valeurs sur les instructions FP scalaires, et si non, est-ce que la micro-architecture peut éventuellement aider à tricher pour rendre ça possible. Non pas que ça serve à quelque chose hein, c'est pas super prédictible en général .
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  29. #239
    Bah t'as qu'à prédire les parties hautes des instructions AVX scalaires alors, ça doit marcher super bien.

    Sinon, tu sais prédire les endroits où tu as besoin d'un blend et ceux où tu peux t'en passer ? De préférence dès l'étage de decode, pour pouvoir insérer des µops facilement. Si tu as ça, j'achète.
    (Enfin je paie moins qu'Intel et Apple : dépose plutôt un brevet.)

  30. #240
    Ben pour gérer les écritures partielles sur les registres general purpose il faut bien avoir renommé tes instructions pour injecter le merge/blend, non? Donc ça doit être faisable au Rename, et de manière non spéculative, en plus.
    Enfin je ne suis pas sûr de ce que tu cherches à faire exactement, juste savoir, sachant une instruction scalaire, si tu dois faire un blend ou pas?

    Sinon tu mets un TAGE-like et hop, c'est bon, plus de problèmes.
    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
  •