不要假设所有（有人用的）软体都还能更新。

对于是「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显然暂时是用不了的。

推荐阅读：
相关文章