Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 15 sur 19 PremièrePremière ... 578910111213141516171819 DernièreDernière
Affichage des résultats 421 à 450 sur 567

Discussion: Intel et Larrabee

  1. #421
    voila, le pixel shading represente grosso modo 70% de la charge de travail que tu as a faire... Si tu ne le fais plus en x86, ben c'est fini.
    fefe - Dillon Y'Bon

  2. #422
    Citation Envoyé par newbie06 Voir le message
    Bah suffisait de coller des unités dédiées au pixel shading, des dizaines/centaines à la nVidia/AMD et avec leur propre jeu d'instruction parce que forcément des décodeurs x86 c'est un peu gros.
    Tu as certainement raison, mais l'argument de la taille des décodeurs est pas valable...
    Un GF100 "fetche" et décode 32 instructions Fermi par cycle à 700 MHz.
    Un Westmere (Gulftown) fetche 36 instructions x86, en décode 24 pour produire 42 µop par cycle à 3,3 GHz.

    Le débit du front-end n'est pas vraiment un problème dans un GPU...

    Après, x86 est tout sauf adapté à du calcul sur GPU, mais c'est un autre problème.

  3. #423
    Le problème n'est pas le débit du FE, mais la taille que tu lui accordes. Je peux t'assurer qu'un décodeur avec un jeu d'instructions simple peut être vraiment petit (et tu n'auras pas de chemin critique dedans). C'est quoi la taille d'un décodeur Westmere ? Qu'aurais-tu pu faire avec ces 24 décodeurs ? Avais-tu besoin de toutes les instructions complexes x86 ?

    Enfin bref, comme tu dis l'ISA x86 n'étant pas adaptée, pour augmenter l'efficacité il aurait probablement fallu ajouter de la fonctionnalité (ça c'est pas un problème) et surement supprimer d'autres choses complètement inutiles et coûteuses, et là ce n'était plus compatible x86, donc plus du tout le concept fondamental du projet.

    Bref x86 caca.

    PS - On peut troller le week-end, hein ?

  4. #424
    Je ne vois pas de troll, pourtant c'est le weekend . Je ne pense pas qu'il y ait grand monde qui ait besoin d'etre convaincu que le x86 est un jeu d'instruction merdique . Larrabee tentait de compenser le manque de debit en instruction par des vecteurs larges, et honnetement, pour tout ce qui est pixel shading je ne vois pas de raisons que ca ne fonctionne pas avec le jeu d'instruction qu'ils ont publie. Certes quand les vecteurs ne sont pas denses le debit tombe, mais ce n'est pas comme si les GPU actuels n'avaient aucun probleme avec ca non plus.

    Augmenter l'isa n'est pas particulierement un probleme , sauf quand ce que tu veux faire ce sont des operations de longue latence tres pipelinees et que tu ne veux pas qu'elles soient bloquantes. Oui ca grossit les decodeurs, mais honetement un frontend x86 de pentium n'est vraiment pas gros et ne consomme vraiment pas beaucoup.... quel pourcentage du die (et du power) les decodeurs d'une archi simple (sans tout ce qui est lie aux branchements qui fera la meme taille) prennent ils ? 0.5%, 1% ? Ca te laisse de la marge, surtout quand derriere tu as 16 FMA simple precision et plusieur centaines de ko de cache.
    Bien entendu quand tu chasses les mW pour tenir dans une enveloppe tres faible c'est un probleme, mais quand tu as 200+W de budget, meme si tu mets 50 cores ce n'est pas la fin du monde.
    Si tu parts du principe que ce qui est dit dans cet article est vrai, tu n'arrivera pas a construire un Larrabee-like quel que soit l'ISA que tu emploies tant que tu parts d'un microprocesseur generique. L'ISA n'y est pour rien, le modele d'execution, lui oui.
    fefe - Dillon Y'Bon

  5. #425
    Ca me fait penser à quelque chose, attention question de newbie... Ne peut-on pas gagner en surface en pipelinant ? J'imagine qu'il y a un threshold au-delà duquel trop de pipelining augmente la surface à cause de la filasse, mais je me dis qu'on peut gagner en surface si on n'augement pas trop la profondeur. Faux ?

  6. #426
    Vrai, pour les unités de calcul, c'est ce que font Nvidia avec leurs shaders SP CUDA Cores double vitesse. Après, il y a bien sûr un seuil à partir duquel ce n'est plus rentable.
    Les x86 OoO sont largement au-delà de ce seuil.

    Je dirais plus à cause de la difficulté d'équilibrer des étages très courts qui fait qu'on se retrouve à devoir réduire la latence de certaines opérations faute de savoir les diviser. Ce qui pénalise la surface et la conso.

    Ceci en plus du surcoût des latches supplémentaires, de la difficulté de distribuer l'horloge, etc.

  7. #427
    Citation Envoyé par fefe Voir le message
    Pas particulierement difficile a faire dans une architecture dediee comme un GPU, particulierement impossible a integrer a un multicore classique qui n'accepte des fonctions dediees que comme un comme un coprocesseur accessible par MMIO.
    Soit, je peux pas partir d'un multicore et le spécialiser pour le rendu. Mais si on prend le problème dans l'autre sens, est-ce qu'on pourrait partir d'un rasterizer de GPU et le généraliser à d'autres applis avec dépendances producteur-consommateur?
    Les googleries genre MapReduce, ça ne ressemble pas vaguement à ça?

    Ou bien c'est juste un problème spécifique aux API graphiques et leur contraintes sur l'ordre de traitement des primitives?...

    ...C'était le délire "J'ai une solution et je cherche un problème..."

    Sinon je vais donner un Larrabee à faire à mes étudiants cette année, on va bien voir ce qu'il en sort.
    (mais pour du rendu 2D seulement...)

  8. #428
    Tu me diras a quel type d'IPC tu arrives dans ta rasterization.

    Pour ce que tu proposes, la question a laquelle repondre est la meme que pour la proposition inverse. A quel niveau relatif a une archi prevu pour tu arrives ? Ce niveau est-il acceptable.

    Personne n'a dit que Larrabee n'etait pas fonctionnel, juste qu'il n'etait pas competitif. 20%, 2x, 10x, 100x plus lent, quel est ton objectif ?
    Si tu demandes 20% je peux te donner la reponse a ta proposition: tu ne peux pas (je pars du principe que tu regardes plus d'1 appli), 10x tout a fait faisable. Le probleme est que pour tout ce qui est au milieu c'est beaucoup plus difficile de repondre. En fait je dirais impossible sans venir avec une proposition d'implementation detaillee.

    La reponse n'est pas plus facile que celle de Larrabee, et ca a pris a Intel des ressources assez impressionantes pour reussir a venir avec un element de reponse solide.
    fefe - Dillon Y'Bon

  9. #429
    Citation Envoyé par fefe Voir le message
    ca a pris a Intel des ressources assez impressionantes pour reussir a venir avec un element de reponse solide.
    Le problème est que vu du dehors après coup la réponse paraît tellement évidente qu'on se demande bien comment cela a pu durer aussi longtemps.

  10. #430
    La reponse parait simple mais elle ne l'est pas. Intel savait certainement qu'il y avait un desavantage a faire en soft tout ce que les GPU font en hardware. En moyenne Intel a 1/2 process d'avance sur la competition et 10% de voltage (ou plus suivant le competiteur). Ca te fait en gros un avantage de 30-40% de perf/power sur le reste de la competition a design equivalent. Apres tu peux etre 30-40% moins efficace pour faire la meme chose et ca a pris pas mal de temps pour se rendre compte que c'etait plus de 40%...
    C'est un peu ce que je disais a Mogluglu pour sa suggestion inverse, quel est l'objectif ? Etre plus rapide ? Meme pas la peine d'essayer, etre 10x moins rapide, faisable...

    Si ce que tu rends possible avec ton archi est suffisament interressant tu peux contrebalancer une certaine perte de perf. Pour savoir exactement combien il faut le construire et ecrire le soft. Rien n'est noir et blanc.
    fefe - Dillon Y'Bon

  11. #431
    Ça fait quand-même très peur vu comme ça. Une boîte comme Intel est capable d'investir des pata-millions de dollars et des zigo-années-hommes d'ingénieurs juste pour parvenir à une réponse comme oui, non ou 42.

    Le CERN et Intel, même combat.

    (sauf qu'Intel eux ils font des benefs record...)

  12. #432
    L'ampoule n'a pas ét inventé en améliorant la bougie (c) Frank
    Mes propos n'engagent personne, même pas moi.

  13. #433
    Citation Envoyé par Møgluglu Voir le message
    Ça fait quand-même très peur vu comme ça. Une boîte comme Intel est capable d'investir des pata-millions de dollars et des zigo-années-hommes d'ingénieurs juste pour parvenir à une réponse comme oui, non ou 42.

    Le CERN et Intel, même combat.

    (sauf qu'Intel eux ils font des benefs record...)
    Justement... Soit dit en passant, ils prouvent que la recherche pure (pour ne pas dire fondamentale) peut *aussi* fonctionner sur fonds privés.

  14. #434
    Ouais enfin entre Larrabee et la recherche fondamentale, il y a quand-même de la marge...

    Je vois pas ce qu'il y a dedans qu'on n'aurait pas su faire il y a 15 ans. Peut-être des trucs subtils dans l'interconnect et les protocoles de cohérence qui ne sont pas publics, mais dans l'ensemble ça reste un processeur in-order de 1995 avec des unités SIMD et du multi-core...
    Ça fait très "bougie perfectionnée" justement.

    Comme machines parallèles, les stream processors à la Bill Dally semblent bien plus convaincants... :vend son truc:

  15. #435
    La seule cjose qui n'ait pas 15 ans est le SMT et les unites de Texture le controleur memoire integre, le cache numa... .
    fefe - Dillon Y'Bon

  16. #436
    Petit déterrage, pour la publication de l'ISA de Knights Corner.

    C'est marrant, avec toutes les conversions avec des formats virgule fixe et les descriptions du genre « cette instruction elle sert à scaler les coordonnées u et v pour sampler les mipmaps », leur jeu d'instruction MIC juste-pour-le-HPC il ressemble quand-même vachement à celui d'un GPU.

    L'encodage des instructions fait toujours pleurer, mais ça c'est normal... Après saturation de l'espace des opcodes, va-t-on bientôt arriver à saturation de l'espace des mnémoniques ? (comment appeler les prochains registres SIMD après mm, xmm, ymm et zmm ? VCVTFXPNTPS2DQ, ça fait quoi déjà ?...)
    Dernière modification par Møgluglu ; 06/06/2012 à 19h52.

  17. #437
    Citation Envoyé par Møgluglu Voir le message
    VCVTFXPNTPS2DQ, ça fait quoi déjà ?...)
    J'ai cru à une connerie, recherche google, 1 seul résultat, le lien vers le PDF en question

  18. #438
    Cela dit, celui-là n'est pas si dur à parser avec un peu d'habitude : Vector ConVerT FiXed-PoiNT Packed Single-precision to Doublewords-Quad (*)

    (*) Le Q doit probablement être une convention héritée du temps de SSE où les registres faisaient 4×32-bit et où PD était déjà pris pour le type Double...

  19. #439
    Ca donne quoi au niveau des compilateurs un bazar pareil ? Les machins capable de faire un truc convenable de 50+cores existent vraiment ? Ou c'est un truc genre orgie de flops en peak théorique, mais dans la vraie vie on divise par 2 et plus ?

    Sinon, ya pas moyen d'en avoir un, parce que le cluster du taff est surchargé et ça fait mal au coeur un BE qui se pignole juste pour un problème d'encombrement calcul (comme si il avait besoin de ça pour...) ?
    Mes propos n'engagent personne, même pas moi.

  20. #440
    Citation Envoyé par Neo_13 Voir le message
    Ca donne quoi au niveau des compilateurs un bazar pareil ? Les machins capable de faire un truc convenable de 50+cores existent vraiment ? Ou c'est un truc genre orgie de flops en peak théorique, mais dans la vraie vie on divise par 2 et plus ?
    Si j'ai bien compris y'a pas vraiment de parallelisation massive automatique, ca passe par OpenMP et autres trucs similaires.
    Par ailleurs pas de support gcc pour le moment (enfin pour les vecteurs), donc j'imagine que c'est icc et rien d'autre.

  21. #441
    Coucou les gens

    Merci pour l'autorisation. Promis, je serai sage.

  22. #442
    On peut espérer qu'il ont des outils compatibles à diffusion plus restreinte, genre des implémentations de TBB, Cilk, OpenCL, etc.
    Pour le logiciel libre, faudra attendre un peu. Par exemple qu'il y ait un peu plus de MIC en circulation...

    Sinon, histoire de faire de la pub honteuse, c'est les soldes chez CAPSi :
    http://blogs.nvidia.com/2012/06/open...199-from-caps/

  23. #443
    Ha CAPS, ca me rappelle ma jeunesse ca Sauf qu'a l'epoque c'etait pas du multi-coeur, on etait a peine au debut du OoO, me sens vieux tiens. C'est un truc serieux cet OpenACC ? Genre pas OpenRT ?

    ---------- Post added at 16h30 ---------- Previous post was at 16h29 ----------

    Citation Envoyé par vectra Voir le message
    Merci pour l'autorisation. Promis, je serai sage.
    On t'a dit que le tarif d'entree c'etait un access Tesla a tous ceux qui te le demandent ?

  24. #444
    T'es vieux.
    Oui, OpenACC est un truc plutôt sérieux (du moins plus sérieux que les tentatives d'étendre OpenMP pour les many-cores…) C'est le résultat des négociations entre PGI, CAPSi et Cray, parce que 3 langages de directives différents ça faisait désordre. Pathscale devrait suivre.
    Derrière tout ça il y a Nvidia. Ils l'ont annoncé en grande pompe l'an dernier et font régulièrement des campagnes de com comme le 2x in 4 weeks, guaranteed...

  25. #445
    Comme le monde est petit, c'est ce sur quoi mon ancien binome a la fac travaille maintenant si je ne m'abuse .
    fefe - Dillon Y'Bon

  26. #446

  27. #447
    Ouai le gros foutage de gueule : ils veulent faire croire aux gens que c'est un Xeon

    Je vois de moins en moins l'interet du x86 la-dedans vu que ce n'est pas compatible avec les autres x86. Enfin si, il y a un interet pour Intel: kernel plus rapide a porter et ICC qui genere deja du x86 et comme ca en a l'odeur... Mais pour l'utilisateur final quel est l'interet ?

  28. #448
    Citation Envoyé par newbie06 Voir le message
    Je vois de moins en moins l'interet du x86 la-dedans vu que ce n'est pas compatible avec les autres x86. Enfin si, il y a un interet pour Intel: kernel plus rapide a porter et ICC qui genere deja du x86 et comme ca en a l'odeur... Mais pour l'utilisateur final quel est l'interet ?
    Avoir de la concurrence face aux Tesla de Nvidia ? même si on ignore l'argument foireux du x86 et du "100% Intel", ça fait un GPU pour le HPC comme un autre.

  29. #449
    Citation Envoyé par Møgluglu Voir le message
    Avoir de la concurrence face aux Tesla de Nvidia ? même si on ignore l'argument foireux du x86 et du "100% Intel", ça fait un GPU pour le HPC comme un autre.
    Nan mais je comprends bien qu'ils font ce qu'ils savent faire de mieux, mais au final moi je m'en tape que dedans ca soit du x86, ca pourrait aussi bien etre du SPARC, ou du MIPS, ou du ARM, ca ne changerait rien du tout. Je voudrais juste qu'un utilisateur final me dise ce que va lui apporter le x86 ici

  30. #450
    Rien dans l'immédiat, je pense que pour Intel c'est juste une étape avant quelque chose de plus ambitieux. Il leur faudra bien une archi SIMD éprouvée le jour où ils vont tenter de démocratiser le many-core.

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
  •