效能、功耗與能量

反應時間/延遲(response time / latency)

你按下一個鍵,希望字立刻出現。你點一下搜尋按鈕,然後等網頁。從你發問到得到答案之間的空檔——你實際坐在那裡等的時間——就是反應時間,也叫延遲。它是最貼近人類感受的速度量度,因為它是你會親身感覺到的那一個。當網站感覺卡頓、遊戲畫面一頓一頓時,你注意到的是反應時間,不是吞吐量。

精確地說,反應時間是一件任務從開始到結束所經過的全部牆上時鐘時間,包含一切:CPU 在做工、等記憶體、等磁碟,甚至等其他程式讓出處理器。架構師常把它分成 CPU 時間(處理器真正花在你的程式上的部分)和其餘部分(輸入輸出,以及被其他任務搶走的時間)。效能鐵律適用於那段 CPU 時間:CPU 時間 = 指令數乘以每指令週期數乘以時脈週期時間。把這三項中任何一項壓低,反應時間就跟著降。

這裡關鍵的誠實點是:反應時間和吞吐量不一樣,而且最佳化其中一個可能會惡化另一個。管線提升吞吐量(每秒幾件工作),卻不會縮短任何單一指令的延遲。一個把很多工作擠在一起以維持機器忙碌的批次系統能拿到極佳的吞吐量,但可能讓每個別使用者等更久。如果你在意的是某個答案多快備妥——一次按鍵、一個有人正盯著看的資料庫查詢——那麼反應時間才是要緊的量度,而對那一個卡在等待中的請求來說,平均吞吐量再高也只是冷冰冰的安慰。

一個網頁請求總共花 200 毫秒:5 毫秒 CPU 做工、15 毫秒從固態硬碟讀取、180 毫秒等網路。使用者感受到的反應時間是完整的 200 毫秒——即便其中 CPU 只忙了 5 毫秒。把 CPU 加速十倍,最多只能從 200 毫秒的等待裡省下 4.5 毫秒。

反應時間是整段牆上時鐘的等待。加速 CPU 只對 CPU 真正成為瓶頸的那部分時間有幫助。

反應時間和吞吐量是不同的目標,單一的「速度」數字會把兩者的差別藏起來。一條指令的延遲由它走過機器的路徑決定;管線和批次處理提升吞吐量,卻不會縮短它。

又称
latencyexecution timewall-clock time反應時間延遲執行時間