De quelles fonctionnalités les utilisateurs ont-ils besoin d'une interface MPI C ++?

La version 3.0 de la norme MPI a officiellement supprimé l'interface C ++ (elle était auparavant obsolète). Bien que les implémentations puissent toujours le prendre en charge, les fonctionnalités qui sont nouvelles dans MPI-3 n'ont pas d'interface C ++ définie dans la norme MPI. Voir http://blogs.cisco.com/performance/the-mpi-c-bindings-what-happened-and-why/ pour plus d'informations.

La motivation pour supprimer l'interface C ++ de MPI était qu'elle n'avait aucune valeur significative sur l'interface C. Il y avait très peu de différences autres que "s / _ / :: / g" et de nombreuses fonctionnalités auxquelles les utilisateurs C ++ sont habitués n'étaient pas utilisées (par exemple la détermination automatique de type via des modèles).

En tant que personne qui participe au Forum MPI et travaille avec un certain nombre de projets C ++ qui ont implémenté leur propre interface C ++ aux fonctions MPI C, je voudrais savoir quelles sont les caractéristiques souhaitables d'une interface C ++ à MPI. Bien que je ne m'engage à rien, je serais intéressé à voir la mise en œuvre d'une interface MPI C ++ autonome qui répond aux besoins de nombreux utilisateurs.

