Política MPI para várias transferências assíncronas

Qual é a política de várias transferências assíncronas sobrepostas no MPI?

Eu tenho um programa com várias irecvoperações assíncronas abertas . Acho que as transferências que podem ocorrer (o correspondente isendfoi chamado) aguardam outras transferências que ainda não estão prontas (o correspondente isendainda não foi chamado). Para ficar claro, essa ineficiência não decorre da contenção de rede; minha rede está desnecessariamente ociosa.

Meu programa é semelhante ao seguinte:

Máquina 1

call irecv(variable A from machine 2)
call irecv(variable B from machine 2)
call irecv(variable C from machine 2)
call wait(variable C from machine 2)
call do_important_work_with(variable C)
....

Máquina 2

call isend(variable C to machine 1)
call isend(variable B to machine 1)
call do a bunch of costly work
call isend(variable A to machine 1)
....

Problema

A transferência de Cparece estar desnecessariamente bloqueada pela transferência de A.

Acho que o waitligado variable Cna Máquina 1 não é concluído até que o dispendioso trabalho na Máquina 2 seja concluído. Isso é lamentável, porque essa transferência poderia ter começado no início do meu programa. Parece esperar desnecessariamente a transferência de Aconcluir.

Questões

Em particular, tenho um cálculo como o seguinte.

Isso é esperado?
Qual é a política de várias transferências assíncronas sobrepostas?
Isso pode ser evitado sem reorganizar meu código (há alguma configuração interna relevante)?
Onde devo saber mais sobre a política da MPI para várias transferências ao vivo?

parallel-computing software mpi

— MRocklin
fonte

Qual o tamanho das transferências? Transferências com a mesma assinatura são necessárias para ocorrer em ordem. Você usa tags diferentes para as diferentes transferências? Além disso, não importa qual pilha MPI você usa. A semântica da ordem das transferências é definida pelos padrões MPI.

— Bill Barth

As transferências são grandes (cerca de 1 MB) e têm o mesmo tamanho / origem / destino (essa é a assinatura?). Eles têm tags diferentes.

— 21913 MRocklin

Tags diferentes devem permitir que eles sigam em qualquer ordem, mas o hardware precisa realmente mover os dados, e na verdade não pode fazer isso em paralelo. Portanto, se for uma mensagem grande, você pode estar esperando o hardware subjacente copiar A e B em buffers internos ou DMA na NIC (dependendo do hardware que você possui). Eu recomendaria alterar a ordem em que você envia os recebimentos e também tentar usar uma pilha diferente (MPICH, MVAPICH, Intel MPI etc.), dependendo do seu hardware. Além disso, você pode tentar ativar os threads de progresso.

— Bill Barth

Se você tem esse tipo de padrão de comunicação, já através da Ethernet, recomendo o uso do zmq em vez do mpi.

— precisa saber é

Não há garantia no padrão de que seja feito qualquer progresso nos envios sem bloqueio até que você realmente ligue MPI_WAIT. É uma implementação perfeitamente válida para enfileirar as operações e quando você chama MPI_WAIT, todas as MPI_ISENDoperações são concluídas de uma só vez. Na realidade, eles geralmente tendem a ter a chance de progredir sempre que você entra na biblioteca MPI e, se você habilitar threads de progresso assíncronos, eles terão uma chance maior de progredir em segundo plano.

Quanto ao problema de assinatura, o MPI garante que as mensagens no mesmo comunicador para as mesmas fileiras serão recebidas na mesma ordem em que foram enviadas.

No padrão MPI versão 3.0:

As mensagens de pedido não ultrapassam: Se um remetente enviar duas mensagens consecutivas para o mesmo destino e ambas corresponderem ao mesmo recebimento, essa operação não poderá receber a segunda mensagem se a primeira ainda estiver pendente. Se um destinatário postar dois recebimentos consecutivos e ambos corresponderem à mesma mensagem, a segunda operação de recebimento não poderá ser satisfeita por essa mensagem, se o primeiro ainda estiver pendente.

Isso não diz nada sobre como a implementação escolhe enviar as mensagens, mas pelo menos elas serão recebidas na ordem correta.

Meu conselho seria primeiro verificar se os threads de progresso estão ativados e, em seguida, verifique se você está ligando para wait, onde realmente precisa das mensagens enviadas (embora, com os threads de progresso, você provavelmente esteja bem).

— Wesley Bland
fonte