developpement:activites:qualification:30ans1code

Différences

Ci-dessous, les différences entre deux révisions de la page.

--- developpement:activites:qualification:30ans1code [2019/12/16 14:28]
equemene [Parallélisation avec OpenCL]
+++ developpement:activites:qualification:30ans1code [2019/12/17 10:52]
equemene
@@ Ligne 14: / Ligne 14: @@
 (détournement de Tolkien...)
 ===== Résumé =====
@@ Ligne 105: / Ligne 106: @@
   * Multiplication des coeurs. Avant : les précédents. Après : le Northwood P4 et le AthlonX2
   * Manipulation des GPU. Avant : tous les processeurs. Après : 10 ans d'évolution de GPU et GPGPU.
 === Conditions expérimentales et exécution du code ===
@@ Ligne 120: / Ligne 119: @@
 En fonction de la performance et de la mémoire disponible dans chaque système.
+=== Eléments de sortie ===
+Ces simulations ont pour objectif de "montrer" quelle serait l'apparence d'un disque d'accrétion gravitant autour d'un trou noir. Cependant, ce n'est pas une mais deux images que nous allons synthétiser :
+  * la première en **[https://fr.wikipedia.org/wiki/D%C3%A9calage_vers_le_rouge|z]]**
+  * la seconde en **[[https://fr.wikipedia.org/wiki/Flux_lumineux|flux]]**
+Si le programme originel ne "produit" qu'une image en niveaux de gris normalisés sur la valeur maximale, le programme en Python exploite des "fausses couleurs" de manière équivalente à celle produite en avril dernier.
+Voici une image en **décalage spectral** en fausses couleurs, pour un observateur situé 10° au dessus du disque.
+{{ :developpement:activites:qualification:trounoirz_trajectopixel_device0_casimir_20191217_104144.png?500 |}}
+Voici une image en **flux** dont l'émission du disque est une **raie monochromatique** (une unique couleur).
+{{ :developpement:activites:qualification:trounoirf_trajectopixel_device0_casimir_20191217_104144.png?500 |}}
+Voici une image en **flux** dont l'émission est un **spectre de corps noir** (une distribution de couleurs).
+{{ :developpement:activites:qualification:trounoirf_trajectopixel_device0_casimir_20191217_104150.png?500 |}}
 === Intégration du calcul flottant dans le processeur ===
@@ Ligne 383: / Ligne 402: @@
 {{ :developpement:activites:qualification:voltavsall.png?500 |}}
-Nous constatons que les Tesla offrent des performances comparables aux cartes de gamer en Mono. La très onéreuse Tesla V100 est même inférieure à l'onéreuse RTX Titan. Il en est de même de la Tesla P100 avec sa concurrente directe, la GTX 1080 Ti. Par contre, dès que nous passons en BB, le rapport s'inverse complètement : les Tesla récentes sont entre 5x et 10x plus rapides que les GTX ou RTX équivalentes. D'où vient une telle différence ? Il y a la charge calculatoire d'abord : beaucoup plus d'opérations sont nécessaires dans la simulation BB face à Mono. Il y a ensuite la nature des opérations : beaucoup de fonctions transcendantes sont exploitées et, manifestement, elles ne sont pas confiées aux mêmes unités de calculs. Une telle différence suggère que les opérations transcendantes sont confiées systématiquement aux unités flottantes 64 bits beaucoup moins nombreuses sur les cartes de Gamer.
+Nous constatons que les Tesla offrent des performances comparables aux cartes de gamer en Mono. La très onéreuse Tesla V100 est même inférieure à l'onéreuse RTX Titan. Il en est de même de la Tesla P100 avec sa concurrente directe, la GTX 1080 Ti. Par contre, dès que nous passons en BB, le rapport s'inverse complètement : les Tesla récentes sont entre 5x et 10x plus rapides que les GTX ou RTX équivalentes.
+D'où vient une telle différence ? Il y a la charge calculatoire d'abord : beaucoup plus d'opérations sont nécessaires dans la simulation BB face à Mono. Il y a ensuite la nature des opérations : beaucoup de fonctions transcendantes sont exploitées et, manifestement, elles ne sont pas confiées aux mêmes unités de calculs. Une telle différence suggère que les opérations transcendantes sont confiées systématiquement aux unités flottantes 64 bits beaucoup moins nombreuses sur les cartes de Gamer.
+D'autre part, un espoir du côté de AMD : jusqu'alors complètement distancée dans toutes les simulations, la Radeon 7 dépasse toutes les cartes de gamer Nvidia, RTX Titan compris, et ce d'un facteur 2, mais uniquement en BB.
 === Et CUDA dans tout cela ? ===
@@ Ligne 428: / Ligne 451: @@
 Ainsi, l'exploitation CUDA apporte de très substanciels gain en performance. Compte-tenu du temps à passer au passage OpenCL/CUDA, il serait dommage de s'en passer.
-=== Calculer, c'est bien. Exploiter c'est mieux ===
+=== Calculer, c'est bien ! Exploiter c'est mieux... ===
 Il ne sert à rien de calculer s'il n'est pas possible d'en exploiter les résultats. Qu'il s'agisse de OpenCL ou CUDA, nous avons vu que tout est périphérique, processeur ou GPU. Il convient donc d'intégrer dans notre simulation le transfert du périphérique vers l'hôte des résultats. Nous allons découvrir que leur importance est loin d'être marginale !
+L'intégration de ce temps de transfert modifie très sensiblement les classements. Alors que les Nvidia, GPU ou GPGPU, régnaient sans partage avec juste une Radeon 7 plus efficace que les RTX ou GTX en mode BB, la dernière de chez AMD devient comparable à la Tesla P100. Pour une carte 10x moins chère qu'une Tesla V100, elle n'est pas 10x inférieure.
+{{ :developpement:activites:qualification:cudavsall_elapsed_bb.png?500 |}}
+En mode Mono, la domination écrasante de la Tesla V100 se réduit à un timide facteur 2 face à la meilleure des AMD. Il est véritablement de voir AMD s'en sortir beaucoup beaucoup mieux que CUDA dans ces transferts, mais peut-être est-ce dû au fait que les 3 cartes AMD présentées ici partagent le même ThreadRipper 1950X comme socle et donc bénéficient de meilleures communications entre hôte et périphériques.
+{{ :developpement:activites:qualification:cudavsall_elapsed_mono.png?500 |}}
+Au final, de 12x face au meilleur du GPU AMD, de 30x face aux meilleurs CPU, la performance du "monstre" V100 se réduit à un facteur entre 4x et 6x pour les processeurs et entre 2x et 3x pour les GPU. Dans ce cas, clairement, le temps de calcul devient marginal au temps de transfert des résultats du GPU à l'hôte.
+Ainsi, nous pouvons, au travers de ces diverses simulations, identifier une troisième frontière. La première est la limite calculatoire (Compute-bound), la seconde est la limite d'échange mémoire (Memory-bound), la troisième est la limite d'échange périphérique (IO-bound).
+==== Comparaison finale sur 30 ans de matériel informatique ====
+Nous avions présenté, au début de notre analyse, la distribution des processeurs en fonction de leur année de sortie et de deux paramètres définissant chacun d'eux : leur nombre de transistors et leur fréquence. Cela nous avait permis de conclure que, finalement, nous disposions d'une bonne répartition permettant de revenir à la loi de Moore "statique". Plus loin, nous nous étions rendu compte que, malgré la progression en nombre de transistors, nos performances n'augmentaient pas en conséquence et qu'il fallait modifier le programme pour mieux en exploiter les transistors, répartis sur plusieurs coeurs : la parallélisation du code, d'abord en OpenMP puis en OpenCL, a ainsi permis de largement mieux exploiter ces processeurs récents.
+Temps est venu de comparer tous nos 30 processeurs et accélérateurs, toutes natures confondues, et de les replacer sur un unique graphique, mais en fonction de leur année de commercialisation.
+{{ :developpement:activites:qualification:performancesyear_bb.png?600 |}}
+Pour les simulations BB, Les triangles jaunes (programme OpenCL) se placent bien au dessus des carrés bleus (programme séquentiel) voire des losanges oranges (programme OpenMP). L'échelle étant logarithmique en ordonnée, nous voyons également émerger timidement quelques triangles verts (programme CUDA).
+{{ :developpement:activites:qualification:performancesyear_mono.png?600 |}}
+Pour les simulations Mono, la différence entre GPU et CPU est beaucoup plus marquée : les triangles verts (CUDA) se détachent beaucoup plus largement. Elément intéressant, ils assurent la continuité de progression en performance assurée, d'abord par les processeurs monocoeur (de 1989 à 2004), puis les multicoeurs (jusqu'à 2008) avant que les GPGPU (en OpenCL) ne proposent des performances supérieures.
+Ainsi, l'exploitation du GPU a eu, dans l'histoire de l'informatique, le même caractère "disruptif" que l'intégration systématique de l'unité en virgule flottante dans les processeurs dès 1993. Grâce à l'exploitation de ces derniers, la loi de Moore "dynamique" (celle sur une performance mesurée) reste encore valable.

developpement/activites/qualification/30ans1code.txt · Dernière modification: 2019/12/17 15:34 par equemene

Rechercher

Translations

Navigation

Piste:

Boîte à outils