異質平行運算與對運算速度的需求 (Heterogeneous Parallel Computing)
重點總覽 (Overview)
| 主題 | CPU (latency-oriented) | GPU (throughput-oriented) |
|---|---|---|
| 發展路線 | multicore trajectory:維持序列程式速度 | many-thread trajectory:最大化平行吞吐量 |
| 核心數量範例 | Intel 24-core、ARM Ampere 128-core | A100 數萬個 threads(簡單 in-order pipeline) |
| 設計目標 | 降低單一 thread 的 latency | 提高大量 threads 的 total throughput |
| 晶片面積花在 | 大 cache、branch prediction、複雜 control、低延遲 ALU | 大量小 ALU、大量 memory channels、小 cache |
| FP throughput (2021) | FP64 0.33 / FP32 0.66 TFLOPS | FP64 9.7 / FP32 156 / FP16 312 TFLOPS |
| Memory bandwidth | 基準 | 約為同期 CPU 的 ~10× |
| 擅長 | 1 個或極少 thread 的工作 | 大量 thread 的數值密集工作 |
核心觀念:降低 latency 的成本遠高於提高 throughput。所以兩條路線在固定的功耗/面積預算下做出相反的取捨,進而衍生出 CPU + GPU 協同 (heterogeneous) 的運算模型 — 序列部分跑 CPU、數值密集部分跑 GPU。
兩條設計路線 (Multicore vs Many-thread Trajectories)
自 2003 年起(因 clock frequency 受限於能耗與散熱),半導體業分成兩條路線:
| Multicore trajectory | Many-thread trajectory | |
|---|---|---|
| 訴求 | 維持序列程式的執行速度 | 提高平行應用的執行吞吐量 |
| 起點 | 雙核心 → 隨製程世代增加 | 一開始就大量 threads → 持續增加 |
| 核心特性 | out-of-order、multiple-issue、hyperthreading、完整 x86 | 大量簡單的 in-order pipeline |
| 代表 | Intel 24-core server、ARM Ampere 128-core | NVIDIA A100 GPU(數萬 threads) |
自 2003 年起,many-thread GPU 在 floating-point 效能上一直領先;GPU 與 CPU 的峰值 FP throughput 比值持續擴大。這種「電位差 (electrical potential)」推動開發者把運算密集部分搬到 GPU,並催生了 deep learning 這類本質上運算密集的革命性應用。
這些是硬體可支援的原始峰值速度 (raw peak),不等於實際應用速度。實際 speedup 受 Amdahl's Law、memory bandwidth 等限制(見 01-Introduction/02-Speedup-Challenges-and-Related-Interfaces)。
設計哲學:Latency-oriented vs Throughput-oriented
為什麼峰值差距這麼大? 來自兩者根本不同的設計哲學 (Fig. 1.1)。
(A) CPU — Latency-oriented (B) GPU — Throughput-oriented
+---------------------------+ +-----------------------------------+
| Control (branch pred.) | | Ctrl | ALU ALU ALU ALU ALU ALU |
| +-------+ +-------+ | |------+ ALU ALU ALU ALU ALU ALU |
| | ALU | | ALU | big | | Ctrl | ALU ALU ALU ALU ALU ALU |
| | (大) | | (大) | ALU | |------+ ALU ALU ALU ALU ALU ALU |
| +-------+ +-------+ | | small cache (控制頻寬需求) |
| +-----------------------+ | +-----------------------------------+
| | LARGE last-level | | | 大量 memory channels (寬頻寬) |
| | CACHE | | +-----------------------------------+
| +-----------------------+ |
| few memory channels | 多: 小 ALU、小 cache、多 channel
+---------------------------+ 少: 大 ALU、大 cache、少 channel
| 設計面向 | CPU(降低延遲) | GPU(提高吞吐) |
|---|---|---|
| ALU | 少而大、低延遲 | 多而小、允許長 latency 的 pipelined 運算 |
| Cache | 大 last-level cache,把長延遲記憶體存取轉成短延遲 | 小 cache,只為控制頻寬需求(避免重複存取同一資料) |
| Control | 複雜 branch prediction、execution control | 簡單 control |
| 隱藏延遲方式 | 用硬體降低每個 thread 的延遲 | 用大量 threads,某些在等待時切換去做其他工作 (latency hiding) |
關鍵量化:Latency 降低 vs Throughput 提高的成本
| 目標 | 手段 | 晶片面積 | 功耗 |
|---|---|---|---|
| 吞吐量加倍 | ALU 數量加倍 | 2× | 2× |
| 延遲減半 | 電流加倍 | > 2× | 4× |
因為「延遲減半」比「吞吐加倍」貴得多,GPU 選擇為大量 threads 的吞吐量做優化,寧可讓單一 thread 跑得更久。省下的面積與功耗用來放更多 ALU 與 memory channel。
Memory Bandwidth 優勢
GPU 不只 FP 運算強,memory bandwidth 同樣關鍵(甚至更關鍵):
- 圖形應用的速度常受限於資料能多快在 memory 與 processor 間搬運(frame buffer 進出 DRAM)。
- 遊戲應用採用relaxed memory model(對記憶體存取順序要求寬鬆),讓 GPU 容易支援大規模的記憶體平行存取。
- 通用 CPU 必須滿足 legacy OS / 應用 / I/O 裝置的需求,難以提高平行記憶體存取的吞吐量。
結果:GPU 的 memory bandwidth 約為同期 CPU 的 10 倍,而且預期此優勢會維持一段時間。如何繞過 DRAM 頻寬限制(用 on-chip memory)是本書核心優化主題,見 06-Performance-Considerations/02-Hiding-Memory-Latency。
CPU/GPU 協同與 CUDA (Heterogeneous Execution)
GPU 是平行、吞吐導向的引擎,不擅長 CPU 擅長的工作。對只有 1 個或極少 thread 的程式,低延遲的 CPU 反而快得多。
因此多數應用會同時用 CPU 與 GPU:序列部分跑 CPU、數值密集部分跑 GPU。這正是 NVIDIA 於 2007 年推出 CUDA 的目的 — 支援 CPU-GPU 聯合執行。
速度不是唯一的選擇因素,其他考量甚至更重要:
| 因素 | 說明 | GPU 的優勢 |
|---|---|---|
| Installed base(市場保有量) | 大客群才能攤平軟體開發成本 | 已有 超過 10 億顆 CUDA-enabled GPU |
| Form factor / 易取得性 | 臨床等場景無法塞進整櫃伺服器 | 一台 PC + GPU 即可(如 MRI 產品) |
GPGPU → CUDA 演進
| 階段 | 時間 | 程式設計方式 | 限制 |
|---|---|---|---|
| GPGPU | ~2006 前 | 透過 graphics API(OpenGL / Direct3D);運算必須偽裝成「畫 pixel」的函式 | 只能寫成 pixel 著色,應用種類受限,未普及 |
| CUDA | 2007 起 | 晶片新增 silicon,提供通用平行程式介面;直接用 C/C++ 工具 | 不再經過 graphics interface(G80 及後續晶片) |
CUDA 不只是軟體改變 — NVIDIA 實際投入晶片面積 (silicon) 來簡化平行程式設計。除了 GPU,其他 accelerator(如 FPGA 加速網路應用)也適用本書的技術。
為什麼需要更多速度 (Why More Speed?) — §1.2
主要動機:讓應用能持續享受未來硬體世代帶來的速度提升。
- 適合平行的應用,在 GPU 上良好實作可達 > 100× speedup(相對單一 CPU core)。
- 若具備 data parallelism,常常幾小時就能拿到 ~10× (10³ 級語境的快速收益) speedup。
Superapplications(未來大眾市場的超級運算應用):
| 領域 | 對運算速度的需求 |
|---|---|
| 分子生物 | 以模擬補足顯微鏡的觀測極限,可建模更大系統、更長反應時間 |
| 影音編碼 | HDTV、3D 成像、view synthesis、低解析影片高解析顯示 |
| 使用者介面 | 高解析觸控、3D 顯示、語音與電腦視覺介面 |
| 遊戲 | 從預設場景 → 動態物理模擬(撞擊真實損壞);digital twins |
Deep Learning(被算力解放的關鍵應用):
類神經網路 (1970s 起研究) ── 因「需大量 labeled data + 大量運算」而長期無法實用
│
┌──────────────────────┴──────────────────────┐
網際網路興起 GPU 興起
(海量 labeled 圖片) (運算吞吐量暴增)
└──────────────────────┬──────────────────────┘
▼
2012 起神經網路應用快速採用 → 革新 computer vision / NLP
→ 推動自駕車、家庭助理裝置
這些新應用都是在不同層次模擬/表示一個物理且並行的世界,處理巨量資料。資料的大部分可平行處理,而有效管理資料遞送 (data delivery) 對可達速度有決定性影響 — 這正是 CUDA 提供的程式模型要解決的問題。
考試/面試重點 (Exam / Test Patterns)
| 情境 / 關鍵字 | 答案 / 技巧 |
|---|---|
| 為何 CPU 慢但延遲低? | latency-oriented:大 cache + branch prediction + 大 ALU 降低單 thread 延遲 |
| 為何 GPU 峰值 FP 高? | throughput-oriented:大量小 ALU + 多 memory channel,靠大量 threads 隱藏延遲 |
| Multicore vs Many-thread | multicore=維持序列速度(少而強核);many-thread=最大化吞吐(多而簡單) |
| 「延遲減半」vs「吞吐加倍」哪個貴? | 延遲減半貴:需 2× 電流 → >2× 面積、4× 功耗;吞吐加倍只要 2× 面積/功耗 |
| GPU 記憶體頻寬約多少倍 CPU? | ~10×;原因含遊戲的 relaxed memory model |
| CUDA 哪年推出?解決什麼? | 2007;支援 CPU-GPU 聯合執行,擺脫 graphics API |
| GPGPU 的限制是什麼? | 運算須表達成「畫 pixel」,受 OpenGL/Direct3D API 限制,未普及 |
| 選 GPU 的非速度因素 | installed base(>10 億顆)、form factor / 易取得性(MRI 例) |
| Deep learning 為何 2012 才起飛? | 網際網路提供 labeled data + GPU 提供算力,兩者同時到位 |
| 何時該用 CPU 而非 GPU? | 只有 1 個或極少 thread 的序列工作,低延遲 CPU 較快 |
Related Notes
- 01-Introduction/02-Speedup-Challenges-and-Related-Interfaces
- 01-Introduction/03-Overarching-Goals-and-Book-Organization
- 02-Heterogeneous-Data-Parallel-Computing/01-Data-Parallelism-and-CUDA-Program-Structure
- 04-Compute-Architecture-And-Scheduling/02-Warps-SIMD-and-Control-Divergence
- 06-Performance-Considerations/02-Hiding-Memory-Latency
- 16-Deep-Learning/01-Machine-Learning-Foundations-Perceptrons-Backpropagation