Vì sao có cache — và những con số độ trễ nên nhớ

TL;DR: Tốc độ CPU và tốc độ bộ nhớ đã rời nhau hàng chục năm: CPU làm vài tỉ lệnh/giây, nhưng một lần đọc RAM tốn ~100 nanosecond — tương đương hàng trăm lệnh bị bỏ phí nếu CPU ngồi chờ. Giải pháp là memory hierarchy: xếp tầng nhiều loại bộ nhớ, từ nhỏ-và-cực-nhanh (thanh ghi, cache L1) tới lớn-và-chậm (RAM, SSD, mạng). Dữ liệu hay dùng được giữ ở tầng nhanh; tầng càng xa CPU càng lớn nhưng càng chậm theo bậc. Mỗi lập trình viên nên thuộc thang độ trễ tương đối giữa các tầng — nó cho bạn ước lượng nhanh "thao tác này tốn gì" và biết bottleneck nằm ở đâu trước cả khi đo.

Bạn viết một vòng lặp O(n) đẹp đẽ nhưng nó chậm bất ngờ. Bạn thay một HashMap bằng cấu trúc "tối ưu hơn về big-O" nhưng thực tế lại chậm hơn. Lý do thường không phải số phép tính, mà là mỗi phép tính phải chờ dữ liệu từ tầng bộ nhớ nào. Một lần đọc trúng cache L1 và một lần đọc trượt xuống RAM chênh nhau cả trăm lần — và big-O không thấy điều đó.

Bài này giải thích vì sao tồn tại nhiều lớp bộ nhớ, đặt ra thang độ trễ để bạn ghi nhớ, và cho bạn cách dùng nó để ước lượng hiệu năng.

1. Analogy — bàn làm việc, ngăn kéo, kho lưu trữ

Hình dung bạn đang làm một dự án giấy tờ:

• Vài tờ đang cầm trên tay — lấy tức thì (thanh ghi).
• Tập hồ sơ trên mặt bàn — với tay là tới (cache L1/L2).
• Tài liệu trong ngăn kéo bàn — mở ngăn, mất vài giây (cache L3).
• Hồ sơ trong tủ tài liệu cuối phòng — đứng dậy đi lấy (RAM).
• Thùng lưu trữ dưới tầng hầm — đi thang máy xuống (SSD).
• Tài liệu phải xin từ chi nhánh thành phố khác — gửi yêu cầu, chờ chuyển (mạng).

Bạn không để mọi thứ trên tay (không đủ chỗ) và không để mọi thứ dưới hầm (quá chậm). Bạn giữ thứ đang dùng gần nhất, đẩy thứ ít dùng ra xa. CPU làm y hệt với dữ liệu.

2. Cơ chế — vì sao không làm RAM nhanh bằng cache?

Câu hỏi tự nhiên: nếu cache nhanh thế, sao không làm toàn bộ RAM bằng vật liệu cache? Hai lý do vật lý và kinh tế:

• Công nghệ khác nhau. Cache dùng SRAM (6 transistor/bit, nhanh, không cần refresh nhưng đắt và tốn diện tích). RAM dùng DRAM (1 transistor + 1 tụ/bit, rẻ và đặc, nhưng chậm hơn và phải refresh liên tục). Làm 16 GB toàn SRAM sẽ cực kỳ đắt và to.
• Tốc độ ánh sáng và khoảng cách. Tín hiệu điện đi trong dây với tốc độ hữu hạn. Cache L1 nằm ngay trong nhân CPU, cách ALU vài milimet; RAM nằm trên thanh cách CPU vài centimet. Khoảng cách đó, nhân với số lần truy cập, tạo độ trễ thật.

Đây là dãy tầng điển hình trên một CPU desktop hiện đại, từ gần CPU ra xa:

→

→

→

→

Khi CPU cần một dữ liệu, nó hỏi tầng gần nhất trước (L1). Trúng (hit) → trả về ngay. Trượt (miss) → hỏi xuống L2, L3, rồi RAM, dừng ở tầng nào có dữ liệu. Mỗi lần trượt xuống một tầng cộng thêm độ trễ của tầng đó.

flowchart TD
  CPU["CPU"] --> L1{"L1 hit?"}
  L1 -->|hit ~1ns| DONE["Tra ve du lieu"]
  L1 -->|miss| L2{"L2 hit?"}
  L2 -->|hit ~4ns| DONE
  L2 -->|miss| L3{"L3 hit?"}
  L3 -->|hit ~12ns| DONE
  L3 -->|miss| RAM["RAM ~100ns"]
  RAM --> DONE

