Forum Programmation.c++ Programmation parallèle en POP-C++

Posté par  .
Étiquettes : aucune
3
22
juin
2009
Bonjour,

Pas de question ici mais un peu de pub pour un logiciel intéressant que nos avons développé il y a quelques années.

POP-C++ est un outil qui permet de faire tourner un programme orienté objet en parallèle sur plusieurs machines. C'est un logiciel libre qui étend le langage C++ et permet de transformer très simplement des classes C++ en des classes parallèles. Les objets parallèles générés peuvent alors tourner indépendamment sur plusieurs machines.

POP-C++ contient entre autre :
- Un parseur qui génère le code de ces objets parallèles
- Une gestion des threads pour permettre d'appeler des méthodes de manière synchrone/asynchrone ...
- Une gestion des protocoles de communication, en particulier les socket tcpip, afin de passer des structures de données complexes entre différents objets.
- ...

Si vous êtes intéressés, je vous invite à visiter le wiki de POP-C++ et en particulier la page tutoriel : http://gridgroup.hefr.ch/popc/index.php/Quick_start

Questions et remarque sont les bienvenues !

PS: Pour tester POP-C++, je vous conseille vivement de prendre la version béta des sources.
  • # Et pourquoi pas CORBA ?

    Posté par  . Évalué à 2.

    De ce que je comprends, pop-c++ ferait à peu près la même chose que CORBA, qui a l'avantage d'être standardisé, poussé, qui binde sur une foule de langages, etc. Qu'en dis-tu ?
    • [^] # Re: Et pourquoi pas CORBA ?

      Posté par  . Évalué à 2.

      CORBA, le truc imbitable, avec une architecture tellement complexe que pour un simple « hello world » il faut 1 min. pour traverser toutes les couches d'abstraction ? :-)

      Plus sérieusement, dans le cadre du calcul haute-performance, le surcoût qu'impose CORBA est clairement trop important. De plus les objectifs des deux projets ne sont pas les mêmes :

      - CORBA propose une abstraction « objet » pour une architecture logicielle distribuée et multi-plateforme (enfin, au moins C++ et Java)
      - de ce que j'ai pu voir POP-C++, il s'agit surtout de rajouter des mots-clef à la syntaxe pour prendre en compte le parallélisme, et ainsi gérer les synchro, la concurrence en règle générale, etc (et bon, quelque part, j'ai envie de dire que ça permet un peu de rattraper le retard sur le langage Java qui propose déjà des "synchronize", etc.)

      Du coup, j'aurais plutôt envie de demander à Laurent si rajouter des mots-clef à C++ (qui en est déjà bien rempli) est une bonne chose. Comment se compare POP-C++ à Thread Building Blocks d'Intel, par exemple (qui ne se servent « que » de templates) ?
      • [^] # Re: Et pourquoi pas OpenMP ?

        Posté par  . Évalué à 1.

        Effectivement, rajouter des mots clefs à C++, c'est pas forcément ce qu'il y a de plus conseillé.

        Mais du coup, ce que tu me donnes comme différence entre CORBA et Pop-C++ m'amènerait à comparer de la même façon Pop-C++ à OpenMP (encore que je préfère MPI, personnellement, mais c'est simplement une API (« simplement » en terme d'empreinte sur le langage) et à grain plus fin...)

        Je pose ces questions, c'est pas pour ennuyer et dire « bouh ça sert à rien ton truc », hein. J'ai juste pas suffisamment envie de savoir tout ça pour faire des recherches moi-même ^^
        • [^] # Re: Et pourquoi pas OpenMP ?

          Posté par  . Évalué à 3.

          OpenMP et MPI c'est vraiment pas pareil. Déjà, MPI ne fonctionne « officiellement » qu'avec des processus (même s'il existe des implémentations à base de threads), car c'est ce qui est marqué dans le standard. Ensuite, OpenMP ne propose pas que des appels de fonctions à une bibliothèque, mais aussi un ensemble de directives de compilation et un runtime (pilotable via la bibliothèque et des variables d'environnement). De plus les approches OpenMP et MPI sont différentes :
          - MPI propose un ensemble d'appels de fonctions plus complexes (communications 1-1, 1-*, *-*, etc, canaux, en fonction du nombre de processus, etc), et tout doit être explicite. En contrepartie, le principe de MPI est très simple, et une fois assimilé, c'est toujours pareil, et on sait ce qu'on fait. En plus de ça, comme il faut communiquer explicitement quand on utilise MPI, utiliser un programme MPI sur un ou plusieurs nœuds de calcul se fait de façon identique (après il faut espérer que le runtime MPI est assez intelligent pour faire la différence entre communication inter-nœud et intra-nœud).
          - OpenMP propose un modèle de programmation basé sur les tâches/threads, en mémoire partagée. Ça exclut d'office le calcul inter-nœud (même s'il existe des machins qui essaient de fabriquer une fausse mémoire globale inter-nœuds, mais pour ce que j'en ai vu, ça marche mal). Comme pour tout prog multithreadé, ça suppose que tout est partagé implicitement, mais du coup on y gagne en empreinte mémoire, on n'a pas besoin de faire d'appel de fonction spécifique pour accéder aux données ou les modifier -- mais par contre il faut toujours faire des synchros à la main...

          Les TBB sont un ensemble de templates C++ pour faire de « l'OpenMP » juste avec de la programmation. Cela dit ça va plus loin puisqu'il propose des conteneurs, etc., et aussi moins loin, car le compilateur OpenMP est capable de détecter des choses au niveau de la représentation intermédiaire, en se « souvenant » que plusieurs threads sont mis en jeu, ce qui n'est pas le cas des TBB.

          Quant à POP-C++, là aussi a priori le compilateur est du coup capable de générer du code plus efficace vu que les mots-clef sont intégrés au niveau du langage... Mais j'ai des doutes malgré tout sur l'efficacité au final. À tester donc. :)
          • [^] # Re: Et pourquoi pas OpenMP ?

            Posté par  . Évalué à 1.

            Effectivement, ce logiciel a été développé par quelques personnes dans un milieu académique. Il ne tient donc absolument pas la comparaison avec des MPI et CORBA.

            Pour ce qui est d'une comparaison directe. MPI est, selon mes connaissances, plus une gestion de la communication entre différente machines. Il permet par extension de faire de la programmation en parallèle mais cela doit être fait explicitement par le programmeur (que ce soit considéré comme un ennui ou non). POP-C++ se base lui sur une décomposition en objets très similaires à celle utilisé pour de la programmation séquentielle.

            CORBA est, il me semble une suite très complète mais plus orientée vers la création d'applications de gestion. Ca a l'air assez bien monté pour la création d'objets à distance et la communication. Je ne sais par contre pas ce qu'il en est pour la complexité du programme et la lourdeur.

            Les TBB ont l'air très prometteurs pour la gestion des threads. En comparaison POP-C++ est beaucoup plus simpliste. Par contre, l'utilisateur n'a besoin de gérer que les descripteurs des méthodes, la gestion des threads est gérée automatiquement.

            Pour ce qui est de l'efficacité, POP-C++ n'est pas conçu pour faire de la parallélisation fine. La création d'objets parallèles est trop lente pour cela. MPI est probablement plus efficace. Mais les approches peuvent être complémentaires. (Pour l'info, on a déjà fait de la prog parallèle POP-C++ et MPI dans un même programme).

            Il est clair que comme c'est une extension de C++, on hérite par défaut des forces et faiblesses du langage. Mais la syntaxe supplémentaire ne pose pas de problème majeur. A partir du moment où on a vu la différence entre "class" et "parclass", le reste est juste une subtilité dans l'appel de méthodes. Il y a par contre d'autres complications par rapport à un programme séquentiel simple.

            Par exemple :
            - Restrictions sur la structure d'une classe pour en faire un classe parallèle (toutes les variables doivent être privés, pas de variables statique,...)
            - Conception du programme en parallèle et exécution efficace. (Mais ça, c'est commun à tous les programmes parallèles)

            Toutes les questions et critiques sont de toute façon les bienvenues ! C'est très intéressant d'avoir un avis extérieur.
            • [^] # Re: Et pourquoi pas OpenMP ?

              Posté par  . Évalué à 1.

              Je ne vois pas l'intérêt de ce genre de systèmes de parallélisation.
              Si on cherche à paralléliser une application, en général, c'est pour optimiser son fonctionnement, et plus on sera prêt des API systèmes pthread & co, plus on sera efficace.

              Si on cherche à faire de la parallélisation "magique" avec des mots à la synchronised, on se retrouve la plupart du temps avec des applications buggé dont les concepteurs ne savent pas ce qu'est un deadlock ...

              Enfin bref ... je me trompe surement, surement trop "old school" comme approche, mais ça ne m'a jamais convainqu :)
              • [^] # Re: Et pourquoi pas OpenMP ?

                Posté par  . Évalué à 2.


                void matvec(double *mat, double *vec1, double *vec2, const int m, const int n) {
                int i,j;
                #pragma omp parallel for default(none) shared(mat,vec1,vec2) private(i,j)
                for (i = 0; i < m; ++i)
                for (j = 0; j < n; ++j)
                vec2[i] += mat[i][j] * vec1[i];
                }


                Bien sûr il s'agit d'un code naïf de multiplication de matrice, mais ça montre quand même l'idée. Faire ça en pthreads est bien plus fastidieux si tu veux bien le faire. Il y a tout un tas de cas où avoir une syntaxe qui gère le parallélisme (directement dans le langage ou les pragmas) permet d'aller quand même bien plus vite que les pthreads.
              • [^] # Re: Et pourquoi pas OpenMP ?

                Posté par  (site web personnel) . Évalué à 1.

                L'intérêt, c'est que l'immense majorité des logiciels de simulation utilisés en physique pour la recherche sont développés par des gens qui n'ont pas eut de formation solide en informatique (et quand je dis l'immense majorité, c'est pour être prudent: je n'ai en fait jamais rencontré de code pour lequel ce ne soit pas le cas). Donc une parallélisation au petits oignons, il faut oublier: c'est soit un système très simple permettant de paralléliser de façon convenable (mais pas optimale), soit pas de parallélisation du tout...

                Et pour faire encore plus frémir dans les chaumières: de grosses partie du code sur lequel je travaille ont étés écrites par des étudiants qui ont appris la programmation en développant le code lui même... Déjà que la plupart ne voient pas pourquoi il ne faudrait pas mettre toutes les variables en variables globales, alors les threads...

                Mathias
                PS: et nous utilisons Pop-C++ pour notre code

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.