发送数据：MPI_Type_contiguous vs原始类型

Question

我正在尝试交换数据（30个字符）b / w两个进程以将MPI_Type_contiguous API理解为：

char data[30];
MPI_Type_contiguous(10,MPI_CHAR,&mytype);
MPI_Type_commit(&mytype);
MPI_Send(data, 3,mytype,1, 99,MPI_COMM_WORLD);

但类似的任务可以通过以下方式完成：

MPI_Send(data, 30,MPI_CHAR,1, 99,MPI_COMM_WORLD);

我想没有延迟因素优势，因为我在两种情况下都只使用单个函数调用（或者是吗？）。

任何人都可以共享 MPI_Type_contiguous 优于原始类型的用例（就完成任务的性能/易用性而言）吗？

Answer 1

立即想到的一个用途是发送非常大的消息。由于count的{​​{1}}参数类型为MPI_Send，因此在典型的LP64（类Unix操作系统）或LLP64（Windows）64位操作系统上，无法直接发送更多即使MPI实现内部使用64位长度，也不会超过2个 ³¹ -1个元素。由于现代计算节点具有数百个GiB的RAM，因此这变得令人讨厌。解决方案是创建长度为int的新数据类型，并发送新类型的m个元素，共计n个数据元素，其中n*m现在可以达到2 ⁶² -2 ³² 1。该方法是面向未来的，也可以在128位计算机上使用，因为MPI数据类型可以进一步嵌套。这种解决方法以及注册数据类型比执行时间更便宜（与执行时间相比）的事实相比，MPI论坛拒绝了添加新的大计数API或修改现有的参数类型。杰夫哈蒙德（@Jeff）写了library来简化这个过程。

MPI-IO的另一个用途。使用n*m设置文件视图时，可以提供连续的数据类型作为基本数据类型。它允许一个例如以更简单的方式处理没有内置复杂数据类型的语言的复数二进制文件（如早期版本的C）。

Answer 2

MPI_Type_contiguous用于创建新数据类型，即现有数据类型的count个副本。这对于简化将多种数据类型一起发送的过程非常有用，因为您无需跟踪它们的组合大小（count中的MPI_send可以替换为1）。

对于你的情况，我认为它完全一样。来自using MPI的文字略微适合您的示例，

  

当在MPI操作中使用count参数时，它与构造该大小的连续类型的情况相同。

MPI_Send(data, count, MPI_CHAR, 1, 99, MPI_COMM_WORLD);

     

与

完全相同

MPI_Type_contiguous(count, MPI_CHAR, &mytype);
MPI_Type_commit(&mytype);
MPI_Send(data, 1, mytype, 1, 99, MPI_COMM_WORLD);
MPI_Type_free(&mytype);

你是对的，因为只有一个实际的通信呼叫，延迟将是相同的（带宽，发送相同的字节数）。