로그-로그 병렬 스케일링 / 효율 플롯

내 자신의 많은 작업이 알고리즘의 스케일링을 개선하는 데 중점을두고 있으며, 병렬 스케일링 및 / 또는 병렬 효율성을 나타내는 선호되는 방법 중 하나는 코어 수에 대해 알고리즘 / 코드의 성능을 플롯하는 것입니다.

여기서 축은 코어 수를 나타내고 y 축은 몇 가지 메트릭을 나타냅니다 ( 예 : 단위 시간당 수행 한 작업). 서로 다른 곡선은 64 코어에서 각각 20 %, 40 %, 60 %, 80 % 및 100 %의 병렬 효율성을 보여줍니다.$x$$y$

불행하게도, 많은 출판물, 이러한 결과는 플롯되는 로그 - 로그 의 결과 예, 스케일링 이 나 이 종이. 이러한 로그-로그 도표의 문제점은 실제 병렬 스케일링 / 효율을 평가하기가 매우 어렵다는 것입니다.

위와 동일한 플롯이지만 로그 로그 스케일링이 있습니다. 60 %, 80 % 또는 100 % 병렬 효율성의 결과에는 큰 차이가 없습니다. 나는 이것에 대해 더 광범위하게 비트를 작성했습니다 여기에 .

그래서 내 질문은 : 로그 로그 스케일링에 결과를 표시하기 위해 어떤 근거가 있습니까? 나는 정기적으로 선형 스케일링을 사용하여 내 자신의 결과를 보여주고, 정기적으로 내 자신의 병렬 스케일링 / 효율 결과가 다른 사람들의 (로그-로그) 결과만큼 좋지 않다고 말하면서 심판들에 의해 망치게됩니다. 플롯 스타일을 전환해야하는 이유를 알 수 없습니다.

우리는 현재 많은 비교 가능한 음모가 포함 된 논문을 작성 중이며, 거의 같은 문제가있었습니다. 이 논문은 BlueGene에서 1에서 최대 100k 사이의 코어 수에 대한 다양한 알고리즘의 스케일링을 비교하는 것에 관한 것입니다. 이 상황에서 loglog-plots를 사용하는 이유는 포함 된 자릿수입니다. 선형 스케일에서 6 배의 자릿수를 그릴 수있는 방법은 없습니다.

실제로 로그 로그의 코어 수에 대한 시간을 플롯 할 때 다음 플롯에서 볼 수 있듯이 알고리즘을 구분할 수 없습니다.

$E_p=T_1/(p T_p)$$T_1$$T_p$$p$$p$$E_p$$p$

$E_p=T_{ref}/(p T_p)$$T_{ref}$

세미 로그 스케일에서 상대 병렬 효율성을 플로팅하면 알고리즘의 스케일링이 매우 명확하게 표시되며 알고리즘이 서로 상대적으로 수행되는 방식도 보여줍니다.

Georg Hager는 Fooling the Masses-Stunt 3 에서 이에 대해 썼습니다 .

강력한 스케일링의 로그-로그 플롯이 하이 엔드에서 그다지 분별되지는 않지만, 더 많은 수의 스케일에서 스케일링을 표시 할 수 있습니다. 이것이 왜 유용한 지 알아 보려면 정기적으로 수정하는 3D 문제를 고려하십시오. 리니어 스케일에서는 약 1024 코어, 8192 코어 및 65536 코어와 같은 약 2 배의 성능을 합리적으로 표시 할 수 있습니다. 독자가 줄거리에서 작은 것을 실행했는지 여부를 알 수는 없으며 실제로 줄거리는 가장 큰 두 번의 실행을 비교합니다.

이제 메모리에 코어 당 백만 개의 그리드 셀을 장착 할 수 있다고 가정하면 이는 8 배로 2 배로 강력한 스케일링을 수행 한 후에도 코어 당 16k 셀을 가질 수 있음을 의미합니다. 이것은 여전히 ​​상당한 크기의 하위 도메인 크기이며 많은 알고리즘이 효율적으로 실행될 것으로 기대할 수 있습니다. 차트의 시각적 스펙트럼 (1024 ~ 65536 코어)을 다루었지만 강력한 확장이 어려워지는 정권에 들어 가지 않았습니다.

대신 코어 당 1 백만 개의 그리드 셀을 사용하여 16 개의 코어에서 시작했다고 가정합니다. 이제 65536 코어로 수평 확장하면 코어 당 244 개의 셀만있게되므로 훨씬 더 안목이 높아질 것입니다. 로그 축은 16 코어에서 65536 코어까지의 스펙트럼을 명확하게 나타내는 유일한 방법입니다. 물론 선형 축을 사용하고 "그림에서 16, 128 및 1024 코어의 데이터 포인트가 겹칩니다"라는 캡션을 가질 수 있지만 이제는 그림 자체 대신 단어를 사용하여 표시합니다.

또한 로그 로그 스케일을 사용하면 스케일링을 통해 단일 노드 나 랙을 넘어서 움직이는 것과 같은 시스템 속성에서 "복구"할 수 있습니다. 이것이 바람직한 지 아닌지는 당신에게 달려 있습니다.

나는 제드가 그의 대답에서 말한 모든 것에 동의하지만 다음을 추가하고 싶었다. 나는 Martin Berzins와 그의 동료들이 그들의 Uintah 프레임 워크를위한 스케일링을 보여주는 방식의 팬이되었습니다. 그들은 로그-로그 축에 코드의 약하고 강한 스케일링을 플로팅합니다 (방법의 단계 당 런타임 사용). 코드가 어떻게 잘 스케일링되는지 보여줍니다 (완전한 스케일링과의 편차는 결정하기가 약간 어렵습니다). 7 페이지와 8 그림 7, 8 참조 이 예를 들어 * 종이. 또한 각 스케일링 수치에 해당하는 숫자가있는 표를 제공합니다.

이것의 장점은 일단 숫자를 제공하면 검토자가 말할 수있는 것이 많지 않다는 것입니다 (또는 적어도 반박 할 수없는 것은 아닙니다).

*제이. Luitjens, M. Berzins. "Uintah의 성능 향상 : 대규모 적응 형 메싱 계산 프레임 워크", GA, Atlanta, GA, 24 페이지 IEEE 국제 병렬 및 분산 처리 심포지엄 (IPDPS10) 진행. 2010. DOI : 10.1109 / IPDPS.2010.5470437