英特爾的安騰 (Itanium) 架構處理器是怎麼失敗的？

01-04

&> Itanium（官方中文名稱為安騰），是Intel Itanium架構（通常稱之為IA-64）的64位元處理器。Intel推出了兩個Itanium的家族：其一是Itanium，另一個是Itanium 2。在2007年11月1日，Itanium 2的家族又再一次稱為Itanium。該處理器的市場定位是在於企業伺服器與高效能運算系統。該架構由HP創始，後來則是HP與Intel共同開發。
via Itanium - 維基百科，自由的百科全書

《程序員》2013-2期《MAC OS背後的故事——向Intel遷移！（中）》說的很明白。以下是摘自其內容：

Itanium的誕生

有了Marklar團隊的成果，接下去只是何時轉換到x86架構平台的問題。但這時，Intel卻持續走低，蘋果似乎有了一個除Intel以外的選擇——AMD。

在1989年，HP認為RISC架構將來會遇到每周期只能執行一個指令的瓶頸。所以想搞一套名為EPIC的新架構。但由於HP不具備研發處理器的資本，所以在1994年拉攏Intel跟它以EPIC為基礎，合搞一套叫IA-64的處理器。

先前提到，為了使代碼高效地執行，當時Intel已經做出了超純量亂序執行的Pentium Pro架構。整個框架的原理是讀入一系列的指令，把每個指令分解成RISC分格的微指令，使用暫存器重命名等演算法來計算並移除指令的依賴關係，然後並發執行多條語句，達到一個時鐘頻率能夠執行多個指令的目的。

但HP的忽悠能力比較強，它對Intel說：「為什麼我們需要由硬體實現亂序執行呢？你們的處理器為了把x86指令解成微指令，需要一個比RISC架構複雜得多的解碼器。而為了達到亂序執行，你們設計了一整套複雜得多的邏輯去判斷執行，這是計算機在運行中所需要付出的代價！

現代的編譯器早就足夠高級了，完全能在編譯時判斷語句的依賴關係，並且自動進行暫存器命名等一系列的演算法，所以在程序編譯時就能給出一個個指令包，每個指令包包含了一系列能同時並發執行的RISC指令。

我們完全可以設計一個新指令集，稱為超長指令字架構（VLIW，Very Long Instruction Word），一個指令包中的所有指令都會轉化成一個VLIW語句。這樣，當VLIW語句通往芯處理器時，處理器就無需進行複雜的解碼（因為指令本身是 RISC風格的）、邏輯判斷（因為編譯時己判斷好了）、暫存器重命名、亂序執行演算法，只要解開一個VLIW指令讓分配器並發執行就行了。

因此，我們的編譯器就能決定讓這些小指令同時執行於單一周期，處理器能夠簡單地執行這些指令而不需要很複雜的架構去決定哪些指令能夠並行執行。」

Intel被這麼一忽悠覺得IA-64大有前途，如果搞出來，會被多數的企業系統製造業採用，所以開始下血本開發。由於1998年正值電影泰坦尼克號熱映，Intel在1999年10月4日發布該處理器的官方名稱為Itanium。

Intel 認為，Itanium將會是個終級架構，可以解決一切問題，將會是未來的發展方向。雖然指令集和x86完全不兼容，但隨著伺服器領域和將來的桌面領域從 32位遷移到64位，指令集肯定是需要做出重大改變的，利用這個機會，Intel自然可以自由採用一種新指令集和過去劃清界限。於是索性就不用開發64位的x86了，逼著大家都用Itanium就可以了。

正當Intel做著天上降下黃金雨的美夢時，它完全沒有意識到災難己經臨近。Itanium的設計看似完美無缺，但他們沒有意識到其中兩個重大的問題——指令寬度和Cache。

「短板」原理在Itanium上應驗

x86的好處是，雖然這是一個CISC的指令集，但這個指令集對程序執行的邏輯沒有額外的限制，所以只要Intel保證產生的運算結果是一致的，就可以以任何方式實現這個指令集，例如解成RISC、增加超純量模塊、調度成亂序並行執行，Intel想怎麼做都可以。

但Itanium讓編譯器決定一切，編譯器自動判別依賴關係併產生一個個指令包，每個包內的指令不存在依賴關係，所以指令集一公布，要想改就困難了。例如每個VLIW指令包是包著三個RISC指令的，如果若干年後做出了能並行執行六個指令的晶元，那它能一起執行兩個VLIW指令嗎？

