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

Discussion: Micro-Architecture

  1. #91
    Très instructif !
    Mes propos n'engagent personne, même pas moi.

  2. #92
    Oui, très intéressant. Merci.

  3. #93
    Citation Envoyé par fefe Voir le message
    Le choix pour les fabriquants de cpus a ete assez simple quand ils ont reussi a se convaincre que les gens du soft allaient ecrire des threads.
    Ha c'est marrant je voyais plutot ca dans l'autre sens : les gens du hard n'y arrivaient plus, et ont montre qu'en mettant plusieurs coeurs ca revenait moins cher, ca consommait moins, etc.
    Maintenant il faut que les programmeurs s'habituent au multithreading et Intel est meme oblige de mettre des tutoriaux sur son site.

    La verite se trouve surement entre ton point de vue et le mien

  4. #94
    Vous dites un peu la même chose, non ? Grosso modo.

  5. #95
    Moui tu as raison, j'avais lu un peu trop vite, faut dire que sa phrase etait plutot trop subtile pour un mec en manque de cafeine

  6. #96
    Ma phrase ne disait pas comment ils avaient reussi a se convaincre , donc n'exprimait pas d'opinion. En disant aux gens du soft que ca leur reviendrait moins cher et que ca consommerait moins... Apres avoir tape dans le mur du power...

    Et c'est faux de dire que les gens du hard n'y arrivaient plus (ils en chient, mais ils y arrivent encore, merci l'huile de ricin). Si on utilise un core2 en reference il y a encore une bonne marge d'IPC que l'on sait extraire dans des machines frabriquables aujourd'hui(>2x), mais est que ces machines interesseraient les marches auquels elles sont destinees, les reponses qu'ont choisi AMD et Intel semblent assez evidentes (c'est AMD qui a commence la course au nombre de cores a l'origine, et est parfaitement comprehensible car leurs equipes de dev sont nettement plus reduites qu'Intel) et ont clairement une raison economique derriere.

    Au final on sait toujours comment faire des CPUs plus performants sur des applis single thread, probablement pas avec une progression aussi rapide qu'auparavant mais pas loin. En revanche et ce pour des raisons de couts, c'est la premiere fois dans l'histoire des microprocesseurs "grand public" que la capacite a progresser a ete rejetee sur le software.

    J'ai toujours pense que c'etait une erreur de passer brutalement d'une direction a l'autre, sachant qu'on ne formerait pas tous les informaticiens du monde a ecrire des threads en moins d'une generation... Apres la periode plus de GHz c'est mieux, il y a la periode plus de cores c'est mieux, on verra surement arriver d'autres metriques plus c'est mieux .
    fefe - Dillon Y'Bon

  7. #97
    Ouch, mal à la tête un peu pour avaler tout ça :/

    En y pensant, est-ce que ce n'est pas cette même logique qui a initié NetBurst ?
    Plutôt que d'améliorer l'IPC des P3 - qui aurait pû leur sembler très couteux à l'époque, suivant ce que tu détailles -, ils ont préféré partir sur ce qui a été montré également dans le forum - à savoir qu'à ~ 5 - 6GHz, et avec un pipeline ~55 étages, on était au maxiumm théorique de perfs - ...
    Dernière modification par Lissyx ; 22/05/2008 à 15h28.

  8. #98
    Citation Envoyé par fefe
    [...] c'est la premiere fois dans l'histoire des microprocesseurs "grand public" que la capacite a progresser a ete rejetee sur le software.

    J'ai toujours pense que c'etait une erreur de passer brutalement d'une direction a l'autre, sachant qu'on ne formerait pas tous les informaticiens du monde a ecrire des threads en moins d'une generation... Apres la periode plus de GHz c'est mieux, il y a la periode plus de cores c'est mieux, on verra surement arriver d'autres metriques plus c'est mieux .
    Tout à fait... c'est une erreur soulevée par bien des codeurs. Même les algos qui se parallélisent assez bien (peu/pas de dépendance entre les données traitées etc.) ont un scaling qui s'écrase qd on monte en nombre de threads. Il est parfois possible d'améliorer tout ça mais le travail et l'investissement (temps, argent etc.) n'est clairement pas le même.

  9. #99
    Citation Envoyé par Lissyx Voir le message
    Ouch, mal à la tête un peu pour avaler tout ça :/

    En y pensant, est-ce que ce n'est pas cette même logique qui a initié NetBurst ?
    Plutôt que d'améliorer l'IPC des P3 - qui aurait pû leur sembler très couteux à l'époque, suivant ce que tu détailles -, ils ont préféré partir sur ce qui a été montré également dans le forum - à savoir qu'à ~ 5 - 6GHz, et avec un pipeline ~55 étages, on était au maxiumm théorique de perfs - ...
    Effectivement netburst etait parti dans ce sens, mais avait oublie de mettre le power dans l'equation.
    fefe - Dillon Y'Bon

  10. #100
    Citation Envoyé par fefe Voir le message
    Effectivement netburst etait parti dans ce sens, mais avait oublie de mettre le power dans l'equation.
    Oublié, ou se sont fait avoir en ayant supputé qu'ils trouveraient la solution d'ici là ?

  11. #101
    Citation Envoyé par Lissyx Voir le message
    Oublié, ou se sont fait avoir en ayant supputé qu'ils trouveraient la solution d'ici là ?
    Ya eu ça et le fait que ce n'est pas facile de calculer une dissipation.
    Mes propos n'engagent personne, même pas moi.

  12. #102
    Citation Envoyé par Lissyx Voir le message
    Oublié, ou se sont fait avoir en ayant supputé qu'ils trouveraient la solution d'ici là ?
    Option 1, a l'epoque personne ne voyait venir le probleme de limites a cause du power. Les premiers papiers de recherche parlant d'optimiser le ratio profondeur du pipeline/performance en tenant compte du power sont arrives plus de 5 ans apres le developpement de l'archi de P4, et ont ete ecrits essentiellement apres avoir observe ce qui se passait avec P4.

    Cela ne veut pas dire que aucune attention n a ete apportee au Power lors du developpement de P4 loin de la le P4 ayant ete un des premiers CPUs Intel employant de maniere extensive le clock gating, mais ce n'etait pas dans l'equation originale qui determinait la profondeur du pipeline/frequence en fonction de la perf voulue.
    fefe - Dillon Y'Bon

  13. #103
    Un slide presente a ISCA cette annee montrant la chronologie d'un projet de developpemmt d'un CPUs chez Intel, et pourquoi de nouvelles "features" mettent 5 ans a arriver.
    fefe - Dillon Y'Bon

  14. #104
    Explications très intéressantes comme toujours, je comprend mieux pourquoi les architectures multicores parraissent beaucoup plus attirantes, même si l'investissement pour les développeurs n'est pas négligeable, il semblait en effet beaucoup plus logique de s'orienter vers de telles architectures plutôt qu'un super CPU à la consomation délirante...

    D'ailleurs à se sujet j'ai fait 2-3 recherches et je me suis apperçu que certains avaient tenté l'aventure notamment les équipes "Ex" Digital/Compaq/HP avec l'architecture Alpha et l'EV8 (qui ne sortira jamais) ce processeur visiblement suivait la même logique que ces prédécesseurs avec un pipeline toujours plus large et probablement une OOO monstrueuse, visiblement cette dernière ne suffisant pas ou n'étant pas assez performantes (pure spéculation de ma part) l'EV8 était également capable de gérer pas moins de 4 threads simultanément (problablement du SMT) sans doute une technique pour permettre d'augmenter le taux d'occupation des unitées de calculs en nombre assez impressionant pour le coup... évidement tout ceci avait pour conséquence une consomation délirante de 250 W à 1.2 V en 0.13 µm, un espèce de "dinosaure" en quelque sorte une anomalie de la nature... n'empêche j'aurais bien voulu voir la bestiole tourner...
    "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

  15. #105
    Citation Envoyé par EPIC Voir le message
    D'ailleurs à se sujet j'ai fait 2-3 recherches et je me suis apperçu que certains avaient tenté l'aventure notamment les équipes "Ex" Digital/Compaq/HP avec l'architecture Alpha et l'EV8 (qui ne sortira jamais) ce processeur visiblement suivait la même logique que ces prédécesseurs avec un pipeline toujours plus large et probablement une OOO monstrueuse, visiblement cette dernière ne suffisant pas ou n'étant pas assez performantes (pure spéculation de ma part) l'EV8 était également capable de gérer pas moins de 4 threads simultanément (problablement du SMT) sans doute une technique pour permettre d'augmenter le taux d'occupation des unitées de calculs en nombre assez impressionant pour le coup... évidement tout ceci avait pour conséquence une consomation délirante de 250 W à 1.2 V en 0.13 µm, un espèce de "dinosaure" en quelque sorte une anomalie de la nature... n'empêche j'aurais bien voulu voir la bestiole tourner...
    L'EV8 aurait ete tres performant, DEC a juste coule avant que le projet n'arrive a terme (l'EV7 etait tres en retard et est arrive juste avant qu'ils vendent leur departement d'architecture et toute sa propriete intellectuelle a Intel). La uarchi de l'EV8 avait enormement de points communs avec P4, il etait juste plus "gros" et plus aggressif et aurait probablement ete vendu entre la periode Northood et Prescott. Et plus gros que P4 avec des similarites, forcement ca degageait de l'energie, mais ce n'est pas ca qui a tue le projet.
    fefe - Dillon Y'Bon

  16. #106
    Citation Envoyé par fefe Voir le message
    forcement ca degageait de l'energie, mais ce n'est pas ca qui a tue le projet.
    Oui oui on est daccord la dessus... c'est bien malheureux en tous cas, car il y avait vraiment du savoir faire dans les équipes de DEC ! il y avait aussi le projet "piranhna" également qui me fait inévitablement pensé à l'Ultrasparc T1/T2 (Niagara) de chez SUN... Elles sont partis où les équipes de chez DEC maintenant ? chez Intel pour l'essentiel (équipes travaillant sur l'Itanium il me semble) non ?
    "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

  17. #107
    Citation Envoyé par EPIC Voir le message
    Oui oui on est daccord la dessus... c'est bien malheureux en tous cas, car il y avait vraiment du savoir faire dans les équipes de DEC ! il y avait aussi le projet "piranhna" également qui me fait inévitablement pensé à l'Ultrasparc T1/T2 (Niagara) de chez SUN... Elles sont partis où les équipes de chez DEC maintenant ? chez Intel pour l'essentiel (équipes travaillant sur l'Itanium il me semble) non ?
    Piranha etait un CMP qui visait le meme marche que Niagara, mais sans multiflot simultane. Piranha etait plus une exploration dans les methodes de design que destine a devenir un produit. L'equipe complete comprenait une 12aine de personnes, et tout etait base sur la reutilisation de blocs deja designes dans la compagnie (le core etait un bloc qui existait deja par exemple). C'etait une preuve que l'on pouvait faire un CPU avec une tres petite equipe et de l'automatisaytion. En effet DEC etait specialise dans le full custom design optimise a mort a la main, etca demandait de (trop) grosses equipes tres experimentees.

    La ou Piranah etait vraiment novateur est que l'accent avait ete mis sur le sous systeme memoire/reseau d'interconnection/plateforme plus que sur le core ce qui commence juste a etre le cas sur les x86 et autres. Bien entendu le marche et les applications vises etaient demandeurs (et Sun l'a exploite quelques temps apres que Piranha ait ete tue avec Niagara).

    Sinon pour la petite histoire EV8 s'appelait Aranha et son coprocesseur vectoriel Tarantula. DEC aimait les animaux dangereux .

    Les equipes se sont reparties chez differents constructeurs. Une partie de l'equipe Piranha a fini chez Google, le reste dans diverses startups et qui ont poursuivi dans diverses boites faisant des network processors. Une partie de l'alpha team est alle chez AMD importer l'uncore de l'EV7 pour le K7 et ca a donne le K8. Ceux qui bossaient sur EV8 et qui ne sont pas partis lors du rachat de la division par Intel sont restes avec Intel a faire de la recherche, de l'Itanium et des cpus pour serveurs x86.
    fefe - Dillon Y'Bon

  18. #108
    Tarantula, oui c'est vrai je l'avais oublié celui là... ça tape bien comme nom de code ! Merci Féfé pour toutes ces précisions !
    "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

  19. #109
    Performance Modeling and Analysis at AMD: A Guided Tour
    http://www.ispass.org/ispass2007/keynote2.pdf

    Une presentation interressante sur la methodologie d'analyse de performance d'AMD.
    fefe - Dillon Y'Bon

  20. #110
    ça date pas un peu (dixit le Phenom 1ere gen).


  21. #111
    Un peu mais ca n'en reste pas moins interressant.
    fefe - Dillon Y'Bon

  22. #112
    100K+400K lignes de code pour leur simu niveau cycle, moi qui étais tout fier d'avoir pissé 20K lignes en 3 mois pour un simu à moi, je me sens tout petit.
    Mais bon ça me semble pas choquant non plus pour un core de K10 au niveau cycle + uncore au niveau transaction, j'aurai même imaginé plus.

    Sur le slide 24 (Detailed Small-scale MP), ils disent en gros qu'il n'ont pas de solution générale précise pour simuler les interactions et la cohérence entre coeurs, à part simuler tout le core+uncore (+OS?) au niveau cycle?...

  23. #113
    Citation Envoyé par Møgluglu Voir le message
    100K+400K lignes de code pour leur simu niveau cycle, moi qui étais tout fier d'avoir pissé 20K lignes en 3 mois pour un simu à moi, je me sens tout petit.
    Mais bon ça me semble pas choquant non plus pour un core de K10 au niveau cycle + uncore au niveau transaction, j'aurai même imaginé plus.
    Ca me parait aussi assez peu a moi, mais pas deraisonnable pour un tel processeur.

    Sur le slide 24 (Detailed Small-scale MP), ils disent en gros qu'il n'ont pas de solution générale précise pour simuler les interactions et la cohérence entre coeurs, à part simuler tout le core+uncore (+OS?) au niveau cycle?...
    Peut-etre est-ce parce que si tu n'es pas vraiment tres precis tu ne vas rien valider et en plus avoir des chiffres de perf completement faux ?

    Quand tu pousses un design multi coeur a fond, tu vas t'amuser a reordonner ce qui peut l'etre a tous les niveaux, et pour que tout cela reste semantiquement correct, il faut que tous ces niveaux fassent les choses proprement. Un cycle de decalage et tout peut tomber. Donc si tu n'es pas precis, tu testes/mesures n'importe quoi.

  24. #114
    Sur le slide 24 (Detailed Small-scale MP), ils disent en gros qu'il n'ont pas de solution générale précise pour simuler les interactions et la cohérence entre coeurs, à part simuler tout le core+uncore (+OS?) au niveau cycle?...
    Je comprends pas le simuler ? Il y a les cache L3 pour la cohérences des autres cores ou ça ne suffit pas ?

    EDIT : j'avais pas vu qu'il parlait d'une plateforme MP. Dans ce cas là c'est assez différents.


  25. #115
    Citation Envoyé par lordmagnum Voir le message
    Je comprends pas le simuler ? Il y a les cache L3 pour la cohérences des autres cores ou ça ne suffit pas ?
    Même en passant par le cache L3, ce que dit newbie s'applique : il faut que la simu de tous les coeurs soit parfaitement synchrone au cycle près.
    Si par exemple le coeur 1 écrit une donnée au cycle n dans son cache, que ça invalide la copie du coeur 2 au cycle n+10, suivant que le coeur 2 tente de lire cette valeur au cycle n+9 ou bien n+11, ça pourra avoir une influence importante sur la suite de l'exécution.

  26. #116
    Un gros cache L3 externe inclusif ne pourrait par régler ça ? Exemple les données en cache dans chaque CPU sont directement copiées dans ce cache externe, comme ça les CPU n'auront à faire des demandes aux autres et attendre plusieurs cycles, ils auront juste à ce servir dans ce cache qui devrait avoir une taille conséquente.


  27. #117
    Je crois que tu n'as pas compris de quoi nous parlons

    On parle de simuler avec un programme un processeur existant, ou a venir, de maniere suffisamment precise pour savoir si 1. ca fonctionne, 2. ca aura de bonnes performances. On n'essaie pas de trouver une micro-architecture particuliere.

    Dans ce cadre-la, quels que soient tes choix de micro-architecture, si l'ensemble du traffic entre les composants (L3 ou autres) n'est pas simule au cycle pres, tes mesures n'ont potentiellement aucun sens.

    J'espere que j'ai ete plus clair, mais je ne suis pas sur

  28. #118
    Tu n'es pas oblige d'avoir tout precis au cycle pres si tes operations de maintien de coherence sur ton cache sont atomiques. Si ce n'est pas le cas et si tu as un delai entre le moment ou tu signales qu'une donnee est observable et le moment ou elle l'est vraiment, la tu es oblige de tout simuler a 1 cycle de precision.

    Pourquoi ne pas avoir tou implemente de maniere atomique ? Les performances du bouzins seraient catastrophiques.
    Au final tu es effectivement oblige d'implementer des pipelines au cycle pres, mais pas tout. De toutes facons dans le hard les latences sont variables vu la quantite de buffers et d'arbitres que tu traverses pour arriver au L3. Par contre lors de la validation il faut generer tous les cas possibles pour verifier que rien ne casse ton modele de coherence.

    A ce moment la soit tu implementes tout au cycle pres comme le RTL, soit ton modele de performance est modulaire et tu peux le forcer a generer toutes ces configurations de latences que le RTL peut generer mais tes traces ne couvrent pas (tu insere effectivement des latences random dans ton simulateur et les utilise pour augmenter le coverage de tes tests).

    Au final j'etais decu, leur modele une fois correle n'est pas si precis que ca , meme si abs 2-3% c'est pas mal .

    Ca manque aussi un peu de details sur le modele du chipset et du graphique mais le fait que ca date de 2007 n'y est probablement pas pour rien.

    Sinon j'ai trouve la taille de leur infrastructure tres raisonable, arriver a garder une base de code si petite est bon signe sur la qualite de leur simulateur .
    fefe - Dillon Y'Bon

  29. #119
    Merci pour l'explication.

    Citation Envoyé par fefe Voir le message
    Au final j'etais decu, leur modele une fois correle n'est pas si precis que ca , meme si abs 2-3% c'est pas mal .
    Leur métrique, c'est la différence observée de temps d'exécution de fenêtres de 1000 instructions entre leur simu et le RTL? Horizontalement c'est quoi qui est représenté sur leur courbe?

    Ca manque aussi un peu de details sur le modele du chipset et du graphique mais le fait que ca date de 2007 n'y est probablement pas pour rien.
    Ça m'aurait intéressé aussi.
    Mais je suppose que encore aujourd'hui la division processeurs et l'ex-ATI des chipset et GPU se basent toujours principalement chacun sur leurs propres outils (the future is Fusion, qu'ils disaient... )

  30. #120
    Citation Envoyé par Møgluglu Voir le message
    Merci pour l'explication.



    Leur métrique, c'est la différence observée de temps d'exécution de fenêtres de 1000 instructions entre leur simu et le RTL? Horizontalement c'est quoi qui est représenté sur leur courbe?
    Sur ce genre de courbes x peut etre 2 choses:
    - soit chaque point represente une application differente (et en general tu tries par correlation croissante ou decroissante). Vu la legende ce n'est pas le cas.
    - soit c'est le temps: tu fais tourner une regression chaque mois et tu regardes ou tu en es. A priori c'est le cas ici. Tu demarres avec 20% de mauvaise correlation et au fur et a mesure de tes efforts pour corriger le modele tu converges vers un degre de correlation (qui est en general fixe par le management).

    Y ici est la moyenne de la valeur absolue de l'ecart (%) entre leurs simulations RTL et simulations de performances sur un ensemble de tests courts.

    Ça m'aurait intéressé aussi.
    Mais je suppose que encore aujourd'hui la division processeurs et l'ex-ATI des chipset et GPU se basent toujours principalement chacun sur leurs propres outils (the future is Fusion, qu'ils disaient... )
    CPU+GPU c'est super dur a faire sans avoir un modele ou tu emules tout, y compris l'OS. Les interactions entre le GPU et le CPU sont assez complexes et tres dynamiques donc impossibles a mettre dans une trace que tu ne fais que rejouer. Bien entendu rien n'empeche de combiner le modele de CPU et le modele de GPU ensemble, mais ca restera assez loin de la realite tant que le comportement dynamique de l'OS et de l'appli et de la stack de driver n'est pas modelise. C'est un cauchemard, et je suis dedans jusqu'aux oreilles.
    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
  •