Non ils sont partis chez Bull
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.
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².
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.
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.
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.
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...
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.
Hé mais y'a des formations intéressantes et tout
Prévenez-moi pas surtout
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.
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 :
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...
C'est vieux Pascal, vous avez pas précommandé votre DGX-Station Volta ?
https://www.nvidia.com/en-us/data-center/dgx-station/