¿Qué características necesitan los usuarios de una interfaz MPI C ++?

La versión 3.0 del estándar MPI eliminó formalmente la interfaz C ++ (anteriormente estaba en desuso). Si bien las implementaciones aún pueden admitirlo, las características que son nuevas en MPI-3 no tienen una interfaz C ++ definida en el estándar MPI. Consulte http://blogs.cisco.com/performance/the-mpi-c-bindings-what-happened-and-why/ para obtener más información.

La motivación para eliminar la interfaz C ++ de MPI fue que no tenía un valor significativo sobre la interfaz C. Hubo muy pocas diferencias además de "s / _ / :: / g" y no se emplearon muchas características a las que los usuarios de C ++ están acostumbrados (por ejemplo, la determinación automática de tipos mediante plantillas).

Como alguien que participa en el Foro MPI y trabaja con una serie de proyectos C ++ que han implementado su propia interfaz C ++ para las funciones MPI C, me gustaría saber cuáles son las características deseables de una interfaz C ++ para MPI. Si bien no me comprometo a nada, me interesaría ver la implementación de una interfaz MPI C ++ independiente que satisfaga las necesidades de muchos usuarios.

Y sí, estoy familiarizado con Boost :: MPI ( http://www.boost.org/doc/libs/1_54_0/doc/html/mpi.html ) pero solo es compatible con las funciones MPI-1 y el modelo de serialización sería extremadamente difícil de soportar para RMA.

Una interfaz de C ++ para MPI que me gusta es la de Elemental ( https://github.com/poulson/Elemental/blob/master/src/core/imports/mpi.cpp ) para que tal vez la gente pueda proporcionar algo de información enfoque. En particular, creo que MpiMap resuelve un problema esencial.

Permítanme primero responder por qué creo que las interfaces C ++ a MPI generalmente no han tenido demasiado éxito, después de haber pensado en el problema durante un buen tiempo al tratar de decidir si deberíamos usar los enlaces C estándar de MPI o construir en algo de nivel superior :

Cuando nos fijamos en los códigos MPI del mundo real (por ejemplo, PETSc, o en mi caso. II), uno encuentra que quizás sorprendentemente, el número de llamadas MPI no es realmente muy grande. Por ejemplo, en las 500k líneas de acuerdo. II, solo hay ~ 100 llamadas MPI. Una consecuencia de esto es que el dolor que implica el uso de interfaces de nivel inferior, como los enlaces MPI C, no es demasiado grande. Por el contrario, uno no ganaría mucho utilizando interfaces de nivel superior.

Mi segunda observación es que muchos sistemas tienen múltiples bibliotecas MPI instaladas (diferentes implementaciones de MPI o diferentes versiones). Esto plantea una dificultad significativa si desea utilizar, por ejemplo, boost :: mpi que no solo consiste en archivos de encabezado: o bien debe haber múltiples instalaciones de este paquete, o uno necesita construirlo como parte del proyecto que usa boost :: mpi (pero eso es un problema en sí mismo nuevamente, dado que boost usa su propio sistema de compilación, que es diferente a cualquier otra cosa).

Así que creo que todo esto ha conspirado contra la actual cosecha de interfaces C ++ a MPI: los viejos enlaces MPI C ++ no ofrecían ninguna ventaja, y los paquetes externos tenían dificultades con el mundo real.

Todo esto dicho, esto es lo que creo que serían las características asesinas que me gustaría tener desde una interfaz de nivel superior:

• Debería ser genérico. Tener que especificar el tipo de datos de una variable definitivamente no es similar a C ++. Por supuesto, también conduce a errores. La clase MpiMap de Elemental ya sería un buen primer paso (aunque no puedo entender por qué diablos la MpiMap::typevariable no es constante estática, por lo que se puede acceder sin crear un objeto).

• Debe tener facilidades para transmitir tipos de datos arbitrarios.

• Las operaciones que requieren un MPI_Opargumento (p. Ej., Reducciones) deben integrarse bien con la std::functioninterfaz de C ++ , de modo que sea fácil pasar un puntero de función (¡o un lambda!) En lugar de tener que registrar algo torpemente.

boost :: mpi en realidad satisface todo esto. Creo que si fuera una biblioteca de solo encabezado, sería mucho más popular en la práctica. También ayudaría si admitiera funciones posteriores a MPI 1.0, pero seamos honestos: esto cubre la mayor parte de lo que necesitamos la mayoría del tiempo.

Para que la pelota ruede, estas son dos de mis necesidades:

• La interfaz debe poder eliminar argumentos redundantes o innecesarios, por ejemplo, MPI_IN_PLACE.
• La interfaz debe detectar automáticamente los tipos de datos incorporados en MpiMap de Elemental.
• Si / siempre que sea posible, los tipos de datos definidos por el usuario deben construirse para las clases.

Mi lista en ningún orden particular de preferencia. La interfaz debe:

• ser solo encabezado, sin dependencias pero <mpi.h>, y la biblioteca estándar,
• ser genérico y extensible
• no bloquee solo (si desea bloquear, bloquee explícitamente, no de forma predeterminada),
• permitir el encadenamiento basado en la continuación de operaciones sin bloqueo,
• admite serialización extensible y eficiente (como Boost.Fusion, de modo que funcione con RMA),
• tener penalización de abstracción cero (es decir, ser al menos tan rápido como la interfaz C),
• estar a salvo (el destructor de un futuro no preparado se llama? -> std :: terminate!),
• tener un DEBUGmodo fuerte con toneladas de afirmaciones
• extremadamente seguro para escribir (no más ints / void * para todo, ¡diablos, quiero que las etiquetas sean tipos!),
• debería funcionar con lambdas (p. ej., todos reducen + lambda),
• use excepciones consistentemente como mecanismo de informe y manejo de errores (¡no más códigos de error! ¡No más argumentos de salida de función!
• MPI-IO debería ofrecer una interfaz de E / S sin bloqueo al estilo de Boost.AFIO,
• y simplemente siga las buenas prácticas modernas de diseño de interfaz C ++ (defina tipos regulares, funciones que no sean amigos y que no sean amigos, juegue bien con la semántica de movimientos, soporte de operaciones de rango, ...)

Extras:

• permítame elegir el ejecutor del entorno MPI, es decir, qué grupo de subprocesos utiliza. En este momento, puede tener aplicaciones con una combinación de OpenMP, MPI, CUDA y TBB ... todo al mismo tiempo, donde cada tiempo de ejecución cree que es el propietario del entorno y, por lo tanto, solicita subprocesos al sistema operativo cada vez que lo desee. eso. ¿Seriamente?

• use la convención de nomenclatura STL (y Boost). ¿Por qué? Todo programador de C ++ lo sabe.

Quiero escribir código como este:

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();

Piense cómo se podrían encadenar todas estas operaciones usando los MPI_C request. Tendría que probar en múltiples (o todos) pasos intermedios a través de una gran cantidad de código no relacionado para ver si puede avanzar su cadena sin bloquear .

Personalmente, no me importa llamar a funciones largas de estilo C por la razón exacta que mencionó Wolfgang; realmente hay pocos lugares a los que deba llamarlos e incluso entonces, casi siempre quedan envueltos por algún código de nivel superior.

Las únicas cosas que realmente me molestan con el MPI de estilo C son los tipos de datos personalizados y, en menor grado, las operaciones personalizadas (porque las uso con menos frecuencia). En cuanto a los tipos de datos personalizados, diría que una buena interfaz C ++ debería ser capaz de soportar una forma genérica y eficiente de manejar esto, probablemente a través de la serialización. Por supuesto, esta es la ruta que boost.mpiha tomado, que si tiene cuidado , es un gran ahorro de tiempo.

En cuanto a boost.mpitener dependencias adicionales (en particular, boost.serializationque no es solo de encabezado), recientemente me encontré con una biblioteca de serialización de C ++ de solo encabezado llamada cereal que parece prometedora; dado que requiere un compilador compatible con C ++ 11. Podría valer la pena analizarlo y usarlo como base para algo similar a boost.mpi.

El proyecto github easyLambda proporciona una interfaz de alto nivel para MPI con C ++ 14.

Creo que el proyecto tiene objetivos similares y dará una idea de las cosas que se pueden hacer y se están haciendo en esta área utilizando C ++ moderno. Guiando otros esfuerzos, así como easyLambda en sí.

Los puntos de referencia iniciales sobre el rendimiento y las líneas de código han mostrado resultados prometedores.

A continuación se incluye una breve descripción de las características y la interfaz que proporciona.

La interfaz se basa en la programación del flujo de datos y las operaciones de la lista funcional que proporcionan paralelismo inherente. El paralelismo se expresa como propiedad de una tarea. La asignación del proceso y la distribución de datos para la tarea se pueden solicitar con una propiedad .prll (). Hay un buen número de ejemplos en la página web y en el repositorio de código que incluyen el procesamiento posterior de dinámica molecular LAMMPS, la solución explícita de diferencia finita a la ecuación de calor, la regresión logística, etc. Como ejemplo, el problema de difusión de calor discutido en el artículo HPC está muriendo ... se puede expresar en ~ 20 líneas de código.

Espero que esté bien dar enlaces en lugar de agregar más detalles y códigos de ejemplo aquí.

Descargo de responsabilidad: soy el autor de la biblioteca. Creo que no estoy haciendo ningún daño al esperar obtener una retroalimentación constructiva sobre la interfaz actual de easyLambda que podría ser ventajosa para easyLambda y cualquier otro proyecto que persiga objetivos similares.