不要假設所有（有人用的）軟體都還能更新。

對於是「IBM PC 兼容機」（雖然現在沒有 CSM 的 UEFI 機器已經不能算了……）這種開放式、標準化平台，它的特點就是有非常長的軟體長尾（long tail），這裡面搞不好就有哪個哪個公司的關鍵業務在裡面。

先別考慮性能有多大提升，還是先考慮如何拋棄歷史包袱、老舊指令集吧。

看看這個回答下的評論區，不多，600條不到。

木頭龍：都2020年了，為什麼還有人會無腦吹win7比win10好用？?

www.zhihu.com圖標

大家對幾乎完全兼容的Win10尚且如此抗拒，微軟幾個公認比較失敗的版本如Win ME/2K/Vista/8就更不用說了。

所以這些年來web base應用那麼流行，很大一個原因就是軟體開發商對於這種「用戶提交了bug，我改了但用戶死活不願意更新到新版本」現象累覺不愛——只要我更新了服務端，你有本事繼續用舊版的web頁面啊。

其實拋棄老指令集不一定能直接帶來性能提升。

老指令集的一個問題是佔一些硬體空間，如果能省下這個空間，拿來堆核、堆規模、降成本都是好事，但這些算是間接幫助了。

不過老指令解碼也沒占很誇張的面積，帶來的改善可能比較有限。真要說改善比較顯著的，可能是省去x87計算單元、省去16位模式這種。

我覺得老指令的更大問題是設計思路的問題。

比如，x86的一個優勢（同時也是劣勢）是變長，即理論上可以把頻繁使用的指令用較短的長度去表示，算是一種壓縮。但這麼多年下來，當年塞在短編碼里的指令可能已經不再常用了，但兼容性需求導致它們一致占著位置……

更麻煩的是，「沒有限制」的變長意味著，一條指令不但可能跨緩存行，其長度還可能是奇數，這對於「崇尚2次冪對齊」的計算機世界可不是什麼好消息。

如果能對長度多做些限制，那取指、解碼部分的複雜度或許也能下降不少。而且在一些硬體架構上，DSB等單元也對指令對齊有一些隱性的要求，不對齊的話是會有性能損失的。

（但是插了NOP的話，NOP也要解碼的哦，而且這還浪費了I-Cache，甚至可能會浪費uop cache？雖然很多人都說uop已經抹平了指令集的差異，但真要細究的話，還是埋下了不少坑的。）

https://llvm.org/devmtg/2016-11/Slides/Ansari-Code-Alignment.pdf?

llvm.org

Code alignment issues.?

easyperf.net圖標

看蘋果的表演，當Apple Silicon A14Z版的iMac上市了，親自買來測試一輪，就知道能有多大提升了。

雖然無法實現1:1的Windows環境，但是可以實現1:1的macOS環境啊。可以測試跑分軟體，xcode，C編譯器，Python應該可是能互相交叉跨系統運行。

這樣新舊iMac的理論標準演算法例如SuperPI，SPEC2006/2017，LightGBM跑個ImageNet基準等等和通用應用程序性能跑分對比出來，我們就可以知道完全拋棄舊指令集包袱，能獲得多大的提升了。

不會有多少提升。

指令集只是表層，處理器內部是翻譯成微代碼執行的，性能與表層指令集沒有直接聯繫，與CPU的設計本身關係更大。

一個指令集是否強勁，歸根結底不是看指令集本身，而是看是否有人有錢有研發。arm指令集原本也表現平平，乘著智能手機的快車發展了起來，投入了大量的研發資源，多研發多迭代了幾輪架構設計，就厲害起來了。x86體系也同樣是靠pc行業的龐大出貨量龐大的利潤，被推動研發完善。

其他指令集事實上與x86跟arm也並沒有本質上的優劣，但如果缺乏生態，缺乏大量的生產生活中的實踐，缺乏足夠的利益驅使大量的研發圍繞它們進行，那就很難發展起來。

