Différences

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

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
developpement:activites:qualification:30ans1code [2019/12/17 12:22]
equemene
developpement:activites:qualification:30ans1code [2019/12/17 15:34]
equemene
Ligne 1: Ligne 1:
 ====== Simuler un trou noir : du processeur à la carte graphique ====== ====== Simuler un trou noir : du processeur à la carte graphique ======
- 
-<note important>​En construction...</​note>​ 
  
 **Simuler l'​apparence d'un trou noir et son écharpe de plasma,\\ de la parallélisation à la GéPUfication d'un code,\\ 40 ans d'​histoire scientifique en 30 ans d'​évolution technologique.** **Simuler l'​apparence d'un trou noir et son écharpe de plasma,\\ de la parallélisation à la GéPUfication d'un code,\\ 40 ans d'​histoire scientifique en 30 ans d'​évolution technologique.**
Ligne 376: Ligne 374:
 {{ :​developpement:​activites:​qualification:​c1060_harpertown.png?​500 |}} {{ :​developpement:​activites:​qualification:​c1060_harpertown.png?​500 |}}
  
-En Mono, la Tesla C1060 est 3.5x plus rapide que le serveur bi-socket ​en OpenCL, l'​OpenMP étant très légèrement inférieur en performances. En BB, c'est une toute autre affaire : l'​OpenCL de la Tesla est à peine supérieure à la version OpenMP du serveur bi-socket. La version OpenCL d'AMD, exploitée ici, est dramatiquement inefficace face à l'​OpenMP. Ainsi, déjà, nous constatons que, pour notre première exploitation de GPU, son comportement n'est pas du tout équivalent en fonction de la "​charge"​ que nous portons à chaque processus élémentaire.+En Mono, la Tesla C1060 est 3.5x plus rapide que le serveur bi-sockets ​en OpenCL, l'​OpenMP étant très légèrement inférieur en performances. En BB, c'est une toute autre affaire : l'​OpenCL de la Tesla est à peine supérieure à la version OpenMP du serveur bi-socket. La version OpenCL d'AMD, exploitée ici, est dramatiquement inefficace face à l'​OpenMP. Ainsi, déjà, nous constatons que, pour notre première exploitation de GPU, son comportement n'est pas du tout équivalent en fonction de la "​charge"​ que nous portons à chaque processus élémentaire.
  
 == AMD : les trois dernières générations == == AMD : les trois dernières générations ==
Ligne 424: Ligne 422:
 Le portable inital du code en CUDA a été plutôt rapide : il n'a pris qu'une soirée. Il a suffit de remplacer tous les "​workitem"​ par "​BlockIdx"​ et préfixer les fonctions primaires par  "​__device__"​. Le portable inital du code en CUDA a été plutôt rapide : il n'a pris qu'une soirée. Il a suffit de remplacer tous les "​workitem"​ par "​BlockIdx"​ et préfixer les fonctions primaires par  "​__device__"​.
  
-Mais la première exécution a été plutôt très décevante : en effet, sur la Tesla P100, j'​avais ​un temps de référence de 1 seconde d'​exécution en OpenCL sur une simulation BB. En CUDA, ce temps est devenu 24 secondes (soit 24x plus lent !). En Mono, le temps était un peu supérieur.+Mais la première exécution a été plutôt très décevante : en effet, sur la Tesla P100, nous avions ​un temps de référence de 1 seconde d'​exécution en OpenCL sur une simulation BB. En CUDA, ce temps est devenu 24 secondes (soit 24x plus lent !). En Mono, le temps était un peu supérieur.
  
 == Exploiter les deux étages de parallélisme : une nécessité mais comment ? == == Exploiter les deux étages de parallélisme : une nécessité mais comment ? ==
Ligne 445: Ligne 443:
 == Exploitation de CUDA : tirer le maximum, mais des plus récents == == Exploitation de CUDA : tirer le maximum, mais des plus récents ==
  
-Commençons par la simulation en BB : nous constatons tout d'​abord que certaines architectures ne fonctionnent pas en CUDA avec notre code. En effet, les machines les plus anciennes (GTX 560 Ti, Tesla C1060, Tesla M2090) plantent à l'​exécution de CUDA. En effet, le CUDA version 10.1 exploité ne supporte pas les anciens pilotes 340, les derniers disponibles dans la distributions ​permettant le support de ces GPU ou GPGPU vieillissants.+Commençons par la simulation en BB : nous constatons tout d'​abord que certaines architectures ne fonctionnent pas en CUDA avec notre code. En effet, les machines les plus anciennes (GTX 560 Ti, Tesla C1060, Tesla M2090) plantent à l'​exécution de CUDA. En effet, le CUDA version 10.1 exploité ne supporte pas les anciens pilotes 340, les derniers disponibles dans la distribution Debian ​permettant le support de ces GPU ou GPGPU vieillissants.
  
 {{ :​developpement:​activites:​qualification:​cudavsall_compute_bb.png?​500 |}} {{ :​developpement:​activites:​qualification:​cudavsall_compute_bb.png?​500 |}}
  
-Nous remarquons que seules les cartes Tesla récentes présentent des accélérations notables au passage en CUDA. La Tesla V100 est plus de deux fois plus rapide, la P100 2/3 plus rapide. La dynamique effondre donc tous les autres accélérateurs et plus encore processeurs. Pour les GPU de //gamer//, CUDA fait à peine mieux que OpenCL. Il se passe donc des "​choses bizarres"​ lors de la phase de compilation des noyaux CUDA avec ''​NVCC''​. Dès la Tesla K40m, nous sont plus performants que n'​importe quel autre accélérateur. Quant à la Tesla V100, elle règle ​sans partage, reléguant la P100 à un facteur 2.+Nous remarquons que seules les cartes Tesla récentes présentent des accélérations notables au passage en CUDA. La Tesla V100 est  deux fois plus rapide, la P100 2/3 plus rapide. La dynamique effondre donc tous les autres accélérateurs et plus encore processeurs. Pour les GPU de //gamer//, CUDA fait à peine mieux que OpenCL. Il se passe donc des "​choses bizarres"​ lors de la phase de compilation des noyaux CUDA avec ''​NVCC''​. Dès la Tesla K40m, les GPGPU sont plus performants que n'​importe quel autre accélérateur ​de gamer. Quant à la Tesla V100, elle règne ​sans partage, reléguant la P100 à un facteur 2.
  
 {{ :​developpement:​activites:​qualification:​cudavsall_compute_mono.png?​500 |}} {{ :​developpement:​activites:​qualification:​cudavsall_compute_mono.png?​500 |}}
  
-Pour une simulation Mono, les gains sont beaucoup plus significatifs. Pour les GTX ou RTX, les performances quintuplent. Pour les Tesla, nous dépassons le décuplement. La Tesla V100 est moins dominatrice que précédemment face aux RTX ou GTX, mais elle place son facteur 2. Face aux processeurs ou même tous les autres GPU, il y a la Tesla V100 et les autres.+Pour une simulation Mono, les gains sont beaucoup plus significatifs. Pour les GTX ou RTX, les performances quintuplent. Pour les Tesla, nous dépassons le décuplement. La Tesla V100 est moins dominatrice que précédemment face aux RTX ou GTX, mais elle impose un facteur 2 aux précédentes. Face aux processeurs ou même à tous les autres GPU, il y a la Tesla V100 et les autres.
  
-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.+Ainsi, l'​exploitation CUDA apporte de très substantiels gains en performance. Compte-tenu du temps passé ​au portage de OpenCL ​à CUDA, il serait dommage de s'​en ​priver...
  
 === 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 !+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 ​des résultats ​du périphérique vers l'​hôte. 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.+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 ​en performances.
  
 {{ :​developpement:​activites:​qualification:​cudavsall_elapsed_bb.png?​500 |}} {{ :​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.+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 ​bien 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 |}} {{ :​developpement:​activites:​qualification:​cudavsall_elapsed_mono.png?​500 |}}
Ligne 471: Ligne 469:
 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. 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).+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 deuxième ​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 ==== ==== Comparaison finale sur 30 ans de matériel informatique ====
Ligne 477: Ligne 475:
 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. 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.+Le 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 |}} {{ :​developpement:​activites:​qualification:​performancesyear_bb.png?​600 |}}
Ligne 487: Ligne 485:
 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. 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. ​+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