Mở đầu: khi CPU và GPU thôi tranh giành, chúng chia sẻ

Bài 7-8 mô tả phân cấp bộ nhớ trong mô hình PC truyền thống: CPU có RAM riêng, GPU có VRAM riêng, kết nối qua bus PCIe. Mỗi lần CPU cần GPU xử lý dữ liệu (render đồ hoạ, huấn luyện mô hình AI), dữ liệu phải được SAO CHÉP từ RAM sang VRAM qua PCIe — một bước tốn thời gian, dù chỉ đơn thuần là "chuyển dữ liệu từ nơi này sang nơi khác" chứ không tính toán gì. Apple Silicon đặt câu hỏi ngược: nếu CPU và GPU cùng nằm trên MỘT đế silicon, tại sao không để chúng CHIA SẺ luôn một bể RAM duy nhất?


📚 Điều kiện tiên quyết
Nên đọc Bài 7 (Cache) và Bài 8 (Bộ nhớ ảo) — UMA bài này là một cách tổ chức KHÁC của chính phân cấp bộ nhớ đã học, không phải khái niệm tách biệt.

1. Hệ thống trên chip (SoC) vs Bo mạch truyền thống

PC truyền thống lắp CPU, GPU, RAM, ổ đĩa... là các LINH KIỆN RỜI trên bo mạch chủ, kết nối qua các bus (PCIe, SATA...). Apple Silicon (dòng M) tích hợp CPU, GPU, Neural Engine (NPU), bộ điều khiển bộ nhớ... lên CÙNG một đế silicon — gọi là SoC (System on a Chip). Khoảng cách vật lý giữa các khối cực ngắn, giảm độ trễ và tiêu thụ năng lượng đáng kể so với việc tín hiệu phải đi qua các đường dẫn (traces) dài trên bo mạch giữa các chip rời.

soc_layout.txt (SoC vs bo mạch rời rạc)
PC truyen thong (linh kien roi tren bo mach):
  [CPU chip] ---bus--- [GPU chip roi] ---bus--- [RAM DIMM]
  Tin hieu di qua duong dan (traces) DAI tren bo mach giua cac chip

Apple Silicon SoC (mot de silicon):
  +--------------------------------------------------+
  | [CPU: Firestorm x N] [CPU: Icestorm x M] [GPU]    |
  | [Neural Engine (NPU)] [Bo dieu khien bo nho UMA]  |
  +--------------------------------------------------+
  Khoang cach vat ly giua cac khoi CUC NGAN - giam do tre + nang luong
⚠️ Cạm bẫy: SoC đánh đổi khả năng nâng cấp
Vì RAM và các thành phần khác được HÀN CHẾT trên cùng đế silicon với CPU/GPU, người dùng KHÔNG THỂ nâng cấp RAM hay thay thế linh kiện rời rạc khi hỏng hóc — khác hẳn PC truyền thống nơi RAM, GPU đều là các khe cắm (slot) có thể tháo lắp. Đây là đánh đổi CÓ CHỦ ĐÍCH giữa hiệu năng/tiết kiệm năng lượng (SoC) và khả năng sửa chữa/nâng cấp (kiến trúc rời rạc) — không phải giới hạn kỹ thuật ngẫu nhiên.

2. Nhân lớn/nhỏ (big.LITTLE) & UMA

Apple M1 có 2 loại nhân CPU: Firestorm (hiệu năng cao, ăn nhiều điện) và Icestorm (tiết kiệm điện, hiệu năng thấp hơn) — hệ điều hành TỰ ĐỘNG đẩy tác vụ nền (đồng bộ email, quét virus) sang Icestorm để tiết kiệm pin, và tác vụ nặng (biên dịch code, render video) sang Firestorm. Quan trọng hơn cho bài này: CPU (cả 2 loại nhân) và GPU đều truy cập CHUNG một bể RAM LPDDR5 duy nhất — đây là UMA (Unified Memory Architecture).

