Extending WRSS to Rust, Julia, Haskell, and Python Under Irregular Parallel Workloads

엔지니어들이 거대한 문제를 해결하기 위해 소프트웨어를 구축할 때, 그들은 종종 작업을 더 작은 조각으로 나누어 여러 프로세서에 동시에 배분함으로써 작업이 더 빨리 끝나기를 기대합니다. 병렬 컴퓨팅(parallel computing)이라고 알려진 이 전략은 모든 더미가 동일한 수의 카드를 가진 카드 덱을 분류하는 작업처럼 작업이 완벽하게 균등할 때 아름답게 작동합니다. 이러한 질서 정연한 상황에서 연구자들은 성능 향상이 멈추는 지점, 즉 더 많은 작업자를 추가해도 더 이상 도움이 되지 않는 지점을 정확히 측정하는 방법을 개발해 왔습니다. 워크로드-런타임 스케일링 시그니처(Workload–Runtime Scaling Signature)라고 불리는 이 측정 도구는 작업이 예측 가능하고 균일할 때 여러 프로그래밍 언어의 성능 한계를 성공적으로 지도화했습니다. 그러나 현실 세계는 결코 그렇게 깔끔하지 않습니다. 많은 과학 및 비즈니스 애플리케이션은 불규칙하고 무질서한 데이터를 포함하며, 이로 인해 어떤 작업자는 산더미 같은 일을 맡는 반면 다른 작업자는 거의 아무것도 하지 못하게 되어, 표준 도구로는 볼 수 없는 숨겨진 병목 현상을 만들어냅니다.

한 연구자가 기존의 측정 도구가 이러한 혼돈을 처리할 수 있는지 테스트하기로 했습니다. 그는 깔끔하고 규칙적인 작업을 위해 작동했던 프레임워크를 복잡한 네트워크 탐색, 깊은 결정 트리 탐색, 희소 행렬 곱셈, 입자 이동 시뮬레이션이라는 네 가지 까다롭고 불규칙한 작업에 적용했습니다. 그는 이 작업들을 Rust, Julia, Haskell, Python이라는 매우 다른 네 가지 프로그래밍 언어를 사용하여 강력한 컴퓨터 시스템에서 실행했습니다. 목표는 작업 분포가 예측 불가능하고 데이터에 따라 달라지는 상황에서도 기존 방식이 여전히 어디에서 저하가 발생하는지 알려줄 수 있는지 확인하는 것이었습니다.

연구자는 기존 도구가 퍼즐의 중요한 조각을 놓치고 있다는 사실을 발견했습니다. 기존 방식에서는 계산에 소요된 모든 시간이 하나의 범주로 묶여 있었습니다. 하지만 이러한 불규칙한 작업에서는 가장 느린 작업자가 단순히 데이터 때문에 평균적인 작업자보다 훨씬 더 많은 일을 해야 하는 경우가 빈번했습니다. 연구자는 불균형한 작업 분배로 인해 발생하는 이 추가적인 부담이 전체 계산량과는 별개의 문제라는 점을 깨달았습니다. 그는 데이터를 바라보는 새로운 방식을 제안했는데, 계산 시간을 두 부분, 즉 모든 사람이 수행하는 평균 작업과 가장 느린 작업자에게 강요된 불공평한 추가 작업으로 나누는 것이었습니다. 이 새로운 네 부분 구성의 관점은 기존의 세 부분 구성 방식이 실제 병목 현상이 어디에 있는지에 대해 종종 거짓을 말하고 있음을 드러냈습니다.

연구자가 이 새로운, 더 상세한 관점을 테스트에 적용했을 때 결과는 극적으로 변했습니다. 복잡한 네트워크 탐색이나 밀집된 클러스터 내 입자 시뮬레이션과 같은 작업의 경우, 기존 방식은 컴퓨터가 여전히 순수한 계산량에 의해 제한되고 있다고 주장했습니다. 즉, 더 많은 작업자를 추가하는 것이 계속 도움이 될 것이라고 시사했습니다. 그러나 새로운 방식은 실제 문제가 불균형 그 자체라는 것을 보여주었습니다. 많은 경우, 가장 느린 작업자에게 가해진 추가 작업이 너무 커서 대기 및 조정으로 인해 발생하는 시스템의 한계에 이미 도달했다는 사실을 가려버렸습니다. 예를 들어, 400만 개의 점이 있는 네트워크를 대상으로 한 한 테스트에서, 새로운 방식은 불균형이 전체 시간의 최대 34%를 차지한다는 것을 보여주었으며, 이는 기존 방식이 일반적인 계산 수치 안에 숨겨두었던 요인이었습니다.

이러한 관점의 변화는 연구자가 작업자 추가를 언제 멈춰야 하는지에 대한 이해를 바꾸어 놓았습니다. 기존의 관점에서는 프로그램이 16명의 작업자까지 잘 확장되는 것처럼 보일 수 있습니다. 그러나 새로운 관점에서는 동일한 프로그램이 불균형이 지배적인 문제가 됨에 따라 단 4명 또는 8명의 작업자에서 혜택이 멈춘다는 것을 보여줄 수 있습니다. 연구는 이 새로운 진단 도구가 불규칙한 워크로드에는 필수적이지만, 작업이 자연스럽게 균형 잡힌 규칙적인 작업에는 불필요하다는 것을 발견했습니다. 연구자는 평균 작업과 가장 느린 작업자에게 부과된 불공평한 추가 작업을 분리하지 않는다면, 성능 연구가 엔지니어들에게 소프트웨어를 최적화하는 방법에 대해 체계적으로 오도할 수 있다고 결론지었습니다.

또한 이 연구는 서로 다른 프로그래밍 언어가 이 혼란을 어떻게 다루는지 강조했습니다. 메모리를 매우 엄격하게 관리하는 Rust라는 언어는 가장 적은 양의 불공평한 추가 시간을 기록하며 작업을 균형 있게 유지하는 데 최고의 능력을 보여주었습니다. 작업 분할 방식이 다른 접근법을 사용하는 Python은 작업 분할 방식이 미세한 불규칙성을 처리하기에 너무 거칠기 때문에 가장 큰 불균형을 보였습니다. Julia와 Haskell은 그 중간 어디쯤에 위치했으며, 특히 Julia는 마주하는 특정 데이터에 따라 변동성을 보였습니다. 이러한 발견은 무질서하고 예측 불가능한 작업의 경우, 언어 선택이 단순히 원시적인 속도에 관한 것이 아니라, 해당 언어가 얼마나 잘 불균등한 부하를 작업자들 사이에 분산시킬 수 있는지에 관한 것임을 시사합니다.

궁극적으로, 이 연구는 현대 컴퓨팅의 복잡성을 항해하기 위한 더 명확한 지도를 제공합니다. 이는 작업이 불규칙할 때 기존의 경험칙이 더 이상 적용되지 않음을 입증합니다. 단순히 평균 노력과 가장 느린 작업자에게 부과된 추가 부담을 분리함으로써, 엔지니어들은 마침내 시스템의 진정한 한계를 볼 수 있게 됩니다. 이러한 명확성은 그들이 언제 더 많은 전력을 추가하고 언제 부하의 균형을 맞추는 데 집중해야 하는지에 대해 더 나은 결정을 내릴 수 있게 하여, 그들의 소프트웨어가 현실 세계 데이터의 혼돈 속에서도 최대한 효율적으로 작동하도록 보장합니다.