✎ developpement:activites:qualification:30ans1code[CBP]

✎ developpement:activites:qualification:30ans1code
Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== 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.**


"Un code pour les exploiter tous,\\
 Un code pour les évaluer,\\
 Un code pour les confronter tous..."

"Et sur des plateaux techniques les comparer \\
 Dans une computhèque où ils subsistent sans crainte."

(détournement de Tolkien...)
===== Résumé =====

Partout, on parle d'augmentation de puissance de calcul des ordinateurs mais comment et en quoi ces capacités ont-elles évolué ces 30 dernières années ? Quoi de plus illustratif que de chercher à "retrouver" par la simulation une image comparable à celle qui a inondé nos médias en ce printemps 2019 : celle d'un trou noir et son écharpe de plasma. Partant du premier article représentant un trou noir, un programme de 25 ans d'âge sera modifié et exécuté sur différents "moteurs de traitement de l'information", les processeurs, classiques, graphiques et éphémères : ceux qui existaient il y a 30 ans, ceux qui émergeaient il y a 10 ans et ceux d'aujourd'hui. 

===== Flash Back de 40 ans : Entre l'image "mesurée" de 2019 et l'image simulée de 1979 =====

Impossible, en ce printemps 2019, d'échapper à cette "image" du trou noir de Messier 87. Belle "image", plus dans son sens étymologique que son sens "photographique". Ce qui est dommage, c'est que le traitement médiatique de l'évènement se soit focalisé sur une brillante programmeuse ayant participé à la réduction de données... Dommage parce que c'est la conjonction du dispositif de synthèse d'ouverture (qui a bouleversé l'astronomie ces dernières décennies) et la progression exponentielle de la puissance de calcul scientifique qui ont permis, ensemble, de parvenir à cette prouesse.

{{:developpement:activites:qualification:blackhole20190410.jpg?400|}}

Aussitôt cette "image" publiée, montrant sans ambiguïté l'horizon du cadavre obscur et son possible disque d'accrétion en rotation, beaucoup se sont rappelés une autre image, la première image (simulée cette fois) d'un disque d'accrétion autour d'un trou noir. Pour cela, il fallait revenir 40 ans en arrière avec un article publié en 1979 dans Astronomy & Astrophysics par un jeune astrophysicien, Jean-Pierre Luminet. Sur la dernière page de son article apparaissait la première image, image issue cette fois d'une expérience numérique. 

{{:developpement:activites:qualification:1979aa_75_228l.png?400|}}

===== De l'article de 1979 à un sujet de travaux pratiques en 1993 =====

De cet article a émergé un sujet de travaux pratiques de DEA (ancien Master 2) d'Astrophysique parisien, celui de Meudon. Et ce sujet a donné naissance à un programme, à l'époque écrit en Fortran 77.

{{ :developpement:activites:qualification:trou_noir_1994_flux.png?300|}}
{{:developpement:activites:qualification:trou_noir_1994_z.png?300| }}