醒醒吧，因為這兩個VLIW指令很可能有依賴關係！那可以重新讓處理器判斷依賴關係後再執行嗎？該吃藥了——Itanium花那麼多血本就是想讓編譯器搞定一切而不用處理器判斷！

那怎麼辦呢？只有兩個辦法：其一是一次運行三條指令（即使我的機器有能力執行六個寬度），所以程序執行效率只有一半；其二是要求每有新一代的晶元出現，所有程序都要重新編譯才能完全發揮晶元設計的理論效能。這是讓人無法忍受的一件事——難道今後軟體發布出來，要為各個指令寬度的Itanium各做一個版本嗎?

更麻煩的問題是Cache。Cache是處理器上用於減少處理器訪問記憶體所需平均時間的部件。其容量遠小於內存，但速度卻可以接近處理器的頻率。當處理器發出內存訪問請求時，會先查看Cache內是否有請求資料。如果命中，則不經訪問記憶體直接返回該資料；如果不存在，則要先把記憶體中的相應資料載入Cache，再將其返回處理器。

與前面那種情況相比，這需要更長的等待時間。至於什麼資料是在Cache內的，完全是由計算機程序運行時決定。編譯器在編譯時是無法預測程序在執行時所使用Cache的情況的——這一切完全是隨機的。對於一個可以亂序執行的處理器而言，如果某條數據的結果不在Cache里，可以動態調度，先執行別的語句，從內存里取出，再執行這條語句。

像Itanium把可以並發的程序指令捆在一個包中，如果這個包中所需要的變數還在內存里，那處理器就什麼都幹不了，只能等從內存數據搬到Cache中。所以，Itanium的執行效率不會好於亂序執行的處理器。

正當Intel一步步堅定不移地在死路上越走越遠時，Intel的競爭對手AMD卻沒閑著。

Intel不做x86架構的64位版？我們做（2003年AMD搶先於Intel發布了Athlon 64，隨後又推出了面向主流消費市場的Athlon 64 X2）！Intel不做x86架構的多核處理器？我們做（2005年4月22日，AMD領先於Intel率先發布了擁有雙核的Opteron處理器）！

跑分測試下來，AMD技術在許多方面遠勝Intel，其中尤其以浮點運快著稱。同時，AMD允許用戶選擇比Intel高的頻率來跑運算（當然用戶自己要承擔CPU高頻燒毀的風險），所以很多計算機愛好者更青睞AMD。

作者王越，美國賓夕法尼亞大學計算機系研究生，中國著名TeX開發者，非著名OpenFOAM開發者。

向前完全不兼容。
VLIW作大死。

@馮東所說並不準確，早期的 Itamium 兼容 IA-32，但是性能非常低，戰不動 x64。

而且 IA-64 是喪心病狂的 EPIC 架構，這簡直是和全世界做編譯器的作對……也難怪沒有軟體支持。

失敗的原因是不兼容 x86 32-bit 指令集。

說來也奇怪，Intel 你要搞 clean slate 64-bit 就搞唄，有什麼必要不兼容 x86 32-bit 呢？AMD 64 的 64-bit 指令集只不過和 x86 32-bit 的形似而已，本質上就是兩套指令集。

補充：

EPIC 是不是難以實現編譯器我不清楚細節，但是問題是 Intel 自己是有力量寫的，Microsoft 也是有力量寫的。既然已經有了編譯器，能不能流行就不是編譯器好不好寫的問題，而是是否支持已有軟體的問題。

兼容 IA-32 靠的是軟體模擬。如果這也算支持，那 x86 也一直能支持 PPC 了。而且更重要的，Mac 在 x86 上模擬 PPC 可是 06 年之後了。那時候硬體的性能比 Itanium 時代高出一個數量級了。

已經邀請 @破布大大回答，我覺得他是我在知乎上見過的最懂處理器的人，而且看到過他在一個帖子里批評過安騰，但是是一句帶過，希望他可以在這裡展開講講。

