답변:
이것은 건축 적 요인으로 인해 발생할 수 있습니다 .
하나 이상의 프로세스에 동일한 메모리 대역폭을 사용할 수있는 경우 SpMV 및 관련 선형 대수 연산이 메모리 대역폭에 제한되어 있으므로 거의 속도가 향상되지 않습니다.
통신 오버 헤드가 로컬 계산을 압도하는 경우도 있습니다. 예를 들어 선형 반복 방법에서는 공정 당 10,000 개 이상의 미지수를 권장합니다.
또는 수치 적 요인 :
병렬 프리 컨디셔너는 종종 직렬 대응 장치보다 약합니다. 예를 들어, 블록 Jacobi는 사용하는 블록이 많을수록 약해집니다. 따라서 추가 선형 반복에 소요되는 추가 시간을 고려해야합니다. 비선형 조건은 일반적으로 이런 방식으로 작동하지 않으므로 뉴턴 반복은 종종 일정합니다.
프로그램을 병렬화하려고 할 때마다 많은 비용을 균형을 잡아야하지만, 주로
귀하의 계산이되면 곤란하게 평행 하고 통신 비용이 매우 낮은 (입력 및 출력 만 해당) 및 관리 비용이 매우 낮은해야 될 것입니다.
계산간에 상호 종속성이 있으면 통신 비용이 크게 증가 할 수 있습니다. 주어진 계산에 대해 완료하는 데 다른 시간이 걸리는 복잡한 알고리즘이있는 경우 보유한 리소스를 효율적으로 사용하려고하면 관리 복잡성이 증가합니다.
모든 형태의 최적화와 마찬가지로 핵심은 벤치마킹하는 것입니다. MPI없이 수행하는 방식, MPI 및 하나의 프로세스로 수행되는 방식을 살펴보고 확장 방법을 살펴보십시오.
CUDA를 사용하는 경우 훨씬 더 많은 데이터를 제공하십시오 . 여기에서 한 번의 테스트는 부정적인 속도 향상을 가져 왔습니다. 우리는 1000 배 더 많은 데이터를 주었고 GP-GPU 버전은 거의 동시에 완료되었지만 메인 CPU에서 실행되는 버전은 1000 배의 시간이 걸렸습니다.
다음을 수행하는 것이 좋습니다.
병렬화 여부에 관계없이 코드의 시간 실행 프로파일을 작성하십시오. 이 작업을 수행하는 방법에 대해 의문이있는 경우 코드를 더 잘 설명하면 도와 드리겠습니다.
이제 느리게 실행되는 부품에 집중할 수 있습니다. 프로세스 간 통신이 느려질 수 있습니다. Mark와 Sean이 지적한 것처럼 문제를 스레드로 나눌 수 있다고해서 그렇게하는 것이 효율적이라는 것은 아닙니다. 더 깊이 살펴 봐야합니다. 그러나 코드를 프로파일 링하면 기존 버그를 찾는 데 도움이 될 수 있습니다. 내 두 센트
예를 들어 워크 플로를 통해 수행중인 작업을보다 자세히 설명하면 다른 사람이 더 나은 설명을 제공 할 수 있습니다.