Сравнение загрузки процессора во время тупика потока MPI с использованием mvapich2 и openmpi

Question

Я заметил, что когда у меня есть заблокированная программа MPI, например, wait.c

#include <stdio.h>
#include <mpi.h>


int main(int argc, char * argv[])
{
    int taskID = -1; 
    int NTasks = -1; 
    int a = 11; 
    int b = 22; 
    MPI_Status Stat;

    /* MPI Initializations */
    MPI_Init(&argc, &argv);
    MPI_Comm_rank(MPI_COMM_WORLD, &taskID);
    MPI_Comm_size(MPI_COMM_WORLD, &NTasks);

    if(taskID == 0)
        MPI_Send(&a, 1, MPI_INT, 1, 66, MPI_COMM_WORLD);
    else //if(taskID == 1)
        MPI_Recv(&b, 1, MPI_INT, 0, 66, MPI_COMM_WORLD, &Stat);

    printf("Task %i :    a: %i    b: %i\n", taskID, a, b); 

    MPI_Finalize();
    return 0;
}

Когда я компилирую wait.c с библиотекой mvapich2-2.1 (которая сама была скомпилирована с использованием gcc-4.9.2) и запустите ее (например, mpirun -np 4 ./a.out) Я замечаю (через top), что все 4 процессора работают на 100%.

Когда я компилирую wait.c с библиотекой openmpi-1.6 (которая сама была скомпилирована с использованием gcc-4.9.2) и запустите ее (например, mpirun -np 4 ./a.out) Замечаю (через top), что 2 процессора загружаются на 100%, а 2 - на 0%.

Предположительно, 2 при 0% - это те, которые завершили общение.

ВОПРОС: Почему разница в загрузке ЦП между openmpi и mvapich2? Это ожидаемое поведение? Когда загрузка процессора составляет 100%, это от постоянной проверки, чтобы увидеть, отправляется ли сообщение?

Answer 1

Обе реализации заняты ожидания MPI_Recv() чтобы минимизировать задержки. Это объясняет, почему ранги 2 и 3 равны 100% в любой из двух реализаций MPI.

Теперь четко занимает 0 и 1 прогресс в MPI_Finalize() call, и здесь две реализации различаются: mvapich2 busy-wait, а openmpi - нет.

Чтобы ответить на ваш вопрос: да, они на 100% проверяют, было ли получено сообщение и ожидаемое ли это поведение.

Если вы не на InfiniBand, вы можете наблюдать это, прикрепив strace к одному из процессов: вы должны увидеть несколько вызовов poll().