▲

GN⁺: 나는 좋은 병렬 컴퓨터를 원해요

 (raphlinus.github.io)
8P by neo 5일전 | ★ favorite | 댓글 1개
  • GPU는 CPU보다 10~100배 더 강력하지만, 동적 작업 처리에 어려움이 있고 병렬 프로그래밍 도구가 부족해 일반 작업에서 성능을 충분히 활용하지 못하고 있음
  • 과거에 Connection Machine, Cell, Larrabee 같은 병렬 컴퓨터 디자인이 있었지만 프로그래밍 모델의 복잡성 등으로 실패함
  • 현대 GPU는 메모리 관리 문제와 복잡한 실행 모델 때문에 성능 최적화가 어렵고, 큐 기반의 효율적인 데이터 전달 구조가 필요함
  • AI 가속기와 병렬 코어 집합 같은 새로운 아키텍처가 GPU의 한계를 극복할 가능성이 있음
  • 병렬 컴퓨터의 발전은 아직 미완성 상태이며, 단순하고 효율적인 실행 모델과 프로그래밍 도구의 개선이 필요함

GPU의 강력한 성능과 한계

  • GPU는 CPU보다 약 10~100배 더 강력함 (작업 종류에 따라 다름)
  • 실시간 그래픽 렌더링 및 머신러닝에서는 이 성능이 잘 활용되고 있음
  • 그러나 GPU 성능이 일반적인 작업에서 충분히 활용되지 못하고 있음

GPU의 한계 원인

  • 빈약한 실행 모델
    • GPU는 예측 가능한 대규모 데이터(예: 밀집 행렬 곱셈)에 강하지만 동적 작업에서는 성능이 떨어짐
  • 부족한 언어 및 도구
    • 병렬 컴퓨터 프로그래밍 자체가 매우 어려움

복잡성의 증가

  • 최신 GPU는 복잡성이 빠르게 증가하고 있음
  • 메시 셰이더(mesh shaders), 워크 그래프(work graphs) 등의 새로운 기능이 도입되었지만 일부 기본 작업은 여전히 지원되지 않음

복잡한 GPU 메모리 효율 문제

  • 필자는 Vello라는 고급 2D 벡터 그래픽 렌더러를 개발 중
    • CPU가 장면 설명(SVG 형식) 업로드 → 컴퓨트 셰이더가 처리 후 이미지 생성
  • 문제점: 메모리 관리의 어려움
    • 중간 결과 저장을 위한 버퍼 크기 예측이 어려움
    • 버퍼 초과 시 GPU에서 CPU로 읽기 작업이 성능 저하를 초래함

해결책 제안

  • GPU 내부에서 큐(queue) 를 통해 결과를 전달하도록 개선
    • 2009년 GRAMPS 논문에서 제안된 모델
    • Brook 프로젝트에서도 비슷한 접근 시도

과거의 병렬 컴퓨터 디자인

  • Connection Machine (1985)

    • 64k 프로세서가 하이퍼큐브 네트워크로 연결된 병렬 컴퓨터
    • 각각의 프로세서는 성능이 낮았지만 대규모 병렬 작업이 가능
    • 병렬 알고리즘 연구에 큰 기여

  • Cell (2006, PS3)

    • PS3에 포함된 병렬 컴퓨터 (약 87.4백만 대 출하)
    • 8개의 병렬 코어가 독립적으로 연산 수행 가능
    • 프로그래밍 모델의 복잡성이 실패 원인

  • Larrabee (2008)

    • x86 기반 병렬 컴퓨터로 개발됨
    • 실패 이유: 전력 소비 및 소프트웨어 지원 부족
    • 이후 Xeon Phi 및 AVX-512 명령어로 이어짐

변화하는 작업 부하

  • 게임에서도 연산 작업 비중이 증가
    • Starfield의 경우 총 작업 시간의 약 **50%**가 연산
    • Nanite 렌더러는 작은 삼각형의 래스터화도 연산으로 처리