Et oui, je connais Boost :: MPI ( http://www.boost.org/doc/libs/1_54_0/doc/html/mpi.html ) mais il ne prend en charge que les fonctionnalités MPI-1 et le modèle de sérialisation serait extrêmement difficile à supporter pour RMA.

Une interface C ++ vers MPI que j'aime est celle d'Elemental ( https://github.com/poulson/Elemental/blob/master/src/core/imports/mpi.cpp ) donc peut-être que les gens peuvent fournir des avantages et des inconvénients qui approche. En particulier, je pense que MpiMap résout un problème essentiel.

Permettez-moi d'abord de répondre à la raison pour laquelle je pense que les interfaces C ++ vers MPI n'ont généralement pas été un succès excessif, après avoir réfléchi au problème pendant longtemps en essayant de décider si nous devons simplement utiliser les liaisons C standard de MPI ou construire sur quelque chose à un niveau supérieur. :

Lorsque vous regardez les codes MPI du monde réel (par exemple, PETSc, ou dans mon cas deal.II), on constate que peut-être de manière surprenante, le nombre d'appels MPI n'est pas vraiment très important. Par exemple, dans les 500 000 lignes de deal.II, il n'y a que ~ 100 appels MPI. Une conséquence de cela est que la douleur liée à l'utilisation d'interfaces de niveau inférieur telles que les liaisons MPI C, n'est pas trop grande. Inversement, on ne gagnerait pas beaucoup en utilisant des interfaces de niveau supérieur.

Ma deuxième observation est que de nombreux systèmes ont plusieurs bibliothèques MPI installées (différentes implémentations MPI ou différentes versions). Cela pose une difficulté importante si vous voulez utiliser, par exemple, boost :: mpi qui ne se compose pas uniquement de fichiers d'en-tête: soit il doit y avoir plusieurs installations de ce paquet également, soit il faut le construire dans le cadre de la projet qui utilise boost :: mpi (mais c'est encore un problème en soi, étant donné que boost utilise son propre système de construction, qui ne ressemble à rien d'autre).

Je pense donc que tout cela a comploté contre la récolte actuelle d'interfaces C ++ vers MPI: les anciennes liaisons MPI C ++ n'offraient aucun avantage, et les packages externes avaient des difficultés avec le monde réel.

Cela dit, voici ce que je pense être les fonctionnalités de tueur que j'aimerais avoir d'une interface de niveau supérieur:

• Il doit être générique. Décider de spécifier le type de données d'une variable n'est décidément pas du genre C ++. Bien sûr, cela conduit également à des erreurs. La classe MpiMap d'Elemental serait déjà une bonne première étape (bien que je ne puisse pas comprendre pourquoi la MpiMap::typevariable n'est pas une constante statique, afin qu'elle soit accessible sans créer d'objet).

• Il devrait avoir des installations pour diffuser des types de données arbitraires.

• Les opérations qui nécessitent un MPI_Opargument (par exemple, des réductions) devraient bien s'intégrer à l' std::functioninterface de C ++ , de sorte qu'il est facile de simplement passer un pointeur de fonction (ou un lambda!) Plutôt que d'avoir à enregistrer maladroitement quelque chose.

boost :: mpi satisfait en fait tout cela. Je pense que s'il s'agissait d'une bibliothèque uniquement en-tête, elle serait beaucoup plus populaire dans la pratique. Il serait également utile de prendre en charge les fonctions post-MPI 1.0, mais soyons honnêtes: cela couvre la plupart de ce dont nous avons besoin la plupart du temps.

Pour lancer le bal, voici deux de mes besoins:

• L'interface doit être en mesure d'éliminer les arguments redondants ou inutiles, par exemple MPI_IN_PLACE.
• L'interface doit détecter automatiquement les types de données intégrés comme MpiMap d'Elemental.
• Si / chaque fois que cela est possible, des types de données définis par l'utilisateur doivent être construits pour les classes.

Ma liste sans ordre de préférence particulier. L'interface doit:

• être en-tête uniquement, sans aucune dépendance mais <mpi.h> , et la bibliothèque standard,
• être générique et extensible,
• être non bloquant uniquement (si vous voulez bloquer, puis bloquer explicitement, pas par défaut),
• permettre le chaînage basé sur la continuation des opérations non bloquantes,
• prendre en charge la sérialisation extensible et efficace (Boost.Fusion comme, de sorte qu'il fonctionne avec RMA),
• avoir une pénalité d'abstraction nulle (c'est-à-dire être au moins aussi rapide que l'interface C),
• être en sécurité (le destructeur d'un avenir non prêt est appelé? -> std :: terminate!),
• avoir un fort DEBUG mode avec des tonnes d'assertions,
• extrêmement sûr pour le type (plus d'ints / void * pour tout, diable je veux que les tags soient des types!),
• cela devrait fonctionner avec les lambdas (par exemple tous réduire + lambda),
• utiliser les exceptions de manière cohérente comme mécanisme de rapport et de traitement des erreurs (plus de codes d'erreur! plus d'arguments de sortie de fonction!),
• MPI-IO devrait offrir une interface d'E / S non bloquante dans le style de Boost.AFIO,
• et il suffit de suivre les bonnes pratiques modernes de conception d'interface C ++ (définir des types réguliers, des fonctions non-amis non-amis, bien jouer avec la sémantique de déplacement, prendre en charge les opérations de plage, ...)

Extras:

• permettez-moi de choisir l'exécuteur de l'environnement MPI, c'est-à-dire le pool de threads qu'il utilise. À l'heure actuelle, vous pouvez avoir des applications avec un mélange d'OpenMP, MPI, CUDA et TBB ... le tout en même temps, où chaque exécution pense qu'il est propriétaire de l'environnement et demande donc au système d'exploitation des threads chaque fois qu'il le souhaite il. Sérieusement?

• utilisez la convention de dénomination STL (et Boost). Pourquoi? Chaque programmeur C ++ le sait.

Je veux écrire du code comme ceci:

auto buffer = some_t{no_ranks};
auto future = gather(comm, root(comm), my_offsets, buffer)
              .then([&](){
                /* when the gather is finished, this lambda will 
                   execute at the root node, and perform an expensive operation
                   there asynchronously (compute data required for load 
                   redistribution) whose result is broadcasted to the rest 
                   of the communicator */
                return broadcast(comm, root(comm), buffer);
              }).then([&]() {
                /* when broadcast is finished, this lambda executes 
                   on all processes in the communicator, performing an expensive
                   operation asynchronously (redistribute the load, 
                   maybe using non-blocking point-to-point communication) */
                 return do_something_with(buffer);
              }).then([&](auto result) {
                 /* finally perform a reduction on the result to check
                    everything went fine */
                 return all_reduce(comm, root(comm), result, 
                                  [](auto acc, auto v) { return acc && v; }); 
              }).then([&](auto result) {
                  /* check the result at every process */
                  if (result) { return; /* we are done */ }
                  else {
                    root_only([](){ write_some_error_log(); });
                    throw some_exception;
                  }
              });

/* Here nothing has happened yet! */

/* ... lots and lots of unrelated code that can execute concurrently 
   and overlaps with communication ... */

/* When we now call future.get() we will block 
   on the whole chain (which might have finished by then!).
*/

future.get();

Imaginez comment on pourrait enchaîner toutes ces opérations en utilisant les MPI_C request. Vous devrez tester à plusieurs (ou à chaque étape) intermédiaire à travers un tas de code non lié pour voir si vous pouvez faire avancer votre chaîne sans bloquer .

Personnellement, cela ne me dérange pas vraiment d'appeler de longues fonctions de style C pour la raison exacte mentionnée par Wolfgang; il y a vraiment peu d'endroits où vous devez les appeler et même alors, ils sont presque toujours enveloppés par un code de niveau supérieur.

Les seules choses qui me dérangent vraiment avec les MPI de style C sont les types de données personnalisés et, dans une moindre mesure, les opérations personnalisées (car je les utilise moins souvent). En ce qui concerne les types de données personnalisés, je dirais qu'une bonne interface C ++ devrait être capable de prendre en charge un moyen générique et efficace de gérer cela, très probablement par le biais de la sérialisation. C’est bien sûr l’itinéraire qui boost.mpia été emprunté, qui si vous faites attention , beaucoup de temps.

En ce qui concerne boost.mpiles dépendances supplémentaires (en particulier boost.serializationqui n'est pas uniquement en-tête), j'ai récemment rencontré une bibliothèque de sérialisation C ++ uniquement en-tête appelée cereal qui semble prometteuse; étant donné qu'il nécessite un compilateur compatible C ++ 11. Il pourrait être utile de l'examiner et de l'utiliser comme base pour quelque chose de similaire à boost.mpi.

Le projet github easyLambda fournit une interface de haut niveau à MPI avec C ++ 14.

Je pense que le projet a des objectifs similaires et il donnera une idée des choses qui peuvent être et sont faites dans ce domaine en utilisant le C ++ moderne. Guider d'autres efforts ainsi que easyLambda lui-même.

Les repères initiaux sur les performances et les lignes de code ont montré des résultats prometteurs.

Voici une brève description des fonctionnalités et de l'interface qu'il fournit.

L'interface est basée sur la programmation de flux de données et les opérations de listes fonctionnelles qui fournissent un parallélisme inhérent. Le parallélisme s'exprime comme la propriété d'une tâche. L'allocation de processus et la distribution de données pour la tâche peuvent être demandées avec une propriété .prll (). Il y a un bon nombre d'exemples dans la page Web et le code-référentiel qui incluent LAMMPS dynamique moléculaire traitement post, solution explicite de différence finie à l' équation de la chaleur, la régression logistique , etc. Par exemple , le problème de la diffusion de la chaleur discuté dans l'article HPC est en train de mourir ... peut être exprimé en ~ 20 lignes de code.

J'espère qu'il est bon de donner des liens plutôt que d'ajouter plus de détails et d'exemples de codes ici.

Disclamer: Je suis l'auteur de la bibliothèque. Je crois que je ne fais aucun mal en espérant obtenir une rétroaction constructive sur l'interface actuelle d'easyLambda qui pourrait être avantageuse pour easyLambda et tout autre projet poursuivant des objectifs similaires.