Archive

06-2 병렬 프로세서

7 min read

1. 메시지 패싱/클러스터

1.1. Message Passing 모델

  • 각 프로세서가 사적(Private) 물리 주소 공간 보유
  • HW가 프로세서 간 메시지를 send/receive

1.2. Loosely Coupled Cluster

  • 독립 컴퓨터들의 네트워크(각자 메모리/OS)
  • I/O 시스템(Ethernet/switch/Internet)으로 연결
  • 독립 태스크 중심 앱에 적합: 웹서버/DB/시뮬레이션 등
  • 장점: 고가용성/확장성/저비용
  • 문제: 관리 비용(→ VM 선호), 낮은 인터커넥트 BW(SMP의 CPU–memory BW와 대비)

1.3. Sum Reduction을 메시지 패싱으로(재등장)

  • 분배 후 각 노드가 부분합, 이후 절반은 send, 절반은 receive+add…
  • send/receive가 동기화 역할도 수행
  • 가정: send/receive 시간이 add와 비슷

1.4. Grid computing

  • 장거리 네트워크로 연결된 컴퓨터들에 작업 단위를 분배하고 결과 회수
  • 유휴 PC 시간 활용: SETI@home, World Community Grid

2. 상호연결 네트워크 토폴로지

2.1. 대표 토폴로지

  • Bus, Ring, 2D Mesh, N-cube(예: 3차), Fully connected

2.2. Multistage network

  • Crossbar, Omega network(스위치 박스 포함)

2.3. 네트워크 특성(평가 축)

  • 성능

    • Latency(비부하시 메시지 지연)
    • Throughput: 링크 BW, 총 네트워크 BW, Bisection BW
    • Congestion delay(트래픽 의존)

  • Cost, Power, 실리콘 라우팅 용이성

3. 벤치마크와 성능 모델

3.1. 병렬 벤치마크 예

  • Linpack(선형대수)
  • SPECrate(SPEC CPU 병렬 실행, job-level parallelism)
  • SPLASH(공유메모리 병렬, 커널+앱, strong scaling)
  • NAS(CFD 커널)
  • PARSEC(Pthreads/OpenMP 멀티스레드 앱)

3.2. Code vs Application 논점

  • 전통 벤치마크는 코드/데이터셋 고정
  • 병렬 프로그래밍이 진화 중 → 알고리즘/언어/툴도 시스템의 일부로 봐야 하나?
  • 주어진 애플리케이션 구현을 비교하는 방식(Linpack, Berkeley Design Patterns 등) → 병렬성 혁신 촉진 가능

4. Roofline 모델로 성능 이해

4.1. 성능 모델링 절차

  • 관심 지표: 달성 가능한 GFLOPs/s

  • Berkeley Design Patterns의 커널로 측정

  • Arithmetic intensity = FLOPs / 메모리 바이트 접근량

  • 시스템별로

    • Peak GFLOPS(스펙)
    • Peak memory B/s(Stream 벤치마크)

4.2. Roofline 방정식

  • 낮은 AI는 BW 제한(기울어진 지붕), 높은 AI는 연산 제한(수평 지붕)

4.3. 시스템 비교 예(Opteron X2 vs X4)

  • 코어 수/FP 성능은 증가, 메모리 시스템은 동일
  • X4가 X2보다 유리하려면 높은 AI 필요, 또는 working set이 X4의 2MB L3에 들어가야

4.4. 최적화 방향(지붕선에 따라)

  • FP 최적화: add/mul 균형, superscalar ILP↑, SIMD 활용

  • 메모리 최적화: SW prefetch로 load stall 회피, memory affinity로 비지역 접근 회피

  • AI는 고정이 아닐 수 있음

    • 문제 크기에 따라 변함
    • 캐싱은 메모리 접근을 줄여 AI를 증가시킴

5. DNN 가속기 사례: TPUv3 vs Volta

5.1. TPUv3 내부 구성 요약

  • Core Sequencer

    • SW-managed memory를 가진 VLIW
    • 322-bit VLIW에 8 ops: scalar ALU 2, vector ALU 2, vector load/store, MXU 관련 queue ops 2

  • VPU

    • DLP(2D matrix/vector 유닛) + ILP(한 명령에 8 ops)
    • 온칩 Vmem: 32K × (128×32-bit) elements (16MiB)
    • Vregs: 32개 2D 벡터 레지스터(각 4KiB)

  • MXU

    • 16-bit 입력의 곱을 32-bit로 누산
    • TensorCore당 MXU 2개

  • Transpose/Reduction/Permute 유닛

    • 128×128 transpose/reduction/permutation

6. 멀티프로세서로 DGEMM 더 빠르게

6.1. 전략

  • 블로킹(BLOCKSIZE) + 벡터화(AVX-512 intrinsics) + OpenMP 병렬화
  • #pragma omp parallel for로 블록 단위 병렬 수행(페이지 53 코드)

6.2. 성능 관찰(그래프)

  • 스레드 수 증가에 따른 speedup 곡선
  • 크기별 GFLOPs/s 비교 막대그래프 → 행렬이 작으면 오버헤드/병목으로 확장이 제한되고, 큰 행렬에서 확장성/성능이 더 잘 나온다는 전형적 패턴

7. 오류와 함정

7.1. Fallacies(오해)

  1. 암달의 법칙은 병렬 컴퓨터에 적용 안 된다. (선형 가속 가능)

    • 약한 스케일링(문제 크기 증가)에서만 선형 가속이 가능할 수 있음

  2. 피크 성능이 관측 성능을 따라간다.

    • 마케팅에서 좋아하지만, 실제는 병목을 봐야 함

7.2. 추가 Fallacy: 새로운 아키텍처용 SW 최적화 미흡

  • 아키텍처 특성을 반영하지 않으면 예상치 못한 병목(예: 페이지 테이블 직렬화)
  • DSA의 사용성 문제
  • 메모리 BW를 개선하지 않고도 “벡터 성능이 좋아 보일” 수 있음 → Roofline의 기울기 구간을 경계

7.3. Pitfalls(함정)

  • 멀티프로세서 구조를 고려하지 않은 SW 설계

    • 예: 복합 공유 자원에 단일 락 하나 → 접근 직렬화 → 실제 병렬 가능성도 묶어버림
    • 해결: 더 미세한 락(파인 그레인 락킹)

  • ISA가 물리 구현 특성을 완전히 숨긴다고 가정하는 함정

    • 공격자는 롤백된 실행의 상태 변화나, 서버에서 다른 프로그램과 섞일 때 생기는 성능 차이를 관찰 가능
    • 원인: speculation, caching, HW multithreading

8. 결론

  • 목적: 다중 프로세서로 더 높은 성능

  • 어려움

    • 병렬 SW 개발
    • 적절한 아키텍처 설계

  • SaaS 중요성 증가, 클러스터가 잘 맞음

  • 성능/$, 성능/J이 모바일과 WSC(warehouse-scale computing)를 모두 견인

  • SIMD/Vector는 멀티미디어 앱과 잘 맞고 프로그래밍이 상대적으로 쉬움

그래프 뷰