La programmation parallèle et OpenMP : le présent et le futur

Version imprimable

16/03/2017, 07h01
Michael Guilloux

La programmation parallèle et OpenMP : le présent et le futur

La programmation parallèle et OpenMP : le présent et le futur
un livre blanc d’Intel disponible en téléchargement

Le but d'un programme est d'exécuter une tâche, et pour cela, on donne à l'ordinateur une liste d'instructions qu'il va effectuer en général les unes après les autres. Lorsque l'ordinateur a fini de traiter une instruction, il exécute la suivante.

Mais il y a aussi une autre manière de le faire. On peut, pour gagner du temps, découper la tâche en un ensemble de petites tâches qui seront exécutées en même temps : on peut donc parler de programmation parallèle. Elle tire parti du fait que les processeurs récents sont dotés de plusieurs cœurs. Cette augmentation du nombre de cœurs nécessite de nouvelles habitudes de programmation pour profiter de ces ressources, sachant qu'un programme non adapté n'utilise qu'un seul des cœurs. Pour exploiter cette puissance de calcul, il est nécessaire de découper une tâche conséquente en un ensemble de petites tâches pouvant être traitées sur plusieurs cœurs de manière simultanée.

Aujourd'hui, quand on parle de programmation parallèle, on pense également à OpenMP. Il s’agit d’une interface de programmation pour le calcul parallèle sur architecture à mémoire partagée. Cette API est prise en charge par de nombreuses plateformes, incluant GNU/Linux, OS X et Windows, pour les langages de programmation C, C++ et Fortran. OpenMP se présente sous la forme d'un ensemble de directives, d'une bibliothèque logicielle et de variables d'environnement.

OpenMP est portable et dimensionnable. Il permet de développer rapidement des applications parallèles à petite granularité en restant proche du code séquentiel.

OpenMP Technical Report 4 : Version 5.0 Preview 1 (pour faire court TR4) est le pas suivant dans l’évolution d'OpenMP. Il ajoute la réduction des tâches et représente une extension de la programmation parallèle SIMD et augmente considérablement la productivité de la programmation hétérogène.

Dans un livre blanc, Intel passe en revue les caractéristiques de l’OpenMP existant et nous présente en avant-première les nouveautés à venir dans les mises en œuvre utilisant TR4. Le livre blanc est disponible gratuitement en téléchargement.

:fleche: Télécharger le livre blanc
29/03/2017, 17h26
athlon64

Pour souligner qu'on peut faire aussi de la programmation parallèle sans CPU multicœurs, on peut utiliser par exemple le processeur graphique (GPU) pour calculer (GPGPU).
Certains programmes offrent des gains tellement considérables par rapport au calcul sur CPU que le calcul sur ce dernier est désactivé pour ne pas ralentir les opérations...
29/03/2017, 17h40
dourouc05

Justement, j'ai plutôt entendu dire que, pour exploiter au mieux la puissance disponible, certains codes de calcul répartissent la charge entre CPU et GPU. Il s'agissait plutôt de démos assez réduites de chez NVIDIA que du code industriel ou de recherche, cependant.

Le gros problème des GPU, c'est que c'est difficile à bien exploiter, leur architecture est très différente des CPU.
31/03/2017, 18h45
athlon64

1 pièce(s) jointe(s)

Oui tout à fait on parle calculs hétérogènes quand on utilise à la fois les CPU et GPU pour calculer, lorsqu'on a des types de taches différentes et que c'est bien organisé ça passe encore,
c'est à dire le CPU fait un genre de tache et le GPU d'autres.
Mais si c'est un même calcul qui doit être subdivisé en mini taches et reparti sur les deux modules, ça devient un brin délicat, puisque'il faut synchroniser... En effet comme tu le dis :

Citation:

Envoyé par dourouc05

Le gros problème des GPU, c'est que c'est difficile à bien exploiter, leur architecture est très différente des CPU.

SI le CPU est une voiture de sport classique, le GPU serait une camion poids lourd...

