使用 MPI::Isend as 的语法
MPI::Request MPI::Comm::Isend(const void *buf, int count,
const MPI::Datatype& datatype,
int dest, int tag) const;
是限制发送的数据量
std::numeric_limits<int>::max()
许多其他 MPI 函数都有 int 参数。这是 MPI 的限制吗？
最佳答案
MPI-2.2 定义数据长度参数为int .自 int 以来，这可能而且通常是大多数 64 位 Unix 系统上的问题。仍然是 32 位的。此类系统称为 LP64，这意味着 long和指针是 64 位长，而 int长度为 32 位。相比之下，Windows x64 是一个 LLP64 系统，这意味着 int和 long是 32 位长，而 long long指针是 64 位长。用于 64 位 x86 CPU 的 Linux 是 LP64 类 Unix 系统的一个示例。
鉴于以上所有MPI_Send在 MPI-2.2 实现中，消息大小限制为 2^31-1元素。可以通过构造用户定义的类型(例如连续类型)来克服该限制，这将减少数据元素的数量。例如，如果您注册了 2^10 的连续类型一些基本 MPI 类型的元素，然后使用 MPI_Send发送2^30这种新类型的元素，它会导致消息 2^40基本类型的元素。如果使用 int，某些 MPI 实现在这种情况下可能仍会失败。在内部处理元素计数。它也打破了MPI_Get_elements和 MPI_Get_count作为他们的输出 count参数类型为 int .
MPI-3.0 解决了其中的一些问题。例如，它提供了 MPI_Get_elements_x和 MPI_Get_count_x使用 MPI_Count 的操作typedef 为他们的 count争论。 MPI_Count被定义为能够保存指针值，这使得它在大多数 64 位系统上为 64 位长。还有其他扩展调用(全部以 _x 结尾)需要 MPI_Count而不是 int .老MPI_Get_elements/MPI_Get_count保留操作，但现在它们将返回 MPI_UNDEFINED如果计数大于 int输出参数可能成立(MPI-2.2 标准中不存在此说明，并且在未定义的行为中使用非常大的计数)。
正如 pyCthon 已经指出的那样，C++ 绑定(bind)在 MPI-2.2 中已弃用，并已从 MPI-3.0 中删除，因为 MPI 论坛不再支持。您应该使用 C 绑定(bind)或求助于第 3 方 C++ 绑定(bind)，例如Boost.MPI .
关于c++ - 使用 MPI::Send 可以发送的最大数据量，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13558861/