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
Prochaine révision Les deux révisions suivantes
developpement:activites:qualification:30ans1code [2019/12/17 11:40]
equemene
developpement:activites:qualification:30ans1code [2019/12/17 12:22]
equemene
Ligne 267: Ligne 267:
 {{ :​developpement:​activites:​qualification:​openmp_bb.png?​500 |}} {{ :​developpement:​activites:​qualification:​openmp_bb.png?​500 |}}
  
-En bleu apparaissent les performances du code séquentiel en BB, non parallélisé,​ déjà ​présentés... Effectivement,​ le résultat est impressionnant. Les deux premiers processeurs à être équipés multi-coeurs logiques ou physiques sont invisibles. Nous constatons cependant que les machines équipées de 8 coeurs physiques et relativement récents ont des performances comparables (W-2145, Gold 5122x2 et E5-2637v4x2). Les machines équipées de coeurs plus anciens présentent des performances inférieures à la moitié voire au cinquième. Autre logique respectée, les machines disposant de plus de 8 coeurs physiques (16, 20 et même 28 coeurs) respectent la logique : elles forment le podium.+En bleu apparaissent les performances du code séquentiel en BB, non parallélisé,​ déjà ​présentées... Effectivement,​ le résultat est impressionnant. Les deux premiers processeurs à être équipés ​de multi-coeurs logiques ou physiques sont invisibles. Nous constatons cependant que les machines équipées de 8 coeurs physiques et relativement récents ont des performances comparables (W-2145, Gold 5122x2 et E5-2637v4x2). Les machines équipées de coeurs plus anciens présentent des performances inférieures à la moitié voire au cinquième. Autre logique respectée, les machines disposant de plus de 8 coeurs physiques (16, 20 et même 28 coeurs) respectent la logique : elles forment le podium.
  
 Regardons s'il en est de même en Mono. Regardons s'il en est de même en Mono.
Ligne 273: Ligne 273:
 {{ :​developpement:​activites:​qualification:​openmp_mono.png?​500 |}} {{ :​developpement:​activites:​qualification:​openmp_mono.png?​500 |}}
  
-La même distribution apparaît, avec des ratio de performances encore plus marqués par rapport au code séquentiel.+La même distribution apparaît, avec des ratios ​de performances encore plus marqués par rapport au code séquentiel.
  
 Ainsi, le parallélisme en OpenMP permet de porter notre gain en performance de 3 millions à 68 millions en B  et de 700000 à plus de 14 millions : un gros facteur 20 ! De quoi rattraper la loi de Moore largement maltraitée par le code purement séquentiel. Ainsi, le parallélisme en OpenMP permet de porter notre gain en performance de 3 millions à 68 millions en B  et de 700000 à plus de 14 millions : un gros facteur 20 ! De quoi rattraper la loi de Moore largement maltraitée par le code purement séquentiel.
  
-En fait, pour être honnête, ces résultats n'ont pu être obtenus sans modification du "​système"​. En effet, lors de l'​exécution,​ il est apparu que tous les coeurs n'​étaient pas sollicités de manière ​équivalentes ​et donc que l'​exécution n'​était pas optimale. Pour obtenir de telles performances,​ nous avons littéralement "bourrer" les coeurs avec beaucoup plus de tâches simultanées qu'ils n'​en ​existaient ​de physiques : jusqu'​à 128x le nombre de coeurs physiques.+En fait, pour être honnête, ces résultats n'ont pu être obtenus sans modification du "​système"​. En effet, lors de l'​exécution,​ il est apparu que tous les coeurs n'​étaient pas sollicités de manière ​équivalente ​et donc que l'​exécution n'​était pas optimale. Pour obtenir de telles performances,​ nous avons littéralement "bourré" les coeurs avec beaucoup plus de tâches simultanées qu'il n'​en ​existait ​de physiques : jusqu'​à 128x le nombre de coeurs physiques.
  
 Pour illustrer cela, nous avons exploré le temps de calcul pour différentes tailles d'​images et nous avons joué sur le parallélisme imposé au code OpenMP, allant de 1x le nombre de coeurs à 128x le nombre de coeurs, pour les deux méthodes Mono et BB. Pour illustrer cela, nous avons exploré le temps de calcul pour différentes tailles d'​images et nous avons joué sur le parallélisme imposé au code OpenMP, allant de 1x le nombre de coeurs à 128x le nombre de coeurs, pour les deux méthodes Mono et BB.
  
