As mensagens MPI podem ser priorizadas?

Pelo que entendi, a ordem na qual as mensagens MPI ponto a ponto sem bloqueio (Isend e Irecv) são recebidas é consistente com a ordem em que são enviadas. Existem técnicas para priorizar determinadas mensagens em detrimento de outras?

Por exemplo, temos um algoritmo de vários níveis no qual as soluções de alta resolução são enviadas com chamadas sem bloqueio e os cálculos nos níveis aproximados são feitos enquanto as mensagens são enviadas. No entanto, quando chegar a hora de enviar as soluções de baixa resolução, gostaríamos que elas tivessem prioridade (elas estão essencialmente bloqueando).

Também posso imaginar que isso pode ser útil para outros algoritmos à medida que avançamos para a exascala: algumas mensagens estão no "caminho crítico", enquanto outras não.

Eu acho que a resposta para isso é não. Depois de colocá-los na pilha MPI, eles ficam fora de seu controle e a semântica MPI governa a maneira como as mensagens são enviadas.

Você certamente pode priorizar mensagens enfileirando-as em seu código antes de enviá-las e depois verificando com frequência quais são as mais importantes a serem enviadas. Mas não estou absolutamente convencido de que você obterá algum benefício. Há evidências de que suas mensagens não são completas quando você se prepara para enviar as mais grosseiras? Se não houver, convém investigar se é necessário, em primeiro lugar.

Atualmente, o MPI não possui disposições para priorização de mensagens e nem o próximo padrão do MPI 3.0. Cabe à implementação do MPI decidir como transmitir as mensagens. Por exemplo, mensagens menores podem ser enviadas mais rapidamente devido a certos desvios no mecanismo de comunicação (altamente dependente da implementação e do sistema). Você pode explorar o fato de que a maioria das implementações de MPI divide mensagens grandes em partes e as mensagens menores podem deslizar entre as partes grandes. Mas, mais uma vez, isso depende muito da implementação e eu não confiaria nisso.

Fiz um experimento simples usando o Open MPI 1.5.3 através da conexão InfiniBand. O programa envia uma mensagem muito grande (1 GiB) com MPI_Isende, em seguida, duas mensagens curtas (16 bytes) com MPI_Sende, em seguida, aguarda a conclusão do grande envio MPI_Wait. Por outro lado, um MPI_Irecvé lançado primeiro para o grande recebimento e, em seguida, duas MPI_Recvoperações subseqüentes , seguidas por MPI_Waitpara o grande recebimento. Consegui consistentemente receber as duas mensagens curtas antes de o recebimento da grande mensagem ser concluído. Aqui está a saída do meu teste:

[0] Rank 0 running on host1
[0] Starting big send at 0.000019s
[0] Starting small send at 0.215448s
[0] Starting small send 2 at 0.224105s
[0] Starting wait at 0.224114s
[0] Finished wait at 0.935843s
[1] Rank 1 running on host2
[1] Starting big receive at 0.000020s
[1] Starting small recv at 0.000037s
[1] Starting small recv 2 at 0.548396s
[1] Starting wait at 0.548418s
[1] Finished wait at 0.935780s

Ambos os envios pequenos são bem-sucedidos antes que o envio assíncrono seja concluído como evidente a partir do tempo de espera de ~ 700 ms. Eu diria que o primeiro recebimento pequeno é bem-sucedido algum tempo (~ 300 ms) após o início do grande recebimento em segundo plano. Tentei fazer isso usando apenas MPI_COMM_WORLDou usando um comunicador separado para pequenas mensagens - os resultados são os mesmos. Os nós possuem um QDR IB HCA cada um e em execução --mca btl_base_verbose 50confirmam que não há canais de comunicação alternativos em uso.

Isso não é suportado pelo MPI nem por nenhum outro middleware de comunicação que eu conheça. Provavelmente, isso é porque não é suportado por nenhum hardware que eu conheça, com exceção do Blue Gene, onde existem pacotes de alta prioridade para mensagens de controle que ultrapassarão outras mensagens sob algumas condições. No entanto, eles não são para uso geral, pois permitem apenas a comunicação de 64 bytes (pelo menos no Blue Gene / P).

A boa notícia é que você não precisa disso. A sobrecarga para implementá-la não valerá a pena e você encontrará - supondo que você sempre investigue os detalhes de baixo nível - que a não implementação de prioridades na rede permite que a MPI ofereça o melhor desempenho na maioria dos usos.

É um pouco estranho que você mencione isso no contexto da ordem das mensagens. Citando você:

Pelo que entendi, a ordem na qual as mensagens MPI ponto a ponto sem bloqueio (Isend e Irecv) são recebidas é consistente com a ordem em que são enviadas.

Vale ressaltar aqui que o MPI garante apenas que as mensagens correspondentes entre os processos serão recebidas na ordem em que foram enviadas. Você realmente não quer que esse tipo de pedido seja alterado, pois torna seu código mais compreensível e tira um fardo enorme de você como programador de aplicativos.

No entanto, se você enviou mensagens com tags diferentes, isso altera os critérios de correspondência e você pode facilmente receber o segundo antes do primeiro. Veja o segundo exemplo na parte relevante da norma para obter detalhes. Eu espero que, se você tem dois pedaços de seu código enviando simultaneamente que você já está separando as mensagens grosseiras e finas usando tags, e não tentar implementar algum protocolo de sua própria no topo da mensagem de encomenda. Essa é uma segunda natureza para a maioria dos programadores de MPI que conheço.

De qualquer forma, supondo que você esteja fazendo isso, provavelmente está preocupado com o fato de as mensagens granulares de alto volume entupirem sua rede quando você deseja enviar mensagens grosseiras. Meu conselho geral sobre isso é que, se não for um problema de desempenho que você possa realmente medir no momento, não deverá se preocupar em resolvê-lo ainda. Você parece confirmar que ainda não é um problema em um dos comentários acima.

Uma solução possível que você pode considerar seria usar um coletivo não-bloqueador (NBC) como Bcast ou Barrier para notificar a todos que a fase grosseira está pronta e pronta para enviar sua solução. Com toda a probabilidade, o tráfego da NBC não será priorizado, mas os processos notificados podem pelo menos parar de enviar montes de soluções finas até que os envios grosseiros sejam feitos. As NBCs estarão no MPI-3 ou você pode tentar usar a libNBC se não puder esperar tanto tempo.

Mais uma vez, porém, isso parece dar muito trabalho para algo que ainda não parece um problema de desempenho.