Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 16 sur 19 PremièrePremière ... 68910111213141516171819 DernièreDernière
Affichage des résultats 451 à 480 sur 567

Discussion: Intel et Larrabee

  1. #451
    Citation Envoyé par Sp1d3r Voir le message
    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.
    Je ne suis pas convaincu que ce type de machines serve pour le grand public : au final peu de soft ont besoin de faire du flottant, en tout cas à ce niveau de perf. Et s'il y avait un tel besoin de perf flottantes, je pense qu'on aurait vu bien plus d'applications GPGPU grand public.

  2. #452
    Citation Envoyé par newbie06 Voir le message
    Je ne suis pas convaincu que ce type de machines serve pour le grand public : au final peu de soft ont besoin de faire du flottant, en tout cas à ce niveau de perf. Et s'il y avait un tel besoin de perf flottantes, je pense qu'on aurait vu bien plus d'applications GPGPU grand public.
    /agree.

    Je ne suis certainement pas a la page, mais cote grand public en dehors du transcodage video (qui est plus efficace avec un accelerateur dedie inclu dans les 2 dernieres generation de CPU Intel entre autre et qui arrive chez AMD), il y a quoi comme Appli qui fasse du GPGPU. Les applis Adobe comme CS5/6, mais je n'ai pas vraiment vu la difference a l'utilisation (et puis Photoshop c'est pas vraiment grand public), quoi d'autre ?
    fefe - Dillon Y'Bon

  3. #453
    De temps en temps, AMD (entre autres) évoque la reconnaissance faciale ou vocale. Mais je ne suis pas entièrement convaincu que ça ait réellement un intérêt pour le grand public non plus.
    Mon blog (absolument pas à jour) : Teχlog

  4. #454
    Citation Envoyé par newbie06 Voir le message
    Je ne suis pas convaincu que ce type de machines serve pour le grand public : au final peu de soft ont besoin de faire du flottant, en tout cas à ce niveau de perf.
    Le jeu vidéo ?

  5. #455
    Citation Envoyé par newbie06 Voir le message
    Je ne suis pas convaincu que ce type de machines serve pour le grand public : au final peu de soft ont besoin de faire du flottant, en tout cas à ce niveau de perf. Et s'il y avait un tel besoin de perf flottantes, je pense qu'on aurait vu bien plus d'applications GPGPU grand public.
    Tu penses qu'Intel a définitivement abandonné l'idée d'essayer d'en faire un GPU (castré en DP pour ne pas concurrencer les Xeon Phi) ?

  6. #456
    @Møgluglu:

    Citation Envoyé par Foudge Voir le message
    Tu penses qu'Intel a définitivement abandonné l'idée d'essayer d'en faire un GPU (castré en DP pour ne pas concurrencer les Xeon Phi) ?
    Aucune idee. Je n'y connais pas grand-chose, mais j'ai quand meme l'impression que sans unites dediees a certaines taches faire un GPU performant est illusoire. J'irais meme un cran plus loin (a prendre avec des pincettes) : il est probable que le parallelisme doive etre bien plus massif pour faire un GPU efficace (les specialistes me corrigeront ).

  7. #457
    Moi je ne sais pas. Mais Intel ils ont déjà essayé... et ils ont eu des problèmes.

    Pour le parallélisme, ça ne me choque pas plus que ça : 16 (voies SIMD) * 4 (threads SMT) * 8 (threads SoE "fibers") * 50 (cores), ça fait 25600 threads. C'est raisonnable par rapport aux 25000 pour le GF100, 31000 pour le GK110 et 82000 pour GCN. (Je n'ai pas vu de mention explicite du nombre de fibers employés en pratique, sinon que c'est assez pour couvrir la latence de l'unité de texture.)
    S'ils arrivent à saturer leur unités de calcul avec moins de threads que les concurrents (grâce à plus d'ILP ou une latence mémoire moyenne plus faible), c'est autant de gagné en localité dans les caches et c'est tout bénef pour eux.

  8. #458
    Citation Envoyé par Møgluglu Voir le message
    Pour le parallélisme, ça ne me choque pas plus que ça : 16 (voies SIMD) * 4 (threads SMT) * 8 (threads SoE "fibers") * 50 (cores), ça fait 25600 threads. C'est raisonnable par rapport aux 25000 pour le GF100, 31000 pour le GK110 et 82000 pour GCN. (Je n'ai pas vu de mention explicite du nombre de fibers employés en pratique, sinon que c'est assez pour couvrir la latence de l'unité de texture.)
    S'ils arrivent à saturer leur unités de calcul avec moins de threads que les concurrents (grâce à plus d'ILP ou une latence mémoire moyenne plus faible), c'est autant de gagné en localité dans les caches et c'est tout bénef pour eux.
    S'quoi le SoE ?

  9. #459
    Switch on event. Le modèle d'exécution des shaders de Larrabee prévoyait des basculements de contexte en niveau user entre threads pour couvrir les latences de sampling de texture.
    L'idée du scheduling à 2 niveaux n'est pas débile, AMD le fait depuis longtemps et on trouve même des papiers de Nvidia Research qui le réinventent. Le faire en soft a un coût supplémentaire, mais pas forcément délirant.
    Ils peuvent donc avoir autant de parallélisme qu'ils veulent. Mais au final, c'est toujours la capacité du cache L1 ou du banc de registres GPU qui va dicter le nombre de threads. Et s'ils sont toujours à 32K de L1D/core, la comparaison n'est pas à l'avantage de Larrabee...

  10. #460
    Citation Envoyé par Møgluglu Voir le message
    Et s'ils sont toujours à 32K de L1D/core, la comparaison n'est pas à l'avantage de Larrabee...
    S'ils avaient mis autre chose que du x86 ils auraient gagne assez de place pour passer de 32k a 64k. Quoi, je trolle ?

  11. #461
    S'ils avaient mis autre chose que du x86 ils n'auraient pas besoin d'autant de cache L1 parce qu'ils auraient un nombre décent de registres et des conventions d'appel potables.

  12. #462
    Bah pour l'ABI c'est du x86_64, y'a pire hein.

    Y'a un endroit ou on peut reclamer une carte gratos quand on n'est pas au CERN ?

  13. #463
    De toute façon, il n'y a pas de registres dédiés à LRBni, de la même façon qu'il y a des registres SSE ?
    Mon blog (absolument pas à jour) : Teχlog

  14. #464
    Citation Envoyé par Alexko Voir le message
    De toute façon, il n'y a pas de registres dédiés à LRBni, de la même façon qu'il y a des registres SSE ?
    Oui, tu as les registres vectoriels, 32 de 512-bit.

  15. #465
    Rhôo, moi aussi je peux troller si je veux…

    La différence, c'est que sur les GPU les données privées des threads sont allouées de manière statique dans un gros banc de registres partitionné entre les threads (#registres/thread variable) et ne bougent plus, tandis qu'avec Larrabee on passe par le cache L1 à chaque basculement de contexte.

    A priori l'approche Larrabee est plus coûteuse, mais le nombre de registres / thread variable a un gros désavantage : la génération de code dépend du contexte. C'est un sacré problème pour la composabilité : on ne peut pas compiler séparément la moindre fonction de bibliothèque, parce que suivant l'endroit où elle est appelée, "l'architecture cible" sera différente. C'est une des raisons qui oblige à avoir du JIT de partout dans les drivers GPU.

    En ce sens, le x86 (au sens de jeu d'instruction CPU classique, ça pourrait aussi bien être ARM ou PPC ou Alpha...) peut être vu comme un avantage.

    Citation Envoyé par newbie06 Voir le message
    Y'a un endroit ou on peut reclamer une carte gratos quand on bosse pour un concurrent ?
    Euh... Tu peux toujours demander.

  16. #466
    On n'est pas concurrents sur le HPC. Enfin pas encore

  17. #467

  18. #468

  19. #469
    Je me posais une question sur Xeon Phi. Il n'y a pas de versions scalaires des instructions flottantes SIMD dans le jeu d'instructions comme en SSE/AVX.
    Du coup, en quoi est compilé le flottant scalaire (par icc et dans l'idée d'Intel) ?
    1) en instructions x87,
    2) en instructions SIMD sur des vecteurs de 512 bits,
    3) en instructions SIMD prédiquées par le masque 0000000000000001,
    4) ça n'existe pas, icc sait tout vectoriser.

    La réponse 3) me semble la plus raisonnable. La solution 1) pose des problème de déterminisme des résultats entre le même calcul vectorisé et non-vectorisé (bon, c'était déjà le cas avant), et l'ABI copié-collée sur celle du x86_64 relègue x87 aux calculs en double-étendue. La solution 2) doit poser des soucis avec les traps et les exceptions (ah non pardon, Phi gère pas les exceptions flottantes), en plus d'être pas super efficace en énergie. Pour 4), no comment.

    La solution 3 voudrait dire :
    - Le compilo doit initialiser un registre de masque à 00…01 dans chaque fonction qui manipule du flottant scalaire. Et le refaire entre chaque appel de fonction, les registres ki étant temporaires d'après l'ABI.
    - On a plein d'écritures partielles, et la micro-archi voit des dépendances de partout. Pas trop gênant encore en in-order, mais en out-of-order bon courage…
    - A-t-on une voie privilégiée ? Si je décide de choisir plutôt le masque 0000001000000000, je consommerait autant ? Ça voudrait dire que les datapaths et les registres sont clock-gatés et banqués à une granularité de 64 bits, voire 32 bits ?

  20. #470
    Plus de résultats de bench Xeon Phi (mais toujours par Intel) : http://www.intel.co.jp/content/dam/w...ance-brief.pdf

  21. #471
    50% du débit crête sur la mémoire, c'est pas terrible ?
    Je n'ai pas trouvé de chiffres pour Kepler, mais sur Fermi c'était autour de 80% (ECC on).

  22. #472
    Citation Envoyé par Møgluglu Voir le message
    50% du débit crête sur la mémoire, c'est pas terrible ?
    Je n'ai pas trouvé de chiffres pour Kepler, mais sur Fermi c'était autour de 80% (ECC on).
    Je trouve surtout etrange d'utiliser triad pour mesurer la BP surtout sur un processeur in order, non ?

  23. #473
    Bah ils doivent software-prefetcher à fond de toute façon. Plus il y a de loads en vol, mieux c'est. Et le ratio lectures:écritures de 2:1 est probablement plus intéressant.

    Sinon au temps pour moi, 80% c'est pour du trafic en lecture uniquement. Sur triad, on doit plutôt tomber à 70% à la louche.

  24. #474
    Ça bouge ici aussi.

    Xeon Phi premier au top 500.

    Lancement des Xeon Phi séries 5100 et 7100 : http://ark.intel.com/products/family/71840


    Et surtout on commence à avoir des infos un peu plus précises sur l'animal. Notamment cet article :
    http://software.intel.com/en-us/arti...o-architecture

    Et... ça fait plutôt peur.

    Intel Xeon Phi processors have global stall pipeline architecture; that is, part of the pipeline will stall if one of the stages is stalled for some reason.
    Global stall et SMT ? C'est pas censé aller bien ensemble...

    The hardware cannot issue instructions back to back from the same thread in the core. To reach full execution unit utilization at least two threads must be running at all times.
    En single-thread, on ne schedule des instructions qu'un cycle sur 2... OK, donc sur du code séquentiel on part d'un IPC crête divisé par 2 par rapport au Pentium d'il y a 20 ans...

    The Intel Xeon Phi coprocessor uses time-multiplexed multithreading. The PPF thread picker determines the request to be sent to instruction cache and put into the prefetch buffer and the second one selects what entries to read from the prefetch buffer and send them to the decoder. It uses a smart round-robin mechanism to pick only threads that have work to do and avoids threads that are inactive due to various conditions like cache miss. One can control thread scheduling by putting delay loops in the thread that the thread picker will not schedule in the actual hardware(which is useful for optimization)..
    Là ça sent l'enfummage. Si le thread qui doit attendre n'est pas schedulé, alors ça ne change rien de mettre des boucles d'attente...
    Je comprend plutôt : en fait le "smart" scheduler est juste greedy et sélectionne les instructions qui suivent le load pour le thread qui a eu un miss. Ces instructions se retrouvent bloquées sur la dépendance au load, et à cause du global stall elles bloquent aussi toutes les instructions des autres threads qui sont derrière. Du coup pour contourner le problème le programmeur doit mettre des nops après les loads pour remplir les slots du scheduler et comme ça les autres threads peuvent avancer.

    Jespère que j'ai mal compris...

    L'article répond aussi à ma question plus haut sur le flottant scalaire.

    The figure shows that the single threaded non vectorized run only provided ~0.66 Gflops. However, expected DP flops for a single core run is 2(FMA)x1(DP elements-non vectorized)x1.1 GHz = 2.2 Gflops. However, as described in architecture section, the hardware cannot issue instructions back to back from the same thread in the core. To reach full execution unit utilization at least two threads must be running at all times. So running on 2 threads (OMP_NUM_THREADS=2), we are able to reach 1.45 Gflops per core. As the core still uses vector unit to perform scalar arithmetic, the code for scalar arithmetic is very inefficient. For each fma on a DP element, it has to broadcast the element to all the lanes. Operate on the vector register with a mask and then store the single element back to memory.
    C'est bien ce que je craignais. Le code scalaire est quasiment deux fois plus lent que le code vectoriel.

    Heureusement, icc n'aura aucun problème à tout vectoriser, surtout que les codes qui tournent sont déjà plein de #pragma vector aligned, de notations Cilk+ propriétaires et de tailles de vecteurs hardcodées comme l'exemple.

  25. #475
    Apparemment Phi est dispo pour le commun des mortels : http://www.sabrepc.com/p-3936-intel-...or-active.aspx
    Enfin faut avoir $1700

  26. #476
    A peine sorti, et le jeu d'instructions change : AVX-512 pour Knight Landing

  27. #477
    Encore heureux, en même temps. Bon, l'unification des encodages aurait été fait une génération plus tôt, ça n'aurait pas fait de mal non plus...

    Il y a des ajouts à part une fusion entre AVX et LRBni ?
    Apparemment on récupère les masques, les gather-scatter, la config FPU statique et autres features de "vrai SIMD" de Knight Corner (mais les fonctions exp/log,rcp/rsq restent en option), et les instructions scalaires, les shuffle et autre unpack d'AVX.

    Cool, on aura donc des instructions scalaires dans Knight Landing. :monomaniaque:

  28. #478
    Citation Envoyé par newbie06 Voir le message
    Apparemment Phi est dispo pour le commun des mortels :
    Avec le Phi, il faut revoir ses vieilles habitudes :

    $ ssh mic0
    $ cat /proc/cpuinfo



    $ less /proc/cpuinfo

    Les numéros de processeurs à 3 chiffres, ça surprend au début.

    Plus sérieusement je vais voir ce que j'arrive à en tirer. Si vous avez des benchmarks ou des tests pas trop compliqués à installer que aviez toujours rêvé de faire tourner sur un Phi, dites toujours...

  29. #479
    Ton cat et ton less sont vides. Autant de substance que le Phi somme toute.

    EDIT: Enfoire !

    ---------- Post added at 17h46 ---------- Previous post was at 17h42 ----------

    Ha tiens j'ai une idee d'un truc a faire tourner : POVray...

  30. #480
    Je croyais que les PHI ca servait a faire tourner SGEMM . Et j'ai failli suggererer Dhrystone .
    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
  •