為什麼IA-64指令集架構失敗了？

01-06

按照我的理解，OS只要能夠支持IA-64就可以了，其他64位軟體就都可以使用了。
但是為什麼Intel的IA-64失敗了，被迫回到了x86-64架構？

按照我的理解，OS只要能夠支持IA-64就可以了，其他64位軟體就都可以使用了

這個理解是錯誤的。

因為64位OS里有大量的32位軟體運行。

以WIN7為例，WIN7里有大量的32位軟體在運行，比如QQ，比如老版的Office，比如各種老遊戲（紅警、魔獸）等等。

所以x86-64的最大優勢是能在64位環境里直接運行32位程序——也就是兼容性好。

但是IA-64做不到這一點，如果一個32位軟體非要在IA-64環境里運行，唯一的選擇就是重新編譯。

比如，如果用戶要裝一個QQ，就要精心挑選匹配IA-64的版本，如果不小心下載了一個32位的，那麼這個軟體根本無法運行，這樣的用戶體驗是很糟糕的。

現在裝應用軟體會仔細區分32位或者64位嗎？一般不會，這就是x86-64的優勢。

並且，有些軟體公司已經倒閉了，根本不會給用戶提供IA-64的版本，這樣的軟體用戶根本沒辦法在IA-64上用，所以就算有人搞出IA-64的操作系統，這種操作系統對於普通用戶來說使用起來太難了。

後來Intel為了改進這一點，搞出一個x86-to-IA-64的解碼器，但效率極低，這樣的效率用戶也是無法接受的。

所以最終微軟選擇了x86-64，因為它能保證大部分應用軟體的兼容性。

最後補充點歷史資料，這種不兼容的事情在當年從16位擴展到32位的時候就發生過一次。

早年的時候，8086 CPU是一款純16位CPU，當時的計算機從操作系統到硬體都是16位的，後來Intel搞出個80286，裡面開始支持32位，但是80286架構有一個很大的問題，一旦切換到32位環境里，就無法再運行16位程序了（或者說運行起來很麻煩），這樣的兼容性是用戶無法接受的。直到後來Intel推出80386，在80386架構里加入了虛擬8086模式，才算比較徹底的解決了兼容性的問題——歷史總是在不停的重演。

如果有人記得OS/2這個操作系統的話就會知道，OS/2是最早在80286上運行的32位系統，但是它出現的時代太倒霉了，80286不兼容8086，也就是不兼容DOS程序，這樣的後果也影響了後來OS/2的發展。而Windows3.X開始大量發售的時候，已經趕上了80386的好時代，再也沒有兼容性的問題了。

所以兼容性是一個很重要的東西。

因為x86已經長成了一頭巨獸，Intel自己都馴服不了，任何推翻向後兼容的決定都是作死。

VLIW也是一個重要原因，然而就算是沒用VLIW，只要不兼容x86，IA-64就是死路一條。

大規模轉換不兼容的指令集的結果基本都是杯具。

微軟想在ARM上試試Windows，WinRT慘死（雖然不完全是指令集的問題）。最近再次嘗試用高通CPU跑的時候，實際是在用ARM模擬x86。

Intel想擠進ARM為主的移動市場，x86手機一直半死不活。

唯一一個比較大的成功案例是蘋果由Power PC轉到x86。因為蘋果用了一個無縫遷移的特殊技術：Universal Binary。一個可執行文件中，不同指令集的代碼各有一份，在哪個平台上跑就執行哪一份，而這個功能還是OS X設計時預留下來的。

因為存在很多現有軟體並不完全支持ia64，比較大部分銀行的系統，舊式伺服器上的資料庫系統，某些軍用系統。企業的主要目的是盈利，推動科技發展只是盈利過程中的副作用。intel的主要盈利之一是在於眾多企業寵大的data center。

再者，需要操作系統與軟體的多方面支持，完全獨立使用ia64，眾多公司不願負擔。比如說，你90年代初開了一家公司，架設了server farm，花了不少錢讓軟體工程師把系統服務什麼的做好，過了這麼多年，硬體各種老化了，你開始更新server farm的硬體，這時你有兩種產品選擇：1，只支持ia64的硬體，你除了更新所有硬體，還要請一組工程師，更新代碼，更新編譯版本，更新操作系統，還要測試，保證所有原有程序都能正常運行。2，x86-64，更新操作系統，大部分程序如常運行，維護和更新相對方案1簡單。單純從支出和影響來說，你怎麼選擇。

再比如，intel又出了新isa，但是新cpu只支持該isa，你只是一般家庭用戶，你在steam 上買的東西都不能玩了，身為用戶，你買嗎？為了新硬體，遊戲公司要為以前開發的遊戲作出修改，別人總不能無償做吧？修好的補丁每個賣5美元吧，快來買，網上會一群罵遊戲公司掙黑心錢。大公司若不收費提供更新，那獨立工作室的壓力就會非常大了，很多公司變成某知名碧那樣，賣bug送遊戲。

就比如電子支付完全釆代現金那樣，在大城市，基礎設備跟上時，可行，但是出了大城市，出了中國，就很難行了，所以有現在，現金與電子支付共存的時間，題主所說的，在將來是可行的，當大部分軟體應用都運行於64位時，僅支持64位isa的處理器會更高效。

