使用接近“INT_MAX”的“count”值传送数据

消息传递接口 API 始终使用int作为一个类型count变量。例如，原型为MPI_Send is:

int MPI_Send(const void* buf, int count, MPI_Datatype datatype, int dest, int tag, MPI_Comm comm);

如果要发送或接收的元素数量过多，这可能会出现问题接近甚至超越 INT_MAX.

当然这个问题可以通过降低值来解决count通过以下任一方式：

1. 将单个呼叫拆分为多个呼叫
2. 定义（不必要的）聚合MPI_Datatype

无论如何，这两种方法都更像是一种黑客行为，而不是真正的解决方案，特别是如果使用简单的启发式方法来实现。因此我想问的是：

是否有更好的习惯用标准 MPI 调用来处理此类情况？如果没有，有人知道一些围绕 MPI 构建的（实体）包装库来克服这个限制吗？

我是 的首席开发人员BigMPI并共同撰写了一篇论文，题为到 INT_MAX...甚至更远！：探索 MPI 中的大计数支持这里对这个主题的讨论比篇幅所允许的要详细得多。

如果您无法免费访问 ACM DL，您可以下载阿贡预印本或结账纸质资源库.

以下是这项工作的主要亮点：

• BigMPI 是 MPI 的一个相对高质量的接口，支持 64b 整数计数（技术上该类型是MPI_Count but MPI_Aint内部使用）。讽刺的是，它并没有利用 MPI-3 大计数功能。这是因为 BigMPI 并不完全通用，而是旨在支持最常见的使用模型。

• BigMPI 的设计部​​分是为了教育目的。它采用了超宽容的麻省理工学院许可证使任何人都可以将代码从其中复制到另一个项目中，并可能进行更改以满足不可预见的需求。

• 在 MPI-3 接口中超过 INT_MAX 不仅仅是一个小问题。这是无效的 ISO C 代码。与无符号整数不同，有符号整数的翻转行为是未定义的。因此，主要问题不在于 MPI，而在于 C 整数不能容纳大于 INT_MAX 的数字。将 count 参数指定为 C 是否是 MPI 的问题是一个有争议的问题int类型，而不是size_t， 例如。在说 MPI 显然应该切换到之前size_t，您需要了解 MPI 的历史以及重要性ABI兼容性到 MPI 用户的子集。

• 即使使用 BigMPI 或类似的基于数据类型的方法，实施可能有错误。这意味着执行符合标准的操作将不起作用，因为在内部 MPI 实现可能会不正确地存储类似的内容count*sizeof(type)转换为 32b 值，如果满足以下条件，该值可能会溢出，导致有效计数（如 10 亿）sizeof(type)例如，是八。正如上述论文中所指出的，除了这些 bug（在 MPICH 和 Open-MPI 的最新版本中似乎不存在）之外，POSIX 函数中还存在必须缓解的 bug。

• Fortran 的情况更为复杂。 Fortran 默认整数大小未指定，理论上，MPI 实现应尊重编译器使用的任何内容。然而，实际情况往往并非如此。我相信由于使用 C，许多 MPI 实现在计数超过 INT_MAX 时就会被破坏int内部。 BigMPI 没有 Fortran 接口，尽管我希望有一天能编写一个。在那之前，请敦促 MPI 实施者做正确的事情。福特兰语言INTEGER内部转换为 C 类型。

无论如何，我不想将我们论文的全部内容转录到这篇文章中，特别是因为它和源代码一样都是免费提供的。如果您觉得这篇文章有不足之处，请评论，我会在稍后尝试添加更多内容。

最后，BigMPI 是研究代码，我不会说它已经完成（但是，您不应该点击未完成的代码）。强烈鼓励用户在生产中使用之前对 BigMPI 和 MPI 实现进行自己的正确性测试。