mpi_allgather 작업의 계산 비용은 수집 / 스 캐터 작업과 어떻게 비교됩니까?

단일 mpi_allgather 작업 또는 하나의 mpi_scatter 및 하나의 mpi_gather 작업을 사용하여 병렬화 할 수있는 문제를 연구 중입니다. 이러한 작업은 while 루프 내에서 호출되므로 여러 번 호출 될 수 있습니다.

MPI_allgather 스킴을 사용한 구현에서 중복 행렬 해석을 위해 모든 프로세스에 분산 벡터를 수집하고 있습니다. 다른 구현에서는 분산 벡터를 단일 프로세서 (루트 노드)에 수집하고이 프로세서의 선형 시스템을 해결 한 다음 솔루션 벡터를 모든 프로세스에 다시 분산시킵니다.

수집 작업의 비용이 분산 및 수집 작업을 결합한 것보다 훨씬 많은지 궁금합니다. 메시지 길이가 복잡성에 중요한 역할을합니까? mpi 구현에 따라 다릅니 까?

편집하다:

첫째, 정확한 답은 (1) 사용법, 함수 입력 인수, (2) MPI 구현 품질 및 세부 사항, (3) 사용중인 하드웨어에 따라 다릅니다. 하드웨어 공급 업체가 네트워크에 대한 MPI를 최적화 할 때와 같이 종종 (2) 및 (3)이 관련됩니다.

일반적으로 MPI 집합 통합은 소규모 메시지에 더 좋습니다. 시작 비용이 중요하지 않으며 호출 간 계산 시간에 편차가있는 경우 집합 차단으로 인한 동기화를 최소화해야하기 때문입니다. 더 큰 메시지의 경우 전송되는 데이터 양을 최소화하는 것이 목표입니다.

예를 들어, 이론적으로 MPI_Reduce_scatter_block는 전자가 후자의 관점에서 종종 구현되기 때문에 MPI_Reduce뒤에 MPI_Scatter나오는 것보다 낫습니다 . 따라서 실제 이점은 없습니다. 대부분의 MPI 구현에서 구현 품질과 사용 빈도 사이에는 상관 관계가 있으며 공급 업체는 기계 계약에 필요한 기능을 분명히 최적화합니다.

다른 한편으로, 하나가 블루 진에 있다면, 보다 많은 의사 소통을 하고 결합 하는을 MPI_Reduce_scatter_block사용 MPI_Allreduce하는 것이 실제로는 훨씬 더 빠릅니다. 이것은 내가 최근에 발견 한 것으로 MPI의 성능 자체 일관성 원칙에 대한 흥미로운 위반입니다 (이 원칙은 "자체 일관성있는 MPI 성능 지침" 에 자세히 설명되어 있음 ).MPI_ReduceMPI_Scatter

분산 + 수집 대 수집의 특정 경우, 전자의 경우 모든 데이터가 단일 프로세스로 이동해야하므로 병목 현상이 발생하지만 병목 현상의 경우 데이터가 모든 등급에서 즉시 유입 및 유출 될 수 있습니다. 모든 순위에는 다른 모든 순위로 보낼 데이터가 있기 때문입니다. 그러나 일부 네트워크에서는 모든 노드에서 한 번에 데이터를 보내는 것이 좋은 아이디어는 아닙니다.

마지막 으로이 질문에 대답하는 가장 좋은 방법은 코드에서 다음을 수행하고 실험을 통해 질문에 대답하는 것입니다.

#ifdef TWO_MPI_CALLS_ARE_BETTER_THAN_ONE
  MPI_Scatter(..)
  MPI_Gather(..)
#else
  MPI_Allgather(..)
#endif

더 나은 옵션은 처음 두 번 반복하는 동안 코드를 실험적으로 측정 한 다음 나머지 반복에 더 빠른 것을 사용하는 것입니다.

const int use_allgather = 1;
const int use_scatter_then_gather = 2;

int algorithm = 0;
double t0 = 0.0, t1 = 0.0, dt1 = 0.0, dt2 = 0.0;