uma_vs_traditional.txt (so đồ 2 mô hình)
PC truyen thong:
  [CPU] --RAM rieng--    [GPU] --VRAM rieng--
     |______________PCIe Gen4 x16 (~32 GB/s)_____________|
     Moi lan GPU can du lieu CPU dang giu -> SAO CHEP qua PCIe

Apple Silicon (UMA):
  [CPU] ---+
           +--- CHUNG mot be RAM LPDDR5 (vd 400 GB/s tren M1 Max) ---+
  [GPU] ---+                                                         |
     CPU va GPU deu doc/ghi TRUC TIEP, KHONG can sao chep gi ca
⚠️ Cạm bẫy: lập lịch sai lầm gây hao pin
Nếu bộ lập lịch hệ điều hành (thread scheduler) đẩy NHẦM một tác vụ nền nhẹ lên nhân Firestorm hiệu năng cao (thay vì Icestorm tiết kiệm điện), pin bị tiêu hao một cách VÔ ÍCH — công việc vẫn hoàn thành đúng, nhưng tốn điện hơn hẳn mức cần thiết. Lập lịch big.LITTLE đúng đắn là bài toán liên tục cân bằng giữa "xong việc nhanh" và "xong việc tiết kiệm điện", không có công thức cố định cho mọi tác vụ.

3. Bài toán tính toán băng thông: PCIe vs UMA

Render MỘT khung hình 4K (3840×2160 pixel, 32-bit màu — 4 byte/pixel gồm R/G/B/Alpha) cần đúng:

$$\text{Frame Bytes} = 3840 \times 2160 \times 4 = 33.177.600 \text{ byte}$$

Verified thật: khung hình 4K nặng đúng 33.177.600 byte (31,64 MiB). So sánh thời gian truyền dữ liệu này qua 2 kênh — PCIe Gen 4 x16 (băng thông thực tế ~32 GB/s, cần SAO CHÉP từ RAM sang VRAM) vs UMA trên Apple M1 Max (băng thông RAM 400 GB/s, GPU truy cập TRỰC TIẾP, không sao chép):

bandwidth_compare.js (trích engine dùng chung cpu-core.js)
function frameBytes(width, height, bytesPerPixel) {
  return width * height * bytesPerPixel;
}
function transferTimeSeconds(bytes, bandwidthGBps) {
  return bytes / (bandwidthGBps * 1e9);
}
// Verified: frameBytes(3840, 2160, 4) = 33.177.600 byte
// Verified: transferTimeSeconds(33177600, 32) * 1000  = 1,0368 ms  (PCIe Gen 4 x16)
// Verified: transferTimeSeconds(33177600, 400) * 1000 = 0,0829 ms  (UMA M1 Max)
// UMA nhanh hon PCIe DUNG bang ty le bang thong: 400/32 = 12,5 lan

Ở khung hình 4K này, PCIe mất 1,0368 ms, UMA chỉ mất 0,0829 ms — nhanh hơn đúng 12,5 lần, khớp CHÍNH XÁC tỷ lệ băng thông ($400/32=12,5$), không phải một con số ước lượng mơ hồ. Ở khung hình 60fps (ngân sách mỗi khung hình $1000/60 \approx 16,67$ ms), PCIe chiếm 6,22% ngân sách CHỈ ĐỂ SAO CHÉP dữ liệu (chưa tính thời gian GPU thực sự xử lý), trong khi UMA chưa tới 0,5%.