Quelques années plus tard, un des étudiants (moi même ;-) ) reprend ce programme et le porte en langage C sans requérir à aucune librairie d'affichage. Les images se multiplient et deviennent [[http://www.cbp.ens-lyon.fr/emmanuel.quemener/documents/TrouNoir/z_bb.mpg|Vidéo Doppler]], montrant un voyage autour du disque gravitant autour d'un trou noir [[http://www.cbp.ens-lyon.fr/emmanuel.quemener/documents/TrouNoir/f_bb.mpg|Vidéo Corps Noir]].

{{ :developpement:activites:qualification:flux_bb.jpg?300|}}
{{:developpement:activites:qualification:z_bb.jpg?300| }}

Il aura fallu 22 ans (un cycle solaire ;-) ) pour que ce programme en C serve de matrice à un autre programme permettant d'exploiter les deux révolutions technologiques majeures de ce 21e siècle en informatique : la multiplication des coeurs et l'exploitation des GPU comme accélérateur.

=== Simuler l'image d'un trou noir, mais comment ? ===

La méthode numérique pour construire cette image est aussi vieille que la génération d'images par ordinateur : le //[[https://fr.wikipedia.org/wiki/Ray_tracing|lancer de rayons]]// (ou //raytracing//). Le principe consiste à "remonter le temps" : partir de chaque élément de l'image (ou de chaque pixel) et suivre son parcours jusqu'à sa "source". Chaque rayon peut intercepter une surface ou pas. Si non, le pixel est noir, si oui, le pixel a un "couleur" à définir par rapport à son point de contact. Si l'objet est bleu, le pixel sera bleu mais avec une intensité déterminée à partir de des lois physiques. La surface peut aussi être transparente et le rayon peut poursuivre sa route jusqu'à intercepter une autre surface.

Dans notre cas, les rayons ne sont pas des lignes mais suivent des "géodésiques de l'espace-temps", lesquelles sont des courbes dans un espace courbe. Il faudra donc estimer, pour chaque pixel, quelle est la trajectoire du rayon. 3 solutions s'offrent alors pour son origine :
  * soit elle sort de la "zone" de nos objets (trou noir et disque), au delà du rayon externe : le pixel est noir
  * soit elle rentre à un distance inférieure au rayon de Schwarzschild et ne peut en sortir : le pixel est noir (un peu le principe du trou noir, c'est que rien n'en sort en deça du fameux rayon de Schwarzschild)
  * soit elle intercepte le disque : le pixel est d'une intensité à définir à partir de l'intersection entre trajectoire et disque

C'est comme cela que toutes les images par lancer de rayons sont construites.

===== L'évolution informatique des années 1990-2010 en cinq révolutions technologiques =====

==== Loi de Moore & loi d'Ohm ====

En électronique, les lois gouvernant le plus l'évolution technologique sont la loi de Moore et la loi d'Ohm. 

La loi "commune" de Moore stipule que la "puissance" de traitement d'un circuit double tous les 18 mois. En fait, Moore n'a jamais proposé cette loi en l'état mais a proposé qu'un circuit intégrait chaque année deux plus de de transistors pour le même budget que l'année précédente. Il révisa en 1975 son énoncé en allongeant la période de doublement de transistors à deux années.

La loi d'Ohm décrit elle le comportement endémique d'un composant électrique à dissiper une partie de son énergie sous forme de chaleur quand un courant électrique le traverse. Si cette dernière loi est très utile pour nos bouilloires ou nos machines à laver, elle est plutôt gếnante lorsqu'il s'agit de composants électroniques, notamment les circuits électroniques présents dans tous nos équipements quotidiens.

==== 30 "systèmes informatiques" et un seul programme ====

Nous allons illustrer 5 révolutions technologiques de ces 30 dernières années en exécutant (presque) un même programme sur 30 "systèmes informatiques" différents : 16 d'entre eux seront des systèmes à base de processeurs traditionnels (un ou plusieurs CPU ou Central Processing Units), 13 à base de circuits graphiques (des GPU ou GPGPU pour Graphical Processing Units ou General Purpose GPU) et le 30ème sera le seul accélérateur de type MIC (Many Integrated Cores).

Parmi les 16 processeurs testés, 11 Intel et 5 AMD, des modèles entre 1989 et 2018. Pour les processeurs Intel : 80386SX, 80486SX, 80486DX4, Pentium 4 Northwood, E5440, X5550, E5-2637v4, E5-2680v4, Gold 5122, Silver 4144 et W-2145. Pour les AMD : Amd5x86, K6-2, K7, AthlonX2, ThreadRipper 1950X. Leurs fréquence va de 25 MHz pour le plus lent à 3.7 GHz pour le plus rapide.

Pour la panoplie des GPU, nous avons 5 générations successives de circuits graphiques de gamer Nvidia de 2013 à 2019 avec les cartes GTX 560 Ti, GTX 780 Ti, GTX 980 Ti, GTX 1080 Ti, RTX Titan. Pour les circuits Nvidia graphiques "dédiés" au calcul, nous avons 5 générations Tesla : C1060, M2090, K40m, P100, V100. Pour les AMD, nous avons les trois dernières générations : Nano Fiji, Vega 64 et Radeon VII. A ces 13 accélérateurs de type GPU s'ajoute le Xeon Phi Intel 7120P.

==== Echantillon de machines pertinent pour la loi de Moore ? ====

Comme premier travail cherchons d'abord à vérifier si notre échantillon de processeurs informatiques "respecte" la loi de Moore. Ce premier travail de bibliographie n'est pas si anodin que cela. 

En effet, avant 2010, tout allait bien : d'un côté, tous les processeurs sont bien documentés et la base de données Ark d'Intel publiait sans souci le nombre de transistors sur ses sockets de processeurs. Ainsi, nous apprenons que le E5440 dispose de 810 millions de transistors et le X5550 de 731 millions. Nous pouvons être surpris de voir le nombre de transistors baisser alors que le nombre de coeurs est identique, surtout que ce dernier embarque le contrôleur mémoire alors que son aîné avait cela sur son processeur. Ceci illustre un élément intéressant, lequel apparaît nettement si nous regardons une photographie de la lithographie d'un processeur : la mémoire cache "occupe" une surface imposante des processeurs, et donc un nombre croissant de transistors : autour de 40% pour le E5440 et 30% pour le X5550. A partir de la génération suivante, Westmere, Intel est beaucoup moins prolixe sur le nombre de transistors et les informations deviennent de plus en plus difficiles à trouver avec la croissance du nombre de coeurs. Etablir une relation entre le nombre de coeurs et le nombre de transistors, pour une génération donnée de processeur, tient de l'ingenérie inverse : des informations fragmentaires sont à dénicher sur des sites spécialisés, en les recoupant, et, surtout, en sachant résoudre des systèmes d'équations ! Ce sont donc des estimations pour certains d'entre eux.

Ainsi, nous avons 275000 transistors pour le 80386SX, le 80486SX est le premier à dépasser le million, le K6-2 approche les 10 millions. Le milliard n'est dépassé qu'en associant 2 E5440 Harpertown et le plus "lourd" reste le ThreadRipper hébergeant près de 10 milliards de transistors.

A la représentation de l'évolution du nombre de transistors des "systèmes processeurs", nous ajoutons leur évolution en fréquence. Nous avons ajouté la "fréquence turbo". Cette fréquence est très significative pour les processeurs récents, représentant jusqu'à 40% de la fréquence nominale. Elle est essentiellement exploitée pour les tâches non parallélisées.

Une représentation logarithmique permet de saisir la progression géométrique du nombre de transistors. Pour la fréquence, elle suit aussi une progression géométrique mais, en 2005, s'arrête, régresse et repart légèrement à la hausse. Avec une méthode de régression de type moindre carrés, tâchons de retrouver les "lois" qui gouvernent ces droites.

{{ :developpement:activites:qualification:transistorsfrequencies.png?500 |}}

Pour le nombre de transistors, si nous exprimons cette loi par ''Transistors(Y)=exp(a*Y+b)'', nous trouvons que ''a'' vaut ''0.342'' et ''b'' vaut ''-667''. Si nous cherchons le temps qui sépare le doublement du nombre de transistors par cette loi, nous effectuons le calcul ''ln(2)/a'' et nous trouvons ''2.02'', soit 2 à 1% près ! Effectivement, nous retrouvons la loi selon laquelle l'intégration de transistors sur un support double tous les deux ans : la loi de Moore. Petit détail comique : si nous cherchons quand le nombre de transistors était égal à l'unité (par ''-b/a''), nous tombons sur 1951 (seulement 3 ans après l'invention du transistors :-).

Quant est-il de l'évolution de la fréquence ? Nous constatons 2 périodes successives : une première suit une loi à peu près comparable de 1989 à 2004. En exprimant cette loi par un ''Frequence(Y)=exp(c*Y+d)'', nous trouvons ''c=0.307'' et ''d=-609''. La fréquence a donc doublé tous les 27 mois en moyenne durant cette période. Après, nous assistons à un léger replis sous les 3 GHz puis une réaugmentation ces toutes dernières années. Cette "brisure" est fondamentale : elle illustre comment l'effet Joule a stoppé net la progression de la fréquence alors que la miniaturisation des transistors se poursuivait. Les transistors devaient donc être exploité "autrement".

Toujours est-il que cette simple représentation montre que notre échantillon est bien pertinent : il respecte la loi de Moore et nous montre cette "transition" en 2004 sur la fréquence. Reste maintenant à exécuter notre code.

==== Quelles révolutions informatiques ces 30 dernières années ? ====

Il ne suffit pas de disposer de plus de transistors sur un processeur pour augmenter sa capacité de traitement. Cependant, cette croissance complémentaire va permettre d'intégrer directement dans le circuit des éléments qui ne s'y trouvaient pas, ou seulement dans des architectures "confidentielles" pour l'époque. Voici les 5 (r)évolutions que nous avons choisies :
  * intégration systématique d'une unité de calcul en virgule flottante, la FPU (ou Floating Point Unit)
  * exploitation de l'architecture RISC en interne au processeur
  * utilisation d'unités de calcul vectoriel
  * multiplication des coeurs dans un socket
  * manipulation de cartes graphiques pour le calcul

Chacune de ces révolutions sera illustrée par un avant et un après :
  * Intégration FPU. Avant : le 30386SX et le 80486SX. Après le 80486DX4 et le Amd5x86
  * Exploitation RISC et vectorisation. Avant : les précédents. Après : le K6-2
  * 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 ===

C'est un même code que nous allons exploiter mais ce dernier propose un certain nombre d'options. Parmi ces options, nous avons
  * la masse (en fait, un trou noir statique n'est défini "que" par ce paramètre)
  * la taille de l'image générée
  * les rayons intérieur et extérieur du disque de plasma
  * l'inclinaison de l'observateur par rapport au disque
  * la nature de l'émission du plasma :
    * émission monochromatique, noté Mono, irréaliste mais instructive
    * émission de corps noir, noté BB, plus réaliste

En fonction de la performance et de la mémoire disponible dans chaque système.

=== Intégration du calcul flottant dans le processeur ===

Dès le premier IBM PC, Intel a proposé sur sa carte mère d'associer au processeur une unité spécialisée permettant d'effectuer les opérations classiques de calcul en virgule flottante : le [[https://en.wikipedia.org/wiki/Intel_8087|8087]] était ainsi associé au processeur [[https://en.wikipedia.org/wiki/Intel_8086|8086]]. Cette approche s'est poursuivie durant toutes les années 1980 sur les évolutions de ses processeurs, le 80286 puis le 80386. Il suffisait d'ajouter un x87 (80287 ou 80387) pour "transformer des minutes en secondes".

Dans notre cas, nous allons exploiter 4 processeurs : deux sont dépourvus de coprocesseur flottant (le 80386SX à 40 MHz et le 80486SX à 25 MHz), deux en sont équipés (le 80486DX à 75 MHz et le Amd5x86 à 133 MHz).

Si nous évaluons les deux qui en sont dépourvus, nous avons :

{{:developpement:activites:qualification:8038680486.png?500|}}

Nous constatons que la fréquence ne fait pas tout ! En effet, le 80386SX est à une fréquence presque 2 fois supérieure au 80486SX et pourtant le 80486SX l'emporte largement. Plus de transistors ont permis au 80486SX de multiplier par 2.5x la performance dans les deux cas. 

Si nous ajoutons d'abord le premier processeur de notre gamme à être équipé de FPU, le 80486DX4, le gain est très significatif :

{{:developpement:activites:qualification:80486dx4.png?500|}}

Le gain est si impressionnant que la performance de nos deux premiers processeurs tombe dans les oubliettes ! Pour avoir une meilleure perception de cela, passons en échelle logarithmique :

{{:developpement:activites:qualification:80486dx4_log.png?500|}}

C'est plus de 2 ordres de grandeur (autour de 240) que nous permet de gagner le FPU (nous avons dédié la part liée à l'augmentation de fréquence). Effectivement, "les minutes deviennent des secondes" dans notre cas, et même mieux ! 

En ajoutant le premier processeur AMD le Amd5x86 de fréquence presque double au précédent, nous obtenons (en échelle logarithmique) :

{{:developpement:activites:qualification:fpu_apreslog.png?500|}}

L'augmentation de fréquence nous fait gagner autour d'un facteur 2. Rapportées à une même fréquence, ces performances sont comparables en BB mais doublées en Mono. Ainsi, l'architecture interne a son importance dans les performances.

La révolution du FPU a donc offert dans nos tests un gain entre 240 et 470. Avec l'augmentation de la fréquence, c'est un gain entre 815 et 1575.

=== Utilisation du RISC et de la vectorisation ===

Le premier processeur dont nous disposons équipé d'un jeu RISC (Reduced Instruction Set Computer) est le AMD K6-2. Evolution du K6, ce processeur intègre également des unités vectorielles 3D-Now. Nous l'avons évalué en exploitant deux distributions Debian (la Hamm de 1998 et la Squeeze de 2011). Cette comparaison croisée a permis de juger l'évolution des compilateurs des distributions respectives.

{{:developpement:activites:qualification:k6-2_hammsqueeze.png?500|}}

Si nous enlevons l'augmentation de fréquence (presque doublée), le changement d'architecture du Amd5x86 au K6 apporte un gain de 75% en BB et 2 en Mono si nous restons en 1998 (avec la distribution équipée d'un compilateur GCC version 2.7). Par contre, en 2011 avec un compilateur GCC 4.4, ce gain passe à presque 10 en BB et presque 5 en Mono. Ainsi, les microarchitectures anciennes (et là probablement la vectorisation) sont bien mieux supportées dans les compilateurs récents.

Au final, le RISC86 et la vectorisation du K6-2 auront offerts un gain de 2400 en BB et 2200 en Mono. Avec l'augmentation de fréquence, c'est un gain entre 12500 et 14000. C'est plus d'un ordre de grandeur par rapport à ce qu'offrait déjà l'intégration du FPU dans le processeur.

=== Avant la multiplication des coeurs, le passage de l'an 2000 ===

Notre processeur franchissant le millénaire est l'Athlon K7. Celui dont nous disposons retrouve un format "classique" sous forme de "socket" (la planche à clous) et abandonne le format en "carte d'extension" (en "slot"). Notre Athlon est cadencé à 800 MHz soit 3 fois la fréquence de base de notre K6-2.

{{:developpement:activites:qualification:k7_log.png?500|}}

Alors que sa fréquence est triple, le K7 offre entre 5.6 et 5.7 la performance du K6-2. Les progrès dans la microarchitecture suggèrent que le K7 parallélise en interne l'exécution des opérations. Nous sommes entre 70000x et 80000x en gain de performances par rapport à notre antique 80386SX.

=== Multiplication des coeurs sur les précurseurs ===

Les architectures internes vont évoluer entre le K6-2 de 1998 et le premier de nos processeurs à offrir du multi-coeur logique (le Pentium 4 Northwood) de 2004 ou le premier à offrir le multi-coeur physique (le AthlonX2) de 2005. Sur cette période cependant, les processeurs passent de 10 millions à 55 millions (pour le P4) voire 221 millions (pour l'AthlonX2). La fréquence augmente d'un facteur 10 à 15 : de 233 MHz en 1998 à 3 GHz en 2004.

Notre programme originel n'étant pas parallélisé, nous pouvons cependant l'exécuter et "juger" du gain que les générations successives de processeurs vont offrir.

La première comparaison consiste donc d'abord à rajouter nos deux Northwood et AthlonX2 évoqués plus haut à l'Athlon K7 arrivé en 2000.

{{:developpement:activites:qualification:northwood_athlonx2_log.png?500|}}

Les résultats du Northwood à 3 GHz et du AthlonX2 à 2600 MHz sont ambiguës face au K7 à 800 MHz. Pour une fréquence triple, l'AthlonX2 offre une performance triple en BB et un peu moins que triple en Mono. Pour une fréquence presque quadruple du Northwood, nous n'avons qu'un gain timidement doublé en B ou en Mono. La fréquence ne fait clairement pas tout et la microarchitecture de l'AthlonX2 ne semble pas tant que cela impacter les performances.

=== Les quatre générations de serveurs bi-sockets quadricoeurs ===

Nous avons intégré à notre test quatre serveurs en mode bi-socket (deux processeurs) de quatre générations de processeurs de serveur Xeon : Harpertown à 2930 MHz, Westmere à 2660 MHz, Broadwell à 3.5 GHz et Skylake à 3.6 GHz. 

{{:developpement:activites:qualification:quadcores.png?500|}}

Nous constatons non sans une certaine surprise que le processeur le plus récent avec la fréquence la plus élevée (le Skylake Gold 5122 à 3.6 GHz) est bien inférieur à son prédecesseur (le Broadwell E5-2637v4 à 3.5 GHz). Il faut aussi noter que, finalement, entre le Harepertown de 2008 et le Skylake de 2018, sur ce code séquentiel, c'est seulement un gain d'un facteur 3, bien en dessous de ce que 10 années précédentes avaient offert...

{{:developpement:activites:qualification:quadcores_log.png?500|}}

=== Avec les processeurs les plus "gros" ou les plus récents ===

A ces 4 systèmes équipés de 2 processeurs disposant de 4 coeurs, nous ajoutons 4 autres processeurs : un système disposant de 28 coeurs physiques (2 Broadwell E5-2680 à 2.4 GHz), un système disposant de 20 coeurs physiques (2 Skylake Silver à 2.2 GHz), un AMD Threadripper 1950X à 3.6 GHz disposant de 16 coeurs physique et un Skylake W-2145 à 3.6 GHz disposant de 8 coeurs. Ces quatre systèmes illustrent des configurations avec beaucoup de coeurs ou les dernières générations de processeurs disponibles au CBP.

 {{:developpement:activites:qualification:serialallprocessors.png?500|}}

Pas de grande surprise sinon la victoire d'une courte tête du Threadripper 1950X, devant le processeur de station de travail W-2145. Ainsi, ce n'est pas parce que c'est un processeur de serveur que c'est le plus performant, ou que c'est le plus récent à la fréquence la plus élevée.

Au final, nous avons exécuté un code séquentiel, exactement le **même code** sans modification (à quelques déclarations de variables près) sur des processeurs séparés de 30 ans sur des systèmes d'exploitations entre 1996 (la Debian Buzz) et 2019 (la Ubuntu 18.10 ou la Debian Buster). 

Le gain sans avoir modifié le code dépasse (ou approche) le million : 3 millions en BB mais "seulement" 700000 en Mono séparent le Intel 80386SX du Threadripper 1950X.

Dans ces gains, quelle est la part uniquement liée à la microarchitecture ? Pour cela, nous allons renormaliser nos résultats en divisant par la fréquence de chaque système.

{{:developpement:activites:qualification:serialallprocessorsvsfreq.png?500|}}

Nous constatons que les processeurs au sein d'une même génération sont complètement comparables (Skylake avec les Silver 4114, Gold 5122 et W-2145) en Mono et en BB. Il n'y a pas, en 15 ans (depuis le P4 Northwood) un gain supérieur à 3 en Mono. Le gain en BB est beaucoup plus significatif sur cette période : autour de 15.

Ainsi, le processeur le plus rapide sur notre problème est 3430x plus rapide en BB et plus de 7763x en Mono qu'un 80386SX à fréquence équivalente.  

=== Et la loi de Moore dans tout ça ? ===

{{:developpement:activites:qualification:moorelawsequentialwcurves.png?500|}}

En reportant sur les années de sortie les performances obtenues, nous constatons 2 périodes et une césure :
  * la césure a lieu en 1994 lorsque les processeurs embarquent une FPU
  * une période entre 1994 et 2000 de forte croissance
  * une période entre 2000 et 2019 de faible croissance

Entre 1994 et 2000, les deux droites de régression permettent d'estimer un doublement de performances au bout d'une année seulement (1.01 et 1.1 années en BB et en Mono respectivement) : l'âge d'or de la microinformatique ! 

Mais à partir de 2004, un vrai tassement avec "presque" un pallier de performances comme le montrait le schéma précédent : en fait, seule la performance en BB augmente significativement d'une génération de processeur à la suivante (20x entre le ThreadRipper et le Northwood en BB et seulement 4x en Mono).

Ce constat est sans appel : il va falloir exploiter tous les coeurs disponibles, logiques ou physiques, pour augmenter la performance de son code.

==== Parallélisation à la OpenMP ====

Programmer avec OpenMP se résume souvent de la manière suivante : "casser des boucles". En fait, il s'agit plutôt de respecter le premier principe de la parallélisation : on distribue ce qui peut l'être le plus longtemps possible.

Dans notre cas, la génération de notre image par //lancer de rayons// ne s'est pas faite pixel par pixel avec un calcul individuel des trajectoires. Nous avons exploité la symétrie du problème : la trajectoire ne dépend "que" de la distance qui sépare l'axe de l'image (pointant le centre du trou noir) avec la direction initiale du rayon partant de notre image. Cette valeur est le "paramètre d'impact". Ensuite, un fois cette trajectoire calculée pour ce paramètre d'impact, tous les pixels sur ce cercle étaient explorés pour savoir si oui ou non ils correspondaient à des trajectoires entrant en collision avec le disque.

La parallélisation naturelle s'est donc développée sur ce paramètre d'impact : pour une image 256x256, il y a 128 paramètres d'impact à explorer, lesquels peuvent être traités indépendamment, donc parallélisés. Cependant, nous pressentons un petit souci : au fur et à mesure que nous nous éloignons du centre de l'image, le cercle à explorer grandit et donc le nombre de pixels à explorer aussi. Traiter donc un paramètre d'impact "faible" prendra beaucoup moins de temps qu'un cercle de paramètre d'impact sur le bord de l'image.

La modification initiale du programme est plutôt simple : rajouter quelques directives (préfixées par ''#''). Cependant, il faut quand même prendre quelques précautions avec le code : le fait que chaque trajectoire soit traitée indépendamment impose de placer les déclarations de variables exploitées après les directives indiquant la portion à paralléliser. 

Dernier détail : lors de l'exécution d'un programme parallélisé avec OpenMP, le système d'exploitation "détecte" le nombre d'unités de calcul, le nombre de "coeurs" puis parallélise sur ce nombre de coeurs, c'est à dire lance un nombre de tâches simultanées à concurrence du nombre de coeurs disponibles. Il est aussi possible, via la variable d'environnement du système ''OMP_NUM_THREADS'', de "contrôler" le nombre de tâches qui seront exécutées simultanément.

Il est alors intéressant, avec les commandes "système", de contrôler si tous les coeurs sont bien exploités efficacement.

Pour ne pas surcharger les résultats, nous séparons les simulations BB et Mono.

{{ :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.

Regardons s'il en est de même en Mono.

{{ :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.

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.

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.

{{ :developpement:activites:qualification:tr_omp_bb.png?500 |}} 

La courbe violette montre la performance pour le code non parallélisé. Nous distinguons que pour une parallélisation fixée au nombre de coeurs physiques, la performance ne triple même pas alors que nous avons 16 coeurs. Si nous doublons le nombre de tâches concurrentes, la performance approche seulement 5x celle du code séquentiel. Par contre, pour une parallélisation imposée sur 64x le nombre de coeurs, la performance dépasse 16x.

Regardons s'il en est de même pour ma méthode Mono.

{{ :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.

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.