Ainsi lorsque'on veut partager la même tache de calcul entre CPU et GPU, ben le CPU va plus vite mais traite peu de données, le GPU plus lent mais traite plus de données, il faut repartir les données pour que sur le CPU et le GPU elles finissent +ou- en même temps autrement la tache n'est pas terminée... Cela ajoute de la complexité au programme pour un gain de perf plus que discutable.

En effet les GPU sont devenus très puissantes de nos jours autant chez AMD que chez Nvidia, une Gtx 1080 normale par exemple a 2560 cœurs qui peuvent tourner à plus de 1 GHz, les CPU actuels 8 cœurs à 4 GHz à peu près...
En fonction des config on peut observer des perfs CPU/GPU de l'ordre de 1/20 voire 1/50 , pourquoi s’embêter à utiliser le CPU dans ce cas... ?

Autre technique redoutable c'est comme tout le monde le sait on peut mettre plusieurs cartes graphiques dans une tour... Là ça fait fait mal...

Pièce jointe 259828

OpenMP à la base n’était dispo que pour les CPU, mais maintenant il supporte aussi le GPU, sinon il y a aussi OpenACC qui fonctionne aussi comme openMP.
31/03/2017, 21h19
zobal

Citation:

Envoyé par athlon64

En fonction des config on peut observer des perfs CPU/GPU de l'ordre de 1/20 voire 1/50 , pourquoi s’embêter à utiliser le CPU dans ce cas... ?

Déjà c'est plutôt de l'ordre de 1/10 à niveau d'optimisation équivalent, et encore ça dépend du problème et ça demande pas mal de boulot supplémentaire. Ensuite passer un code sur GPU c'est loin d'être trivial donc ce serait plutôt "pourquoi s'embêter à utiliser le GPU".

Citation:

Envoyé par athlon64

OpenMP à la base n’était dispo que pour les CPU, mais maintenant il supporte aussi le GPU, sinon il y a aussi OpenACC qui fonctionne aussi comme openMP.

Les supports GPU d'openmp et d'openacc sont encore très expérimentaux ou limités à des compilateurs commerciaux et à certains GPU.
03/04/2017, 13h49
athlon64

1 pièce(s) jointe(s)

Le GPU ne remplace pas le CPU, le GPU reste cloisonné à certains calculs bien déterminés, je parle de calculs génériques (opérations arithmétiques, matricielles).

Pourrais-tu expliquer pourquoi tu t’arrêtes seulement à

Citation:

1/10 à niveau d'optimisation équivalent

?

Pour les chiffres que j'ai donnés, je pars par exemple de matériels sortis à la même période, c'est à dire un CPU de 2016 à un GPU de 2016, ou dans une config gamer un CPU assez rapide pour ne pas présenter de bottleneck au GPU ...
De plus comme c'est précisé on peut mettre plusieurs cartes graphiques dans une tour, on peut même en mettre beaucoup plus dans des rack dédies

Pièce jointe 260649

Citation:

A niveau d'optimisation équivalent

Oui tout à fait, et les CPU ont déjà des niveaux d'optimisations internes très avancées comparés au GPU. D'une certaine façon le GPU rime avec parallélisme, si le problème qu'on a n'est pas parallélisable, voire massivement parallélisable, c'est même pas la peine de déporter le calcul sur GPU, on est d'accord.
Par exemple une factorielle ou une boucle récurrente sont des opérations séquentielles qui ne gagneront pas en perf à tourner sur GPU, alors que par exemple des algorithmes de simulations de type N body ou permettant de cracker de mots de passe sont plus adaptés à la parallélisation.

La plupart des meilleurs superordinateurs du monde, actuellement sont des mixes CPU/GPU, et ce seulement depuis quelques années, ça prouve que le marché mûrit. CUDA, OpenACC, OpenCL sur GPU sont exploitables, pour OpenMP je ne connais pas très bien les avancées GPU mais plutôt sur CPU.