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

Discussion: Micro-Architecture

  1. #181
    Je vote aussi pour une faute de frappe, sinon je suis trop bête pour comprendre le jeu de mots, et j'ai pas envie d'être bête.

    J'en profite pour poser une question noobesque sur ce post : http://forum.canardpc.com/showpost.p...postcount=4925

    Particulièrement : "J'préfère les switch, ça bouffe moins de cycles". Je pensais naïvement qu'un switch était compilé comme une succession de branchement conditionnels, et que donc ça revenait au même. Ce n'est pas le cas ?

  2. #182
    Un switch peut generer beaucoup de types de code tres differents.

    Par exemple, si les case de ton switch sont tres denses et assez nombreux, tu vas avoir une table de saut.
    Il vaut toujours mieux utiliser un switch sauf cas pathologique

  3. #183
    Citation Envoyé par Alexko Voir le message
    Particulièrement : "J'préfère les switch, ça bouffe moins de cycles". Je pensais naïvement qu'un switch était compilé comme une succession de branchement conditionnels, et que donc ça revenait au même. Ce n'est pas le cas ?
    Suivant l'humeur de ton compilo, il peut aussi l'implémenter avec un tableau de pointeurs et un saut indirect à la valeur lue dans le tableau.

    Il y a bien sur des prédicteurs pour ça...
    Après, est-ce que c'est intéressant par rapport à un nid de ifs, je suppose que c'est au cas par cas en fonction du nombre de cas, de leur probabilité/régularité, de la micro-archi, etc.

    Edit: grillé par le newbie.

  4. #184
    Ca me rappelle un truc que j'utilisais a une epoque : j'avais un gros switch bien dense, avec une tres forte probabilite qu'une valeur soit utilisee. La meilleure facon de faire dans ce cas etait:
    Code:
    if (val == xxx) {
        ....
    } else {
       switch (val) {
       }
    }
    Mais ca a ptet change depuis

    EDIT : J'en profite pour dire que comme tous les tricks d'optim ca peut marcher a un instant donne et etre contre-productif au prochain changement de lune.

  5. #185
    Citation Envoyé par newbie06 Voir le message
    EDIT : J'en profite pour dire que comme tous les tricks d'optim ca peut marcher a un instant donne et etre contre-productif au prochain changement de lune.
    Il parait que le passage de Netburst à Core a été un "bon" moment à passer pour les dev compilo... Genre les ex-tricks devenant à quasi tous les coups plus lent que le vanilla. Quelqu'un peut confirmer ?
    Mes propos n'engagent personne, même pas moi.

  6. #186
    Y'a pas eu un truc du genre add/sub 1 plus rapide que inc/dec qui a change de l'un a l'autre ? Rien que ca, ca peut tuer... Enfin surtout les programmeurs asm

  7. #187
    La latence et le debit de beaucoup d'instructions ont change entre les 2, donc forcement la maniere d'ecrire le code aussi. Toutes les instructions devenues lentes dans P4 parce que soit disant rarement employees, que les compilateurs se sont employe a remplacer par d'autres sont redevenues rapides.

    Un arbre de branchement implique que tu en auras plusieur sur la meme ligne de cache d'instruction, ce qui implique plusieurs fetch a moins d'avoir plusieurs unites de prediction. Avec un switch qui te genere un branchement indirect tu iras plus vite, tu feras le tout en 1 round.

    Si tu as une branche du switch tres prise ca ne devrait pas etre vraiment plus lent que de mettre un if devant puis le switch (depuis Prescott pour Intel). Le predicteur indirect n'est pas aussi bon que le predicteur de branchements conditionnels, mais honnetement pour etre capable de statiquement mieux predire que le predicteur il faudra vraiment un cas pathologoique.
    fefe - Dillon Y'Bon

  8. #188
    Citation Envoyé par fefe Voir le message
    Un arbre de branchement implique que tu en auras plusieur sur la meme ligne de cache d'instruction, ce qui implique plusieurs fetch a moins d'avoir plusieurs unites de prediction. Avec un switch qui te genere un branchement indirect tu iras plus vite, tu feras le tout en 1 round.
    Lopocompris, y'a qu'un predicteur par ligne de cache Ou tu voulais plutot dire qu'il ne peut y avoir qu'un branchement sur un paquet de fetch ?

  9. #189
    Tu ne peux pas savoir quelle ligne fetch si tu n'as pas predit tous les branchements qui se trouvaient sur la precedente. Le fait de pouvoir fetch et decode 4 instructions par cycle ne veut pas dire qu'il peut y avoir tout et n'importe quoi dedans. Si tu as plusieurs branchements (dont au moins le premier non pris) tu vas effectivement devoir y passer plusieur cycles. Le fetch en soit ne prendra pas plusieurs cycles (tu as recupere ta ligne de cache en 1 coup), mais le temps avant de passer au fetch suivant sera accru.
    Je ne connais pas de machine qui predise plus d'1 branchement par cycle mais je peux me tromper ou en avoir rate...
    fefe - Dillon Y'Bon

  10. #190
    Je suis bien fatigue, j'avais lu ton message precedent completement de travers, temps de rentrer a la maison

  11. #191
    J'ai cru un instant que tu allais me dire que le A9 predisait 2 branchements par cycle :jawdrop:
    fefe - Dillon Y'Bon

  12. #192
    Non, non, j'avais vraiment cru lire que les x86 ne pouvaient pas predire plus d'un branch par ligne de cache, ce que je ne croyais pas un seul instant. Je ne sais toujours pas comment j'ai reussi a comprendre ca avec ce que tu as ecrit.

    Et grosse surprise, non le A9 ne predit pas 2 branchement par cycles, surprenant hein ?

  13. #193
    Oui je suis vraiment surpris .
    fefe - Dillon Y'Bon

  14. #194
    Merci pour toutes ces réponses !

  15. #195
    http://www.hardocp.com/article/2010/...essors_preview

    AMD a trouvé malin de mettre le NDA sur la conférence de presse pré-Hot Chips qui divulgue essentiellement la présentation de demain soir à ce matin.

    Super sympa pour ceux qui ont claqué plusieurs centaines de dollars pour y assister ! (les gars d'Oracle s'en foutent probablement, Intel... bah un peu aussi , mais bon pour les étudiants et autres...)

    Dans tous les cas, j'y serais, donc si vous avez des questions en tête !

  16. #196
    Citation Envoyé par PeGGaaSuSS Voir le message
    Super sympa pour ceux qui ont claqué plusieurs centaines de dollars pour y assister ! (les gars d'Oracle s'en foutent probablement, Intel... bah un peu aussi , mais bon pour les étudiants et autres...)
    En même temps, c'est pas comme si le contenu de ces slides avait leaké depuis 1 ans sur les sites chinois.

    Et les présentations de Hot Chips devrait être un peu plus techniques que :
    Bulldozer est une archi clustered avec des unités partagées entre cores, pour un surcoût en surface de 5% par rapport au SMT.
    Bobcat est un core basse-conso x64 qui a 90% de la perf d'un core 2 fois plus gros, d'après nos estimations.
    En conclusion, the future is fusion. Merci de votre attention.
    Enfin j'espère pour toi...

  17. #197
    Citation Envoyé par fefe Voir le message
    J'ai cru un instant que tu allais me dire que le A9 predisait 2 branchements par cycle :jawdrop:
    Je viens de lire sur MDRonline que Bobcat predisait deux branchements par cycle.

  18. #198
    Ca serait interressant et bizarre a la fois. Tu as rarement plus d'un branchement dans un groupe de 4 instructions (je pars du principe que les 2 branchements appartiennent au meme thread, il n y a pas de difficulte technique specifique a predire 2 branchements par cycle dans 2 threads differents).
    C'est certainement facile de determiner combien d instructions (ou micro inst pour les x-86) sont necessaires pour avoir un % non negligeable d'occurences de 2 branchements qui justifierait le cout d'implementer un tel mecanisme.
    fefe - Dillon Y'Bon

  19. #199
    Je vote pour gourage quelque part...
    Autant pour Bulldozer on pourrait imaginer, mais pour une archi comme Bobcat qui décode 2 instructions X86 par cycle ça semble difficile...

    En fait je n'arrive même pas à imaginer un cas où ça ait un intérêt pour cette archi...
    Du genre, on l'a optimisé à mort pour les switch-case avec 15 sauts successifs pas pris.

    Sinon, Peg, tu as prévu un compte-rendu de Hot Chips?
    Autant les infos sur Bulldozer et Bobcat on les retrouve un peu partout, autant d'autres trucs qui m'ont l'air intéressants comme la présentation de Xilinx sur les hybrides FPGA+SoC sont totalement ignorés...
    Dernière modification par Møgluglu ; 30/08/2010 à 22h04.

  20. #200
    On peut espérer que RealWorld Tech ponde quelque chose… mais en général ils prennent leurs temps.

  21. #201
    Citation Envoyé par Møgluglu Voir le message
    Autant les infos sur Bulldozer et Bobcat on les retrouve un peu partout, autant d'autres trucs qui m'ont l'air intéressants comme la présentation de Xilinx sur les hybrides FPGA+SoC sont totalement ignorés...
    Bah forcément, les journalistes ils captent à peine quelques mots sur les archis de CPU (merci P&H) alors va parler de FPGA Ca me rappelle la première fois que j'ai entendu parler de bidule reconfigurable ; c'était dans Byte il y a 15-20 ans ; ça c'était de la revue grand public mais pointue.

  22. #202
    Citation Envoyé par newbie06 Voir le message
    Bah forcément, les journalistes ils captent à peine quelques mots sur les archis de CPU (merci P&H) alors va parler de FPGA Ca me rappelle la première fois que j'ai entendu parler de bidule reconfigurable ; c'était dans Byte il y a 15-20 ans ; ça c'était de la revue grand public mais pointue.
    Justement, à ce sujet, une excellente façon d'appréhender le fonctionnement d'un CPU est bien de l'émuler en FPGA. J'hésite à écrire un truc la dessus en me basant sur le core Zet (http://opencores.org/project,zet86) que j'ai testé récemment. C'est vraiment passionnant les FPGA, même si la consommation en portes et en jus augmente exponentiellement avec la complexité du moteur HW que tu y implémente.

  23. #203
    Citation Envoyé par Doc TB Voir le message
    Justement, à ce sujet, une excellente façon d'appréhender le fonctionnement d'un CPU est bien de l'émuler en FPGA. J'hésite à écrire un truc la dessus en me basant sur le core Zet (http://opencores.org/project,zet86) que j'ai testé récemment.
    Je connaissais pas, ça a l'air sympa. (À part que c'est du x86... )

    C'est vraiment passionnant les FPGA, même si la consommation en portes et en jus augmente exponentiellement avec la complexité du moteur HW que tu y implémente.
    J'imagine que c'est pas spécifique au FPGA, et que ça se passerait pareil si tu essayais de synthétiser un ASIC comme un seul bloc sans t'occuper du layout...

    Même quand le placement-routage est automatique, dès que ça commence à devenir un peu gros, il faut réfléchir à l'architecture globale, comment limiter la longueur du routage et le fanout, s'il faut distribuer ou répliquer le contrôle, etc.
    Sinon on se retrouve vite avec une machine à états dans un coin dont la sortie à un fanout de 10000 et fait 3 fois le tour du FPGA...

  24. #204
    Citation Envoyé par Doc TB Voir le message
    Justement, à ce sujet, une excellente façon d'appréhender le fonctionnement d'un CPU est bien de l'émuler en FPGA. J'hésite à écrire un truc la dessus en me basant sur le core Zet (http://opencores.org/project,zet86) que j'ai testé récemment. C'est vraiment passionnant les FPGA, même si la consommation en portes et en jus augmente exponentiellement avec la complexité du moteur HW que tu y implémente.
    Pourquoi ne pas plutôt parler d'OpenRISC ? Enfin quel que soit ton choix, c'est un article que j'aimerais vraiment lire

  25. #205
    Pour vous répondre, et oui, je suis grave à la bourre, désolé. En fait comme le disait newbie06, mes connaissances ont des limites, et en matière de FPGA c'est ... bah que dalle. En plus, il faut bien comprendre que mon lectorat, bah ça l'intéresse pas vraiment.

    Maintenant j'ai les quelques présentations en question en PDF, elles seront pas disponibles publiquement avant 6 mois donc je veux pas les uploader comme ça, ceci dit je peux vous les filer en PM.

    Et sinon, David Kanter n’est vraiment pas comme je l'aurais imaginé (RWT).
    Dernière modification par PeGGaaSuSS ; 07/09/2010 à 11h30.

  26. #206
    Citation Envoyé par PeGGaaSuSS Voir le message
    Et sinon, David Kanter n’est vraiment pas comme je l'aurais imaginé (RWT).
    Wabon? C'est pas lui, alors? :

  27. #207

  28. #208
    Je viens de percuter que PeGGaaSuSS = Florian Vieru ! :D

  29. #209
    L'actualité est morne pour les boîtes fabless. Pendant qu'Intel fait le malin avec ses transistors Tri-Gate et vend des palettes de Sandy Bridge, ils en sont réduits à attendre que le 28nm de TSMC soit disponible en production de volume.

    Une seule solution pour faire rêver le geek en attendant : montrer leur grosse farm de simulation.
    VIA/Centaur : http://www.anandtech.com/show/4332/v...-gets-bigger/2
    NVIDIA : http://blogs.nvidia.com/2011/05/snea...emulation-lab/

    Shocking : ça tourne avec des processeurs Intel.

    J'ai l'impression que NV privilégie l'approche brute-force en simulant surtout du RTL, et investit moins dans le développement de modèles niveau cycle…

    Sinon, si on suppose qu'on a déjà le code RTL, c'est si difficile que ça de le synthétiser sur une grosse grille de FPGA ? Vu le prix des machines qu'ils montrent, ça devrait valoir le coup ?
    [Edit: en fait si, en relisant le truc c'est ce que NV fait et c'est ça qui est caché dans les boîtes noires de Cadence ?]

    Ou alors on a besoin de plus d'infos que juste le timing, par exemple l'énergie, et c'est plus facile à modéliser en soft ?
    Dernière modification par Møgluglu ; 17/05/2011 à 12h12.

  30. #210
    Citation Envoyé par Møgluglu Voir le message
    Shocking : ça tourne avec des processeurs Intel.
    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.

    J'ai l'impression que NV privilégie l'approche brute-force en simulant surtout du RTL, et investit moins dans le développement de modèles niveau cycle…
    L'investissement en développement pour écrire un modèle "cycle accurate" est juste énorme dès que ta micro-architecture est un peu compliquée, et plus tu augmentes ta précision, plus ton modèle est lent (genre quelques kHz). Donc aucun intérêt, si tu veux un minimum de précision dans tes mesures.

    Sinon, si on suppose qu'on a déjà le code RTL, c'est si difficile que ça de le synthétiser sur une grosse grille de FPGA ? Vu le prix des machines qu'ils montrent, ça devrait valoir le coup ?
    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).

    Ou alors on a besoin de plus d'infos que juste le timing, par exemple l'énergie, et c'est plus facile à modéliser en soft ?
    C'est toujours pareil : ça dépend si tu veux du précis, ou une approximation. Pour du précis, tu n'as pas le choix, il faut faire des simulations très bas niveau de ton RTL (avec des modèles spice par exemple).

    En résumé, toutes les approches (simulation soft, simulation RTL, émulateur, FPGA) sont utilisées (je dirais même doivent être utilisées pour être le plus efficace possible) par tout le monde à divers degrés selon les stades de développement. Donc toutes les boites qui font du design un peu ambitieux ont des gros clusters, des émulateurs, des grilles de FPGA et des stations de travail

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
  •