用户需要MPI C ++接口提供哪些功能？

MPI标准的3.0版本正式删除了C ++接口（先前已弃用）。尽管实现可能仍支持它，但MPI-3中的新功能没有MPI标准中定义的C ++接口。有关更多信息，请参阅http://blogs.cisco.com/performance/the-mpi-c-bindings-what-happened-and-why/。

从MPI中删除C ++接口的动机是，与C接口相比，它没有任何重要价值。除“ s / _ / :: / g”外，几乎没有区别，并且未使用C ++用户习惯的许多功能（例如，通过模板自动确定类型）。

作为参加MPI论坛并与许多实现了自己的MPI C函数C ++接口的C ++项目一起工作的人，我想知道MPI C ++接口的理想功能是什么。尽管我什么也不做，但我希望看到一个满足许多用户需求的独立MPI C ++接口的实现。

是的，我熟悉Boost :: MPI（http://www.boost.org/doc/libs/1_54_0/doc/html/mpi.html），但它仅支持MPI-1功能，并且序列化模型应为支持RMA极其困难。

我喜欢的一个MPI的C ++接口是Elemental（https://github.com/poulson/Elemental/blob/master/src/core/imports/mpi.cpp），所以也许人们可以提供一些专业知识方法。特别是，我认为MpiMap解决了一个基本问题。

让我首先回答一下，为什么我认为C ++与MPI的接口通常并不太成功，在试图决定是否只使用MPI的标准C绑定还是在更高级别上构建时，已经考虑了很长时间：

当您查看现实世界中的MPI代码（例如，PETSc或我的案例交易II）时，可能会发现令人惊讶的是，MPI调用的数量实际上并不是很大。例如，在500k交易行II中，只有约100个MPI调用。其结果是，使用低级接口（例如MPI C绑定）所涉及的痛苦不会太大。相反，通过使用更高级别的接口并不会获得太多收益。

我的第二个观察结果是，许多系统都安装了多个MPI库（不同的MPI实现或不同的版本）。如果您想使用不仅仅由头文件组成的boost :: mpi，这会带来很大的困难：或者还需要多次安装此软件包，或者需要将其构建为其中的一部分。使用boost :: mpi的项目（但这又是一个问题，因为boost使用自己的构建系统，这与其他任何东西都不一样）。

因此，我认为所有这些都与当前MPI的C ++接口的阴谋密不可分：旧的MPI C ++绑定没有提供任何优势，外部程序包在现实世界中遇到了困难。

总而言之，这就是我想从更高级别的界面获得的杀手级功能：

• 它应该是通用的。必须指定变量的数据类型绝对不是C ++。当然，这也会导致错误。Elemental的MpiMap类已经是不错的第一步（尽管我无法弄清楚为什么该MpiMap::type变量不是静态const，因此无需创建对象即可对其进行访问）。

• 它应该具有用于​​流传输任意数据类型的功能。

• 需要自MPI_Op变量的操作（例如，归约）应与C ++的std::function界面很好地集成在一起，因此只需传递函数指针（或lambda！）即可，而不必笨拙地注册某些东西。

boost :: mpi实际上满足了所有这些要求。我认为，如果这是仅标头的库，那么在实践中它将流行得多。如果它支持MPI 1.0之后的功能，也将有所帮助，但是老实说：这涵盖了我们大部分时间的大部分需求。

为了使事情顺利进行，这是我的两个需求：

• 该接口应能够消除冗余或不必要的参数，例如MPI_IN_PLACE。
• 该界面应自动检测ala Elemental的MpiMap内置数据类型。
• 如果可能，应为类构造用户定义的数据类型。

我的列表没有特别的优先顺序。该界面应：

• 仅是标头，除了<mpi.h>和标准库之外，没有任何依赖关系，
• 具有通用性和可扩展性
• 无阻塞只（如果你想阻止，则阻止明确，而不是由默认值），
• 允许对非阻塞操作进行基于连续的链接，
• 支持可扩展且有效的序列化（类似于Boost.Fusion，可与RMA配合使用），
• 具有零抽象损失（即至少与C接口一样快），
• 是安全的（未就绪的未来的析构函数称为？-> std :: terminate！），
• 具有DEBUG大量断言的强大模式，
• 非常安全的类型（没有更多的int / void *用于所有内容，我想让标签成为类型！），
• 它应该与lambda一起工作（例如，所有reduce + lambda），
• 一致地使用异常作为错误报告和错误处理机制（不再有错误代码！不再有函数输出参数！），
• MPI-IO应该以Boost.AFIO的样式提供无阻塞的I / O接口，
• 并遵循良好的现代C ++接口设计规范（定义常规类型，非成员非朋友功能，在移动语义上发挥出色，支持范围操作...）

附加功能：

• 请允许我选择MPI环境的执行程序，即它使用哪个线程池。现在，您可以同时具有混合了OpenMP，MPI，CUDA和TBB的应用程序...，每个运行时都认为它拥有环境，因此每次感觉到操作系统时都向操作系统请求线程它。认真吗

• 使用STL（和Boost）命名约定。为什么？每个C ++程序员都知道这一点。

我想写这样的代码：

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

想一想如何使用MPI_C链接所有这些操作request。您将必须通过大量不相关的代码在多个（或每个）中间步骤中进行测试，以查看是否可以不阻塞地推进链。

就我个人而言，由于沃尔夫冈提到的确切原因，我真的不介意调用长C样式的函数。实际上，您几乎不需要调用它们的地方，即使那样，它们几乎总是被一些高级代码所包裹。

使用C风格的MPI真正困扰我的唯一事情是自定义数据类型，以及程度较小的自定义操作（因为我使用它们的频率降低了）。至于自定义数据类型，我想说一个好的C ++接口应该能够支持通用且有效的处理方式，最有可能是通过序列化的方式。当然，这是boost.mpi采取的路线，如果您小心一点，可以节省大量时间。

至于boost.mpi具有额外的依赖关系（尤其boost.serialization是本身不是仅标头的），我最近遇到了一个称为谷物的仅标头的C ++序列化库，这似乎很有希望。授予它需要一个符合C ++ 11的编译器。可能值得研究并将其用作类似于的基础boost.mpi。

github项目easyLambda提供了C ++ 14与MPI的高级接口。

我认为该项目具有类似的目标，并且将通过使用现代C ++对该领域中可以做和正在做的事情给出一些想法。指导其他工作以及easyLambda本身。

最初的性能和代码行基准已经显示出令人鼓舞的结果。

以下是它提供的功能和界面的简短说明。

该接口基于提供固有并行性的数据流编程和功能列表操作。并行性表示为任务的属性。可以使用.prll（）属性请求任务的进程分配和数据分配。网页和代码库中有很多示例，包括LAMMPS分子动力学后处理，热方程的显式有限差分解决方案，逻辑回归等。作为示例，HPC文章中讨论的热扩散问题正在逐渐消失...可以用约20行代码表示。

我希望可以提供链接，而不是在此处添加更多详细信息和示例代码。

Disclamer：我是图书馆的作者。我相信希望获得对easyLambda当前界面的建设性反馈不会有任何危害，这可能对easyLambda和追求类似目标的任何其他项目都有利。