Non ils sont partis chez Bull :)
Version imprimable
Non ils sont partis chez Bull :)
Bonne nouvelle !
Ça va tu en sais plus que moi. :)
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. :ninja:
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.
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². :O
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...
Ça a l'air de se vendre pas si mal pour le HPC.
Mais l'embargo sur les exportations dearmes de destruction massivesupercalculateurs 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.
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. :trollface:
De manière très peu surprenante, les machines avec accélérateurs s'en tirent plus mal que les autres. :ninja: Ç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.
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. :ninja:
La disparition des unités FP64 ? Ne parle pas de malheur ! :emo:
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... :)
T'es dur quand même :cry:
Voilà, donc avec Spark, on peut connecter des petits tas de gravats entre eux, c'est ça :ninja:
Blague à part, sur la partie calcul, ça revient à faire du MPI avec une surcouche python codée en Java, si j'ai bien compris :wacko:
Hé mais y'a des formations intéressantes et tout :o
Prévenez-moi pas surtout :vibre:
Pourquoi à Toulouse ? C'pas juste :cry:
Moi aussi je veux venir caresser des GPUs avec vous. :emo:
Et moi qui suis à Toulouse, ils ont peur que l'y coince des tournevis :vibre:
Ma M2090 se porte très bien d'abord, bande de médisants.
Le mec il se la pète avec sa Tesla ! T'as la voiture aussi ? :p
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 :
https://tof.cx/images/2017/06/19/b99...cf401f205b.jpg
https://tof.cx/images/2017/06/19/da3...68d5188a59.jpg
Ca y est, ils ont sorti leur Pascal avec la mémoire troisdé ! :o
http://www.nvidia.fr/object/tesla-p100-fr.html
550Go/s de bp mémoire, pas mal...
Bon, garçon, vous m'en mettrez deux palettes s'il vous plait. Je paie par chèque. :cigare:
C'est vieux Pascal, vous avez pas précommandé votre DGX-Station Volta ?
https://www.nvidia.com/en-us/data-center/dgx-station/
Bah, sur leur site, ils ne prennent pas les chèques, si ? :p
On n'accepte pas les chèques !