MPI_Iprobe 대 MPI_Probe 대

Question

MPI_Iprobe에서 메시지를 확인하려면 플래그를 여러 번 확인해야합니다. 한 가지 방법은 while 루프에 넣는 것입니다.이 방법이 MPI_Probe 기본적으로 다른 방식으로 검사를 차단하므로 Iprobe를 사용하는 잘못된 방법입니까?

int flag=0 
while(flag==0) 
{ 
MPI_Iprobe(MPI_ANY_SOURCE, MPI_ANY_TAG, MPI_COMM_WORLD, &flag,&status); 
cout<<myrank<<" "<<flag<<endl; 
} 
if(flag) 
{ 
MPI_Get_count(&status, MPI_INT, &count); 

MPI_Irecv(&rcvbuff,count, MPI_INT,destination.at(0),0, MPI_COMM_WORLD, &request); 

} 

Answer 1

예, 당신이 제안처럼 MPI_Iprobe 주위 기본적으로 루프는 MPI_Probe 같은 의미 같은있다. 그러나 일반적으로 은 자신의에 구현하는 대신 복합 연산을 선호합니다. 따라서 MPI_Iprobe -loop 대신 MPI_Probe을 사용하십시오. MPI_Test -loop 대신 MPI_Wait을 사용하십시오. 가능할 때마다 개별 지점 간 메시지 대신 집합을 사용하십시오.

동기식 MPI_I... 함수는 일반적으로 통신과 계산을 겹치기 위해 유용하지만 기존 MPI 기능을 다시 구현할 때 사용하면 안됩니다.

MPI_Probe을 사용하면 구현에 최적화 및 조정의 자유를 줄 수 있습니다. 한편으로 MPI는 메시지가 올 때까지 블로킹하여 CPU주기/전력을 절약합니다. 반면 MPI 스택에 반복해서 들어가는 데 낭비되는 시간이 없기 때문에 대기 시간이 더 짧을 수 있습니다. MPI_Iprobe 호출 대신 수천 개의 MPI_Probe 호출을 사용하는 PMPI 계층을 사용하는 모든 도구에 더 좋습니다. 저는 MPI_Test -loop을 MPI_Waitany으로 바꾸는 것만으로 실제 HPC 어플리케이션에서 10 % 이상의 속도 향상을 얻었습니다.

유일한 예외는 MPI 구현의 튜닝 옵션을 모두 사용한 경우이며 MPI가 제공하는 복합 연산보다 휠의 자체 구현이 더 우수함을 분명히 보여줄 수 있습니다.

MPI_Irecv 전화도 다소 이상합니다. 이미 보류중인 메시지가 있음에도 불구하고 비동기 수신을 사용해야 할 충분한 이유가 있습니까? 첫 번째 장소에서 프로빙 대신 MPI_Irecv을 게시하는 것이 어떻습니까? 수신 버퍼를 할당하는 데 필요한 최대 크기를 알고있는 경우 MPI_Irecv을 MPI_ANY_SOURCE에 게시 할 수 있으며 수신 횟수는 송신 횟수보다 큽니다.