Différences
Ci-dessous, les différences entre deux révisions de la page.
| Les deux révisions précédentes Révision précédente | Prochaine révision Les deux révisions suivantes | ||
|
developpement:activites:qualification:30ans1code [2019/12/17 11:27] equemene |
developpement:activites:qualification:30ans1code [2019/12/17 11:40] equemene |
||
|---|---|---|---|
| Ligne 176: | Ligne 176: | ||
| {{:developpement:activites:qualification:k6-2_hammsqueeze.png?500|}} | {{: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. | + | 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. | + | Au final, le RISC86 et la vectorisation du K6-2 auront offert 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 === | === Avant la multiplication des coeurs, le passage de l'an 2000 === | ||
| Ligne 206: | Ligne 206: | ||
| {{:developpement:activites:qualification:quadcores.png?500|}} | {{: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... | + | 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édécesseur (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|}} | {{:developpement:activites:qualification:quadcores_log.png?500|}} | ||
| Ligne 212: | Ligne 212: | ||
| === Avec les processeurs les plus "gros" ou les plus récents === | === 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. | + | 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 physiques 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|}} | {{:developpement:activites:qualification:serialallprocessors.png?500|}} | ||
| Ligne 218: | Ligne 218: | ||
| 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. | 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). | + | 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'exploitation 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. | 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. | ||
| Ligne 226: | Ligne 226: | ||
| {{:developpement:activites:qualification:serialallprocessorsvsfreq.png?500|}} | {{: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. | + | Nous constatons que les processeurs au sein d'une même génération sont parfaitement 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. | + | 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 ? === | === Et la loi de Moore dans tout ça ? === | ||
| Ligne 239: | Ligne 239: | ||
| * une période entre 2000 et 2019 de faible 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 ! | + | 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 micro-informatique ! |
| 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). | 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). | ||
| Ligne 247: | Ligne 247: | ||
| ===== La parallélisation du code ===== | ===== La parallélisation du code ===== | ||
| - | Nous allons explorer plusieurs approches de parallélisation. Tout d'abord, la première va chercher à minimiser au maximum la modification du code source avec OpenMP. Puis, la seconde va explorer les approches de distribution massives de tâches avec OpenCL sur CPU : cette méthode permettra en outre, par son universalité, de pouvoir "aussi" être exploitée sur les GPU. Enfin, cette approche OpenCL sera modifier pour exploiter la méthode classique d'exploitation des GPU Nvidia via CUDA. | + | Nous allons explorer plusieurs approches de parallélisation. Tout d'abord, la première va chercher à minimiser au maximum la modification du code source avec OpenMP. Puis, la seconde va explorer les approches de distribution massives de tâches avec OpenCL sur CPU : cette méthode permettra en outre, par son universalité, de pouvoir "aussi" être exploitée sur les GPU. Enfin, cette approche OpenCL sera modifiée pour exploiter la méthode classique d'exploitation des GPU Nvidia via CUDA. |
| ==== Parallélisation à la OpenMP ==== | ==== Parallélisation à la OpenMP ==== | ||
| Ligne 253: | Ligne 253: | ||
| 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. | 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. | + | 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, une 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 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. | + | 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 est 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. | + | 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. | + | Il est donc 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. | Pour ne pas surcharger les résultats, nous séparons les simulations BB et Mono. | ||