背景

這篇討論源自於 cheat.sh/latency 網站所列出的「程式設計師必知的延遲數據」。這些數據最初由 Google 工程師 Jeff Dean 提出，旨在提供開發者對於不同硬體操作（如 CPU 快取、記憶體存取、磁碟讀取與網路傳輸）所需時間的量級概念，是系統設計面試與效能優化時的經典參考資料。

社群觀點

儘管這些延遲數據在軟體工程界被視為金科玉律，但 Hacker News 的社群討論卻對該網站呈現的最新數據提出了強烈質疑。許多資深開發者指出，該網站似乎並非直接引用 Jeff Dean 的原始數據，而是基於十多年前的舊資料進行了錯誤的「線性外推」。這種做法導致目前的數據與現實硬體效能嚴重脫節，甚至被批評為「反知識」。

爭議的核心在於數據的準確性與有效位數。有網友計算發現，網站宣稱從記憶體讀取 1MB 資料僅需 741 奈秒，換算下來頻寬高達每秒 1.3 TB，這遠超目前主流 DDR5 記憶體的極限，僅有昂貴的高頻寬記憶體（HBM3e）才可能接近此數值。同樣地，關於 SSD 與傳統硬碟的讀取速度也被認為過於樂觀，例如網站列出的硬碟讀取速度竟達每秒 3GB，這實際上是 NVMe SSD 的水準，而非傳統機械硬碟所能企及。此外，數據中出現將微秒誤植為奈秒的低階錯誤，以及給出過多無意義的有效位數，都讓社群對其可信度大打折扣。

除了數據準確性的爭論，部分留言者也探討了這些指標在現代架構下的局限性。有人詢問這些數字是否涵蓋了 GPU 的記憶體頻寬，或者在 Apple M1 等 ARM 架構下會有何種差異。也有觀點認為，比起精確的數字，開發者更應該掌握的是不同操作之間的相對成本量級。例如，了解「Doherty 閾值」對於使用者體驗的重要性——即電腦與使用者的互動若能保持在 400 毫秒以內，能顯著提升生產力，因為這能確保雙方都不必處於等待狀態。儘管該網站的具體數值遭到抨擊，但社群仍肯定了這種將抽象延遲視覺化的嘗試，認為這類工具對於建立系統設計的直覺仍有其價值，前提是數據必須回歸現實。

延伸閱讀

• Interactive Latency Numbers：由 Colin Scott 維護的互動式圖表，可查看不同年份的延遲演變。
• Jeff Dean 原始簡報：2009 年於 LADIS 研討會分享的系統設計關鍵數據。
• Doherty Threshold：探討人機互動反應速度與生產力關係的 UX 原則。
• System Design Primer：GitHub 上知名的系統設計學習資源，內含更具參考價值的延遲對照表。
• Infographics: Operation Costs in CPU Clock Cycles：以 CPU 時脈週期為單位的操作成本圖表。