💻 computer science

The Warmup Protocol Problem: JIT, GC, and Lazy Evaluation Effects on WRSS in Julia, Haskell, and Python

본 연구는 JIT 컴파일, 가비지 컬렉션, 지연 평가 효과의 제외 또는 포함과 같은 워밍업 프로토콜 선택이 Julia, Haskell, Python에서 워크로드-런타임 스케일링 시그니처(WRSS)와 병목 전환점(Bottleneck Transition Points)을 어떻게 왜곡하는지 조사하며, 이를 통해 표준 정상 상태(steady-state) 벤치마크가 실제 실행 성능을 잘못 나타내고 오해의 소지가 있는 언어 간 스케일링 결론을 도출할 수 있음을 밝힌다.

원저자: Albert Schulle

게시일 2026-10-06

📖 3 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Albert Schulle

원본 논문은 CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

컴퓨터 과학자들이 프로그램이 얼마나 빨리 실행되는지 측정하려고 할 때, 그들은 숨겨진 함정에 직면하게 됩니다. 현대의 소프트웨어는 사용자가 버튼을 클릭하는 즉시 풀 스피드로 시작되지 않습니다. 대신, 컴퓨터는 프로그램이 실행되는 첫 순간에 코드를 기계가 이해할 수 있는 형태로 번역하거나, 새로운 작업을 위한 공간을 만들기 위해 오래된 데이터를 정리하는 등 프로그램을 준비하는 데 시간을 보냅니다. 이 준비 단계를 "웜업(warmup)"이라고 부릅니다. 수십 년 동안 여러 작업을 동시에 처리하는 방식을 연구해 온 연구자들은 이 웜업을 무시하고, 그 이후에 일어나는 안정적이고 매끄러운 실행만을 측정해 왔습니다. 그들은 이것이 해당 언어의 진정한 성능을 가장 순수하게 보여준다고 믿었습니다. 하지만 이러한 접근 방식은 프로그램이 항상 동일한 데이터 위에서 오랫동안 실행된다는 가정을 전제로 하는데, 이는 소프트웨어가 자주 새로 시작되거나 작업 부하가 빈번하게 바뀌는 실제 세상에서는 좀처럼 존재하지 않는 조건입니다.

최 recent 연구는 웜업을 숨기지 않았을 때 어떤 일이 발생하는지를 질문함으로써 이 오래된 가설에 도전합니다. 연구진은 세 가지 인기 있는 프로그래밍 언어인 줄리아(Julia), 하스켈(Haskell), 파이썬(Python)에 주목했습니다. 그들은 '워크로드-런타임 스케일링 시그니처(Workload–Runtime Scaling Signature)'라는 특정 방법을 사용하여 프로그램이 소요하는 시간을 세 부분으로 나누었습니다. 즉, 작업자가 실제 계산을 수행하는 시간, 결과값을 결합하는 데 드는 시간, 그리고 메모리 관리나 번역과 같은 오버헤드에 소비되는 나머지 시간입니다. 연구진은 세 가지 복잡한 작업(거대한 숫자 목록 정렬하기, 필드 내에서 가장 가까운 두 점 찾기, 거대한 값의 집합 합산하기)을 실행하며, 성능을 측정하는 두 가지 매우 다른 방식을 비교했습니다. 한 방식은 컴퓨터를 먼저 예열하는 전통적인 규칙을 따랐고, 다른 방식은 초기 지연 시간을 모두 포함하여 '콜드 스타트(cold start)' 상태부터 측정을 시작했습니다.

