这是代码的一部分。
if(rank==0) {
temp=10000;
var=new char[temp] ;
MPI_Send(&temp,1,MPI_INT,1,tag,MPI_COMM_WORLD);
MPI_Send(var,temp,MPI_BYTE,1,tag,MPI_COMM_WORLD);
//MPI_Wait(&req[0],&sta[1]);
}
if(rank==1) {
MPI_Irecv(&temp,1,MPI_INT,0,tag,MPI_COMM_WORLD,&req[0]);
MPI_Wait(&req[0],&sta[0]);
var=new char[temp] ;
MPI_Irecv(var,temp,MPI_BYTE,0,tag,MPI_COMM_WORLD,&req[1]);
MPI_Wait(&req[0],&sta[0]);
}
//I am talking about this MPI_Barrier
MPI_Barrier(MPI_COMM_WORLD);
cout << MPI_Wtime()-t1 << endl ;
cout << "hello " << rank << " " << temp << endl ;
MPI_Finalize();
}
1。当使用MPI_Barrier时 - 正如预期的那样,所有过程都花费了相同的时间,即0.02的订单
2。当不使用MPI_Barrier() - 根进程(发送消息)等待一些额外的时间。
并且(MPI_Wtime -t1)
变化很大,根进程所花费的时间是2秒。
如果我没有弄错,MPI_Barrier仅用于将所有正在运行的进程置于同一级别。那么为什么我使用MPI_Barrier()的时间不是2秒(所有进程的最小值。例如root进程)。请解释一下?
答案 0 :(得分:3)
感谢Wesley Bland注意到你在同一个请求上等了两次。以下是对实际情况的解释。
在MPI中有一些称为 progress 的异步(非阻塞)操作。那是实际转移发生的时候。进展可以通过许多不同的方式以及MPI库中的许多不同点发生。当您发布异步操作时,它的进展可以无限延迟,甚至直到一个调用MPI_Wait
,MPI_Test
或某些调用将导致新消息被推送到或从传输中拉出的点为止。接收队列。这就是为什么在启动非阻塞操作后尽快调用MPI_Wait
或MPI_Test
非常重要。
Open MPI支持后台进程线程,即使前一段中的条件不满足,也需要注意进行操作,例如:如果从未在请求句柄上调用MPI_Wait
或MPI_Test
。必须在构建库时显式启用此功能。默认情况下不启用它,因为后台进程会增加操作的延迟。
在您的情况下,您第二次在接收方中呼叫MPI_Wait
时正在等待不正确的请求,因此推迟了第二次MPI_Irecv
操作的进展。该消息的大小超过40 KiB(10000字节4字节+信封开销),高于Open MPI(32 KiB)中的默认eager限制。使用集合协议发送此类消息,该协议要求发送和发送发送和接收操作。接收操作没有进展,因此秩0中的发送操作会阻塞,直到在某个时间点,排名1中的MPI_Finalize
调用的清理例程最终会进行接收。
当您拨打MPI_Barrier
时,它会导致未完成接收的进展,其行为几乎就像是对MPI_Wait
的隐式调用。这就是为什么排名0中的发送快速完成并且两个进程都及时移动的原因。
请注意,MPI_Irecv
后面紧跟MPI_Wait
等同于简单地调用MPI_Recv
。后者不仅更简单,而且更容易出现像你所做的简单错别字。
答案 1 :(得分:0)
你正在为你的Irecv等待两次相同的请求。第二个是一个会占用所有时间的,并且自从它被跳过后,等级0正在前进。
可以实现MPI_BARRIER,使得某些进程可以在进程之前将算法留在其余进程中。这可能就是这里发生的事情。
答案 2 :(得分:0)
在我运行的测试中,我发现运行时几乎没有差异。主要区别在于您似乎在运行代码一次,而我将代码循环数千次然后取平均值。我的输出如下:
With the barrier
[0]: 1.65071e-05
[1]: 1.66872e-05
Without the barrier
[0]: 1.35653e-05
[1]: 1.30711e-05
因此,我认为您所看到的任何变化都是您的操作系统的结果,而不是您的程序。
另外,为什么使用MPI_Irecv和MPI_wait而不是仅仅使用MPI_recv?