Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 17 sur 19 PremièrePremière ... 7910111213141516171819 DernièreDernière
Affichage des résultats 481 à 510 sur 567

Discussion: Intel et Larrabee

  1. #481
    Citation Envoyé par newbie06 Voir le message
    Ha tiens j'ai une idee d'un truc a faire tourner : POVray...
    Ça aurait presque pu marcher :
    Code:
    $ source /opt/intel/bin/compilervars.sh intel64
    $ ./configure --prefix=$HOME/usr/povray CC=icc CXX=icpc CFLAGS=-mmic CXXFLAGS=-mmic COMPILED_BY="Mgg <mgg@mgg.mgg>" --host=x86_64-unknown-linux-gnu
    ...si les autoconfs n'avaient pas été foireux.

    Même une fois tout reconfiguré en donnant les paths à la main, libtiff s'obstine à se compiler en 2 fois en exécutant du code qu'il vient de compiler, et qui plante donc instantanément sur le Xeon pas Phi.
    Heureusement que c'est du x86, c'est pas du tout comme si on avait besoin de cross-compiler.

    Je devrais peut-être plutôt faire un make -j240 avec gcc sur le mic pour éviter de me taper la cross-compil.

    ---------- Post added at 18h55 ---------- Previous post was at 18h48 ----------

    Citation Envoyé par fefe Voir le message
    Je croyais que les PHI ca servait a faire tourner SGEMM . Et j'ai failli suggererer Dhrystone .
    Je pourrais essayer AnTuTu, ça se compile bien avec icc il paraît.

  2. #482
    Citation Envoyé par fefe Voir le message
    Et j'ai failli suggererer Dhrystone .
    Ha ils ont mis des coeurs ARM sur Phi ?

    ---------- Post added at 21h55 ---------- Previous post was at 21h55 ----------

    Citation Envoyé par Møgluglu Voir le message
    Je pourrais essayer AnTuTu, ça se compile bien avec icc il paraît.
    Récupère nbench et ça roule !

  3. #483
    Je vois que le Phi nous donne tous de l'humour .
    fefe - Dillon Y'Bon

  4. #484
    Citation Envoyé par Møgluglu Voir le message
    Ça aurait presque pu marcher :
    Code:
    $ source /opt/intel/bin/compilervars.sh intel64
    $ ./configure --prefix=$HOME/usr/povray CC=icc CXX=icpc CFLAGS=-mmic CXXFLAGS=-mmic COMPILED_BY="Mgg <mgg@mgg.mgg>" --host=x86_64-unknown-linux-gnu
    ...si les autoconfs n'avaient pas été foireux.

    Même une fois tout reconfiguré en donnant les paths à la main, libtiff s'obstine à se compiler en 2 fois en exécutant du code qu'il vient de compiler, et qui plante donc instantanément sur le Xeon pas Phi.
    Pour libtiff, ca aide ca ? http://www.asmail.be/msg0055222497.html

    Heureusement que c'est du x86, c'est pas du tout comme si on avait besoin de cross-compiler.
    C'est un co-processeur, mossieu, pas un vrai CPU ! Hum...

    Je devrais peut-être plutôt faire un make -j240 avec gcc sur le mic pour éviter de me taper la cross-compil.
    Si deja t'arrives pas a cross-compiler libtiff, j'imagine meme pas gcc

    ---------- Post added at 12h54 ---------- Previous post was at 12h53 ----------

    Citation Envoyé par fefe Voir le message
    Je vois que le Phi nous donne tous de l'humour .
    En tout cas il donne pas d'amour a Mogluglu. Ouai c'est nul, mais je suis en vacances dans quelques heures.

  5. #485
    Ça va, j'ai réussi à compiler Povray en hackant les makefiles et en lançant les commandes à la main. Honnêtement, c'était pas la mort. 1 point par rapport à CUDA.

    J'ai lancé le mode benchmark. Le thread 0 du core 0 s'attaque vaillamment à la tâche. À lundi prochain pour le résultat.

  6. #486
    Citation Envoyé par Møgluglu Voir le message
    Ça va, j'ai réussi à compiler Povray en hackant les makefiles et en lançant les commandes à la main. Honnêtement, c'était pas la mort. 1 point par rapport à CUDA.
    Ca aurait ete beaucoup plus complique avec CUDA pour obtenir un premier jet ?

    J'ai lancé le mode benchmark. Le thread 0 du core 0 s'attaque vaillamment à la tâche. À lundi prochain pour le résultat.
    Ce qui va etre interessant c'est le temps qu'il va falloir pour arriver a un niveau de perf acceptable

  7. #487
    Citation Envoyé par newbie06 Voir le message
    Ca aurait ete beaucoup plus complique avec CUDA pour obtenir un premier jet ?
    Sur une usine à gaz comme povray, j'ose même pas imaginer le boulot rien que pour ajouter des __device devant chaque fonction et s'assurer que ça compile.

    Enfin on a inventé OpenACC pour ça.


    Ce qui va etre interessant c'est le temps qu'il va falloir pour arriver a un niveau de perf acceptable
    En fait j'ai installé la 3.6 stable, j'avais pas vu que la 3.7 beta ajoutait le support du multi-threading (youhou!)

  8. #488
    Citation Envoyé par Møgluglu Voir le message
    En fait j'ai installé la 3.6 stable, j'avais pas vu que la 3.7 beta ajoutait le support du multi-threading (youhou!)

  9. #489
    Citation Envoyé par Møgluglu Voir le message
    À lundi prochain pour le résultat.
    Comme quoi je suis mauvaise langue. C'est déjà fini :
    Code:
      Parse Time:    0 hours  0 minutes  5 seconds (5 seconds)
      Photon Time:   0 hours  1 minutes 56 seconds (116 seconds)
      Render Time:   1 hours 54 minutes 15 seconds (6855 seconds)
      Total Time:    1 hours 56 minutes 16 seconds (6976 seconds)
    D'après google, à l'époque du K10 on était autour de 1500 secondes.
    J'essaierai de compiler la 3.7 beta quand il sera moins l'heure de partir en week-end.

  10. #490
    Si tu veux, je peux le tester sur un gros PowerPC, pour te donner une idée

  11. #491
    Citation Envoyé par Møgluglu Voir le message
    Comme quoi je suis mauvaise langue. C'est déjà fini :
    Code:
      Parse Time:    0 hours  0 minutes  5 seconds (5 seconds)
      Photon Time:   0 hours  1 minutes 56 seconds (116 seconds)
      Render Time:   1 hours 54 minutes 15 seconds (6855 seconds)
      Total Time:    1 hours 56 minutes 16 seconds (6976 seconds)
    D'après google, à l'époque du K10 on était autour de 1500 secondes.
    J'essaierai de compiler la 3.7 beta quand il sera moins l'heure de partir en week-end.
    Donc on divise par 240 et... Ouai non on divise pas

    ---------- Post added at 23h56 ---------- Previous post was at 23h55 ----------

    Citation Envoyé par dandu Voir le message
    Si tu veux, je peux le tester sur un gros PowerPC, pour te donner une idée
    Ha ouai on pourrait faire un concours du plus lent

  12. #492
    Non, pour ça je le lance sur mon Karotz ou sur le Raspberry Pi

  13. #493
    Ah, le plaisir de faire tourner des applis de calcul intensif sur un seul Pentium !
    fefe - Dillon Y'Bon

  14. #494
    Un pentium basse frequence avec des unites vectorielles

    Mogluglu, tu as fait tourner quoi exactement ? J'aimerais voir le temps gcc/icc sur des x86 standard.

  15. #495
    Citation Envoyé par newbie06 Voir le message
    Un pentium basse frequence avec des unites vectorielles
    Qui ne tourne qu'un cycle sur deux en monothread et qui doit faire des opérations de masquage en plus pour éviter que les 15 lanes SIMD qu'on n'utilise pas génèrent des exceptions.

    Mogluglu, tu as fait tourner quoi exactement ? J'aimerais voir le temps gcc/icc sur des x86 standard.
    J'ai compilé sans options à part -mmic (ce qui correspond donc en gros au -O3 -ffast-math de gcc), et j'ai juste lancé ./povray --benchmark.

    Je viens de recompiler en x86-mainline avec -march=native et de le lancer sur l'hôte (un Xeon E5-2620, Sandy Bridge-EP à 2GHz, 2,5GHz turbo). Résultat :
    Code:
      Parse Time:    0 hours  0 minutes  1 seconds (1 seconds)
      Photon Time:   0 hours  0 minutes 14 seconds (14 seconds)
      Render Time:   0 hours 10 minutes 51 seconds (651 seconds)
      Total Time:    0 hours 11 minutes  6 seconds (666 seconds)
    On est donc "seulement" à un facteur 10. Mais le Xeon ne tourne pas très vite non plus. Et vu que la mémoire totale allouée est 7Mo, les montagnes de cache qu'il a ne changent pas grand-chose.

    Edit: avec gcc 4.7, ça compile pas même avec -fpermissive...
    Dernière modification par Møgluglu ; 16/08/2013 à 17h13.

  16. #496
    C'est pas un cycle sur 4 plutot ?

    Merci pour les infos

  17. #497
    Les unites vectorielles et le raytracing, c'est pas dement a moins de grouper les raons et d'avoirs de bonnes instructions de masque (et d'avoir qq un qui se paluche le code a la main).
    fefe - Dillon Y'Bon

  18. #498
    Citation Envoyé par fefe Voir le message
    Les unites vectorielles et le raytracing, c'est pas dement a moins de grouper les raons et d'avoirs de bonnes instructions de masque (et d'avoir qq un qui se paluche le code a la main).
    Moui, l'utilisation de RT etait une volonte de ma part de montrer que Phi c'est mimi, mais ca demande au final autant de boulot que du GPGPU pour avoir de tres bons resultats. Sauf cas particuliers bien entendu

  19. #499
    Citation Envoyé par newbie06 Voir le message
    C'est pas un cycle sur 4 plutot ?
    2 threads suffisent pour atteindre les perfs crête, s'ils ont assez d'ILP (encore heureux d'ailleurs).

    Citation Envoyé par newbie06 Voir le message
    Moui, l'utilisation de RT etait une volonte de ma part de montrer que Phi c'est mimi, mais ca demande au final autant de boulot que du GPGPU pour avoir de tres bons resultats. Sauf cas particuliers bien entendu
    Un autre benchmark avec du raytracing en OpenCL, pas du tout biaisé :
    http://clbenchmark.com/compare.jsp?c...fig_1=15887974

    Sinon, révélation du jour :
    - VPSHUFD : permute des blocs de 32 bits à l'intérieur de sous-vecteurs de 128 bits, contrôlé par un immédiat.
    - VPERMD : permute des blocs de 32 bits à l'intérieur de sous-vecteurs de 128 bits, contrôlé par un registre vectoriel.
    Cool, j'ai enfin compris la différence entre shuffle et permute !

    - VPERMF32X4 : permute des blocs de 128 bits, contrôlé par un immédiat.
    Ah bah non.

    Heureusement, AVX-512 arrive pour simplifier tout ça en ajoutant les instructions SHUFPD, SHUFPS, SHUFF32x4, SHUFF64x2, SHUFI32x4, SHUFI64x2, VPERMPD, VPERMPS, VPERMQ, VPERMI2D, VPERMI2PS, VPERMI2Q, VPERMI2PD, VPERMT2D, VPERMT2PS, VPERMT2Q, VPERMT2PD et VPERMILPD, sans oublier VPERMILPS.


    Edit: et puis il y a les intrinsics pour offrir une abstraction élégante au-dessus de l'affreux code assembleur :
    Code:
    __m512i acc_lo = _mm512_mask_adc_epi32(acc[2], lo, c, _mm512_mask_swizzle_epi32(acc[2], lo, acc[2], _MM_SWIZ_REG_CDAB), acc[1], &c);
    Cette légère syntaxe de haut niveau évite d'avoir à se taper le code assembleur équivalent :
    Code:
    vpadcd zmm3{k1}, k2, zmm2{cdab}
    Dernière modification par Møgluglu ; 19/08/2013 à 18h02.

  20. #500
    Citation Envoyé par Møgluglu Voir le message
    Un autre benchmark avec du raytracing en OpenCL, pas du tout biaisé :
    http://clbenchmark.com/compare.jsp?c...fig_1=15887974
    Pire : http://clbenchmark.com/compare.jsp?c...fig_1=15887974

    Enfin j'imagine qu'OpenCL n'est pas encore au point sur Phi (et ptet ne le sera jamais, quoique vu les efforts actuels fournis par Intel pour OpenCL avec leur projet Beignet...).

    Edit: et puis il y a les intrinsics pour offrir une abstraction élégante au-dessus de l'affreux code assembleur :
    Code:
    __m512i acc_lo = _mm512_mask_adc_epi32(acc[2], lo, c, _mm512_mask_swizzle_epi32(acc[2], lo, acc[2], _MM_SWIZ_REG_CDAB), acc[1], &c);
    Cette légère syntaxe de haut niveau évite d'avoir à se taper le code assembleur équivalent :
    Code:
    vpadcd zmm3{k1}, k2, zmm2{cdab}
    Mais quelle horreur Jamais pu encaisser les intrinsics, voire même l'assembleur inline (sauf cas très particulier). Au final une routine entièrement en asm me paraît bien plus lisible, mais j'ai peut-être été déformé par une jeunesse difficile, une époque où même un assembleur prenait trop de place et on assemblait de tête

  21. #501
    La notation en C, avec des variables et des expressions avec uniquement des fonctions pures sans effet de bord, c'est quand-même objectivement plus confortable que du code assembleur avec des instructions et des registres.

    Après, les intrinsics x86 sont affreusement verbeux (et on se rappelle jamais combien d'underscores et de m il faut mettre devant).
    Mais surtout ça devient pire avec l'exécution prédiquée.

    Code:
    c = vadd(a, b);
    devient
    Code:
    c = vadd_mask(ancien_c, cond, a, b)
    .

    Non seulement c'est lourdingue, mais surtout ça tue tout l'intérêt de la notation fonctionnelle. En pratique, ça force à avoir une instruction par ligne avec un registre destination explicite (ça ne peut pas être un temporaire puisqu'il faut aussi le passer explicitement en opérande d'entrée). Au final ça a l'expressivité d'un code macro-assembleur, mais avec la lourdeur en plus.

    En fait, je me rends compte que mon langage idéal ressemble beaucoup à ispc.
    Je vais essayer de réécrire mon code avec pour voir si j'arrrive à faire la même chose et si j'atteins les mêmes perfs. Le seul problème que je vois vient du modèle SPMD : on ne peut pas synchroniser et communiquer directement entre les lanes comme en SIMD.

  22. #502
    Knights Landing : http://vr-zone.com/articles/xeon-phi...015/64112.html

    J'ai un gros doute sur les transparents : il y a trop de fautes de mise en page... Et pourquoi coller du Silvermont modifié pour supporter du SMT x4 ?

  23. #503
    Powerpoint ouvert avec OpenOffice ou la mauvaise taille de police ?

    Pour le Silvermont out-of-order, il faudra aussi qu'on m'explique. Sortir un nouveau jeu d'instruction SIMD avec de la prédication et des masques partout, pour passer en out-of-order l'année d'après ?

  24. #504
    Citation Envoyé par Møgluglu Voir le message
    Powerpoint ouvert avec OpenOffice ou la mauvaise taille de police ?
    Y'a d'autres trucs bizarres comme le term MCDRAM, alors que dans les slides officiels Intel parle de "HBW In-package memory".

    Pour le Silvermont out-of-order, il faudra aussi qu'on m'explique. Sortir un nouveau jeu d'instruction SIMD avec de la prédication et des masques partout, pour passer en out-of-order l'année d'après ?
    On va dire que c'est une blague et attendre plus d'infos vérifiables

  25. #505
    .
    fefe - Dillon Y'Bon

  26. #506
    Une machine Knight Landing pour $5000.
    Je trouve que ce n'est pas si cher que ca, mais j'imagine qu'Intel fait un effort pour imposer la plateforme ailleurs que dans les gros centres de calcul.

    Truc etrange, c'est le refroidissement liquide de la version tour, alors que la version rack ne semble pas l'utiliser. Le flux d'air dans un rack est vraiment mieux optimisable ?

  27. #507
    La plateforme Xeon + Phi 5110 Knights Corner était dans ces prix-là aussi à sa sortie. Par contre ce coup-ci le Xeon n'est pas inclus ? (Heureusement il y a des slots PCIe libres, vivement qu'Intel sorte des cartes d'accélérateurs séquentiels Xeon.)

    Le refroidissement liquide, c'est probablement pour garder un niveau sonore acceptable pour un environnement de bureau. Ils ont du apprendre de leurs erreurs depuis le lancement des premières plateformes de dev Itanium.

  28. #508
    Citation Envoyé par Møgluglu Voir le message
    La plateforme Xeon + Phi 5110 Knights Corner était dans ces prix-là aussi à sa sortie.
    Pour une machine complete avec 100 Go ? Il me semblait que c'etait le prix de la carte seule, c'est moche de vieillir

    Par contre ce coup-ci le Xeon n'est pas inclus ? (Heureusement il y a des slots PCIe libres, vivement qu'Intel sorte des cartes d'accélérateurs séquentiels Xeon.)
    L'argument de ce nouveau Xeon Phi etant qu'il est "standalone", ca se comprend

  29. #509
    Citation Envoyé par newbie06 Voir le message
    Pour une machine complete avec 100 Go ? Il me semblait que c'etait le prix de la carte seule, c'est moche de vieillir
    Pour juste un serveur de base mono-socket avec 16 Go de RAM + 8 Go sur le MIC.
    Pour la carte seule je me souviens vaguement d'un devis à 3000, mais dans ce topic y'avait un type qui disait $1700 sur la page juste avant.

  30. #510
    Y'avait pas un projet français avec une startup qui vendait une carte comme le Xéon Phi?
    Je crois que tu m'avais présenté le truc il y a quelques années, mais j'ai un peu perdu le fil...

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
  •