不同指令集的差異其實很微弱，沒有大到比研發投入程度更重的地步。arm跟x86兩個體系的研發投入，在可以預見的將來，都很難被其他指令集超過。

跨界比喻一下就是：Java語言有如此成熟性能的虛擬機，並非因為Java語言本身很優秀，而是因為有大量的人力財力被投入到研發它的虛擬機上。不同語言本身的差異自然有，但沒有大到能比研發投入比重更大的地步。

x86 指令集對性能最大的制約在於變長，後端再怎麼加寬，前端也很難保持一個周期解碼四五條指令的吞吐率。直到現在 Intel 和 AMD 也還是最多一個周期里能從指令緩存里讀 16 個位元組（AMD 在 K10 年代曾經通過在指令緩存里對指令長度預解碼使得一個周期可以讀取 32 位元組，但後來放棄了；可能是因為對功耗和緩存時延的負面影響）。這個特質是 x86 從娘胎裡帶出來的，不是拋棄幾條老指令能改變得了的。

如果微軟和Intel、AMD可以拋棄自己固有的歷史遺留包袱，二者都可以獲得明顯的提升，但是具體提升多少是沒辦法衡量的。拋棄對過往歷史產品的兼容，意味著在新設計時約束更少，可以更自由的發揮性能。

但目前看來Windows和X86拋棄對歷史兼容的難度很大。不像蘋果自己圈了一個生態，Windows和X86陣營比較開放，雖說微軟和英特爾是這個生態的主導者，但不能和蘋果一樣的做到幾乎完全的控制，很難約束軟體開發商去更新老軟體，去適配新的平台。

單純從技術難度上，X86拋棄對過往指令集的兼容比較簡單。X86指令集的複雜度遠比一個操作系統小很多，總的指令集數量沒多少條，可以/需要被拋棄的老舊指令集一般都有新版的指令集對應，很容易可以轉換過去。無論是操作系統提供一個轉換層，亦或是硬體內置一個轉換層，都比較容易實現。不過X86處理器內部執行的指令也並不是X86指令，指令會被解碼成其他內部指令，拋棄老舊指令集兼容的提升可能不會很大，節省的比較有限。

Windows這邊拋棄歷史兼容就比較困難了，這不僅僅是開發者支持與否的問題。如果只是考慮對於特殊場景歷史應用的兼容性，其實同時維護一個新版Windows和老版Windows就好，就像始終更新一個Windows XP，和一個Windows 10一樣。但實際沒那麼簡單，操作系統可以說是最複雜的一種工程，Windows代碼內部本身就堆積著各種年代、各種版本的代碼，自身的歷史包袱反而更難解決。

Apple MacBook Pro 13.3 新款八核M1晶元 8G 256G SSD京東￥ 9999.00去購買?

Apple iPad Pro 11英寸平板電腦 2020年新款(128G WLAN京東￥ 6229.00去購買?

可以有提升，但要小心各種bug。

現在x86的指令集已經數千條（數在5以上），導致IA兩家的核心內部有相當一部分是為了之前指令集的向下兼容。假使摒棄這些指令集，IA兩家可以堆出更多核更大的規模。

但是，如果隨意放棄一些指令集，往往意味著不少依賴這些指令集開發的軟體將出現各種bug。至於重新開發，拜託，有些軟體的開發者都不在了（字面意思），早已成為絕唱。實際上即使虛擬機運行也要考慮指令集問題，這也就是ps2一類的專用遊戲設備雖然絕對性能很差，但由於其CPU和現有的x86指令集不同，軟體模擬需要消耗大量的硬體的資源（ps2級別的模擬也是近幾年（不早於2017年）才搞定）。

其實之前intel也嘗試過摒棄x86指令集推到重來，那就是安騰CPU，可結果嘛，在2018年那玩意已經徹底停產，安騰CPU的架構IA-64也徹底進入了教科書和回收站。

因而，X86成也兼容敗也兼容，現在龐大的指令集既是x86的基石，也是x86的包袱。

至於蘋果為何能多次改弦更張，這是因為蘋果對生態鏈的掌控和mac下軟體數目和其他家不是一個數量級，自然蘋果可以從powerpc跳到x86再跳到arm（之前還從摩托羅拉68000跳到powerpc）。

就WinRT那遍地的非同步操作，拋棄Win32的"歷史包袱"搞不好性能還會往下掉

Project Reunion的Issue一堆人在控訴WinRT沒有同步的文件API

據說如今寫UWP的最佳實踐是扔掉UWP然後用Win32+XAML island/WinUI 3

不然你都解釋不了為什麼 .NET 5 到現在都不支持UWP

從cpu層面可能不會有太大變化

從系統層面，按照ms的能力，win的穩定性和效率要起飛

這種觀點是有問題的。

處理器的性能來源於什麼，本質上是處理器的ILP能力，X86處理器的ILP也就是內部的亂序執行能力，全都是建立在微指令的基礎上的，這種微指令對於用戶，操作系統，軟體都是不可見的，亂序執行能力的強弱，取決於亂序執行資源的多少，以及微指令的執行效率。例如硬體和微指令設計配合下，使微指令都是單周期指令。或者是革新某些硬體，允許某些微指令進行微融合等。

發展這麼多年，X86處理器的指令集更像是一種軟體開發的API，對於大型的軟體系統而言，它所依賴的API介面最好是維持向前兼容，以避免經常重寫大量代碼，提高軟體維護的成本，導致不可預知的bug 。但是介面背後，其實現卻可以隨著時代進步，演算法進步，硬體進步而越來越高效。X86的指令集，特別是一些非常古老的，不常用的指令集，其實都是寫成了固定的微程序，放在一種高速存儲器里，進入亂序流水線後依舊是微碼形式。

微碼化後，好處顯而易見，微碼系統本身可以作為一種指令集，只要英特爾願意，它可以隨著硬體，工藝革新，微架構重新設計而大幅更新微碼系統，拋棄舊微碼，設計新微碼，提高OOO部件的執行效率。表現在宏觀上，就是開發者發現，這些機器指令「API」變快了。性能提升了。IPC上去了。

解碼前端的複雜性才是X86真正的弱點，不規整，不等長的指令，導致硬體開銷增大，但是，在工藝允許集成數億晶體管的今天，這種硬體開銷就是蚊子腿，而且隨著X86加入微指令緩衝，前端的弱點也逐漸消失。同時享受著比L1更快的微指令緩衝帶來的紅利。微指令緩衝命中很高的程序里，程序執行速度肯定比傳統的L1取指的RISC快。

最後一點，x86處理器保留老的指令，是為了兼容古老的軟體，但是這不代表新軟體和新編譯器中還會大量產生古老的指令，因此隨著時間推移，硬體製造商可以降低前端中針對老指令的設計比例，使得老指令僅僅只做兼容，不考慮老指令執行的性能問題，前述的將老指令做成固定的微程序放入MS ROM便是一種方法，還有在解碼器上做偏向，例如一般英特爾的架構里前端只有一個複雜解碼器，這就大大降低了開銷。

X86為了兼容而付出的額外硬體開銷可能比想像的更少，如果放棄包袱，最多也就是4解碼器從4加1變成了5個一樣的簡單解碼器罷了。微指令緩衝可不是包袱。預解碼和取指令緩衝也沒有去掉的必要。畢竟預解碼可以在正式解碼之前就確認分支指令的存在，還可以檢測微指令緩衝的命中情況，具有降低功耗，提高效率的作用。

我尋思著。。。ARM，MIPS也不是多年輕的指令集啊。

RISCV倒是新，但性能也不咋地啊。

眾人皆言包袱就是包袱，

卻不知包袱 is Money！

兼容老破小是Windows當年一炮成名的殺手鐧之一！

有人提安騰，那就康康蘋果。

M1幾乎完全沒有運行armv8之外指令集的能力，哪怕是虛擬機里也跑不動armv7a的程序。

蘋果歷來喜歡砍歷史包袱，等同於Win32的差不多是Carbon那一套API，Carbon現在在新系統里只剩沒有任何功能的stub了。

10.8宣布廢棄Carbon並不會移植到64位平台的時候各大廠一片哀嚎，原因之一是這套API是面向C的，能給程序員們在界面上很大的優化空間。相反無論是Cocoa還是後來的Mac Catalyst和SwiftUI，性能上都無法和Carbon比。

但是，蘋果把它砍掉了。

M1的話好多大佬已經分析過了，總結一下就是那套設計的高性能和支持不支持32位arm指令集無關，它就是RISC-V的那麼搞也能封神。

能有多大提升？不好說，但是用戶和開發者肯定不買賬就是了。

飯要一口口吃，先實現大小核之類的異構CPU，再考慮將來怎麼把舊的指令都甩給一兩個保持兼容性的核心，而其它核心上專門跑高性能的新指令集。

我沒太懂題主意思，是覺得目前制約了性能的是windows的歷史包袱和老舊指令集嗎？

額。。。所以說我們需要打造一個跑分王？專為跑分而生嗎？

之所以用這玩意是因為生態，如果國產的生態好，我們甚至可以拋棄它們，用兆芯、用鯤鵬，用U班圖、用Linux的魔改等等。

嗯，我們用這套，單純的是因為這套上面的東西多，也因為上面的東西太多，有點尾大不掉的意思。

但是主流的軟體、遊戲應該大概率不會用老舊的指令集等內容，甚至有的遊戲在WIN10表現比WIN7好，這就是很好的說明了。

Windows和老舊指令集並沒有制約他們的性能，制約他們性能的是部分軟體，歷史包袱是為了照顧某些軟體。他們應該也不想

性能提升（x）

營收提升（√）

沒太多提升，win32一直都是windows性能最高的應用，對metro、uwp應用是碾壓級的。如果要優化也是代碼重寫重編譯，不過大部分時候瓶頸不在代碼。

現在的x86 cpu方面內核早就ARM化了，披著x86外衣的ARM，微內核已經是精簡指令集了，兼容老舊的x86歷史負擔不大，對性能影響不大。

真的要性能提升最好的方案應該是軟體編譯為64位，少寫垃圾代碼。現有的32位程序是跑在wow64上面，性能有一點損失。

x86沒什麼歷史包袱，想想第一代奔騰3.1M三極體，Ivy Bridge 就已經2000M多了，更大的核心現在都能到20,000M個晶體管了。

所有的歷史玩法都被消化在微指令里了。就那麼多指令，解碼以後，大部分都是微碼操作，就算有特殊兼容電路能佔千分之一么？算1%專用電路為了歷史，拿掉了也就1%的性能提升。

windows么，我也不覺得有多大的報復，看看各種應用Linux或其他平台能比windows多發揮出多少性能？

如果說windows甩掉包袱，把windows sxs 清理了，估計能省10GB硬碟空間。

現在ssd裝機起步512GB，hdd都8TB左右，10GB帶來優化還是當不存在吧。

反倒是很多日常的代碼質量和為了跨平台兼容性損失的性能么。嗨

我記得知乎有人討論過，x86上老舊的指令集並沒有佔用多少晶體管，並不是x86的負擔。現在最大的問題是，如何在x86和ARM之間確定一個大家認可的測試方法。個人的見解是，x86和ARM在性能上是相近的(人們在解決相似問題的時候，解決方法是趨同的)，但是，蘋果可以利用自己封閉硬體的特性做最優化處理(類似主機)，比如那個內存，A/I顯然暫時是用不了的。

推薦閱讀：
相关文章