【发布时间】:2021-12-22 11:20:03
【问题描述】:
本题是关于接收操作的输入参数count的解释。
在 MPI 手册的one part 中它说(see here 我的):
int MPI_Recv(void *buf, int count, MPI_Datatype datatype, int source, int tag,
MPI_Comm comm, MPI_Status *status)
Output Parameters
count
maximum number of elements in receive buffer (integer) <-------- see here
在other part 中说
int MPI_Sendrecv(const void *sendbuf, int sendcount, MPI_Datatype sendtype,
int dest, int sendtag,
void *recvbuf, int recvcount, MPI_Datatype recvtype,
int source, int recvtag, MPI_Comm comm, MPI_Status * status)
...
recvcount
number of elements in receive buffer (integer) <-------- see here
长期以来,我忽略了措辞上的差异,并将它们解释为两种说法,即可以接收的最大元素数。
但是,如果我从字面上阅读recvcount(第二种情况)是缓冲区中可用(分配)的元素数量,不一定是可以接收的元素的最大数量。
换句话说,recvcount 的意思可能是 MPI 实现可以用来存储临时数据的元素数量,例如,其中的一部分最终会出现垃圾。
还有另一种情况会有所不同:如果我不确切知道收到的元素数量是多少,我可以将MAX_INT 作为参数传递,以确保程序逻辑的正确性。
但是当然,MAX_INT 不是接收缓冲区中分配的内存,它原则上只是说我可以接收其他人正在发送的任意数量的元素。
count(Recv)和recvcount(SendRecv)的解释真的有区别吗?
是否允许在任何一种情况下或两种情况下都传递MAX_INT?如果接收元素的数量未知(在程序的一部分本地)
我对 OpenMPI 进行了一些试验,答案似乎是允许传递 MAX_INT 并按预期工作,但我不知道这是否是流行的解释。
(相反的解释(计数只是分配的内存)会很遗憾,因为这意味着只有分配的缓冲区及其大小才能有效地传递给这些函数。)
编辑:
明确地说,我要问的是在这个程序中,原则上正确且定义明确以接收整个发送的消息:
#include <mpi.h>
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv) {
MPI_Init(&argc, &argv);
int count = 10;
double xsend[count];
double xrecv[123];
for (int i=0; i<count; i++) {xsend[i] = (double)i;}
int rank, nprocs;
MPI_Comm_rank(MPI_COMM_WORLD, &rank);
MPI_Comm_size(MPI_COMM_WORLD, &nprocs);
assert (nprocs == 2);
if(rank == 0) {MPI_Send(xsend, count, MPI_DOUBLE, 1, 0, MPI_COMM_WORLD);}
if(rank == 1) {
MPI_Recv(xrecv, NN, MPI_DOUBLE, MPI_ANY_SOURCE, MPI_ANY_TAG, MPI_COMM_WORLD, MPI_STATUS_IGNORE);
assert( xrecv[9] == 9 );
}
MPI_Finalize();
return 0;
}
NN 的哪些值在语义上正确以接收整个消息:
NN = 10NN = 20NN = 123NN = 100000NN = MAX_INT - 2NN = MAX_INT - 1NN = MAX_INT
我知道选项 1. 是推荐的,选项 2. 和 3. 肯定是正确的。 我的问题是其他选项是否定义明确。
【问题讨论】:
-
MPICH 文档不是 MPI 标准。请使用mpi-forum.org/docs/mpi-4.0/mpi40-report.pdf。我知道 MPICH 文档通常是标准的逐字副本,但最好不要将两者混为一谈。
-
@JeffHammond 是的。为了完整起见,第 37 页的链接文档中写着“计数,接收缓冲区的大小”。