3. Thang độ trễ nên nhớ

Đây là phiên bản gọn của "latency numbers every programmer should know" (Jeff Dean), làm tròn cho dễ nhớ. Con số tuyệt đối thay đổi theo phần cứng — điều quan trọng là tỉ lệ giữa các tầng.

Một phép so sánh trực giác (thu nhỏ về "thời gian con người"): nếu một lần truy cập L1 mất 1 giây, thì đọc RAM mất gần 2 phút, đọc SSD mất gần 4 tiếng rưỡi, và một round trip mạng qua lục địa mất gần 5 năm.

4. Áp dụng vào code của bạn

Thang độ trễ là công cụ ước lượng. Vài cách dùng nó hằng ngày:

Ước lượng "back-of-envelope" trước khi tối ưu. Một vòng lặp duyệt 1 triệu phần tử, mỗi phần tử buộc một lần đọc RAM (~100 ns) → tối thiểu ~100 ms chỉ riêng chờ bộ nhớ. Nếu giữ được trong cache (~1–10 ns/phần tử) → ~1–10 ms. Con số này cho bạn biết "có đáng tối ưu locality không" trước khi viết một dòng benchmark.

Nhận ra ranh giới tầng là nơi hiệu năng nhảy bậc. Khi dữ liệu vượt kích thước một tầng cache, độ trễ trung bình tăng vọt. Đây là lý do một thuật toán "đột nhiên chậm" khi n vượt một ngưỡng — bạn vừa tràn khỏi L2 hoặc L3:

Kich thuoc du lieu nho hon L1 (~32KB)   -> moi truy cap ~1ns
Vuot L1 nhung trong L2 (~256KB-1MB)     -> ~4ns
Vuot L3 (~8-32MB)                        -> ~100ns (xuong RAM)

Thiết kế để giảm lần "đi xa". Mỗi cú nhảy xuống tầng chậm là một cơ hội tối ưu: gộp nhiều request mạng thành một (giảm round trip), đọc tuần tự từ đĩa thay vì ngẫu nhiên, giữ dữ liệu nóng trong RAM thay vì query DB lặp lại. Cùng một nguyên lý ở mọi tầng: đừng đi xa nếu có thể lấy gần.

Đừng tối ưu tầng sai. Nếu bottleneck là một round trip mạng 150 ms, tối ưu cache L1 (tiết kiệm vài ns) là vô nghĩa. Thang độ trễ giúp bạn nhắm đúng tầng đắt nhất trong đường đi nóng (hot path) — quy tắc này sẽ trở lại ở capstone và ở Course 4 (I/O).

5. Đào sâu (tuỳ chọn)

6. Liên hệ các bài khác

• Bài 02 — Cache line và locality: cơ chế cache lấy dữ liệu theo khối 64 byte và vì sao locality biến độ trễ RAM thành độ trễ cache.
• Bài 03 — Viết code cache-friendly: dùng thang độ trễ này để biện minh cho việc duyệt tuần tự và tăng locality.
• Course 1 — Đừng đoán, hãy đo: phương pháp đo lường hiệu năng — dùng nó để kiểm chứng mọi giả thuyết về tầng bộ nhớ trong module này thay vì đoán.

7. Tóm tắt

• CPU nhanh hơn RAM hàng trăm lần; nếu chờ RAM cho mỗi truy cập, CPU sẽ nghỉ phần lớn thời gian.
• Memory hierarchy xếp tầng bộ nhớ: gần CPU thì nhỏ-nhanh-đắt (thanh ghi, L1), xa CPU thì lớn-chậm-rẻ (RAM, SSD, mạng).
• Không làm toàn bộ RAM bằng cache được vì SRAM đắt và to, và vì tốc độ tín hiệu giới hạn bởi khoảng cách vật lý.
• Thang độ trễ nên nhớ (tương đối với L1): L2 ~4×, L3 ~12×, RAM ~100×, SSD ~16.000×, mạng qua lục địa ~150 triệu×.
• Big-O đếm số thao tác nhưng bỏ qua tầng bộ nhớ; một thuật toán "tốt hơn trên giấy" có thể thua nếu nó trượt cache nhiều.
• Dùng thang này để ước lượng nhanh, nhận ra ranh giới tầng (nơi hiệu năng nhảy bậc), và nhắm đúng tầng đắt nhất trong hot path.

8. Tự kiểm tra

Bài tiếp theo: Cache line và locality