frame_budget_60fps.js (tỷ trọng thời gian truyền trên ngân sách khung hình)
const frameBudgetMs = 1000 / 60; // ~16,6667 ms/khung hinh o 60fps
const pcieShare = (cmp.pcieTimeMs / frameBudgetMs) * 100; // ~6,22%
const umaShare = (cmp.umaTimeMs / frameBudgetMs) * 100;   // ~0,50%
// PCIe: gan 1/16 ngan sach khung hinh CHI DE sao chep du lieu
// UMA: khong dang ke - GPU con thua gan het thoi gian de TINH TOAN thuc su
⚠️ Đừng so sánh thô xung nhịp CPU/GPU mà bỏ qua băng thông bộ nhớ
Chênh lệch 12,5 lần ở trên đến HOÀN TOÀN từ tỷ lệ băng thông bộ nhớ (400 GB/s vs 32 GB/s) — KHÔNG liên quan gì đến xung nhịp (GHz) của CPU hay GPU. Một GPU xung nhịp cao nhưng bị nghẽn ở khâu truyền dữ liệu (data-starved) vẫn chạy chậm hơn hẳn tiềm năng lý thuyết — đây chính là lý do "thông số xung nhịp" một mình không đủ để so sánh hiệu năng thực tế giữa 2 kiến trúc khác nhau.

4. Thực hành: So sánh băng thông PCIe vs UMA

Đổi kích thước khung hình, số byte/pixel, và băng thông của cả 2 kênh để xem thời gian truyền thay đổi trực tiếp — thanh màu bên dưới trực quan hoá tỷ lệ chênh lệch:

🖥️ So sánh băng thông PCIe vs UMA
PCIe
UMA

Tóm lược

  • ✅ SoC tích hợp CPU/GPU/RAM lên cùng đế silicon, giảm độ trễ và năng lượng — đổi lại mất khả năng nâng cấp/thay thế linh kiện rời.
  • ✅ big.LITTLE (Firestorm/Icestorm) cân bằng hiệu năng và pin qua lập lịch tác vụ động.
  • ✅ UMA loại bỏ hoàn toàn bước sao chép CPU→GPU của mô hình PC truyền thống — CPU và GPU truy cập TRỰC TIẾP cùng một bể RAM.
  • ✅ Verified: khung hình 4K = 33.177.600 byte; PCIe Gen 4 (32GB/s) = 1,0368ms; UMA (400GB/s) = 0,0829ms — nhanh hơn đúng 12,5 lần, khớp tỷ lệ băng thông.
  • ✅ Pitfall: chênh lệch hiệu năng đến từ BĂNG THÔNG bộ nhớ, không phải xung nhịp CPU/GPU — so sánh thô xung nhịp bỏ qua yếu tố quyết định thực tế.

Trắc nghiệm ôn tập

Câu 1

UMA (Unified Memory Architecture) loại bỏ được bước nào trong luồng xử lý đồ hoạ trên PC truyền thống?

Câu 2

Verified: PCIe Gen 4 (32GB/s) mất 1,0368ms để truyền khung 4K, UMA (400GB/s) chỉ mất 0,0829ms — nhanh hơn đúng 12,5 lần. Con số 12,5 lần này đến từ đâu?

Câu 3

SoC (System on a Chip) tích hợp CPU/GPU/RAM lên cùng đế silicon đánh đổi điều gì so với PC truyền thống?

Câu 4

Vì sao "lập lịch sai lầm" (đẩy tác vụ nền lên nhân Firestorm hiệu năng cao) là một pitfall thực sự của kiến trúc big.LITTLE?

Tải file code thực hành minh họa bài học

File JavaScript CPUJS — thư viện kiến trúc máy tính mini dùng xuyên suốt cả 12 bài, Bài 9 vừa thêm frameBytes(), transferTimeSeconds(), compareTransferMethods() — mô hình dung lượng khung hình và so sánh thời gian truyền PCIe vs UMA, kèm self-test đối chiếu đúng mọi con số trong bài (chạy node cpu-core.js, không cần cài thêm gì):

Tải về cpu-core.js

📖 Tài liệu tham khảo

Bài viết liên quan trong series

Bài 8: Bộ Nhớ Ảo & Khối TLB Bài 10: Tăng Tốc Phần Cứng: GPU, NPU & AMX Quay lại Lộ trình Kiến Trúc Máy Tính