随着语法MPI :: Isend为
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函数有一个整型参数。 这是MPI的限制？
Answer 1:
MPI-2.2定义的数据长度参数为int 。 这可能是和通常是大多数64位Unix系统的一个问题，因为int仍然是32位。 这样的系统被称为LP64，这意味着long和指针是64位长，而int的长度是32位。 与此相反，视窗64是一种LLP64系统，这意味着这两个int和long都是32位长，而long long和指针是64位长。 Linux的64位x86 CPU是这样的类Unix系统，该系统是LP64的一个例子。
鉴于以上所有的MPI_Send在MPI-2.2实现具有的邮件大小限制2^31-1的元件。 一个可以通过构建用户定义的类型（例如连续型），这将减少数据元素的量克服了限制。 例如，如果你注册的连续型的2^10的一些基本MPI类型的元素，然后使用MPI_Send发送2^30这种新型的元件，这将导致消息2^40的基本类型的元素。 有些MPI实现可能仍然无法在这种情况下，如果他们使用int来处理内部的元件数。 此外，它打破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 ++绑定弃用MPI-2.2和从MPI-3.0作为去除不再支持由MPI论坛。 您应该使用C绑定或求助于第三方C ++绑定，如Boost.MPI 。
Answer 2:
我没有做过MPI，然而，int是一个数组的通常大小的限制，我就怀疑是在限制来自。
在实践中，这是一个相当高的限制。 你有一个数据需要传送超过4 GB？ （在单Isend）
欲了解更多信息，请参阅有C ++中的最大数组长度的限制？
确实注意到该链接使得引用为size_t，而不是INT（对于所有意图，几乎允许无限制的数据，至少在2012年） - 然而，在过去，“廉政”是普通类型的这种计数，并同时为size_t应该用，在实践中，大量的代码仍然使用“廉政”。
Answer 3:
一个的最大大小MPI_Send将由可以分配的存储器的最大量的限制
和大多数MPI实现支持sizeof(size_t)
Answer 4:
这个问题和一些解决方法（有代码）进行了讨论https://github.com/jeffhammond/BigMPI 。 特别是，该项目演示了如何发送大于通过用户定义的数据类型INT_MAX元素更多。
文章来源: Maximum amount of data that can be sent using MPI::Send
