전송 된 데이터의 양이 거의 같을 때 MPI_Alltoallv과 MPI_Alltoall 함수를 실행하는 사이의 실행 시간의 차이점은 무엇입니까? 나는 그러한 벤치 마크 결과를 찾을 수 없었다. 저는 수만 또는 수십만의 MPI 프로세스가 사용되는 곳과 이러한 프로세스가 주어진 HPC 시스템의 상당 부분에 해당하는 대규모 인스턴스에 관심이 있습니다 (BGC/Q와 같은 일부 최신 시스템을 고려함). , 크레이 XC30, 크레이 XE6, ...). MPI_Alltoall의 큰 장점MPI_Alltoall은 MPI_Alltoallv보다 얼마나 좋은 성능을 낼 수 있습니까?
하나는 스칼라의 소수에 의존하기 때문에 해당 프로토콜의 의사 결정을 신속하게 할 수있다. 대조적으로, 라이브러리 구현자가 MPI_Alltoallv를 최적화하기를 원한다면, 예를 들어, 통신이 거의 동일하거나, 매우 희박하거나, 다른 패턴인지를 결정하기 위해 네 개의 벡터를 스캔해야합니다.
다른 문제는 모든 프로세스가 동일한 양의 데이터를 제공하고 소비하므로 MPI_Alltoall이 출력 버퍼를 스크래치 공간으로 쉽게 사용할 수 있다는 것입니다. MPI_Alltoallv의 경우 모든 부기 작업을 수행하는 것이 현실적이지 않으므로 스크래치 공간이 할당됩니다. 이 문제의 구체적인 내용을 기억할 수는 없지만 MPI 표준에서 어딘가에 읽은 것 같습니다.
거의 균일 통신, 즉 카운트 벡터가 거의 일정하다 :
배열을 채우고 MPI_Alltoall을 직접 사용하십시오.
동종 통신을 사용하는 프로세스의 하위 집합에 MPI_Alltoall을 사용하고 나머지에는 MPI_Alltoallv 또는 Send-Recv의 일괄 처리를 사용하십시오. 연결된 커뮤니케이터를 캐시 할 수있는 경우 가장 효과적입니다. 비 차단 통신을 사용하면 도움이됩니다.
벡터의 끝에서 개수가 다른 경우를 처리하는 Bruck 구현을 직접 작성하십시오. 이 일을 직접 해보지 않은 나는이 일이 얼마나 어렵고 가치가 있는지 알지 못합니다.
즉, 카운트 벡터는 많은 수의 제로를 포함한다. 이 경우, 비 차단 Send-Recv와 Waitall의 배치를 사용하십시오. MPI 라이브러리가 가장 잘 수행 할 가능성이 높기 때문에, 원하는 경우 배치 크기를 조정할 수 있습니다.
MPI on a Million Processors 벡터 집단과 연관된 scalabillity 문제를 설명한다. 물론 대부분의 CPU에서 벡터 인수를 검색하는 데 드는 비용은 볼 수 없지만 필요한 경우보다 벡터 인수에 손댈 수 없도록 만드는 것은 O (n) 문제입니다.
HykSort: a new variant of hypercube quicksort on distributed memory architectures은 최적화 된 라이브러리보다 훨씬 뛰어난 사용자 지정 구현을 설명합니다.이러한 최적화는 MPI 라이브러리 내부에서 구현하기가 다소 어렵습니다. (이 참조가 그렇고, 흐리 스토의 의견에 있지 질문을 대상으로합니다.)
당신은 MPICH (https://github.com/pmodels/mpich/blob/master/src/mpi/coll/alltoall.c 및 https://github.com/pmodels/mpich/blob/master/src/mpi/coll/alltoallv.c)에서 이러한 작업의 구현을 비교하여 몇 가지 흥미로운 것들을 발견 할 수 있습니다. MPI_Alltoall 만 Bruck's algorithm과 pairwise exchange를 사용합니다. 비슷한 결론은 I_MPI_ADJUST_ALLTOALL 및 I_MPI_ADJUST_ALLTOALLV에 대한 사용 가능한 옵션에서 https://software.intel.com/en-us/node/528906으로 가져올 수 있습니다. 이러한 한계가 근본적이거나 실용적인지 여부는 독자의 연습 과제로 남겨 두었습니다.
.
나는 MPI_Alltoall만큼 빠르던 Blue Gene/Q의 all-to-all 버전을 썼다. 내 버전은 상수 대 벡터 인수에 대해 불가지론 적이므로이 결과는 MPI_Alltoallv가 MPI_Alltoall과 유사하게 수행된다는 것을 의미합니다. 그러나 지금은 코드가 세부 사항을 절대적으로 확신 할 수 없습니다.
그러나 Blue Gene 네트워크는 특히 특별했습니다. all-to-all이기 때문에 CPU가 네트워크보다 훨씬 빠른 시스템에서 fat-tree 또는 dragonly 네트워크의 동작은 매우 다릅니다.
벤치 마크를 작성하고 애플리케이션을 실행할 위치를 측정하는 것이 좋습니다. 데이터가 확보되면 누락 될 수있는 최적화를 쉽게 파악할 수 있습니다.
전송되는 데이터의 양이 동일하면 왜 alltoallv를 사용합니까? 일관성있는 MPI는 alltoallv가 유연성을 제공하므로 어떠한 경우에도 alltoall보다 우수해야한다고 주장한다. 그렇지 않으면 라이브러리가 alltoall의 특수한 경우를 단순하게 만들어야한다. –
데이터 양이 비교적 큰 경우, 일반적으로 'MPI_Alltoall'또는 'MPI_Alltoallv'가 사용되는지 여부는 중요하지 않습니다. 데이터의 양이 비교적 적을 때, 동일한 크기의 청크 (즉, 'MPI_Alltoall')로 모두를 모두 구현하는 효율적인 알고리즘이 많이있다. "상대적으로 작은"것은 무엇이며 "비교적 큰"것은 시스템 및 네트워크 아키텍처에 따라 다릅니다. –
@RobLatham : 내 문제는 MPI_Alltoallv와 달리 MPI_Alltoall이 한 번만 호출되어 해결 될 수 없습니다. 어쩌면 (나는 아직도 모른다, 증명되어야한다) MPI_Alltoall을 여러번 (적어도 두 번) 호출하는 것으로 해결 될 수있다. –