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 :

Quel est le meilleur langage pour la programmation parallèle ?


Sujet :

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

  1. #41
    Membre confirmé
    Franchement la réponse de certains me sidère !

    La question est pourtant simple : Quel langage pour la programmation parallèle... NON PAS quelle bibliothèque !!!

    Répondre C ou C++ !!! parce que c'est bas niveau ²

    C'est la réponse la plus absurde du monde ! Et pour le meilleur langage objet vous répondez aussi le C ou l'assembleur car il permet de tout contrôler et de réinventer les mécanismes d'héritage et tout et tout !!!

    Vous êtes sur de comprendre la question !?

  2. #42
    Membre régulier
    Salut,

    Citation Envoyé par Joel F Voir le message
    concurrence != parallelisme
    Tu peux en dire plus s'il te plait ?

    Merci a+
    --
    Heimdall

  3. #43
    Membre éclairé
    J'ai mis D, parce que son système de type (const transitif, immutabilité, données non partagées entre les threads par défaut...) me parait bien adapté.

    Plus d'infos :
    http://www.informit.com/articles/pri...aspx?p=1609144
    "By and large I'm trying to minimize mentions of D in C++ contexts because it's as unfair as bringing a machine gun to a knife fight." - Andrei Alexandrescu

  4. #44
    Membre à l'essai
    J'avais répondu à un topic similaire il y a quelque temps. Ça reste d'actualité :
    http://www.developpez.net/forums/d95...e/#post5377819

    Déjà il faut bien faire la différence entre parallélisme et concurrence (voir le lien ci-dessus). Ensuite il faut voir les objectifs visés : si vous voulez un code non portable (i.e. dédié à une machine) et qui trace, vous pouvez utiliser un langage bas niveau (C, C++, Fortran). C'est ce qui est fait sur les supercalculateurs comme Tianhe, RoadRunner ou BlueGene.

    Cependant, dans le cas général où on souhaite que l'application soit portable, on doit s'abstraire de l'architecture. Jusqu'ici les langages bas niveau avec des extensions comme OpenMP et des API standards comme MPI permettaient d'avoir des perfs raisonnables sur différentes machines. Ça n'est plus le cas aujourd'hui avec l'introduction des accélérateurs (GPU, CELL...). Les architectures hétérogènes sont beaucoup plus difficiles à programmer. Il faut remettre en cause les algorithmes : un algo tout pourri sur CPU peut être le plus efficace sur GPU. Le modèle de mémoire partagée, qui avait déjà été mis à mal avec les architectures NUMA, n'est plus valide maintenant que les mémoires sont distribuées (mémoire hôte, mémoire GPU, etc.) et que les transferts entre chaque mémoire sont explicites (transferts DMA asynchrones).

    Bref, pour l'instant dans le domaine de la programmation parallèle, il n'y a pas de langage ultime. Il y a bien quelques expérimentations intéressantes comme ZPL/Chapel, Fortress, x10, Single Assignment C, Intel ArBB, mais rien de mainstream jusqu'ici.

    Dans le domaine de la programmation concurrente, les modèles à base d'acteurs (i.e. threads en espace utilisateur), que l'on trouve initialement dans Erlang mais qu'on retrouve désormais également dans Scala par exemple, donnent de très bons résultats. Scala propose d'ailleurs de les exploiter à travers les collections parallèles depuis la version 2.9.

  5. #45
    Membre éprouvé
    Citation Envoyé par gangsoleil Voir le message
    Citation Envoyé par TropMDR Voir le message
    C'est quoi la proportion de programmeur sur cette planète capable de comprendre "jusqu'à l'instruction près ce qui est exécuté, dans quel ordre, sur quel processeur" ? Je parie sur moins de 0,1%
    J'espere que tu te trompes. Pour moi, faire de la programmation parallele, ce n'est pas ecrire un programme en Fortran puis le passer dans un paralleliseur.[...]

    Si tu n'es pas capable de comprendre ce qu'est un niveau de cache, un sous-ensemble de processeurs, une communication reseau, ... Alors je ne pense pas que tu puisses apprehender toutes les contraintes de la programmation parallele.
    Ouais...
    Imaginons que glob1 et blog2 sont des variable globale initialement à 0. Et que les deux block de code suivant s'exécutent en parallèle sur deux coeur d'un processeur x86

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    {
      int i1 = 0;
      int i2 = 0;
      glob1 = 1;
      i1 = glob1;
      i2 = glob2;
    }


    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    {
      int j1 = 0;
      int j2 = 0;
      glob2 = 1;
      j2 = glob2;
      j1 = glob1;
    }


    (Ou si vous préférer, un truc genre
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    MOV [100] ← $1
    MOV EAX ← [100]
    MOV EBX ← [200]

    et
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    MOV [200] ← $1
    MOV ECX ← [200]
    MOV EDX ← [100]
    )
    D'après toi, quelle proportion des programmeurs sont capables de donner toutes les sorties possibles opur i1, i2, j1 et j2 (ou EAX EBX ECX et EDX) et en le justifiant ?

  6. #46
    Membre averti
    Programmation parallèle
    Je ne vois pas trace de la notion d'interruptions et de sa hiérarchisation.
    Dans les automates, où des multitâches sont exécutées parallèlement, c'est un des ressorts de la bonne exécution. L'univers du temps réel est parsemé de pièges "mortels"

  7. #47

  8. #48
    Membre confirmé
    Pour moi c'est C# avec .net 4.0, un gros effort a été mis pour facilité la parallisation et la simplicité avec des trucs du genre : parallel.foreach
    A oui c'est vrai que c'est pas fin, mais dans 80% des cas ça suffit et ça peut être très très simple de refactorer le code pour mutlithreader certaines portion avec des gains rapide. Ok c'est .net qui gère tout... le nb de thread etc... mais bon il le fait pas si mal, je vais pas me cogner de regarder combien y a de Core sur la machine pour voir le nombre de thread optimum à chaque fois que je veux faire un peu de multithreading.

  9. #49
    Modérateur

    Citation Envoyé par TropMDR Voir le message

    D'après toi, quelle proportion des programmeurs sont capables de donner toutes les sorties possibles pour i1, i2, j1 et j2 (ou EAX EBX ECX et EDX) et en le justifiant ?
    Malheureusement pas assez. Neanmoins, ce sont des concepts fondamentaux pour pouvoir apprehender la programmation parallele.

    Savoir qu'il ne faut pas utiliser de variable globale en parallelisme (pas en ecriture sans lock dessus etc ... on se comprend), c'est bien. Mais si en plus le developpeur sait pourquoi, cela permet d'etre certain qu'il ne va pas le faire, ou en connaissance de cause.

    Globalement, cette reflexion est valable pour tout ce qui est haut niveau : c'est extremement utile, et ca permet de faire certaines choses beaucoup plus rapidement, relativement proprement.
    Mais faire du developpement avec un haut niveau d'abstraction en ayant connaissance de tous les mecanismes sous-jacents, cela permet d'etre encore plus efficace et d'eviter de nombreuses erreurs.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  10. #50
    Expert éminent
    Bon, autant vous dire franchement ce que je pense : je suis choqué qu'on pense encore à du C pour faire du parallèle Une réponse beaucoup plus sensée était celle sur Erlang : ce langage est fait pour ! C'est clair qu'il est mieux pour faire du parallèle.

    Sinon, pour donner un langage moins connu : Oz (voir http://www.mozart-oz.org/). À la base c'était une extension d'Erlang (donc les single-assignment et la mémoire distribuée sont là), qui fait pas mal de choses en plus. De nouveau, c'est un langage fait pour la programmation parallèle et surtout distribuée.

    Sinon dans un registre plus "familier" à pas mal de lecteurs, il y a Scala qui se débrouille pas mal non plus. Avec ses nouvelles collections parallèles et Akka, ça prend du poil de la bête

    Et finalement, je ne peux pas écrire ce post sans mentionner Ozma (https://github.com/sjrd/ozma), qui est le sujet de mon mémoire, et qui intègre dans Scala les primitives de Oz. La différence c'est que lui il est pas encore au point
    sjrd, ancien rédacteur/modérateur Delphi.
    Auteur de Scala.js, le compilateur de Scala vers JavaScript, et directeur exécutif du Scala Center à l'EPFL.
    Découvrez Mes tutoriels, ou mon logiciel phare FunLabyrinthe : un jeu de labyrinthe gratuit et personnalisable à l'infini avec des scripts Delphi-like.

  11. #51
    Membre régulier
    Citation Envoyé par sjrd Voir le message
    Bon, autant vous dire franchement ce que je pense : je suis choqué qu'on pense encore à du C pour faire du parallèle Une réponse beaucoup plus sensée était celle sur Erlang : ce langage est fait pour ! C'est clair qu'il est mieux pour faire du parallèle.

    Ca tourne à la polémique ce topic franchement, et un peu au manque d'ouverture d'esprit. Il y a des tas de gens qui utilisent le C pour faire de la programmation parallèle, en utilisant des bibliothèques de haut niveau (exemple MPI) par exemple, énormément de choses sont complètement transparentes... au final dans ces programmes, le C est utilisé pour d'autres raisons... mais il n'apporte aucun inconvénient pour la parallélisation d'un programme initialement séquentiel.
    --
    Heimdall

  12. #52
    Expert éminent
    Ah comme j'aime qu'on me prête un manque d'ouverture d'esprit surtout en matière de langages de programmation. Généralement dans ce genre de débats, ce sont ceux qui se confinent à leur langage "favori" qui manquent d'ouverture d'esprit. Je ne dis pas que c'est ton cas, mais j'ose prétendre que ce n'est pas le mien.

    Comme l'a très bien fait remarquer ijk-ref, la question porte sur le langage, pas la biblio. C avec MPI c'est MPI qui fait tout, en matière de parallélisme. Ce n'est pas C.

    Et puis même, pour avoir fait du MPI et du Oz, je préfère largement travailler avec Oz pour faire du parallélisme, bien que je déteste la syntaxe et la difficulté à se relire dans ce langage.
    sjrd, ancien rédacteur/modérateur Delphi.
    Auteur de Scala.js, le compilateur de Scala vers JavaScript, et directeur exécutif du Scala Center à l'EPFL.
    Découvrez Mes tutoriels, ou mon logiciel phare FunLabyrinthe : un jeu de labyrinthe gratuit et personnalisable à l'infini avec des scripts Delphi-like.

  13. #53
    Membre régulier
    Citation Envoyé par sjrd Voir le message
    Ah comme j'aime qu'on me prête un manque d'ouverture d'esprit surtout en matière de langages de programmation. Généralement dans ce genre de débats, ce sont ceux qui se confinent à leur langage "favori" qui manquent d'ouverture d'esprit. Je ne dis pas que c'est ton cas, mais j'ose prétendre que ce n'est pas le mien.

    oh mais je ne parlais pas forcément de toi, mais du topic entier.


    Comme l'a très bien fait remarquer ijk-ref, la question porte sur le langage, pas la biblio. C avec MPI c'est MPI qui fait tout, en matière de parallélisme. Ce n'est pas C.
    Tout a fait... mais on peut se demander si la question de départ a réellement du sens vis à vis du but (supposé) de ce forum. Ici il est question de parallélisme au sens large (si je puis dire ça ainsi)... Beaucoup de gens (dont je fais partie) prétendent faire des programmes parallèles sans pour autant rien comprendre à comment la biblio qu'ils utilisent (MPI pour moi en l'occurence) fonctionne réellement.

    Quand je dis "je fais des programmes parallèles", je dis que je conçois et code des algorithmes dont le calcul sera executé par des process différents. C'est ce que 99% des scientifiques qui font du calcul intensif sur des clusters de calcul font, et ils n'y connaissent rien à la programmation bas niveau (ou pas) liée au parallélisme en lui même.

    De ce point de vue là (dont j'ose espéré qu'il n'est pas pour certain hors sujet sur ce forum), on se fout effectivement complètement du "langage" que l'on utilise, pourvu qu'un bibliothèque parallèle soit implémentée dans le langage qu'on a choisi (pour d'autres raisons donc) comme le meilleur pour notre objectif.


    Donc en conclusion, soit la question n'a pas de sens, soit elle n'est pas assez précise.
    --
    Heimdall

  14. #54
    Membre confirmé
    De toute manière séparer le langage de la bibliothèque est au final assez absurde.

    Supposons que C+Mpi soit, au final, supérieur à Oz tout seul en matière de parallélisation du code. Faut-il choisir Oz parce que la bibli ça compte pas ?

    Plus sérieusement, Oz ne dispose pas d'une communauté aussi conséquente que C et d'une bibliothèque aussi riche. C+Mpi n'est peut-être pas aussi bien que Oz en matière de parallélisation, mais C+Mpi+les_autres_biblis+les_années_de_rodage_du_langage vs Oz tout seul sans rien d'autre que sa parallélisation, c'est peut-être, dans certains cas, une solution meilleure.

    Je ne connais pas Oz, et puis je suppose que dans ce genre d'affaire tout est fonction du projet et de l'équipe que l'on a avec soit.

    Mais au final, au sujet des bibliothèques d'un langage, j'aime beaucoup cette expression de la communauté Perl :

    Perl est la syntaxe, le CPAN est le langage.

    P.S. : le CPAN c'est l'immense bibliothèque accessible avec l'outil du même nom pour Perl.

  15. #55
    Membre éprouvé
    Citation Envoyé par gangsoleil Voir le message
    Malheureusement pas assez. Neanmoins, ce sont des concepts fondamentaux pour pouvoir apprehender la programmation parallele.
    Ouais, j'évalue le "pas assez" à moins de 0,1% justement (dommage que personne n'ait pris le risque de répondre). Et non, je ne pense pas que comprendre le modèle mémoire relaxé du x86 soit un concept fondamental pour pouvoir appréhender la programmation parallèle, justement parce qu'il y a des modèle bien meilleurs que la mémoire partagé (genre le passage de message). Et heureusement, vu la complexité incroyable de la chose (et le fait que ça change d'un proc à l'autre. Genre un algo qui marche sur x86 échouera lamentablement sur powerPC).

    Citation Envoyé par gangsoleil Voir le message
    Savoir qu'il ne faut pas utiliser de variable globale en parallelisme (pas en ecriture sans lock dessus etc ... on se comprend), c'est bien. Mais si en plus le developpeur sait pourquoi, cela permet d'etre certain qu'il ne va pas le faire, ou en connaissance de cause.
    Le problème, c'est que si tu fais du parallélisme en mémoire partagée et que tu fous des locks sur tous tes accès, tu es un peu dans la merde en terme de perfs...


    Tout ça pour dire que le fait d'être "proche de la machine" n'est vraiment pas un avantage en programmation parallèle, puisque ça augmente *considérablement* la probabilité de faire une grosse connerie...

  16. #56
    Invité
    Invité(e)
    J'ai voté C/C++ et C# que je connais bien. Je sais que Java s'en tire pas mal mais je n'en fais pas !!

    C pour la robustesse et le fait qu'il "colle au natif" mais aussi parce qu'il est incontournable dans certains systèmes alors que les autres apportent surtout du confort.

    C++ parce que L'objet et le parallèle vont bien ensemble

    Et C# parce que je m'amuse a lui faire paralléliser des trucs souvent.
    C'est avec C# que je fais des tests parfois absurdes : Pas envie de mettre la conception avant le test : boom j'encapsule le point d'entrée que j'appelle dans un thread et j'attends que ça crashe !!

    Le gros avantage est que la prise en charge sous debugger est vraiment si bonne que je lance le programme parfois avant même de réfléchir aux conséquences c'est le debugger qui me les donne !

    Je pourrais imaginer mettre au point une approche parallèle en C# pour la porter en C une fois que j'ai tout débuggé (voire réécrit) Mais on pourrait sûrement dire la même chose de tous les ide's avec un bon debugger...

    Parfois il faut se prendre le chou AVANT de concevoir l'algorithme. Perso je fais ça sur papier avec trois stylos de couleur différente... Boucles parralèles ou récursivité donnent du fil à retordre et le site d'Intel m'a sauvé plus d'une fois.

  17. #57
    Invité
    Invité(e)
    Après réflexion : il me semble qu'il n'existe pas de "meilleur" langage parallèle ni de hiatus entre langage et librairie. L'OS est déjà très parallèle quant au réseau il n'a pas son pareil pour parallèliser n'importe quoi même en vba !!
    Dans ce cas la difficulté consiste même parfois à forcer un comportement mono thread pour rester synchrone.
    C'est un peu pour ça que j'insiste sur le debugger.
    A mon avis le sens de l'article parle surtout de multicore car la problématique des développeurs "moderne" passe par ce paradigme. Le multithread est une forme de paralèlisme ou chaque "fork" peut donner lieu à de multiples threads mais on ne sait pas vraiment comment un processeur donné va distribuer ces tâches dans ses cores. On espère juste que les process ne se bloqueront pas entre eux et peut-être un gain de performance.
    Je pense que pour répondre à cette myriade de cas il faudrait mieux préciser le domaine couvert par le mot "parallèle"

    Selon moi le casse-tête vient souvent du fait qu'on attend d'un multicore qu'il soit x fois plus rapide qu'un monocore et ce "malentendu" n'est pas le seul mais c'est le plus fréquent dans l'esprit des clients ou des commerciaux..
    Hélas cette approche est généralement trop simpliste. Il vaut mieux gérer un affichage asynchrone (parallèle donc) car c'est relativement simple à faire qu'une connexion aux données asynchrone qui est complexe et génératrice de nombreux bugs de synchro qui sont parfois presque indétectables.

    Dans ce contexte le language est moins le problème que le rapport entre le besoin formulé et la technique employée.
    Pour revenir à nos moutons : dans le cas d'un programme qui tirera parti du multicore : C# est génial
    Le C on ne sait pas bien car les plateformes embarquées multicores sont encore rares (pas pour longtemps)
    Un chose est sûre : l'expérience du développeur compte plus que le language !!

  18. #58
    Expert éminent
    UPC ?

  19. #59
    Membre confirmé
    La première question à se poser me semble être: parallèle pour quoi faire?

    Pour le calcul intensif, les compilateurs FORTRAN offrent souvent des options permettant une parallèlisation automatique ou controlée, avec l'avantage d'une compatibilité qui rend le code non spécifique.

    N'en déplaise à certains, FORTRAN <<is well and alive>> et toujours fort utilisé dans le domaine du calcul scientifique.
    GraceGTK: a plotting tool at https://sourceforge.net/projects/gracegtk

  20. #60
    Candidat au Club
    Ada ?
    Il y a bien 20 ans j'avais trouvé Ada remarquablement clair pour le parallélisme/multithread. Mais j'en n'ai pas fait depuis ! J'ai bien essayé Erlang, mais j'ai eu du mal à accrocher. Je fais du C 90% de mon temps et je dois bien avouer que c'est pas du tout adapté au parallélisme qq soit la librairie, c'est un peu comme de mettre un réacteur d'avion sur un vélo. Sinon, bash finalement ça marche pas mal en multithread

###raw>template_hook.ano_emploi###