while (..)
{
    if ( (iteration==0 && algorithm==0) || algorithm==use_scatter_then_gather )
    {
        t0 = MPI_Wtime();
        MPI_Scatter(..);
        MPI_Gather(..);
        t1 = MPI_Wtime();
        dt1 = t1-t0;
    } 
    else if ( (iteration==1 && algorithm==0) || algorithm==use_allgather)
    {
        t0 = MPI_Wtime();
        MPI_Allgather(..);
        t1 = MPI_Wtime();
        dt2 = t1-t0;
    }

    if (iteration==1)
    {
       dt2<dt1 ? algorithm=use_allgather : algorithm=use_scatter_then_gather;
    }
}

확실하게 측정 할 수있는 유일한 방법에 대한 Jeff의 절대적인 견해는 과학자입니다. 결국 우리는 과학자이며 실험적인 질문입니다. 이러한 측정을 구현하는 방법에 대한 훌륭한 조언을 제공합니다. 이제 반대 (또는 아마도 보완적인) 관점을 제시하겠습니다.

널리 사용되는 코드를 작성하는 것과 특정 목적에 맞게 코드를 조정하는 것에는 차이가 있습니다. 일반적으로 우리는 첫 번째 작업을 수행하고 있습니다. a) 다양한 플랫폼에서 코드를 사용할 수 있으며 b) 향후 몇 년 동안 코드를 유지 관리하고 확장 할 수 있습니다. 그러나 때때로 우리는 다른 것을하고 있습니다-우리는 몇 대의 큰 기계에 할당 할 가치가 있고, 필요한 큰 시뮬레이션 세트로 올라가고 있습니다. 부여 된 할당 시간.

코드를 작성할 때 특정 머신에서 런타임의 몇 퍼센트를 줄이는 것보다 광범위하게 사용 가능하고 유지 보수가 가능하도록 만드는 것이 훨씬 중요합니다. 이 경우 올바른 작업은 거의 항상 원하는 작업을 가장 잘 설명하는 루틴을 사용하는 것입니다. 일반적으로 원하는 작업을 수행 할 수있는 가장 구체적인 호출입니다. 예를 들어, 직접 수집 또는 allgatherv가 원하는 작업을 수행하는 경우 분산 / 가터 작업에서 자신을 롤링하는 대신이를 사용해야합니다. 그 이유는 다음과 같습니다.

• 이 코드는 이제 당신이하려는 일을보다 명확하게 나타내며, 다음 해에 코드를 어떻게 처리해야할지 전혀 모르는 다음 사람이 더 잘 이해할 수있게합니다.
• 보다 일반적인 경우가 아닌 이보다 구체적인 경우에 대해 MPI 레벨에서 최적화를 사용할 수 있으므로 MPI 라이브러리가 도움이 될 수 있습니다. 과
• 자신의 롤을 시도하면 역효과가 발생할 수 있습니다. MPI 구현 Y.ZZ를 사용하여 시스템 X에서 성능이 향상 되더라도 다른 시스템으로 이동하거나 MPI 구현을 업그레이드하면 성능이 훨씬 떨어질 수 있습니다.

이 매우 일반적인 경우, 일부 MPI 집단이 컴퓨터에서 부적절하게 느리게 작동한다는 것을 알게되면 가장 좋은 방법은 mpi 공급 업체에 버그 보고서를 제출하는 것입니다. 응용 프로그램 코드에서 MPI 라이브러리 수준에서 올바르게 수정해야하는 문제를 해결하려는 자체 소프트웨어를 복잡하게하고 싶지 않습니다.

그러나 . "튜닝"모드 인 경우 작동 코드가있는 경우 짧은 기간 (예 : 1 년 단위 할당)으로 매우 큰 규모로 확장해야하며 코드를 프로파일 링해야합니다. 코드의이 특정 부분에 병목 현상이 있음을 확인한 후 이러한 특정 튜닝을 수행하는 것이 좋습니다. 바라건대 그것들은 코드의 장기적인 부분이 아닐 것입니다. 이상적으로 이러한 변경 사항은 저장소의 일부 프로젝트 특정 지점에 남아 있지만, 변경해야 할 수도 있습니다. 이 경우, 전 처리기 지시어 또는 특정 통신 패턴에 대한 "자동 튜닝 (autotuning)"접근 방식으로 구별되는 두 가지 접근 방식의 코딩은 많은 의미가 있습니다.

따라서 Jeff와 의견이 맞지 않습니다 . 코드를 처리하기 위해 코드를 수정하기 위해 상대적 성능 관련 질문에 충분히 관심을 기울여야 할 시점 에 대한 컨텍스트를 추가하고 싶습니다 .