intel為了扔掉x86指令集兼容性的包袱，所以開發了IA64架構，這個架構最大的特點就是超長指令字（VLIW架構）。該架構可以將並行執行的多條指令打包成一條超長指令，依靠編譯器進行調度，這樣做的目的是為了避免浪費大量的晶元面積去判斷究竟哪些指令可以並行。但是帶來的一個問題是指令長度大大增加，因為指令位置在那裡（可以同時打包三條指令），指令長度固定為128bit，如果沒有足夠的獨立的指令填充的話，就會浪費指令位置，這導致編出來的代碼長度增加。更大的問題其實是兼容性，對x86進行擴展，足以實現IA64新增加的大部分功能，但是使用IA64架構，原有的程序就得重新編譯了。而且很明顯，IA64架構的性能很依賴編譯器，如果不能有優化能力強的編譯器，軟體的性能未必就能在新架構中有所提高，甚至有可能下降。結果intel本來想拋棄兼容性的包袱，沒想到拋棄了自己成功的基礎。

(高性能低功耗)的晶元!= 商業上成功的晶元

說實話，要是安騰能成功，龍芯也好，Windows RT也好，都應該能成功了。

引用自《程序員》2013-2期《MAC OS背後的故事——向Intel遷移！（中）》：

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開發者。

---------------------------------------------------------------------------------------------------------------------

很多人高估了指令集對於功耗、架構的影響——其實引入微結構之後，不管前端有什麼指令集都會被後端翻譯為類似RISC指令的微指令。而真正影響性能的是後端的亂序指令窗口長度、Cache的load-to-use周期、分支預測準確率這些——而運算部件經常因為數據沒準備好導致流水線停頓，而如果是分支預測錯誤，所有預測錯誤時猜測執行的指令都得打回重算。

安騰的設計思路軟硬結合，在編譯層面減少指令依賴性並縮減分支預測相關的部件。事實上，這個思路確實是很漂亮的，現代的通用處理器的絕大部分功耗都消耗在Cache和分支預測器上了，編譯器完全可以在上萬條指令的數量級上調度依賴關係——skylake的亂序指令窗口才224個。

就如前幾個回答所說的，安騰死於不兼容，類似於Windows RT 。商業軟體哪來那麼多源碼給你？程序不少都是二進位發布的，甚至有的廠商都倒閉了，沒軟體的CPU跑什麼程序？況且安騰本身每一代都不是平滑升級的，誰有空給你挨個平台開發程序，那不都是錢堆出來的？然後用戶又少，軟體也賣不出去幾套，又拉高了開發成本。

其次，說是軟硬結合，就安騰本身的編譯器也沒強到哪去，當然這受限於歷史的□□（2001年7月）。我開過腦洞，要是從一開始，幾乎所有的軟體發布都使用類似LLVM IR這種中間碼是不是安騰就成功了？反正歷史沒有如果，真正的結果就是：受限於兼容性，安騰的優點體現不出來；為了兼容老程序的性能需求，分支預測器又不能砍，然後性能沒提升多少（有時還降低了）功耗卻居高不下。

當初給我們上課的老師就吐槽：整套x86指令集不正交（為龍芯準備二進位翻譯x86的工作感想），相對的，安騰的設計思路很不錯，就是現實太骨感。其實，安騰真正適合的應用方嚮應該是全新的，沒有歷史包袱的平台。你看下面的效果就很好：

如何看待 19 歲少年想做出在目前 Intel 同等計算性能下降低 80% 功耗的全新電路系統晶元？

這個ISA使用VLIW 架構，並且讓軟體和程序員分擔硬體的負荷（這貨連Cache和分支預測器都砍了，能不省電嗎？），然後由於是超算，乾脆不用虛擬內存地址了——反正超算也不怎麼用多任務。這其實和Itanium頗有異曲同工的感覺。

兼容性是一方面問題，安騰本身問題也非常多。指令複雜，編譯器非常難寫，CPU也巨多bug，12年的時候，安騰都過氣很久了，超線程還有bug不能開。最後，EPIC架構並沒有真正實現其高性能的目標，性能上完敗x64。

PS:很久沒有搞安騰忘記了，那個不叫VLIW，叫EPIC。

太早了。在IA-64那會兒，正好是Windows的全盛期和UNIX的低谷期，整個商業軟體市場需要的是能跑兼容的二進位執行文件的硬體系統，所以商業上很難成功。龍芯一開始也是遇到這個麻煩

現在，商業軟體回歸到客戶端/伺服器架構了（或稱雲架構），二進位兼容已經無所謂了。現在的趨勢是伺服器端能跑源代碼就行（只要客戶代碼不要耦合到特定平台上就行，這不是難事），所以IA-64的後繼者和其他架構還是有大把的機會，但是品牌名得換一個全新的

因為x86以及x86-64已經深入人心，兼容性太好了

兩個主要問題：

IA64沒有提供32位X86的兼容。想想看32位的操作系統和程序後來依然在市場上持續了多長時間，就知道這問題有多重要。
IA64使用了VLIW架構，每個指令裡面的（好像是）四個子指令允許完全亂序執行。這等於把一些原來CPU乾的優化事情完全推給了編譯器，極大增加了編譯器開發的難度。

居然沒人說x86-64架構是AMD首先提出的？（專利權也屬於AMD）

Windows XP 64bit率先支持x86-64架構，Intel失了先機，最終放棄了IA-64架構，取得了AMD的專利授權後改了一個名字叫EM64T。

為什麼微軟這麼不仗義？Wintel聯盟還玩不玩了？原因是Intel遲遲沒有推出能與x86-64相似的向後兼容的架構，微軟等不下去了，轉而支持x86-64了。

據說VLIW的指令很難debug。

IA-64不兼容X86其實不是致命缺點，因為HP和Intel合作，首先考慮替代的是HP以前高端伺服器的CPU。這東西只要夠好，完全可以在伺服器領域打開市場。企業伺服器市場軟體種類不像消費者市場那麼多元，更新維護一般都有專業團隊負責，架構的遷移不是那麼困難。

但要是很難debug麻煩了，這會影響各大軟體廠商的積極性。沒有軟體配合，這晶元遲早都要完蛋。

不兼容現有32位程序