ILP 的極限（the limits of ILP）
想像把愈來愈多廚師塞進一間廚房，好更快做完一頓飯。一開始很有幫助，但很快廚師就互相絆腳，食譜的步驟仍得照順序來，而第十位廚師幾乎沒能再多貢獻什麼。ILP 的極限描述的正是單一指令流的這種報酬遞減：超過某一點後，把一顆核心做得更寬、更聰明，只能多榨出一點點平行性，代價卻急速上升。
好幾道硬牆疊在一起。真資料相依形成無法平行化的鏈——若每一步都需要前一步的結果，再多硬體也無濟於事。分支預測再好，終究會誤測並沖掉推測工作；控制相依限制了有用的往前看視窗。記憶體延遲與含糊的載入／儲存順序會以無法預測的方式造成停頓。而往更前方看的機制——更大的重排序緩衝區、更多保留站、更寬的發射、更多更名暫存器、喚醒／選擇邏輯——的複雜度大致以平方成長，所以為了多個百分之幾的效能而把視窗加倍，是一筆很糟的交易。對「理想」ILP 的研究發現，即使硬體無限，典型整數程式每週期也只能維持寥寥幾道獨立指令。
這是現代計算中最關鍵的事實之一。約莫 2000 年代中期，單核心 ILP 的增益恰好在 Dennard 微縮告終、功率牆來襲之際趨於平坦，於是把電晶體灌進一顆更寬的單核心，在效能與能耗上都不再划算。這正是業界轉向多核心——靠許多較簡單核心之間的執行緒層級平行——並在後來轉向專用加速器的原因。ILP 的極限不是一時的工程缺口；它是植根於一般程式相依結構中的一道結構性天花板。
把一顆 4 寬的亂序核心做成 8 寬，可能花掉大約兩倍的發射與排程硬體（與功耗），卻只把實際維持的 IPC 抬高一小截，因為大多數程式碼根本無法每週期提供八道獨立、就緒的指令。
過了某一點，更多寬度只換到一點 ILP、代價卻陡升——這就是逼出多核心的那道牆。
ILP 的極限關乎單一執行緒的相依結構，而非缺乏巧思。這就是為何答案是多核心（更多執行緒）、而非不斷加寬核心——也是為何天真地期待單執行緒速度持續加倍是錯的。