Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 22 sur 22 PremièrePremière ... 12141516171819202122
Affichage des résultats 631 à 658 sur 658

Discussion: Archi GPU et GPGPU

  1. #631
    Non ils sont partis chez Bull
    fefe - Dillon Y'Bon

  2. #632
    Bonne nouvelle !
    Ça va tu en sais plus que moi.

  3. #633
    Bull existe encore ? C'est pas la boite qui servait à écouler les stocks d'Itanium ? Mouhahaha :troll:

  4. #634
    Citation Envoyé par newbie06 Voir le message
    Bull existe encore ? C'est pas la boite qui servait à écouler les stocks d'Itanium ? Mouhahaha :troll:
    Ouais, maintenant ils écoulent les stocks de Knights Landing.

    Citation Envoyé par taronyu26 Voir le message
    ...oui quand on me parle de GPUs ça me rend tout chose
    Sur l'équivalent de la prédiction de valeurs sur GPU :

    La prédiction de valeurs sur CPU marche parce qu'il existe des corrélations entre les valeurs manipulées par des instances successives d'une instruction dans les codes raisonnablement réguliers.

    Une fois que tu as parallélisé ton code séquentiel en CUDA, ces corrélations sont toujours là. Mais au lieu d'être réparties entre des itérations successives d'une boucle d'un seul thread, ces instructions corrélées sont maintenant distribuées entre différents threads en parallèle. Et comme ton GPU synchronise les threads d'un warp, il calcule souvent la même valeur ou des valeurs contiguës au même moment sur les différents threads d'un warp.
    "Souvent", sur des codes GPGPU, c'est 95% des instructions entières, et ça monte à 97% pour les écritures.

    Du coup, on peut optimiser en ne calculant la valeur qu'une seul fois pour le compte de tous les threads du warp. C'est la raison d'être des unités scalaires et des registres scalaires dans GCN. Le compilateur d'AMD identifie les instructions qui vont calculer avec certitude la même chose entre les threads du warp et les convertit en instructions scalaire. On va plus vite, on consomme moins et on gagne aussi en latence. Typiquement, le calcul entier te sert à calculer des adresses : Nvidia va calculer l'adresse indépendamment pour chaque thread du warp, puis envoyer le vecteur d'adresses à l'unité mémoire, dont le mécanisme de coalescing va comparer les adresses pour se rendre compte qu'elles sont successives ; AMD va calculer seulement l'adresse de base dans les unités scalaires et va l'envoyer directement à l'unité mémoire, qui saura qu'il faut accéder à une zone contiguë en mémoire.

  5. #635
    Nvidia a annoncé l'archi Volta et donné quelques infos :
    https://devblogs.nvidia.com/parallel.../inside-volta/

    Avec un gros GPU pour commencer, le GV100 de 815mm².
    Le plus visible : comme les CUDA Cores c'est has-been, ils ont ajouté des Tensor Cores pour le deep learning, et la phase de training en particulier. Un Tensor Core ça fait un produit de matrices 4x4 en FP16 dont le résultat est accumulé dans une matrice FP32, et il y en a 8 comme ça par SM. Uniquement pour le GV100 a priori.

    Le mécanisme d'exécution SIMT n'avait quasiment pas changé depuis 10 ans. Avec Volta il a été remis à plat. Maintenant les threads sont enfin de vrais de vrais threads, ils peuvent avoir leur vie propre et reconverger dans le désordre. Il n'est désormais plus possible de prétendre que les GPU sont des simples processeurs SIMD, et il va falloir une nouvelle édition du Hennessy-Patterson.
    C'est surtout bien pour le modèle de programmation. Plutôt que de programmer le GPU en "C for CUDA", on pourra le programmer en C ou C++ tout cout. Tout en gardant la possibilité de faire du SIMD explicite quand on en a besoin.

    Dans sa keynote à la GTC, Jensen a aussi promis qu'il allait rendre open-source l'accélérateur de deep learning de la plateforme Tegra Xavier (rien à voir avec les Tensor Cores a priori, là c'est pour l'inférence). Sûrement parce qu'ils ont peur de se faire bouffer par les accélérateurs d'inférence de Google...

  6. #636
    Citation Envoyé par Møgluglu Voir le message
    Ouais, maintenant ils écoulent les stocks de Knights Landing.
    Tiens, ça marche comment les Intel MIC, commercialement parlant ?
    Le KL, ça me paraissait vraiment intéressant en termes de performances de calcul pourtant.

  7. #637
    Ça a l'air de se vendre pas si mal pour le HPC.
    Mais l'embargo sur les exportations de armes de destruction massive supercalculateurs vers la Chine leur a fait raté un gros contrat, et surtout les prive de l'accès au marché du leader mondial du HPC.

  8. #638
    En parlant d'accélérateurs, de top 500 et de ventes d'accélérateurs... J'ai vu Dongarra présenter récemment, maintenant il insiste aussi sur le benchmark HPCG, censé être plus représentatif des vrais applications qu'un bête LINPACK.

    http://www.hpcg-benchmark.org/custom...d=155&slid=289

    Je vous laisse regarder les proportions de puissances crêtes théoriques atteintes.
    De manière très peu surprenante, les machines avec accélérateurs s'en tirent plus mal que les autres. Ça peut faire relativiser l'importance d'avoir un accélérateur pour la simulation numérique : c'est très code-dépendant.

    Après là, typiquement l'implémentation d'HPCG doit beaucoup compter. Je ne sais même pas s'il l'implémentation de référence se contente d'offloader ou si un moteur de tâches est utilisé pour les calculs sur accélérateurs.

    Le domaine où les accélérateurs ont le vent en poupe c'est le deep learning. Il y a désormais du matériel dédié. Ils en viennent même à faire des instructions half-precision parce que ce n'est pas important pour ces applications-là. Il y a aussi un marché pour un bonne bibliothèque permettant de faire du traitement par lot sur les calculs matricielles de petites tailles.

  9. #639
    Linpack mesure essentiellement la puissance de calcul brute, et HPCG mesure essentiellement la vitesse de l'interconnect. Donc le Tofu japonais s'en sort bien mieux que les nouilles chinoises.
    Malgré ça Dongarra est le premier à reconnaître qu'on peut faire de la vraie science sur une machine à 100 Pflops comme TaihuLight malgré l'interconnect faiblard.

    Et ouais le deep learning arrive même dans le domaine HPC. Et autant développer des accélérateurs dédiés pour le calcul scientifique à papa n'est pas rentable, autant le machine learning est un vrai marché pour lequel le matériel dédié a du sens. Encore un point en défaveur du Phi.
    Je prédis bientôt l'utilisation indiscriminée de deep learning pour calculer n'importe quoi, et du GPNNU (General-Purpose computing on Neural Network Units), pour remplacer les unités flottantes double précision qui auront disparu des processeurs.

  10. #640
    La disparition des unités FP64 ? Ne parle pas de malheur !

  11. #641
    Pourquoi pas... il n'y a pas de raison fondamentale à vouloir du flottant binaire 64 bits, à part l'inertie des codes existants, des jeux d'instructions, des langages de programmation définis en dépit du bon sens, et d'Excel.
    On pourrait très bien avoir du Decimal128 pour la finance et du Binary32/Binary16 pour le reste. Le calcul scientifique est une niche, il continuera à se contenter de charogner ce qui existe ailleurs.

    Après tu auras toujours des gens pour se plaindre que la nouvelle archi est bugguée parce que leur calcul est plus précis qu'avant...

  12. #642
    T'es dur quand même

  13. #643
    Citation Envoyé par Sp1d3r Voir le message
    En parlant d'accélérateurs, de top 500 et de ventes d'accélérateurs... J'ai vu Dongarra présenter récemment, maintenant il insiste aussi sur le benchmark HPCG, censé être plus représentatif des vrais applications qu'un bête LINPACK.

    http://www.hpcg-benchmark.org/custom...d=155&slid=289

    Je vous laisse regarder les proportions de puissances crêtes théoriques atteintes.
    De manière très peu surprenante, les machines avec accélérateurs s'en tirent plus mal que les autres. Ça peut faire relativiser l'importance d'avoir un accélérateur pour la simulation numérique : c'est très code-dépendant.

    Après là, typiquement l'implémentation d'HPCG doit beaucoup compter. Je ne sais même pas s'il l'implémentation de référence se contente d'offloader ou si un moteur de tâches est utilisé pour les calculs sur accélérateurs.

    Le domaine où les accélérateurs ont le vent en poupe c'est le deep learning. Il y a désormais du matériel dédié. Ils en viennent même à faire des instructions half-precision parce que ce n'est pas important pour ces applications-là. Il y a aussi un marché pour un bonne bibliothèque permettant de faire du traitement par lot sur les calculs matricielles de petites tailles.


    Tu étais au CERFACS vendredi ?
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  14. #644
    Citation Envoyé par Møgluglu Voir le message
    Je prédis bientôt l'utilisation indiscriminée de deep learning pour calculer n'importe quoi, et du GPNNU (General-Purpose computing on Neural Network Units), pour remplacer les unités flottantes double précision qui auront disparu des processeurs.
    Mais tais-toi







    Pour moi, l'armaggedon il vient plutôt de l'"architecture" Spark, qui à en croire certains est à même de résoudre toutes les solutions de calcul, même quand on se contente de relier avec 3 PCs asmathiques et dépassés.

  15. #645

  16. #646
    Voilà, donc avec Spark, on peut connecter des petits tas de gravats entre eux, c'est ça
    Blague à part, sur la partie calcul, ça revient à faire du MPI avec une surcouche python codée en Java, si j'ai bien compris
    Dernière modification par vectra ; 17/05/2017 à 14h12.

  17. #647
    Citation Envoyé par Lazyjoe Voir le message


    Tu étais au CERFACS vendredi ?
    Yep. En fait, je me rend compte qu'on peut se faire une IRL à Toulouse HPC/CPC; on serait au moins 3.

  18. #648
    Hé mais y'a des formations intéressantes et tout

    Prévenez-moi pas surtout

  19. #649
    Citation Envoyé par Sp1d3r Voir le message
    Yep. En fait, je me rend compte qu'on peut se faire une IRL à Toulouse HPC/CPC; on serait au moins 3.
    Le monde est petit. IMFT ?
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  20. #650
    Pourquoi à Toulouse ? C'pas juste

    Moi aussi je veux venir caresser des GPUs avec vous.

  21. #651
    Et moi qui suis à Toulouse, ils ont peur que l'y coince des tournevis
    Ma M2090 se porte très bien d'abord, bande de médisants.

  22. #652
    Le mec il se la pète avec sa Tesla ! T'as la voiture aussi ?

  23. #653
    L'actu du supercomputing : avec Piz Daint upgradé en Tesla P100, la Suisse prend la 3e place au Top500, derrière la Chine et devant les US.
    Les Tesla P100 inondent aussi le Green500.

    Seuls les accélérateurs PEZY-SC2 japonais refroidis à l'huile résistent encore, dans leurs friteuses :



  24. #654
    Ca y est, ils ont sorti leur Pascal avec la mémoire troisdé !

    http://www.nvidia.fr/object/tesla-p100-fr.html
    550Go/s de bp mémoire, pas mal...

  25. #655
    Bon, garçon, vous m'en mettrez deux palettes s'il vous plait. Je paie par chèque.

  26. #656
    C'est vieux Pascal, vous avez pas précommandé votre DGX-Station Volta ?
    https://www.nvidia.com/en-us/data-center/dgx-station/

  27. #657
    Bah, sur leur site, ils ne prennent pas les chèques, si ?

  28. #658

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
  •