-La première représentation parle d'elle même, en appliquant ces paramètres sur la méthode BB.+La première représentation parle d'elle-même, en appliquant ces paramètres sur la méthode BB.
  
 {{ :​developpement:​activites:​qualification:​tr_omp_bb.png?​500 |}}  {{ :​developpement:​activites:​qualification:​tr_omp_bb.png?​500 |}} 
Ligne 291: Ligne 291:
 {{ :​developpement:​activites:​qualification:​tr_omp_mono.png?​500 |}} {{ :​developpement:​activites:​qualification:​tr_omp_mono.png?​500 |}}
  
-Ici, c'est encore pire ! Pour un parallélisme fixé à 16 tâches, nous n'​avons qu'un ratio de 2. Par contre, au delà de 64x le nombre de coeurs, la performance en OpenMP dépasse 16x la performance en séquentiel.+Ici, c'est encore pire ! Pour un parallélisme fixé à 16 tâches, nous n'​avons qu'un ratio de 2. Par contre, au-delà de 64x le nombre de coeurs, la performance en OpenMP dépasse 16x la performance en séquentiel.
  
 Il existe certainement des méthodes plus "​astucieuses"​ pour faire cela directement à l'​intérieur du code source. Mais nous voulions illustrer que l'​exploitation optimale des performances ne passe pas "​que"​ par le code source. Cela passe par les options de compilation (que nous n'​avons pas évoquée) mais surtout par une connaissance du système d'​exploitation et de ses mécanismes. Il existe certainement des méthodes plus "​astucieuses"​ pour faire cela directement à l'​intérieur du code source. Mais nous voulions illustrer que l'​exploitation optimale des performances ne passe pas "​que"​ par le code source. Cela passe par les options de compilation (que nous n'​avons pas évoquée) mais surtout par une connaissance du système d'​exploitation et de ses mécanismes.
Ligne 297: Ligne 297:
 ==== Parallélisation avec OpenCL ==== ==== Parallélisation avec OpenCL ====
  
-Bien qu'​existant depuis plus de 10 ans [[https://​fr.wikipedia.org/​wiki/​OpenCL|OpenCL]] est un mal aimé dans les approches de programmation ​parallèles. Et pourtant, il dispose d'un atout de choix : son universalité ​ ; il est en effet possible, en programmant "​bien"​ en OpenCL, d'​avoir un même programme fonctionnant sans modification et sans recompilation,​ sur la presque quasi-totalité des GPU, sur des FPGA Intel ou Xilinx, sur des DSP mais aussi sur les processeurs. ​+Bien qu'​existant depuis plus de 10 ans [[https://​fr.wikipedia.org/​wiki/​OpenCL|OpenCL]] est un mal-aimé dans les approches de programmation ​parallèle. Et pourtant, il dispose d'un atout de choix : son universalité ​ ; il est en effet possible, en programmant "​bien"​ en OpenCL, d'​avoir un même programme fonctionnant sans modification et sans recompilation,​ sur la presque quasi-totalité des GPU, sur des FPGA Intel ou Xilinx, sur des DSP mais aussi sur les processeurs. ​
  
-Il existe ainsi 3 implémentations OpenCL pour les processeurs : l'​historique et la première développée par AMD, déjà vieillissante mais exploitable sur les anciens processeurs (avant 2009), l'Open Source et l'inefficace dans Portable CL, dont le seul mérite est d'​exister et l'​implémentation Intel, méconnue et bien suivie (mises à jour régulières).+Il existe ainsi 3 implémentations OpenCL pour les processeurs : l'​historique et la première développée par AMD, déjà vieillissante mais exploitable sur les anciens processeurs (avant 2009), l'Open Source et l'inéfficace ​Portable CL, dont le seul mérite est d'​exister et l'​implémentation Intel, méconnue et bien suivie (mises à jour régulières).
  
-Le portage de notre code en OpenCL va cependant être plus long que sa parallélisation en OpenMP. Il existe des approches comparables avec OpenACC, fonctionnelles,​ mais elles exigent soit l'​exploitation du compilateur PGI (cher pour un non académique),​ soit l'​exploitation d'un compilateur ​effroyablement ​récent.+Le portage de notre code en OpenCL va cependant être plus long que sa parallélisation en OpenMP. Il existe ​également ​des approches comparables avec OpenACC, fonctionnelles,​ mais elles exigent soit l'​exploitation du compilateur PGI (cher pour un non académique),​ soit l'​exploitation d'un compilateur ​"​trop" ​récent.
  
-Précisons tout de suite que programmer en OpenCL //from scratch// dans du C pur est effroyable : par exemple, il faut intégrer DANS le code source le code OpenCL et préciser quelques lignes plus bas le nombre de lignes de code dans un noyau OpenCL. En effet, tout l'​intérêt de OpenCL va être d'​isoler les parties du code à paralléliser dans des "​noyaux"​ lesquels seront appelés en parallèle, massivement,​ très massivement. Pour GPU récent, il est possible de montrer que l'​optimum s'​obtient pour au moins 32 fois le nombre d'​unités de calcul. Si nous avons un processeur avec 8 coeurs, ce sera 256 fois. Si nous avons un GPU à 4352 coeurs, ce sera presque 140000. Tout le travail donc être d'​extraire du code source les parties qui feront partie de chacun de ces "​noyaux"​.+Précisons tout de suite que programmer en OpenCL //from scratch// dans du C pur est effroyable : par exemple, il faut intégrer DANS le code source le code OpenCL et préciser quelques lignes plus bas le nombre de lignes de code dans un noyau OpenCL. En effet, tout l'​intérêt de OpenCL va être d'​isoler les parties du code à paralléliser dans des "​noyaux"​lesquels seront appelés en parallèle, massivement,​ très massivement. Pour GPU récent, il est possible de montrer que l'​optimum s'​obtient pour au moins 32 fois le nombre d'​unités de calcul. Si nous avons un processeur avec 8 coeurs, ce sera 256 fois. Si nous avons un GPU à 4352 coeurs, ce sera presque 140000. Tout le travail donc être d'​extraire du code source les parties qui feront partie de chacun de ces "​noyaux"​.
  
-Plutôt que de coder en C ou en C++, beaucoup trop difficile ​à maintenir, nous choisissons l'​option Python. En effet, [[https://​documen.tician.de/​pyopencl/​|PyOpenCL]] existe depuis plus de 10 ans et permet de simplifier dramatiquement l'​exploitation de OpenCL. De plus, il existe également le pendant CUDA avec [[https://​documen.tician.de/​pycuda/​|PyCUDA]]. Profitons en pour remercier Andreas Kloeckner pour ces superbes outils !+Plutôt que de coder en C ou en C++, beaucoup trop difficiles ​à maintenir, nous choisissons l'​option Python. En effet, [[https://​documen.tician.de/​pyopencl/​|PyOpenCL]] existe depuis plus de 10 ans et permet de simplifier dramatiquement l'​exploitation de OpenCL. De plus, il existe également le pendant CUDA avec [[https://​documen.tician.de/​pycuda/​|PyCUDA]]. Profitons-en pour remercier Andreas Kloeckner pour ces superbes outils !
  
-Sachant que, pour exploiter au mieux nos machines, il faut paralléliser au maximum, regardons ​comme distribuer nos tâches en OpenCL. La première, c'est le code sans la moindre parallélisation,​ ce sera **Original**. La seconde, ce sera d'​appliquer la même méthode qu'en OpenMP : ce sera **EachCircle** où chaque tâche aura à traiter un paramètre d'​impact,​ donc parallélisme équivalent à la moitié de la taille de l'​image. ​Le troisième, ce sera d'​exploiter du //​raytracing//​ brutal, où, pour chaque pixel, la trajectoire est recherchée : ce sera la méthode **EachPixel**. Les deux dernières méthodes seront des méthodes hybrides : la première calculera toutes les trajectoires en parallèle, puis la seconde estimera en parallèle pour tous les secteurs de chaque cercle ​associé ​et chaque paramètre d'​impact la valeur de chaque pixel ; ce sera **TrajectoCircle**. La dernière exploitera les trajectoires calculées dans une première phase dans une seconde en associant directement ​un trajectoire à un pixel donné.+Sachant que, pour exploiter au mieux nos machines, il faut paralléliser au maximum, regardons ​comment ​distribuer nos tâches en OpenCL. La première, c'est le code sans la moindre parallélisation,​ ce sera **Original**. La deuxième, ce sera d'​appliquer la même méthode qu'en OpenMP : ce sera **EachCircle** où chaque tâche aura à traiter un paramètre d'​impact,​ donc  ​un ​parallélisme équivalent à la moitié de la taille de l'​image. ​La troisième, ce sera d'​exploiter du //​raytracing//​ brutal, où, pour chaque pixel, la trajectoire est recherchée : ce sera la méthode **EachPixel**. Les deux dernières méthodes seront des méthodes hybrides : la première calculera toutes les trajectoires en parallèle, puis la seconde estimera en parallèlepour tous les secteurs de chaque cercleet chaque paramètre d'​impact la valeur de chaque pixel ; ce sera **TrajectoCircle**. La dernière exploitera les trajectoires calculées dans une première phase, puis en une secondeen associant directement ​une trajectoire à un pixel donné.
  
-Ainsi, nous pouvons résumer, pour une image de taille NxN, le nombre de tâches exécutables en parallèles ​pour chaque méthode, le "​régime de parallélisme"​ en somme :+Ainsi, nous pouvons résumer, pour une image de taille NxN, le nombre de tâches exécutables en parallèle ​pour chaque méthode, le "​régime de parallélisme"​ en somme :
   * **Original** : 1   * **Original** : 1
   * **EachCircle** : N/2   * **EachCircle** : N/2
Ligne 318: Ligne 318:
 Chacune des méthodes (à l'​exception de **Original**) sera donc étudiée et comparée aux autres pour des images allant de 64x64 à 16384x16384. Dix lancements successifs pour chaque méthode permettront ensuite de disposer d'une statistique pertinente. ​ Chacune des méthodes (à l'​exception de **Original**) sera donc étudiée et comparée aux autres pour des images allant de 64x64 à 16384x16384. Dix lancements successifs pour chaque méthode permettront ensuite de disposer d'une statistique pertinente. ​
  
-Petit détail pour la métrologie : dans le cas du programme originel, le temps de calcul était estimé à partir de plusieurs //timers// : l'un en secondes indexé sur l'​horloge temps réel (''​time(NULL)''​),​ l'un en microsecondes sur la même horloge (''​getttimeofday()''​),​ le dernier exploitant ''​cputime()''​. Avec OpenCL, le principe est d'​exploiter un "​périphérique",​ même si ce dernier est en fait le processeur. Les pesaces ​mémoire exploités doivent être échangés entre l'​hôte et le périphérique,​ et cela prend du temps ! Ainsi, il faut séparer deux durées : celle du calcul proprement dit (ce sera **Compute**),​ et celle du "temps écoulé",​ ajoutant le temps de calcul au temps de transfert de la mémoire du périphérique à l'​hôte (ce sera le **Elapsed**). ​+Petit détail pour la métrologie : dans le cas du programme originel, le temps de calcul était estimé à partir de plusieurs //timers// : l'un en secondes indexé sur l'​horloge temps réel (''​time(NULL)''​),​ l'un en microsecondes sur la même horloge (''​getttimeofday()''​),​ le dernier exploitant ''​cputime()''​. Avec OpenCL, le principe est d'​exploiter un "​périphérique",​ même si ce dernier est en fait le processeur. Les espaces "mémoire" ​exploités doivent être échangés entre l'​hôte et le périphérique,​ et cela prend du temps ! Ainsi, il faut séparer deux durées : celle du calcul proprement dit (ce sera **Compute**),​ et celle du "temps écoulé",​ ajoutant le temps de calcul au temps de transfert de la mémoire du périphérique à l'​hôte (ce sera le **Elapsed**). ​
  
 === Premier lancement en OpenCL === === Premier lancement en OpenCL ===
  
-Illustrons cela sur le processeur ''​TOP 1''​ de notre exécution séquentielle,​ sans parallélisation : sur le ThreadRipper 1950X. ​ Et comparons donc les temps de calcul ou écoulé pour les 7 méthodes pour une grosse image 16384x16384 : **Serial** sans parallélisation,​ **OpenMP** et les 5 méthodes exploitant OpenCL.+Illustrons cela sur le processeur ''​TOP 1''​ de notre exécution séquentielle,​ sans parallélisation : sur le ThreadRipper 1950X. ​ Et comparons donc les temps de calcul ou écoulés, en employant ​les 7 méthodespour une grosse image 16384x16384 : **Serial** sans parallélisation,​ **OpenMP** et les 5 méthodes exploitant OpenCL.
  
 {{ :​developpement:​activites:​qualification:​tr1950x_7methods_elapsed.png?​500 |}} {{ :​developpement:​activites:​qualification:​tr1950x_7methods_elapsed.png?​500 |}}
Ligne 342: Ligne 342:
 Inutile de préciser que, pour les processeurs antérieurs à 2008, leurs performances sont imperceptibles. Inutile de préciser que, pour les processeurs antérieurs à 2008, leurs performances sont imperceptibles.
  
-En Mono, nous retrouvons ​le facteur 2 de performances entre OpenCL et OpenMP pour le ThreadRipper. Mais pour les processeurs Intel récents, c'​est ​encore ​meilleur ! Les derniers Skylake d'​Intel (W-2145 et Gold 5122) présentent des performances entre 4 et 5 fois meilleures qu'en OpenMP ! Etrangement,​ le Silver 4114, pourtant Skylake, ne gagne "​que"​ 70% mais le numéro 1, le système disposant de 28 coeurs à base de E5-2680v4, double ses performances. Tous les processeurs Intel gagnent un OpenCL, même l'​antique système à base de E5440 ne fonctionnant qu'​avec l'​implémentation OpenCL d'AMD.+En Mono, nous retrouvons ​un facteur 2 de performances entre OpenCL et OpenMP pour le ThreadRipper. Mais pour les processeurs Intel récents, c'​est ​bien meilleur ! Les derniers Skylake d'​Intel (W-2145 et Gold 5122) présentent des performances entre 4 et 5 fois meilleures qu'en OpenMP ! Etrangement,​ le Silver 4114, pourtant Skylake, ne gagne "​que"​ 70% mais le numéro 1, le système disposant de 28 coeurs à base de E5-2680v4, double ses performances. Tous les processeurs Intel gagnent un OpenCL, même l'​antique système à base de E5440 ne fonctionnant qu'​avec l'​implémentation OpenCL d'AMD.
  
-En BB, le constat est plus nuancé. Pour le Threadripper,​ les performances OpenCL et OpenMP sont équivalentes et rétrograde ​de la seconde à la cinquième place. Les processeurs Intel s'en sortent plutôt mieux au point que le dernier Skylake W-2145 à 8 coeurs détrône le système à E5-2680v4 ​à 28 coeurs ! Pour les processeurs anciens X5550 et E5440, l'​OpenMP fait bien mieux.+En BB, le constat est plus nuancé. Pour le Threadripper,​ les performances OpenCL et OpenMP sont équivalentes et rétrogradent ​de la seconde à la cinquième place. Les processeurs Intel s'en sortent plutôt mieux au point que le dernier Skylake W-2145 à 8 coeurs détrône le système à base de E5-2680v4 ​avec 28 coeurs ! Pour les processeurs anciens X5550 et E5440, l'​OpenMP fait bien mieux...
  
 Regardons ces performances maintenant en intégrant les temps de transferts Regardons ces performances maintenant en intégrant les temps de transferts
Ligne 354: Ligne 354:
 {{ :​developpement:​activites:​qualification:​cpu_elapsed_bb.png?​500 |}} {{ :​developpement:​activites:​qualification:​cpu_elapsed_bb.png?​500 |}}
  
-En BB, nous réalisons quasiment les mêmes constats : Threadripper de second ​à cinquième, meilleur en OpenMP que OpenCL ; les Skylake bien meilleurs d'un facteur presque 3 en OpenCL ; le Silver et les deux Broadwell avec quelques % de mieux. ​Le système E5-2680v4 ​+En BB, nous réalisons quasiment les mêmes constats : Threadripper de deuxième ​à cinquième, meilleur en OpenMP que OpenCL ; les Skylake bien meilleurs d'un facteur presque 3 en OpenCL ; le Silver et les deux Broadwell avec quelques % de mieux.
  
 Quelles conclusions tirer de ces comparaisons ? Quelles conclusions tirer de ces comparaisons ?
  
-Tout d'​abord qu'​Intel a très bien travaillé son OpenCL pour ses propres processeurs... Sans les Skylake, essentiellement le Gold et le W-2145, les gains seraient substantiels pour la partie **Compute** mais fondent dès que les temps de transfert sont intégrés. Puis que le Threadripper "​résiste",​ mais pas pour tous les usages : un test trop sommaire peut donc rapidement induire en erreur quant à la performance d'un processeur. Ensuite que les processeurs anciens, dès lors que l'​implémentation Intel est exploitable (donc après la génération Nehalem), l'​OpenCL reste une bonne option. Enfin que, avec OpenCL, notre ratio de performances de calcul frise les 100 millions en BB et 35 millions en Mono. En intégrant les transferts, ces ratios tombent à 81 millions en BB et 17 millions en Mono : 8 ordres de grandeurs ​séparent ​des processeurs séparés de 30 ans.+Tout d'​abord qu'​Intel a très bien travaillé son OpenCL pour ses propres processeurs... Sans les Skylake, essentiellement le Gold et le W-2145, les gains seraient substantiels pour la partie **Compute** mais fondent dès que les temps de transfert sont intégrés. 
 + 
 +Puis que le Threadripper "​résiste",​ mais pas pour tous les usages : un test trop sommaire peut donc rapidement induire en erreur quant à la performance d'un processeur. 
 + 
 +Ensuite que les processeurs anciens, dès lors que l'​implémentation Intel est exploitable (donc après la génération Nehalem), l'​OpenCL reste une bonne option. 
 + 
 +Enfin que, avec OpenCL, notre ratio de performances de calcul frise les 100 millions en BB et 35 millions en Mono. En intégrant les transferts, ces ratios tombent à 81 millions en BB et 17 millions en Mono : 8 ordres de grandeurs ​distinguent ​des processeurs séparés de 30 ans.
  
 === Intégration des accélérateurs en OpenCL === === Intégration des accélérateurs en OpenCL ===
Ligne 370: Ligne 376:
 {{ :​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, poiur notre première exploitation de GPU, son comportement n'est pas du tout éauivalent ​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-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.
  
 == AMD : les trois dernières générations == == AMD : les trois dernières générations ==
Ligne 378: Ligne 384:
 {{ :​developpement:​activites:​qualification:​amdvsbestcpu.png?​500 |}} {{ :​developpement:​activites:​qualification:​amdvsbestcpu.png?​500 |}}
  
-Nous constatons que ce n'est "​que"​ pour la dernière génération de GPU que AMD dépasse sensiblement nos meilleurs CPU. Avec la Radeon 7, les performances sont entre 2 et 3 fois supérieures en BB et en Mono. Le ratio de performances entre Mono et BB passe de presque 10 à moins de 4, preuve que AMD, dans ses dernières générations adopte un comportement à la charge comparable à celui d'un processeur.+Nous constatons que ce n'est "​que"​pour la dernière génération de GPUque AMD dépasse sensiblement nos meilleurs CPU. Avec la Radeon 7, les performances sont entre 2 et 3 fois supérieures en BB et en Mono. Le ratio de performances entre Mono et BB passe de presque 10 à moins de 4, preuve que AMD, dans ses dernières générations adopte un comportement ​"à la charge" ​comparable à celui d'un processeur.
  
 == Nvidia : 5 générations de "​Gaming"​ == == Nvidia : 5 générations de "​Gaming"​ ==
  
-A l'​origine,​ c'est bien le détournement des cartes de "​gaming"​ grand initateur ​de l'​exploitation des GPU en informatique scientifique. Il est donc naturel de comparer nos deux meilleurs processeurs à 5 générations successives de cartes Nvidia en OpenCL : la GTX560Ti (circuit Fermi), la GTX780Ti (circuit Kepler), la GTX980Ti (circuit Maxwell), la GTX 1080 Ti (circuit Pascal) et la RTX Titan (circuit Turing).+A l'​origine,​ c'est bien le détournement des cartes de "​gaming"​ grand initiateur ​de l'​exploitation des GPU en informatique scientifique. Il est donc naturel de comparer nos deux meilleurs processeurs à 5 générations successives de cartes Nvidia en OpenCL : la GTX560Ti (circuit Fermi), la GTX780Ti (circuit Kepler), la GTX980Ti (circuit Maxwell), la GTX 1080 Ti (circuit Pascal) et la RTX Titan (circuit Turing).
  
 {{ :​developpement:​activites:​qualification:​nvidiagamervsbestcpu.png?​500 |}} {{ :​developpement:​activites:​qualification:​nvidiagamervsbestcpu.png?​500 |}}
  
-En Mono, nous constatons que, dès la GTX780Ti (de fin 2013), un GPU de Gamer dépasse n'​importe lequel des processeur. La progression en Mono des performances et (presque linéaire) entre Fermi et Turing, à l'​exception de la génération Maxwell, un peu en deça des performances attendues. En BB, c'est bien différent : il faut attendre la toute dernière génération pour obtenir une performance comparable. Il existe toujours également un ratio spectaculaire de performances pour les GPU de Gamer entre Mono et BB : largement supérieur à 10.+En Mono, nous constatons que, dès la GTX780Ti (de fin 2013), un GPU de Gamer dépasse n'​importe lequel des processeurs. La progression en Mono des performances et (presque linéaire) entre Fermi et Turing, à l'​exception de la génération Maxwell, un peu en deça des performances attendues. En BB, c'est bien différent : il faut attendre la toute dernière génération pour obtenir une performance comparable. Il existe toujours également un ratio spectaculaire de performances pour les GPU de Gamer entre Mono et BB : largement supérieur à 10.
  
 == Et les accélérateurs non GPU dans tout ça ? == == Et les accélérateurs non GPU dans tout ça ? ==
Ligne 424: Ligne 430:
 En effet, pour exploiter efficacement CUDA, il faut IMPERATIVEMENT solliciter les "​Threads"​. En effet, la programmation en CUDA (et en OpenCL) désarçonne le néophyte en présentant deux "​étages"​ de parallélisme. Si l'​existence de ces deux étages est pleinement compréhensible au regard d'une multiplication de matrices (chaque élément de la matrice résultante est indépendant de tous les autres mais le calcul de chaque élément lui aussi peut être parallélisé),​ elle impose une gestion plus compliquée de la distribution des tâches, essentiellement parce que, si le premier étage permet de lancer plus d'un milliard de tâches concurrentes,​ le second ne permet d'en lancer que 1024. En effet, pour exploiter efficacement CUDA, il faut IMPERATIVEMENT solliciter les "​Threads"​. En effet, la programmation en CUDA (et en OpenCL) désarçonne le néophyte en présentant deux "​étages"​ de parallélisme. Si l'​existence de ces deux étages est pleinement compréhensible au regard d'une multiplication de matrices (chaque élément de la matrice résultante est indépendant de tous les autres mais le calcul de chaque élément lui aussi peut être parallélisé),​ elle impose une gestion plus compliquée de la distribution des tâches, essentiellement parce que, si le premier étage permet de lancer plus d'un milliard de tâches concurrentes,​ le second ne permet d'en lancer que 1024.
  
-Dans notre cas, il ne suffit plus de remplacer un //​workitem//​ ''​get_global_id(0)''​ définissant l'​indice d'une tâche ​élémentaure ​par un ''​BlockIdx.x''​ mais par une combinaison finement choisie de ''​BlockIdx''​ et ''​ThreadIdx''​. ​Ce qui donne, dans notre cas, pour une position ''​xi'',​ nous avons en OpenCL :+Dans notre cas, il ne suffit plus de remplacer un //​workitem//​ ''​get_global_id(0)''​ définissant l'​indice d'une tâche ​élémentaire ​par un ''​BlockIdx.x''​ mais par une combinaison finement choisie de ''​BlockIdx''​ et ''​ThreadIdx''​. ​Dans notre cas, pour une position ''​xi'',​ nous avons en OpenCL :
 <​code>​ <​code>​
 uint xi=(uint)get_global_id(0);​ uint xi=(uint)get_global_id(0);​
Ligne 439: Ligne 445:
 == 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, ​Teska 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 GPGOU vieillissant.+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.
  
 {{ :​developpement:​activites:​qualification:​cudavsall_compute_bb.png?​500 |}} {{ :​developpement:​activites:​qualification:​cudavsall_compute_bb.png?​500 |}}
developpement/activites/qualification/30ans1code.txt · Dernière modification: 2019/12/17 15:34 par equemene