결과는 측정 방식의 선택이 생각보다 훨씬 더 중요하다는 것을 드러냈습니다. 콜드 스타트를 포함했을 때, 이 언어들이 얼마나 잘 확장(scale)되는지에 대한 그림은 극적으로 변했습니다. 실행 중에 코드를 번역하는 시스템을 사용하는 줄리아의 경우, 초기 번역 시간이 너무 무거워 결과 자체를 완전히 바꾸어 놓았습니다. 전통적인 웜업 테스트에서 줄리아는 특정 지점까지는 많은 수의 작업자를 효율적으로 처리하는 것처럼 보였고, 그 이후에는 결과를 결합하는 시간이 병목 현상이 되었습니다. 그러나 초기 번역 시간을 포함했을 때, 그 병목 현상은 훨씬 더 일찍 나타났습니다. 코드 번역에 드는 시간이 '남은 시간'을 부풀려 시스템이 매끄럽게 돌아갈 때의 실제 효율성보다 덜 효율적으로 보이게 만들었기 때문에, 프로그램은 웜업 테스트가 시사했던 것보다 훨씬 적은 수의 작업자 단계에서 벽에 부딪히는 것처럼 보였습니다.

하스켈은 다르게 행동했습니다. 이 언어는 계산이 반드시 필요할 때까지 계산을 지연시키기 때문에, 초기 비용이 처음에 한꺼번에 발생하는 것이 아니라 전체 실행 과정에 걸쳐 분산되었습니다. 이는 연구진이 시스템을 먼저 예열하든 콜드 스타트부터 측정하든 결과가 거의 동일하게 나타남을 의미했습니다. 이 언어의 설계는 시작 단계의 거친 부분을 자연스럽게 완만하게 만들어, 테스트가 어떻게 수행되든 놀라울 정도로 안정적인 모습을 보였습니다. 파이썬은 그 중간 어디쯤에 위치했습니다. 파이썬의 성능은 컴퓨터의 서로 다른 부분 사이에서 데이터가 어떻게 이동하는지에 크게 좌l 의존했습니다. 작업이 느린 직렬화 과정을 통해 대량의 데이터를 이동해야 할 때는 콜드 스타트가 상당한 지연을 초래하여 결과를 변화시켰습니다. 하지만 데이터를 더 직접적으로 공유할 수 있을 때는 그 효과가 작았습니다.

아마도 가장 중요한 발견은 수행되는 작업의 유형이 웜업의 중요성을 결정한다는 점이었을 것입니다. 순수하게 숫자를 계산하는 작업의 경우, 초기 지연 시간이 전체 작업량에 비해 매우 작아서 결과에 거의 영향을 미치지 않았습니다. 하지만 데이터를 조직하고 결합하는 작업이 많은 경우에는 초기 지연 시간이 전체 시간의 주요 부분이 되었습니다. 이러한 경우, 웜업을 무시하는 것은 소프트웨어가 자주 시작되고 중단되는 현대 컴퓨팅의 실제 시나리오에서 어떻게 작동할지에 대해 잘못된 안도감을 줍니다. 연구는 병렬 성능을 측정하는 표준적인 방식, 즉 시작 단계를 제거하는 방식은 꾸준히 오래 실행되는 작업에는 정확하지만, 역동적이고 짧은 수명을 가진 작업이 지배적인 현대 컴퓨팅에서는 오해의 소지가 있다는 결론을 내립니다. 이 언어들이 어떻게 작동하는지 진정으로 이해하려면, 연구자와 개발자들은 프로그램 생애의 첫 몇 초가 전체 성능 특성을 정의할 수 있음을 인정하며, 시작 단계를 어떻게 처리했는지를 정확하게 보고해야 합니다.

기술 요약: 교차 언어 병렬 벤치마킹에서의 웜업 프로토콜 문제

문제 정의
교차 언어 병렬 벤치마킹은 정상 상태(steady-state) 실행을 첫 사용 시의 런타임 효과로부터 격리하기 위해 웜업 프로토콜에 의존한다. 그러나 이러한 프로토콜의 방법론적 결과는 그동안 거의 조사되지 않았다. Khan 등(2026)은 병렬 시간을 가장 느린 워커의 계산( $C_p$ ), 알고리즘 병합/결합 작업( $B_p$ ), 그리고 잔여 오버헤드( $R_p$ )로 분해하는 작업-런타임 스케일링 시그니처(WRSS) 프레임워크를 도입하였으며, 이를 통해 지배적인 비용이 변화하는 병목 전이 지점(BTP)을 식별하였다. 그들의 프로토코는 "깨끗한" 정상 상태 측정을 얻기 위해 Julia의 JIT 컴파일, Julia 및 Haskell의 가비지 컬로렉션(GC), Python의 프로세스 초기화와 같은 첫 사용 효과를 체계적으로 제외했다.

