Qual é uma maneira eficiente de notificar processos MPI de recebimento de mensagens?

8

Em MPI, existe algum mecanismo interno para notificar um grupo de processos de que eles precisam para receber mensagens de outros processos?

No meu aplicativo, todo processo precisa enviar dados para um grupo de processos com IDs de classificação conhecidos (que potencialmente são alterados a cada iteração), mas eles não sabem a classificação dos processos dos quais as mensagens serão recebidas. Existe uma maneira portátil, de preferência embutida, de conseguir isso sem consultar cada processo?

mpi

— mmirzadeh
fonte

7

Você pode tentar que todos os processadores usem MPI_IProbe ou MPI_Probe com MPI_ANY_SOURCE para verificar se há alguma mensagem a receber com uma determinada tag. Se houver mensagens correspondentes, você poderá extrair a classificação dos remetentes do status retornado e ligar para MPI_Recv imediatamente.

— Matthew Emmett
fonte

Ligar é MPI_Probeessencialmente mais barato que MPI_Recv?

— mmirzadeh

@GradGuy Com o MPI_IProbe e o MPI_Probe, você realmente não recebe nenhuma mensagem (você está apenas consultando o MPI para ver se há alguma mensagem a receber), portanto, nesse sentido, suponho que seja mais barato que o MPI_Recv.

— Matthew Emmett

@MatthewEmmett Como o receptor sabe quantas MPI_IProbechamadas para postar ou por quanto tempo continua a sondar?

— Shibli

12

Outros já propuseram as várias variantes do MPI_Probe, mas gostaria de salientar uma coisa: o MPI não é uma chamada de procedimento remoto, ou seja, não há maneiras de notificar um processo de entrada de alguma mensagem (por exemplo, levantando um sinal ) As mensagens são enviadas, mas se o processo de recebimento não for procurá-las, nada acontecerá. Como tal, a resposta para sua pergunta é "não", mas um processo pode descobrir ativamente se uma mensagem foi enviada para ela.

— Wolfgang Bangerth
fonte

Em teoria, o MPI_Probe pode ser desmarcado pelo kernel de forma que seja passivo até ser usado, o que não é muito diferente de como a IBM implementa RPCs reais no Blue Gene (onde o SO e o HW colaboram para implementar interrupções iniciadas na rede muito eficientes que podem chamar retornos de chamada arbitrários definidos pelo usuário). Claro, nenhuma implementação que sei sobre realmente faz isso com o bloqueio de chamadas MPI ...

— Jeff

1

O ponto que eu queria enfatizar não é tanto sobre como ele é realmente implementado, mas sobre o modelo mental que se deve ter ao pensar em MPI. MPI é puramente um conceito passivo: você não pode acessar dados de outro processo, não pode esperar que um sinal seja gerado se uma mensagem chegar; tudo sempre apenas acontece se você enviar ativamente uma mensagem ou olhar se alguém entrou.

— Wolfgang Bangerth

Você está certo quanto a um sinal, mas a RMA fornece acesso a dados remotos e as implementações devem fornecer progresso passivo.

— 10113 Jeff

1

Sim, você está falando sobre o que o MPI 3 chama de "comunicação unilateral". Essa é uma adição relativamente recente, e provavelmente uma raramente usada. Mas acho que isso não tira o modelo mental que expus acima.

— Wolfgang Bangerth

O MPI 2.0 tinha RMA há dez anos e pode-se implementar, por exemplo, put_with_notify usando esses recursos. Concordo que o MPI ainda não possui chamadas de procedimento remoto, também conhecidas como mensagens ativas, mas nenhuma máquina que não seja da IBM implementa aquelas sem polling; portanto, não estamos mais falando sobre o MPI se estivermos criticando a necessidade de polling.

— Jeff

7

http://mpitutorial.com/tutorials/dynamic-receiving-with-mpi-probe-and-mpi-status/ possui um tutorial que descreve o uso do MPI_Probe que pode ser útil para você.

— Jeff
fonte

1

Se os remetentes souberem para quem estão enviando, mas os destinatários não souberem de quem estão recebendo, basta postar seus recebimentos em MPI_ANY_SOURCE. Isso corresponderá ao recebimento com qualquer processo que enviar uma mensagem para ele.

Se os receptores realmente não receberem nada, eles poderão postar um iRecv. Sempre que um processo termina de enviar suas mensagens, ele pode postar um ibarrier. Quando o Ibarrier é concluído porque todos os processos entraram nele (e chamado MPI_WAIT no objeto de solicitação), todos sabem que a comunicação está concluída e podem cancelar o Irecv anterior.

— Wesley Bland
fonte

Em que ordem isso recebe a mensagem? Eu preciso enviar de volta os remetentes resultado de algum cálculo ...

— mmirzadeh

Os recebimentos estarão em ordem por processo de envio. Se o posto 1 enviar mensagens A - B - C nessa ordem, elas chegarão nessa ordem. Não há garantia de pedidos entre os processos.

— Wesley Bland #

Entendo ... mas é garantido que as mensagens dos processos não sejam misturadas?

— 21813 mmirzadeh

Não. As mensagens entre processos podem chegar em qualquer ordem.

— Wesley Bland

3

MPI_Cancel é uma função horrível e deve ser usada com a menor frequência possível. Eu recomendo muito as variantes do probe.

— 21413 Jeff Jeff