我在安騰的環境下工作過兩年，覺得安騰比x64的性能應該要差不少，而且獨特的EPIC架構對編譯器的要求相當高。在本世紀初的時候，還是很多公司相信安騰是未來的，不過在大家投入很多精力和時間搞安騰的編譯器優化後，發現它的性能還是不怎麼樣。x64推出後，大家發現這個性能不錯，而且編譯器實現基本可以復用原來32位那套，就紛紛倒向x64，不久連英特爾都支撐不住了，安騰算是正式失敗。

我個人猜測安騰性能不好的原因，是因為把給處理器流水線插入bubble這個工作也交給編譯器，看一下反彙編出來的程序，起碼有10%以上是nop指令吧，這些指令白白佔據cache的空間了。大概設計安騰的時候，CPU給自己插流水線bubble還是比較昂貴的操作吧，後來時移世易，cache跟不上趟成了處理器的瓶頸。不知道猜測對沒，希望有人可以指出我的錯誤。

PS:感謝評論中PP Chen的指正，基礎差，把bubble和stall搞混了，嚴重的錯誤。

因為通訊軟體以及中間件無法編譯，我們分行的核心系統遷移工作被安騰 (Itanium) 和HP Superdome2拖後整整一年，導致該年的關鍵考評指標沒有達成。同樣受影響的分行全國一共16家。然後我行就再沒什麼安騰和Superdome了。

補充一個，過於依賴編譯器優化的結果，就是debug非常困難，導致軟體一直起不來。Intel和HP算是有影響力的，一開始還能拉到一幫重量級的軟體開發公司來捧場。

非技術人員，不評論技術本身。只是突然想到，當年進外企第一份工看的某大客戶，本來已經決定下一代技術選型全部遷移到Itanium平台加競爭對手的中間件，沒想到市場接受度不高，各種受打擊，最後不得重新回到x86平台+我所在公司產品的組合，也從而將我第一份外企工作時間延長了5年，紀念一下。

沒有安騰的工業使用經驗，也沒有安騰的彙編編寫能力，只是以前看過一段時間的安騰的編程手冊，話說出來害怕丟人故匿名。

我的看法是，安騰目前雖然在市場角度是失敗品，但如果從技術角度看說是失敗品還為時過早。

首先，安騰是三個指令打一個指令包，執行的時候，是每個時鐘周期發多個指令包（我根據官方編程手冊的原話來理解的），所以只要編譯器將指令包好，處理器的實現者只要專註於提升執行單元數和每周期指令包的發射數就行。所以 @邢富的發言中間有段話我覺得不太妥當。

其次，安騰就針對存儲器載入延遲的問題已經有了預案，就是所謂的猜測執行，這也有專門的存儲器載入指令來完成，就相當於是提前從內存載入數據，或提前執行某段程序。當然這需要複雜的編譯器邏輯。

安騰最大的特點就是軟體的運行效率百分之九十九要靠編譯器，比方說，雖然提供了寄存器重命名機制，但還要有專門的指令才能使用，就拿循環來說，安騰就專門提供了一個按模調度循環機制，充分利用硬體的寄存器重命名來優化循環，問題是編譯器有沒有優化到位呢，當然我是不知道因為我沒有看過。不過我看了下 @Scott 的話，反彙編內還有10%的nop指令，我在想別說安騰的性能，至少編譯器方面的優化是不是還有一定的上升空間。

我作為用戶說說我的理解

之前做甲方的時候，我們在用HP的RP8440，用了若干年後，要換機器，銷售給我們2個選擇，一個是安騰，一個是PA的RP機器。

我們搞了一台26系列的拿出來玩玩，我安裝了安騰版的Windows，說實話一開始安裝的時候很興奮，因為windows居然能在小型機上跑，覺得世界很神奇，但安裝完之後，感覺就是個鳥用。因為安騰windows上能跑的東西很少。

當時安騰的RP機器要比PA系列的貴10%-20%，而且還不見得性能好多少，安騰支持的軟體也非常有限。安騰也能跑HPUX，但是安騰版的HPUX，上面的oracle也是安騰版的oracle，但oracle對安騰版的支持非常有限。在我們選產品之後的若干年，oracle也曾經公開場合說將來不會持續支持安騰版hpux的oracle。

從我甲方當時選型來看，主要問題就是一個：指令集兼容性帶來的軟體生態支持的問題。cpu對於整個計算機系統的標準關鍵是指令集，IA64也不能說只能跑64位的系統，32位的不支持。安騰就是這麼有想法，然後自己把自己做死了。