Réseau CPC BIENDEBUTER.NET Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
+ Reply to Thread
Page 17 of 17 FirstFirst ... 7 9 10 11 12 13 14 15 16 17
Results 481 to 505 of 505
  1. #481
    Quote Originally Posted by newbie06 View Post
    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 ----------

    Quote Originally Posted by fefe View Post
    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
    Quote Originally Posted by fefe View Post
    Et j'ai failli suggererer Dhrystone .
    Ha ils ont mis des coeurs ARM sur Phi ?

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

    Quote Originally Posted by Møgluglu View Post
    Je pourrais essayer AnTuTu, ça se compile bien avec icc il paraît.
    Récupère nbench et ça roule !

  3. #483
    *X86 ADV Natif* fefe's Avatar
    Location
    Far far away
    Je vois que le Phi nous donne tous de l'humour .
    fefe - Dillon Y'Bon

  4. #484
    Quote Originally Posted by Møgluglu View Post
    Ç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 ----------

    Quote Originally Posted by fefe View Post
    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
    Quote Originally Posted by Møgluglu View Post
    Ç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
    Quote Originally Posted by newbie06 View Post
    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
    Quote Originally Posted by Møgluglu View Post
    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
    Quote Originally Posted by Møgluglu View Post
    À 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
    Quote Originally Posted by Møgluglu View Post
    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 ----------

    Quote Originally Posted by dandu View Post
    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
    *X86 ADV Natif* fefe's Avatar
    Location
    Far far away
    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
    Quote Originally Posted by newbie06 View Post
    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...
    Last edited by Møgluglu; 16/08/2013 at 17h13.

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

    Merci pour les infos

  17. #497
    *X86 ADV Natif* fefe's Avatar
    Location
    Far far away
    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
    Quote Originally Posted by fefe View Post
    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
    Quote Originally Posted by newbie06 View Post
    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).

    Quote Originally Posted by newbie06 View Post
    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}
    Last edited by Møgluglu; 19/08/2013 at 18h02.

  20. #500
    Quote Originally Posted by Møgluglu View Post
    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
    Quote Originally Posted by Møgluglu View Post
    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
    *X86 ADV Natif* fefe's Avatar
    Location
    Far far away
    .
    fefe - Dillon Y'Bon

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts