c++ - 使用 MPI_Barrier() 后 MPI_Wtime() 的巨大差异？

Question

这是代码的一部分。

    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 秒(所有进程的最小值。例如根进程)。请解释一下？

Answer 1

感谢 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)。此类消息是使用会合协议(protocol)发送的，该协议(protocol)要求发送和接收操作都被发布和进行。接收操作不会进行，因此排名 0 中的发送操作会阻塞，直到某个时间点 MPI_Finalize 在排名 1 中调用的清理例程最终会进行接收。

当您调用 MPI_Barrier 时，它会导致未完成接收的进展，其作用几乎类似于对 MPI_Wait 的隐式调用。这就是为什么排名 0 的发送很快完成并且两个进程都及时进行。

请注意 MPI_Irecv，紧接着 MPI_Wait 等同于简单地调用 MPI_Recv。后者不仅更简单，而且更不容易出现像您所做的那样的简单拼写错误。