📊 Mojo 벤치마킹 - 성능 분석과 최적화

개요

요소별, 타일링, 수동 벡터화, Mojo vectorize 패턴을 학습한 후, 이제 실제 성능을 측정할 차례입니다. p21.mojo에 내장된 벤치마킹 시스템을 사용하여 이러한 접근법을 과학적으로 비교하고 성능 특성을 이해하는 방법을 알아봅니다.

핵심 통찰: 이론적 분석은 가치 있지만, 실증적 벤치마킹이 특정 하드웨어에서의 실제 성능을 보여줍니다.

벤치마크 실행

전체 벤치마크를 실행하려면:

pixi run p23 --benchmark

pixi run -e amd p23 --benchmark

pixi run -e apple p23 --benchmark

uv run poe p23 --benchmark

각 패턴에 대한 성능 측정 결과가 출력됩니다:

SIZE: 1024
simd_width: 4
Running P21 GPU Benchmarks...
SIMD width: 4
--------------------------------------------------------------------------------
Testing SIZE=16, TILE=4
Running elementwise_16_4
Running tiled_16_4
Running manual_vectorized_16_4
Running vectorized_16_4
--------------------------------------------------------------------------------
Testing SIZE=128, TILE=16
Running elementwise_128_16
Running tiled_128_16
Running manual_vectorized_128_16
--------------------------------------------------------------------------------
Testing SIZE=128, TILE=16, Vectorize within tiles
Running vectorized_128_16
--------------------------------------------------------------------------------
Testing SIZE=1048576 (1M), TILE=1024
Running elementwise_1M_1024
Running tiled_1M_1024
Running manual_vectorized_1M_1024
Running vectorized_1M_1024
| name                      | met (ms)              | iters |
| ------------------------- | --------------------- | ----- |
| elementwise_16_4          | 0.0033248             | 100   |
| tiled_16_4                | 0.00327392            | 100   |
| manual_vectorized_16_4    | 0.0036169600000000002 | 100   |
| vectorized_16_4           | 0.0037209599999999997 | 100   |
| elementwise_128_16        | 0.00351999            | 100   |
| tiled_128_16              | 0.00370431            | 100   |
| manual_vectorized_128_16  | 0.0043696             | 100   |
| vectorized_128_16         | 0.00378048            | 100   |
| elementwise_1M_1024       | 0.03130143            | 100   |
| tiled_1M_1024             | 0.6892189000000001    | 100   |
| manual_vectorized_1M_1024 | 0.5923888             | 100   |
| vectorized_1M_1024        | 0.1876688             | 100   |

Benchmarks completed!

벤치마크 설정

벤치마킹 시스템은 Mojo의 내장 benchmark 모듈을 사용합니다:

from benchmark import Bench, BenchConfig, Bencher, BenchId, keep
bench_config = BenchConfig(max_iters=10, num_warmup_iters=1)

• max_iters=10: 통계적 신뢰성을 위해 최대 10회 반복
• num_warmup_iters=1: 측정 전 GPU 워밍업
• Benchmark 문서를 참고하세요

벤치마킹 구현의 핵심

핵심 워크플로우 패턴

각 벤치마크는 다음과 같은 간결한 패턴을 따릅니다:

@parameter
fn benchmark_pattern_parameterized[test_size: Int, tile_size: Int](mut b: Bencher) raises:
    bench_ctx = DeviceContext()
    # 셋업: 버퍼 생성 및 데이터 초기화
    @parameter
    fn pattern_workflow(ctx: DeviceContext) raises:
      # 연산: 측정 대상 알고리즘 실행

    b.iter_custom[pattern_workflow](bench_ctx)
    # 최적화 방지: keep(out.unsafe_ptr())
    # 동기화: ctx.synchronize()

주요 단계:

1. 셋업: 버퍼 할당 및 데이터 초기화
2. 연산: 벤치마크 대상 알고리즘 실행
3. 최적화 방지: 정확한 측정을 위해 필수
4. 동기화: GPU 작업 완료 확인