앞으로의 발전 방향

  • 1. 코어 집합 확장 (Cell 부활)

    • 현대의 고급 CPU는 1000억 개 이상의 트랜지스터 포함
    • 저전력의 단순한 RISC 코어를 수백~수천 개 포함한 칩 제작 가능
    • AI 가속기는 이미 유사한 아키텍처 채택 중

  • 2. GPU에서 Vulkan 명령 실행

    • GPU에서 직접 Vulkan 명령 실행 가능하도록 지원
    • 현재 일부 Vulkan 확장에서 제한적으로 구현됨

  • 3. 워크 그래프(Work Graph)

    • 프로그램을 노드(커널)와 엣지(큐)로 구성
    • 병렬로 실행되나 다음과 같은 제한 사항 존재
      • 조인(join) 작업이 어려움
      • 요소의 정렬 순서 보장 안됨
      • 가변 크기 요소 지원 안됨

  • 4. CPU와의 융합 진화

    • 고성능 CPU 디자인이 병렬 처리에 최적화될 가능성
    • 병렬 연산 및 SIMD(단일 명령 다중 데이터) 처리 성능 개선 중

  • 5. 하드웨어는 이미 준비되어 있을 가능성

    • 일부 GPU에는 사용자 코드 실행 가능한 명령 프로세서 포함
    • 명령 프로세서가 완전히 개방되면 성능 개선 가능성 존재

복잡성 문제

  • GPU 아키텍처는 지나치게 복잡함
    • 병렬 컴퓨터 + 특수 하드웨어 + 명령 처리 구조가 혼재
    • 다양한 API와 드라이버 호환성 문제
  • 반면, CPU는 단순한 명령 집합 기반에서 성능 향상 지속

결론

  • 병렬 컴퓨터의 발전은 아직 미완성 상태
  • GPU가 그래픽 및 AI 작업 외에도 일반 작업에 최적화되기 위해 다음이 필요함
    • 단순한 실행 모델
    • 프로그래밍 용이성
    • 낮은 전력 소비
  • Vello 같은 고급 2D 렌더러 작업에서 병렬 컴퓨터의 성능을 온전히 활용 가능할 것
  • GPU의 성능 한계를 극복할 새로운 병렬 컴퓨터 아키텍처가 필요함
▲
neo 5일전  [-]
Hacker News 의견

  • "두 가지 주요 요인이 이를 방해한다고 믿음"

    • 의견을 과학적으로 포장하는 것에 지침
    • Cell 프로세서 작업 경험에서 많은 미세 관리가 필요했음
    • 현대 시스템은 메모리 보호, 격리, 안정성을 고려하여 설계됨
    • Amiga에서 코드를 작성하게 하면 새로운 감사가 생길 것임

  • 프로그래밍 모델이 2025년에는 비효율적임

    • 런타임에 셰이더 소스/바이트코드를 컴파일해야 함
    • NUMA/디스크리트에서 CPU와 GPU 간의 데이터 구조 조작이 어려움
    • CPU-GPU 및 GPU 작업 간의 데이터 접근 동기화 필요
    • 표준화되지 않은 하드웨어로 인해 혼란스러운 API 처리 필요
    • 다양한 구성의 조합 처리 필요

  • "수백 개의 작은 CPU를 단일 칩에 넣은" 회사에서 일한 경험

    • 프로그래밍 모델이 너무 이상해서 실패할 것임
    • 차세대는 새로운 아키텍처가 아닌 추가 기능이 있는 GPU일 것임

  • GPU가 CPU보다 10~100배 더 강력함

    • 많은 작업이 더 많은 성능을 필요로 하지 않음
    • GUI는 20년 이상 사용자 입력에 반응적이었음
    • GPU 프로그래밍을 단순화해야 함

  • M4 Mac mini 슈퍼컴퓨터 구축에 대한 의견

    • Apple M3 Ultra GPU 및 Neural Engine 명령어 집합 역공학
    • 50조 이상의 연산을 초당 수행할 수 있음

  • 병렬 컴퓨터의 문제점

    • 많은 사람들이 개발 목적으로 장치를 채택해야 함
    • CPU에서 GPU로 코드를 포팅하는 것은 큰 작업임
    • AMD와 다른 회사들이 GPU를 CPU에 더 가깝게 이동시키는 아이디어 탐구

  • 2D 렌더러에 GPU가 필요한 이유가 명확하지 않음

    • 3D 렌더러는 도움이 필요함
    • Vulkan은 렌더러 아래의 레벨임
    • Rust 3D에서 렌더러 설계의 마찰점 존재

  • Larabee에 대한 언급이 많지만 Xeon Phis에 대한 언급이 없음

    • CPU 설계가 단일 코어 성능과 전력 효율성을 최적화하는 방향으로 나뉘고 있음
    • E 코어가 더 많아지면 병렬성을 활용하는 알고리즘이 승리할 수 있음

  • GPU의 높은 처리량을 가능하게 하는 희생

    • Apple Silicon의 통합 메모리 시스템이 있음
    • GPU 프로그래밍 API가 메모리가 통합되지 않은 것처럼 다루게 함
답변달기