Clock và IPC — vì sao GHz cao không có nghĩa nhanh hơn

TL;DR: Tốc độ CPU thực sự do hai yếu tố chi phối: clock speed (bao nhiêu chu kỳ mỗi giây) và IPC (bao nhiêu lệnh hoàn thành mỗi chu kỳ). Nhân hai con số đó mới ra throughput lệnh thực tế. CPU 3 GHz với IPC = 4 nhanh gấp đôi so với CPU 3 GHz khác chỉ có IPC = 2, dù cùng nhãn dán GHz. Hai khái niệm nền tảng cần tách bạch: throughput (tổng công việc hoàn thành / thời gian) và latency (thời gian một tác vụ đơn từ đầu đến cuối). Tối ưu đúng mục tiêu nghĩa là biết bạn đang tối ưu cái nào.

Bạn đang chọn máy tính mới cho server. Catalog ghi hai chip: chip A 3,2 GHz, chip B 3,2 GHz. Giá chip B đắt hơn 40%. Nhà cung cấp giải thích "chip B nhanh hơn gấp đôi khi chạy workload thực tế". Làm sao cùng 3,2 GHz mà nhanh gấp đôi được?

Bài này giải thích cơ chế đằng sau con số GHz — clock speed, chu kỳ, IPC, và tại sao đo tốc độ CPU bằng GHz đơn thuần là một phép so sánh sai từ gốc.

1. Analogy — nhịp trống chèo thuyền

Hãy hình dung một đội thuyền rồng thi đấu. Người giữ nhịp gõ trống: mỗi tiếng trống là một chu kỳ. Số tiếng trống mỗi giây là "clock speed" của đội. Nhưng tốc độ thuyền không chỉ phụ thuộc nhịp trống — nó còn phụ thuộc mỗi nhịp trống, bao nhiêu mái chèo đập xuống nước cùng lúc. Đội A và đội B cùng nhịp trống 80 lần/phút, nhưng đội A có 20 tay chèo mỗi lần đập, đội B chỉ có 10 — đội A nhanh gấp đôi.

CPU cũng vậy: clock speed là nhịp trống, IPC là số mái chèo mỗi nhịp.

2. Clock speed và IPC quyết định hiệu năng như thế nào?

Clock speed (tần số đồng hồ) đo bằng Hz — số chu kỳ hoàn thành trong một giây. 1 GHz = 1 tỷ chu kỳ/giây. CPU hiện đại chạy 3–5 GHz, nghĩa là 3–5 tỷ chu kỳ mỗi giây.

Mỗi lệnh máy tính cần một số chu kỳ để hoàn thành. Số chu kỳ trung bình mỗi lệnh gọi là CPI (cycles per instruction — chu kỳ mỗi lệnh). IPC là nghịch đảo: IPC = 1 / CPI, hoặc hiểu đơn giản là số lệnh trung bình hoàn thành trong một chu kỳ.

Công thức thời gian thực thi chương trình:

Thoi gian = (So lenh) x CPI / Tan so
          = So lenh / (IPC x Tan so)

Ví dụ cụ thể: cùng một chương trình có 3 tỷ lệnh.

Chip B và Chip A cùng 3 GHz nhưng chip B nhanh gấp đôi vì IPC cao gấp đôi. Chip C tần số cao hơn 33% nhưng vẫn chậm hơn chip B vì IPC thấp hơn.

2.1 IPC đến từ đâu?

IPC là kết quả của kiến trúc vi xử lý — thiết kế bên trong chip:

• Superscalar execution: CPU có nhiều đơn vị thực thi song song, có thể bắt đầu nhiều lệnh cùng một chu kỳ. CPU 4-wide superscalar lý tưởng có IPC tối đa bằng 4. Chi tiết cơ chế này sẽ được khám phá ở bài 05 — Out-of-order và SIMD.
• Pipeline sâu hay nông: pipeline dài hơn cho phép tần số cao hơn nhưng mỗi lệnh mất nhiều chu kỳ hơn khi có hazard. Xem bài 02 — Pipeline và hazard.
• Cache hit rate: lệnh chờ dữ liệu từ RAM mất hàng trăm chu kỳ — CPU ngừng làm việc, IPC hiệu dụng tụt thảm. Chủ đề cache sẽ được đào sâu ở Course 2 (Bộ nhớ).
• Branch prediction: dự đoán nhánh sai buộc flush pipeline, lãng phí chu kỳ. Xem bài 03 — Branch prediction.

Đây là lý do hai CPU cùng GHz nhưng IPC có thể khác nhau hoàn toàn khi kiến trúc khác nhau.

3. Throughput và latency khác nhau như thế nào — và tại sao quan trọng?

Đây là một cặp khái niệm thường bị nhầm lẫn nhưng cực kỳ quan trọng khi tối ưu.