중요: keep() 함수 keep(out.unsafe_ptr())는 컴파일러가 연산 결과를 “사용되지 않는 코드“로 최적화하여 제거하는 것을 방지합니다. 이것이 없으면 알고리즘 대신 아무것도 측정하지 못할 수 있습니다! GPU 커널은 비동기적으로 실행되기 때문에 정확한 GPU 벤치마킹에 필수적입니다.

커스텀 반복이 GPU에 필요한 이유

일반적인 벤치마킹은 CPU 스타일의 동기 실행을 가정합니다. GPU 커널은 비동기적으로 실행되므로 다음이 필요합니다:

• GPU 컨텍스트 관리: 적절한 DeviceContext 생명주기
• 메모리 관리: 반복 간 버퍼 정리
• 동기화 처리: 비동기 연산의 정확한 타이밍
• 오버헤드 분리: 셋업 비용과 연산 비용의 분리

테스트 시나리오와 스레드 분석

벤치마크 모음은 성능 특성을 파악하기 위해 세 가지 시나리오를 테스트합니다:

스레드 활용 요약

문제 크기별 성능 특성

소규모 문제 (SIZE=16):

• 실행 오버헤드가 지배적 (~0.003ms 기준선)
• 스레드 수 차이는 거의 무의미
• 타일링/vectorize가 약간 낮은 오버헤드를 보임

중규모 문제 (SIZE=128):

• 여전히 오버헤드가 지배적 (~0.003ms 전 패턴)
• 성능 차이가 거의 사라짐
• 오버헤드 지배에서 연산 지배로의 전환 구간

대규모 문제 (SIZE=1M):

• 실질적인 알고리즘 차이가 드러남
• 비병합 로드의 영향이 명확해짐
• 뚜렷한 성능 순위가 나타남

데이터가 보여주는 것

다양한 하드웨어에서의 실증적 벤치마크 결과를 기반으로:

성능 순위 (대규모 문제)

핵심 성능 인사이트

단순 메모리 바운드 연산의 경우: 최대 병렬성(elementwise)이 대규모에서 복잡한 메모리 최적화보다 우수합니다.

요소별 패턴이 승리하는 이유:

• 262,144개 스레드가 우수한 지연 시간 은닉을 제공
• 단순한 메모리 패턴이 좋은 병합을 달성
• 스레드당 최소한의 오버헤드
• GPU 코어 수에 따라 자연스럽게 확장

타일링과 vectorize가 경쟁력 있는 이유:

• 병렬성과 메모리 지역성 사이의 균형 잡힌 접근
• 자동 최적화(vectorize)가 수동 타일링과 거의 동등한 성능
• 과도한 복잡도 없이 양호한 스레드 활용

수동 벡터화가 고전하는 이유:

• 256개 스레드만으로는 병렬성이 제한적
• 복잡한 인덱싱이 연산 오버헤드를 추가
• 스레드당 대형 청크로 인한 캐시 부담
• 단순 산술에서 효과 체감

프레임워크 자동화 기능:

• 자동 반복 횟수 조정 (91-100회 반복)
• 서로 다른 실행 시간에 걸친 통계적 신뢰성
• 발열 제한과 시스템 변동에 대응

결과 해석하기

출력 테이블 읽기

| name                     | met (ms)           | iters |
| elementwise_1M_1024      | 0.03130143         | 100   |

• met (ms): 단일 반복의 실행 시간
• iters: 수행된 반복 횟수
• 동일 문제 크기 내에서 비교: 같은 크기끼리 비교하는 것이 가장 의미 있음

최적화 의사결정

실증적 증거를 기반으로 패턴을 선택하세요:

프로덕션 워크로드의 경우:

• 대규모 데이터셋 (>100K 요소): 요소별 패턴이 일반적으로 최적
• 소규모/시작 데이터셋 (<1K 요소): 낮은 오버헤드를 위해 타일링 또는 vectorize
• 개발 속도 우선: 자동 최적화를 위한 Mojo vectorize
• 수동 벡터화 지양: 단순 연산에서는 복잡도가 성능으로 보상되는 경우가 드묾