본 연구는 이러한 제외 방식이 정상 상태 동작을 격리하는 데는 타당할 수 있으나, 실제 환경의 첫 실행 및 짧은 간격의 병렬 워크로드에서 지배적인 런타임 효과를 체계적으로 제거한다는 점을 제기한다. 핵심 연구 질문은 Khan 등(2026)이 보고한 스케일링 결론이 프로토콜 변동에 견고한지, 아니면 웜업 제외의 결과물(artifact)인지 여부이다. 구체적으로, 본 연구는 웜업 선택이 어떻게 WRSS 시그니처를 왜곡하고, BTP 위치를 이동시키며, Julia, Haskell, Python에 대한 교차 언어 스케일링 결론을 변화시키는지 조사한다.

방법론
본 연구는 Khan 등(2026)의 벤치마크 스위트를 재현 및 확장하여, 동일한 병렬 메커니즘(Julia Threads.@spawn, Haskell forkOn/MVar, Python multiprocessing)을 사용하여 Julia, Haskell, Python에서 세 가지 워크로드(Merge Sort, Closest Pair of Points, Numerical Sum)를 구현하였다.

실험 설계는 $p \in \{1, 2, 4, 8, 16\}$ 명의 워커에 대해 세 가지 별도의 프로토콜 암(arm)을 비교한다:

완전 웜업(Fully Warmed): Khan 등(2026)을 재현한다. JIT 컴파일과 레이지 던크 포싱(lazy thunk forcing)을 트리거하고, 타이밍 시작 전 명시적인 GC 호출 및 프로세스 풀 생성을 포함하는 미측정 예비 실행을 포함한다.
콜드 스타트(Cold-Start): 초기화 효과(JIT 컴파일, 레이지 던크 포싱, 초기 GC, 인터프리터/프로세스 스타트업)를 측정된 병렬 영역 내에 포함한다. 이는 신선한 런타임 실행을 나타낸다.
부분 웜업(Partially Warmed): 측정된 크기의 절반인 다른 입력 크기에서 웜업이 발생하는 실제 배포 상황을 시뮬레이션한다.

측정은 엄격한 CPU 어피니티(affinity)와 머신 부하 승인 게이트를 적용한 듀얼 소켓 AMD EPYC 시스템에서 수행되어 간섭을 최소화하였다. WRSS 구성 요소( $C_p, B_p, R_p$ )는 전체 시간( $T_p$ )으로부터 분해되었으며, BTP는 $p=1$ 에서의 값으로부터 지배적인 구성 요소가 변하는 첫 번째 워커 수 $p > 1$ 로 식별되었다. 통계 분석에는 중앙값 속도 향상, 병렬 효율성, 그리고 Benjamini-Hochberg 보정이 적용된 비매개변수 검정(Kruskal-Wallis, Mann-Whitney U)이 포함되었다.

주요 결과
본 연구는 웜업 프로토콜의 선택이 WRSS 시그니처와 BTP 위치에 실질적인 영향을 미치며, 그 민감도는 언어와 워크로드에 따라 크게 달라짐을 발견하였다:

Julia: 가장 큰 민감도를 보인다. 콜드 스타트 암에서 JIT 컴플레이션과 초기 GC는 잔여 구성 요소( $R_p$ $R_{p}$ )를 팽창시키며, 특히 오버헤드를 상쇄할 만큼 충분한 계산량이 없는 낮은 워커 수에서 두드러진다.
- 영향: Merge Sort와 Closest Pair의 경우, 콜드 스타트 조건에서는 완전 웜업 암에 비해 BTP가 더 낮은 워커 수로 이동한다(예: Merge Sort의 경우 $p=8$ 에서 $p=4$ 로). 이는 Julia 프로그램이 신선한 런타임 상에서 정상 상태 측정치가 예측하는 것보다 더 일찍 오버헤드 지배 영역으로 전환될 수 있음을 시사한다.
Haskell: 가장 작은 민감도를 보인다. 레이지 평가 모델은 값이 요구될 때까지 계산을 연기하여, 초기화 비용(던크 포싱)을 시작 시점에 집중시키는 대신 실행 과정 전반에 분산시킨다. 또한, GC는 불필요한 추측을 정리한다.
- 영향: BTP 위치는 Closest Pair of Points와 Numerical Sum에 대해 세 가지 프로토콜 암 모두에서 안정적이다. Merge Sort의 경우, BTP는 두 암 모두에서 $p=16$ 에 머물러 있으나, 콜드 스타트 암에서는 초기화 비용의 분산으로 인해 전이가 덜 뚜렷하게 나타난다.
Python: 워크로드의 데이터 전송 메커니즘에 따라 중간 정도의 민감도를 보인다.
- 영향: pickle 직렬화가 필요한 워크로드(Merge Sort, Closest Pair)는 콜드 스타트 시 잔여 오버헤드가 크게 증가하며(프로세스 풀 생성 및 직렬화 비용), 이로 인해 BTP가 이동한다(예: Merge Sort의 BTP가 $p=16$ 에서 $p=8$ 로 이동). 상속된 읽기 전용 메모리 매핑을 사용하는 워크로드(Numerical Sum)는 초기화 비용이 전체 시간에서 차지하는 비중이 작아 민감도가 낮다.

교차 워크로드 패턴
웜업 효과의 크기는 워크로드의 결합 강도(combination intensity)와 상관관계가 있다. 결합 강도가 높은 Merge Sort가 가장 큰 웜업 효과를 보였고, 계산 지배적인 Numerical Sum이 가장 작은 효과를 보였다. 계산이 지배적일 때 초기화 비용은 전체 시간에서 무시할 만한 수준이지만, 결합 또는 통신 구성 요소가 두드러질 때는 초기화 비용이 이들과 맞먹거나 이를 능가하여 지배적인 구성 요소를 변화시킬 수 있다.

의의 및 주장
본 논문은 웜업 프로토콜을 보고하지 않는 교차 언어 병렬 성능 비교는 신뢰할 수 없다고 주장한다. 연구 결과는 정상 상태 시그니처가 실제 배포 조건에서의 동작을 완전히 대표한다는 가설에 도전한다.

방법론적 기여: 본 연구는 WRSS 및 BTP 진단이 웜업 프로토콜 설계에 민감하다는 것을 입증한다. 웜업 프로토콜이 명시되지 않은 WRSS 시그니처는 불완전하다.
실무적 시사점: 첫 실행 동작을 추론하는 실무자들은 이상적인 정상 상태 스케일링에만 의존할 수 없다. Khan 등(2026)의 "정상 상태" 결론은 Haskell 및 계산 지배적인 Python 워크로드에는 견고하지만, Julia 및 통신 집약적인 Python 워크로드에 대해서는 웜업 제외에 따른 결과물(artifact)이다.
권고 사항: 저자는 표준화된 웜업 공개 프레임워크를 제안한다. 연구자들은 웜업 프로토콜을 명시적으로 보고해야 하며, 상당한 비계산 구성 요소를 가진 워크로드를 비교할 때는 가급적 여러 프로토콜 암(완전 웜업, 콜드 스타트, 부분 웜업)을 측정해야 한다.

본 연구는 정상 상태 측정이 병렬 스케일링 동작을 격리하는 데 유용하지만, 실무자가 실제로 마주하게 되는 런타임 특유의 비용을 가릴 수 있다고 결론짓는다. 향후 연구는 초기화 비용이 병렬 스케일링에 미치는 영향을 더욱 정밀하게 조절하기 위해 추가적인 언어와 하드웨어 플랫폼으로 확장되어야 한다.

유사한 논문