Throughput là tổng lượng công việc hoàn thành trong một đơn vị thời gian. Đơn vị: lệnh/giây, requests/giây, bytes/giây, v.v. Nếu server xử lý được 10.000 request/giây, đó là throughput.

Latency là thời gian một tác vụ đơn lẻ từ lúc bắt đầu đến lúc hoàn thành. Đơn vị: milliseconds, microseconds, nanoseconds. Nếu một request mất 5 ms từ khi gửi đến khi nhận phản hồi, đó là latency của request đó.

flowchart LR
  subgraph Throughput
    A["request 1"] --> P["CPU"]
    B["request 2"] --> P
    C["request 3"] --> P
    P --> D["10000 req/s"]
  end
  subgraph Latency
    E["1 request"] -->|"5 ms"| F["response"]
  end

Tăng throughput và giảm latency thường không phải cùng một hướng tối ưu:

• Batch job (render video, machine learning training, nén file): mục tiêu là throughput — cần hoàn thành tổng lượng công việc nhanh nhất, latency của từng chunk không quan trọng.
• Request tương tác (API endpoint, database query từ UI người dùng): mục tiêu là latency — người dùng cảm nhận thời gian chờ, không quan tâm server xử lý được bao nhiêu request song song.
• Streaming real-time (game, video call): cần cả hai — latency thấp để không giật, throughput đủ để không drop frame.

Ví dụ: tăng batch size trong một pipeline xử lý ảnh có thể tăng throughput (GPU làm việc hiệu quả hơn) nhưng tăng latency mỗi ảnh (phải chờ cả batch đủ mới bắt đầu xử lý). Đúng hay sai phụ thuộc mục tiêu của bạn.

4. Đào sâu (tuỳ chọn) — vì sao GHz ngừng tăng mạnh sau 2005

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

Đừng chọn máy hay benchmark bằng GHz đơn thuần. Hai CPU cùng 3,5 GHz nhưng kiến trúc khác nhau (IPC, cache size, số nhân) có thể cho hiệu năng thực tế chênh lệch hai đến ba lần trên cùng workload. Cách đúng là đo bằng workload thật — chủ đề của bài 04 — Đừng đoán, hãy đo.

Hiểu throughput vs latency để chọn đúng mục tiêu tối ưu. Trước khi tối ưu, tự hỏi: mình đang cần giảm latency hay tăng throughput?

• Batch job xử lý file lớn, ML training, data pipeline → tối ưu throughput: vectorize, batch lớn hơn, tận dụng đa nhân.
• API endpoint, query từ dashboard người dùng, game loop → tối ưu latency: tránh blocking, cache kết quả, giảm số lệnh trên critical path.
• Tối ưu nhầm hướng sẽ cải thiện con số benchmark nhưng không cải thiện trải nghiệm thực tế.

Đừng assume "CPU nhanh hơn" giải quyết vấn đề của bạn. Nếu bottleneck là I/O (đọc disk, chờ network), CPU nhanh hơn không giúp được gì. Profiling để tìm đúng nút thắt cổ chai mới là bước đầu tiên — không phải nâng cấp phần cứng.

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

• Bài 02 — Pipeline và hazard: pipeline quyết định IPC thực tế đạt được — số tầng pipeline và hazard xảy ra bao nhiêu lần trực tiếp kéo IPC lên hoặc xuống.
• Bài 03 — Branch prediction: đoán nhánh sai làm flush toàn bộ pipeline, lãng phí nhiều chu kỳ và tụt IPC — đây là một trong những nguyên nhân lớn nhất khiến IPC hiệu dụng thấp hơn IPC lý thuyết.
• Bài 04 — Đừng đoán, hãy đo: cách đo IPC thực tế bằng profiler (perf, VTune) thay vì ước lượng từ spec — bài này nối thẳng từ lý thuyết throughput sang thực hành đo lường.

7. Tóm tắt

• Clock speed (GHz) đo số chu kỳ mỗi giây — là nhịp trống, không phải tốc độ thực sự.
• IPC (instructions per cycle) đo số lệnh hoàn thành mỗi chu kỳ — phụ thuộc kiến trúc vi xử lý.
• Throughput lệnh thực tế = IPC × tần số — cần cả hai con số để so sánh đúng.
• Hai CPU cùng GHz có thể khác nhau hoàn toàn về hiệu năng nếu IPC, cache, hoặc kiến trúc pipeline khác nhau.
• Throughput là công việc hoàn thành / thời gian; latency là thời gian một tác vụ đơn — hai mục tiêu tối ưu khác nhau.
• Sau 2004, tần số CPU gần như chạm trần vì power wall — ngành chuyển sang đa nhân và IPC cao hơn.
• Turbo Boost tăng tần số ngắn hạn nhưng bị thermal throttling kéo xuống khi nhiệt tích tụ.

8. Tự kiểm tra

Bài tiếp theo: Pipeline và hazard