성능 최적화 워크플로우:

1. 먼저 프로파일링: 최적화하기 전에 측정
2. 대규모에서 테스트: 소규모 문제는 실제 성능에 대해 오해를 줄 수 있음
3. 총비용 고려: 개발 및 유지보수 노력을 포함
4. 개선 사항 검증: 대상 하드웨어에서 벤치마크로 확인

고급 벤치마킹 기법

커스텀 테스트 시나리오

매개변수를 수정하여 다양한 조건을 테스트할 수 있습니다:

# 다양한 문제 크기
benchmark_elementwise_parameterized[1024, 32]  # 대규모 문제
benchmark_elementwise_parameterized[64, 8]     # 소규모 문제

# 다양한 타일 크기
benchmark_tiled_parameterized[256, 8]   # 작은 타일
benchmark_tiled_parameterized[256, 64]  # 큰 타일

하드웨어 고려 사항

결과는 다음에 따라 달라집니다:

• GPU 아키텍처: SIMD 폭, 코어 수, 메모리 대역폭
• 시스템 구성: PCIe 대역폭, CPU 성능
• 열 상태: GPU 부스트 클럭 vs 지속 성능
• 동시 워크로드: GPU 활용에 영향을 주는 다른 프로세스

모범 사례 요약

벤치마킹 워크플로우:

1. 중요한 측정 전에 GPU 워밍업
2. 통계적 유의성을 위해 여러 번 반복 실행
3. 확장 특성을 이해하기 위해 다양한 문제 크기 테스트
4. 최적화 아티팩트를 방지하기 위해 keep()을 일관되게 사용
5. 동일 조건에서 비교 (같은 문제 크기, 같은 하드웨어)

성능 의사결정 프레임워크:

• 단순하게 시작: 메모리 바운드 연산에는 요소별 패턴부터
• 추측하지 말고 측정: 이론적 분석은 방향을, 실증적 데이터가 결정을
• 규모가 중요: 소규모 문제의 성능이 대규모 문제의 동작을 예측하지 못함
• 총비용 최적화: 개발 시간 vs 런타임 성능의 균형

다음 단계

벤치마킹 기술을 갖추었다면:

• 실제 애플리케이션 프로파일링: 이 패턴들을 실제 워크로드에 적용
• 고급 GPU 패턴: 리덕션, 합성곱, 행렬 연산 탐구
• 멀티 GPU 확장: 분산 GPU 컴퓨팅 패턴 이해
• 메모리 최적화: 공유 메모리와 고급 캐싱을 더 깊이 탐구

💡 핵심 요약: 벤치마킹은 이론적 이해를 실질적인 성능 최적화로 전환합니다. 실증적 데이터를 사용하여 특정 하드웨어와 워크로드 특성에 가장 적합한 패턴을 선택하세요.

앞으로의 방향: 더 많은 제어가 필요할 때

Part VI의 함수형 패턴은 대부분의 워크로드에서 우수한 성능을 제공하지만, 일부 알고리즘은 직접적인 스레드 간 통신이 필요합니다:

워프 프로그래밍이 유용한 알고리즘:

• 리덕션: 스레드 그룹에 걸친 합계, 최댓값, 최솟값 연산
• 누적 연산: 누적 합, 이동 최댓값
• 데이터 셔플: 스레드 간 데이터 재배치
• 협력 알고리즘: 스레드 간 긴밀한 조정이 필요한 경우

성능 미리보기:

Part VII에서는 Part III의 여러 알고리즘을 다시 살펴보며 워프 연산이 어떻게:

• 코드를 간소화하는지: 복잡한 공유 메모리 패턴을 단일 함수 호출로 대체
• 성능을 향상시키는지: 배리어를 제거하고 메모리 트래픽을 감소
• 새로운 알고리즘을 가능하게 하는지: 순수 함수형 접근으로는 불가능한 패턴을 구현

다음 내용: Part VII: 워프 레벨 프로그래밍 - Puzzle 14의 누적 합을 완전히 새롭게 구현하는 것부터 시작합니다.