# 나는 좋은 병렬 컴퓨터를 원해요

> Clean Markdown view of GeekNews topic #19912. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=19912](https://news.hada.io/topic?id=19912)
- GeekNews Markdown: [https://news.hada.io/topic/19912.md](https://news.hada.io/topic/19912.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2025-03-24T09:19:19+09:00
- Updated: 2025-03-24T09:19:19+09:00
- Original source: [raphlinus.github.io](https://raphlinus.github.io/gpu/2025/03/21/good-parallel-computer.html)
- Points: 10
- Comments: 1

## Summary

GPU는 CPU보다 10~100배 더 강력하지만, 동적 작업 처리의 어려움과 병렬 프로그래밍 도구의 부족으로 인해 일반 작업에서 성능을 충분히 활용하지 못하고 있습니다. 과거의 병렬 컴퓨터 디자인은 프로그래밍 모델의 복잡성 등으로 실패했으며, 현대 GPU는 메모리 관리 문제와 복잡한 실행 모델 때문에 성능 최적화가 어렵습니다. AI 가속기와 병렬 코어 집합 같은 새로운 아키텍처가 GPU의 한계를 극복할 가능성이 있으며, 병렬 컴퓨터의 발전을 위해 단순하고 효율적인 실행 모델과 프로그래밍 도구의 개선이 필요합니다.

## Topic Body

- 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 논문](https://dl.acm.org/doi/10.1145/1477926.1477930)에서 제안된 모델  
    - [Brook](https://graphics.stanford.edu/papers/brookgpu/brookgpu.pdf) 프로젝트에서도 비슷한 접근 시도  
  
### 과거의 병렬 컴퓨터 디자인  
- # 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의 성능 한계를 극복할 **새로운 병렬 컴퓨터 아키텍처**가 필요함

## Comments



### Comment 36255

- Author: neo
- Created: 2025-03-24T09:19:19+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=43440174) 
- "두 가지 주요 요인이 이를 방해한다고 믿음"
  - 의견을 과학적으로 포장하는 것에 지침
  - 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가 메모리가 통합되지 않은 것처럼 다루게 함