성능 문제를 찾아 이벤트 데이터를 시각화하는 방법

비동기식 통신 패턴으로 MPI 응용 프로그램을 최적화하려고합니다. 각 순위에는 계산할 항목 목록이 있으며 입력 또는 출력이 다른 순위에있는 경우 필요에 따라 메시지를 보냅니다. 또한 각 순위는 스레드되어 있습니다 (현재는 하나의 통신 스레드와 5 명의 작업자가 있음).

코드의 다른 성능 결정 부분에 대한 타이머를 사용하여 코드를 계측하여 각 스레드에 대한 (시작, 끝, 유형) 트리플 목록을 제공합니다. 수평 축으로 시간, 수직으로 스레드 및 스레드, 현재 각 스레드에서 수행중인 작업을 나타내는 색상으로 명확한 방식으로 플로팅하여 6 스레드 / 순위로 16 순위에 대해 다음과 같은 이미지를 얻습니다.

내 질문은 : 성능 문제를 해결하는 데 도움이되는이 데이터를 시각화하는 다른 방법은 무엇입니까? 누구나 비동기 애플리케이션을 프로파일 링 할 때 선호하는 유형의 플롯이 있습니까?

이 데이터 세트는 데이터 흐름 구조를 모르기 때문에 제한되어 있지만 더 복잡한 것을 수집하기 전에 가능한 한 많은 정보를 얻고 싶습니다.

압축되지 않은 이미지는 여기에 사람이 (가 정상적인 경로를 통해 업로드하지 못했습니다) 주위를 둘러 봐하고 싶은 경우. 불행히도 Firefox는 유효하다고 생각하더라도 허용하지 않습니다. 단순히 너무 커서 가능하기 때문일 수 있습니다.

공유 및 / 또는 분산 메모리를 사용하여 병렬 코드를 작성하고 디버깅하는 데 많은 시간을 소비하지만 특정 문제를 모른 채 나에게 가장 적합한 것을 알려줄 수 있습니다.

계산 효율성을보고 있다면 어떤 루틴이 시간이 얼마나 걸리는지 아는 것이 중요하지만 병렬 효율성에 대해 걱정이되면 계산을 수행하지 않을 때 코드가 수행하는 작업에 대해 더 걱정해야합니다 . 아이들이 너무 조용 할 때 아이들이하는 일을 걱정하는 것과 같습니다 ...

하이브리드 공유 / 분산 메모리 접근 방식을 사용하고 있기 때문에 코드가 공백에 있거나 MPI 호출 또는 뮤텍스 / 조건 변수에있는 것 같습니다. 이러한 호출을 타이머로 감쌀 수도 있습니다. 예를 들어 항상 조건이 같거나 항상 MPI_REDUCE스레드가 고착되어 있는 경우 속도를 늦추고있는 것을 더 잘 이해할 수 있습니다.

내가 자주 사용하는 소프트웨어 중 하나는 Intel Vtune Amplifier XE 입니다. 스레드 동시성을 시각화하는 멋진 플로팅 기능 / 옵션이 있습니다. 프로그램은 당신과 매우 비슷한 줄거리를 그릴 것입니다. 그러나 스레드가 뮤텍스 또는 조건 변수를 기다릴 때 대기중인 스레드에서 대기를 시작할 때 실제로 뮤텍스를 해제하거나 신호를 보낸 스레드까지 대각선을 그립니다 릴리스 / 시그널링 될 당시의 대기 상태 이 작업은 매우 어려울 수 있지만 병목 현상이 즉시 나타납니다.

마지막으로, 각 뮤텍스 / 신호 / MPI 호출에 대한 대량 통계도 수집합니다. 평균 및 최대 대기 시간은 얼마입니까? 수집 된 대기 시간의 히스토그램은 무엇입니까? 줄거리는 당신에게 좋은 개요를 제공하지만, 미세한 세부 사항에 관해서는 상당히 혼란 스러울 수 있습니다.

마지막으로, 과소 평가해서는 안되는 한 가지 질문 : 타이밍을 어떻게 수집하고 있습니까? 타이머가 방해가되지 않아 코드에 영향을 미치지 않습니까? 가능한 경우, 즉 RDTSCx86 아키텍처 에서 CPU 명령어 수를 사용합니다 . 이것은 보통 코드에 단일 명령어를 추가합니다.

때때로 높은 수준의 리소스 분석을 통해 성능 문제에 대한 대체 견해를 얻을 수 있습니다. 메모리 대역폭과 같은 관련 병목 현상이 있습니까? 모든 작업자 스레드가 같은 양의 작업을 수행합니까? 이 데이터는 LIKWID 도구 모음 LIKWID Google 코드 프로젝트 에서 likwid-perfctr을 사용하여 쉽게 수집 할 수 있습니다 . 프로필에 여러 핫스팟이있는 경우 하나씩 핫스팟을 해결해야 할 수도 있습니다. 사용되는 스레드 / 프로세스 수에 따라 다른 문제가있을 수도 있습니다.

메시지 나 이벤트에 의해 통제되는 비동기 프로세스의 네트워크에서 문제가 발생하면 쉽지는 않지만 효과적인 방법을 사용합니다. 타임 스탬프가있는 프로세스 로그를 가져 와서 공통 타임 라인으로 병합하고, 활동을 트리거 할 때 일부 메시지의 진행 상황을 추적하고, 추가 메시지를 트리거하는 작업이 포함되었습니다. 내가 찾고있는 것은 메시지를받은 시간과 행동 시간 사이의 지연과 지연 이유를 이해하는 것입니다. 문제가 발견되면 해결되고 프로세스가 반복됩니다. 이렇게하면 실제로 만족스러운 성능을 얻을 수 있습니다.

이것이 측정, 측정, 측정 방식과 어떻게 다른지 확인하는 것이 중요합니다. 측정 할 수있는 유일한 것은 볼 수 없는 곳 입니다. 실제 성능 조정을 위해서는 시간 관점에서 세부 사항을주의 깊게 살펴 봐야합니다. 당신이 찾고있는 것은 시간이 소비되는 곳이 아니라 불필요하게 소비되는 곳입니다.

행운을 빕니다.