IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Programmation parallèle, calcul scientifique et de haute performance (HPC) Discussion :

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


Sujet :

Programmation parallèle, calcul scientifique et de haute performance (HPC)

  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Data Consultant
    Inscrit en
    Juillet 2013
    Messages
    2 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Data Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 2 875
    Points : 86 930
    Points
    86 930
    Billets dans le blog
    2
    Par défaut 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.

    Télécharger le livre blanc
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre confirmé Avatar de athlon64
    Profil pro
    Inscrit en
    Février 2009
    Messages
    243
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2009
    Messages : 243
    Points : 547
    Points
    547
    Par défaut
    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...

  3. #3
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    Août 2008
    Messages
    26 609
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2008
    Messages : 26 609
    Points : 188 580
    Points
    188 580
    Par défaut
    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.
    Vous souhaitez participer aux rubriques Qt (tutoriels, FAQ, traductions) ou HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  4. #4
    Membre confirmé Avatar de athlon64
    Profil pro
    Inscrit en
    Février 2009
    Messages
    243
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2009
    Messages : 243
    Points : 547
    Points
    547
    Par défaut
    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 Voir le message
    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...

    Nom : case.jpg
Affichages : 1044
Taille : 42,6 Ko

    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.

  5. #5
    Membre confirmé
    Profil pro
    Développeur informatique
    Inscrit en
    Mai 2012
    Messages
    163
    Détails du profil
    Informations personnelles :
    Localisation : France, Côtes d'Armor (Bretagne)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Mai 2012
    Messages : 163
    Points : 624
    Points
    624
    Par défaut
    Citation Envoyé par athlon64 Voir le message
    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 Voir le message
    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.

  6. #6
    Membre confirmé Avatar de athlon64
    Profil pro
    Inscrit en
    Février 2009
    Messages
    243
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2009
    Messages : 243
    Points : 547
    Points
    547
    Par défaut
    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 à
    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

    Nom : Password_Cracking_HPC.jpg
Affichages : 1055
Taille : 67,0 Ko

    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.

Discussions similaires

  1. Réponses: 3
    Dernier message: 13/04/2008, 22h58
  2. programmation parallèle avec MPI
    Par salseropom dans le forum Algorithmes et structures de données
    Réponses: 1
    Dernier message: 03/08/2006, 10h45
  3. Programmation parallèle - Linux
    Par pilou254 dans le forum Autres éditeurs
    Réponses: 4
    Dernier message: 25/06/2006, 06h55
  4. [MFC] Programmation parallèle sous VC++
    Par Axiome dans le forum MFC
    Réponses: 4
    Dernier message: 14/12/2005, 01h10

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo