使用MPI_Barrier()后MPI_Wtime()的巨大差异?

时间:2013-06-28 23:36:19

标签: c++ c ipc mpi openmpi

这是代码的一部分。

    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进程)。请解释一下?

3 个答案:

答案 0 :(得分:3)

感谢Wesley Bland注意到你在同一个请求上等了两次。以下是对实际情况的解释。

在MPI中有一些称为 progress 的异步(非阻塞)操作。那是实际转移发生的时候。进展可以通过许多不同的方式以及MPI库中的许多不同点发生。当您发布异步操作时,它的进展可以无限延迟,甚至直到一个调用MPI_WaitMPI_Test或某些调用将导致新消息被推送到或从传输中拉出的点为止。接收队列。这就是为什么在启动非阻塞操作后尽快调用MPI_WaitMPI_Test非常重要。

Open MPI支持后台进程线程,即使前一段中的条件不满足,也需要注意进行操作,例如:如果从未在请求​​句柄上调用MPI_WaitMPI_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?