上周有个做后端的朋友发消息问我他把同一份服务分别扔在一台 ARM 小主机和一台老 x86 台式机上跑压测结果小主机 QPS 反而高了一截他下结论说“ARM 架构就是比 x86 先进”。我没直接反驳只问了他三个问题两边内存频率和容量一样吗编译出来的二进制是不是同一份压测时那台台式机是不是还挂着浏览器和一堆后台他沉默了一会儿说好像都没控制。这类围绕 CISC、RISC、x86、ARM 的讨论在技术群里隔三差五就冒出来一次而且十有八九会滑向“谁更先进”这种没法证伪的结论。我干了这么多年底层相关的工作见过太多把架构名词当性能标签用的场景也见过有人因为一句“ARM 更省电”就把整套服务迁过去最后被内存带宽和驱动问题按在地上摩擦。这篇东西我想把这几件事讲透指令集到底规定了什么、CISC 和 RISC 这条分界线今天还剩多少含金量、x86 和 ARM 各自的设计取舍是怎么形成的、除了这两家还有谁在实际跑以及最关键的——写代码的人到底该关心哪些落到实处的差异。不管你是刚接触体系结构的学生还是天天和交叉编译、性能调优打交道的老手下面这些内容应该都能捞到点能直接用的东西。1. 先把“指令集”这个词从神坛上拽下来很多人一上来就纠结 CISC 和 RISC 谁优谁劣其实是因为没搞清楚讨论的对象是什么。指令集架构ISA本质上是一份契约一份写给编译器、操作系统和硬件实现三方看的说明书。搞不清这份契约的边界后面所有比较都是空的。1.1 指令集规定了什么又刻意没规定什么一份 ISA 会明确规定这些东西有哪些指令、每条指令怎么编码、程序员可见的寄存器有哪些、内存访问的语义对齐要求、原子性、可见顺序、特权级怎么划分、异常和中断怎么进入和返回、系统寄存器怎么访问。这些都是“你必须按我说的做”的部分编译器照着生成代码操作系统照着写上下文切换硬件照着实现。但它不规定的东西同样关键流水线有几级、每周期能发射几条指令、分支预测器用什么算法、L1 缓存多大、有几路组相联、频率能跑到多少、功耗墙在哪。这些属于微架构microarchitecture的范畴是各家设计方自由发挥的地方。所以“同一个架构”完全可以做出性能差三倍的芯片就像同一份菜谱交给不同的厨师出来的东西能差出天壤之别。我经常用一句话概括这个区别ISA 决定“能做什么”微架构决定“做得多快、多费电”。网上那些“x86 比 ARM 强”或者“ARM 吊打 x86”的论断绝大多数时候比较的根本不是 ISA而是两台具体机器的微架构加散热加内存。1.2 一个更贴切的类比套餐菜单和乐高积木CISC 的典型代表就是那种“一条指令干一整套活”的设计。比如字符串搬移指令一条指令下去硬件自动循环搬运、自动更新指针、自动递减计数程序员一行代码搞定。这就像餐厅的套餐点一份“宫保鸡丁套餐”后厨把主菜、米饭、汤、小菜全给你配齐你只需要说一句话。RISC 走的是另一条路每条指令只做一件事而且做得极其规整。加载和存储单独成指令运算只能在寄存器之间进行不能直接对内存里的数做加法。要搬一段数据你得自己写循环自己维护指针自己判断边界。这就像给你一盒乐高积木每块都一样大、一样规整你得自己拼出那个套餐。表面看 RISC 更麻烦但积木的好处在于规整的东西能被流水线高效处理。每块积木长度固定取指单元不需要猜边界解码器不需要查变长编码表流水线每一级的延迟都是确定的。这才是 RISC 真正的杀手锏而不是“指令数量少”这种表面特征。1.3 “复杂”和“精简”这两个词今天已经名不副实如果你今天还把 CISC 理解成“指令又多又复杂”、把 RISC 理解成“指令又少又简单”那基本是照着四十年前的教材在理解现在的芯片。现代 x86 处理器内部前端把变长指令译码成一串定长的微操作micro-op后端执行引擎采用的就是典型的乱序、多发射、寄存器重命名那一套和 RISC 的思路高度趋同。反过来AArch64 里也有加载多寄存器、带写回的寻址模式、成组的 SIMD 指令单看某条指令的复杂度一点都不“精简”。所以真正有区分度的特征早就换成了另外几条特征维度x86-64AArch64指令编码长度变长1 到 15 字节定长32 位通用寄存器数量16 个含特殊用途31 个 零寄存器运算指令能否直接访存可以操作数可来自内存不行必须先加载到寄存器内存模型较强TSO 近似较弱需显式屏障或 acquire/release条件执行主要靠条件跳转和 cmov保留部分条件选择类指令这张表里我觉得对写应用代码的人影响最大的是最后两行——内存模型和条件执行后面会单独开一节讲。指令长度和寄存器数量更多是编译器作者关心的事。2. CISC 与 RISC 的分野一场被历史条件逼出来的选择很多讲架构的文章会把 CISC 和 RISC 说成两种设计哲学的对立这话不算错但漏掉了最重要的背景这两种路线都是被各自时代的硬件条件逼出来的不是谁拍脑袋想出来的审美偏好。2.1 内存按字节计价年代的必然结果早期计算机的内存贵到离谱容量以 KB 计。在这种条件下程序体积就是硬通货——代码越短占的内存越少加载越快缓存命中率越高。于是设计者的目标函数非常明确用一条指令表达尽可能多的语义提高代码密度。复杂指令还有一个动机叫“语义鸿沟”就是让机器指令尽量贴近高级语言的语句结构。那个年代编译器技术还很初级把优化责任交给硬件用微码实现复杂指令比交给编译器更现实。一条指令完成数组下标计算加访存编译器就少做一堆事。这套思路在它的时代是完全合理的。问题出在两点一是微码实现复杂指令占用了大量芯片面积和设计验证成本二是编译器成熟之后统计发现程序里 80% 的时间花在 20% 的简单指令上那些精心设计的复杂指令编译器根本懒得用。2.2 RISC 的釜底抽薪把复杂度从硬件搬到编译器RISC 的核心主张其实只有一句话既然编译器能把复杂操作拆成简单指令的组合那就别让硬件干这活了。硬件只保留最常用、最规整的指令把省下来的晶体管和面积用来做更多寄存器、更大的缓存、更深的流水线。这个思路带来一串连锁反应指令定长取指和解码可以并行加载/存储分离运算指令的延迟固定流水线调度简单大量通用寄存器减少访存次数大部分指令单周期完成可以做成经典的五级流水线。我特别想强调一点RISC 的胜利本质上是编译器技术的胜利。硬件把优化责任交出去前提是接手的编译器足够聪明。八十年代那批 RISC 研究之所以能成正是因为编译器技术同时期也在快速进步。这也解释了一个现象同样一颗 RISC 核用不同编译器、不同优化等级编出来的代码性能差距能到百分之几十而 x86 上这个差距往往小一些——因为 x86 的硬件替你兜了一部分底。2.3 边界模糊之后该用什么标准看芯片今天你去拆一颗主流 x86 处理器会发现它的执行核心部分的设计思路和 RISC 高度一致定长微操作、大量物理寄存器、乱序执行、多发射。变长指令的解码压力全压在前端后端反而是“精简化”的。反过来看 AArch64它也吸取了不少 CISC 的教训比如加入了更丰富的寻址模式和批量数据搬移指令用少量“稍复杂”的指令换代码密度。所以我的建议是别再拿 CISC/RISC 当性能标签用。要看一颗芯片的实际表现盯这几个指标更有意义单线程 IPC每周期指令数乘以频率这个决定单核延迟敏感型任务的快慢内存子系统的带宽和延迟这个决定吞吐型任务的天花板每瓦性能曲线注意是曲线不是单点因为不同负载区间的表现可能完全相反缓存层级和一致性协议的实现质量多核扩展性全看这个最后一条经常被忽略。同样是 64 核缓存一致性协议做得差的芯片核数越多性能反而越差因为核间通信开销吃掉了并行收益。3. x86一个被“兼容性”绑架了四十多年的架构聊 x86 绕不开一个事实它是目前唯一一个从 1978 年一路兼容到今天的通用指令集。你手上那台机器开机自检的第一条指令跑的还是几十年前定下的那一套。这种连续性既是它最大的资产也是它最沉的包袱。3.1 前端解码变长指令带来的真实代价x86 指令长度从 1 字节到 15 字节不等这意味着处理器在取指之后必须先找到指令边界才能解码。而边界位置依赖于前面指令的长度形成了一条串行依赖链。现代处理器的应对办法是一层套一层先做预解码把指令边界信息标记出来存进指令缓存循环体里的指令第二次执行时直接走微操作缓存跳过完整解码流程。微操作缓存命中率高的时候前端压力确实小很多但一旦代码体积超过微操作缓存容量通常只有几千条微操作就得退回到慢速路径。这个机制解释了一个很多人困惑的现象同样的算法代码写得紧凑一点在 x86 上可能反而更快。因为变长编码天然有代码密度优势常用指令的编码很短同样的功能编译出来字节数往往比定长编码少指令缓存的压力就小。所以“变长编码一无是处”这种说法是错的它用解码复杂度换来了代码密度这笔交易在不同场景下划不划算结论完全不同。3.2 兼容性护城河的两面性兼容性的价值不用我多说几十年的商业软件、驱动、游戏、行业专用软件全都建立在“二进制不用重编就能跑”这个前提上。任何新架构想进这块市场第一道坎不是性能是这些跑不起来的东西。但代价也很实在。为了向后兼容处理器上电后要经历一串历史遗留状态机的切换从实模式到保护模式再到长模式每一步都要保持旧行为。分段机制、各种历史遗留的地址回绕处理、浮点协处理器的兼容模式这些在现代软件里几乎用不到的东西仍然要在硅片里留位置、在设计里留验证工作量。我参与过一个涉及固件层的项目最深的一个体会是在 x86 上做底层开发你写的代码有相当一部分精力是在和四十年的历史和解。这不是架构优劣问题是时间成本问题。3.3 哪些负载在 x86 上确实吃亏说几个我实测下来有明显体感的场景注意这些是“特定负载吃亏”不是“架构不行”长时间低负载待机x86 的深度休眠状态切换延迟相对较长进出睡眠的代价大做那种每隔几百毫秒醒一次处理小任务的场景累积功耗很难压下去。这是移动设备早期不用它的核心原因之一不是性能问题。强依赖代码密度的小核场景虽然变长编码在密度上有优势但解码电路本身的面积和静态功耗摆在那做超低功耗小核时前端开销占比很高。分支密集且不可预测的代码这是微架构层面的问题x86 和 ARM 都会遇到但不同实现的惩罚程度差异很大选机器时最好拿真实代码跑一遍别信跑分。反过来x86 在需要极致单线程性能、需要跑大量历史遗留二进制、需要成熟虚拟化生态的场景下短时间内没有对手。4. ARM不是“更先进”而是“更会算账”每次听到有人说“ARM 是新一代架构所以更先进”我都想纠正一下ARM 的历史比 x86 短不了太多它早期一样是给桌面电脑设计的。它今天的地位来自一个完全不同的产品逻辑。4.1 授权模式才是 ARM 真正卖的东西x86 生态里能设计处理器的就那么两三家而且指令集授权基本不外放。ARM 走的是完全相反的路线卖设计图纸。芯片厂商可以买现成的核心软核或硬核直接集成也可以买架构授权自己从头设计核心。这个模式带来的后果是双面的。好处是生态扩张极快做路由器的、做手表的、做汽车的、做服务器的都能拿到合适的东西。坏处是碎片化同样是 ARM不同厂商的启动流程、外设布局、中断控制器、电源管理接口可以完全不同。早期移动平台上“同一个应用在不同机型上表现天差地别”根子就在这里。后来服务器和 PC 领域能推起来靠的恰恰是把碎片化压下去统一固件接口、统一设备描述方式、统一启动规范。我参与过把一个服务往 ARM 服务器上迁的活儿最耗时间的不是应用适配是搞明白那台机器的固件和电源管理到底按哪套规范实现。4.2 定长指令和多寄存器怎么转化成能效优势AArch64 的 32 位定长编码让解码器可以做得很轻取指、解码、发射可以高度并行前端功耗占比低。31 个通用寄存器让编译器有充足的空间做寄存器分配减少访存次数。加载/存储分离让运算指令的延迟确定流水线好排。但我要泼一盆冷水这些优势在真实芯片上的贡献占比远没有宣传里说的那么大。一颗芯片的能效大头来自工艺节点、电压频率曲线、缓存和内存子系统的设计、以及电源管理策略的精细程度。指令集带来的差异更多体现在“前端省了多少面积和功耗”这一块属于加分项而不是决定项。真正让 ARM 在移动端赢下来的是它从第一天起就把“低功耗”写进了设计目标函数而不是把桌面芯片缩小了塞进去。这个目标函数的差异会渗透到每一个设计决策里——缓存大小怎么定、频率范围怎么划、大小核怎么调度、休眠状态划几档。4.3 从手机到服务器跨界时踩的那些坑移动端和服务器端的约束几乎相反。移动端要的是极低待机功耗、突发性能、热约束下的持续调度服务器端要的是满负载下的稳定吞吐、内存带宽、多路扩展、IO 通道数量。把移动端设计思路直接搬过来会撞上这些墙内存通道和带宽不够移动芯片通常配窄位宽内存服务器负载对带宽极度饥渴需要完全不同的内存控制器设计多路扩展能力缺失服务器需要多插槽一致性互联这是一整套额外的协议栈IO 通道数量不足高速外设通道数量决定了能挂多少加速卡和存储NUMA 拓扑缺失多核时代的访存延迟不再均匀软件必须感知这一点这也是为什么同一个架构在两类设备上的表现可以差出数量级——不是指令集变了是整个配套体系变了。5. 除了 x86 和 ARM还有哪些架构在实际跑标题里问“CPU 架构有哪些”如果只答 x86 和 ARM 是不完整的。真实世界里还跑着一大堆你平时不注意但关键时刻离不开的架构。5.1 RISC-V开放带来的想象力和碎片化风险RISC-V 最大的不同在于它是一份开放的指令集规范任何人都可以免费实现也可以在上面加自定义扩展。基础指令集加一组标准扩展整数、乘除、原子、单双精度浮点、压缩指令、向量再往上可以自由发挥。它现在的真实状态我这样描述微控制器和专用加速器领域已经大量落地通用高性能计算领域还在补课。缺的不是核是配套——高性能乱序核的成熟实现、向量扩展的工具链支持、虚拟化和管理程序生态、成熟的调试和性能分析工具。这些东西的成熟周期以年计。它还有一个隐忧扩展太多太自由可能导致“同一个 RISC-V”实际互不兼容。历史上吃过这个亏的架构不止一个。5.2 那些还在默默工作的老架构架构主要存活场景现实状态MIPS网络设备、部分嵌入式新设计明显减少存量巨大Power金融核心交易、部分高性能计算生态封闭但极其稳定迁移成本高s390x 系列大型机、银行核心系统兼容性做到了极致几乎不对外扩张SPARC历史系统新部署基本绝迹AVR / 各类 MCU 内核家电、工业控制、汽车电子出货量巨大几乎不进入公众视野这张表想说的是技术选型从来不是纯性能问题。金融核心系统不换架构不是因为新架构不够快而是迁移风险和验证成本高到没法算账。工业控制领域大量用着几十年前的内核是因为认证周期长、供应链稳定比性能重要得多。5.3 一张选型对照表别拿它当标准答案考量维度x86-64AArch64RISC-V大型机架构商业软件生态最成熟快速补齐中薄弱垂直领域极成熟单线程峰值性能强强中等中等偏上每瓦性能中等强取决于实现中等可定制性极低中架构授权极高无供应链多样性少多多单一长期供货稳定性中中取决于厂商极高学习与验证成本低中中偏高极高我特别想提醒一句这张表里的“强”“中”“弱”都是相对的而且随年份变化很快。真要选型拿你自己的负载去实测别信任何人的表包括我这张。6. 写代码的人该关心什么架构差异落到实操层面前面讲的都是“知道就好”的背景知识。这一节讲的是“不知道就会写出 bug”的部分也是我认为最有价值的部分。6.1 内存序最容易写出“只在一种机器上崩”的 bug这是我在跨架构迁移中见过最多的问题没有之一。x86 的内存模型相对较强接近“总存储序”通俗说就是除了“写后读”可能被重排其他顺序基本保持。AArch64 是弱内存模型几乎所有的读写顺序都可能被硬件重排只要没有显式的顺序约束。后果是什么一段在 x86 上跑了三年都没问题的无锁代码换到 ARM 上可能一周崩一次而且崩的位置和原因看起来毫无关联。因为 CPU 重排导致的可见性问题表现出来往往是“另一个线程读到了半个结构体”。正确的写法是在共享数据的读写上使用明确的顺序语义。以 C11 原子操作为例#include stdatomic.h #include pthread.h static _Atomic(int) ready 0; static int payload[64]; void *producer(void *arg) { for (int i 0; i 64; i) payload[i] i * i; /* release 保证上面的写操作在 ready 置位之前对其它核可见 */ atomic_store_explicit(ready, 1, memory_order_release); return NULL; } void *consumer(void *arg) { /* acquire 保证读到 ready 之后能看见 payload 的全部写入 */ while (atomic_load_explicit(ready, memory_order_acquire) 0) { /* 自旋等待 */ } int sum 0; for (int i 0; i 64; i) sum payload[i]; return (void *)(long)sum; }这里的关键不是_Atomic这个类型而是memory_order_release和memory_order_acquire这对语义。如果图省事写成memory_order_relaxed在 x86 上大概率照样能跑因为硬件顺序较强编译器也可能没做激进重排但在弱内存序架构上就是随机炸弹。同理用volatile代替原子操作、用普通变量做线程间标志位、依赖“先写数据再写标志位”这种隐式顺序都是典型的跨架构隐患。我在代码评审里看到这几个模式一律要求改。还有一个容易踩的点是设备驱动和 DMA 场景。CPU 写描述符、更新门铃寄存器、设备读描述符这一串操作的顺序在弱内存序架构上必须显式保证通常需要专门的屏障指令而不是普通的内存屏障。6.2 SIMD 和数据布局向量宽度差异带来的连锁反应x86 这边向量扩展是逐步加宽的128 位、256 位、512 位每一代都有不同的指令集子集用之前要检测 CPU 特性。AArch64 的 NEON 固定 128 位后来的可伸缩向量扩展允许实现选择 128 到 2048 位之间的宽度同一份二进制在不同芯片上跑出来的向量长度可能不同。这对代码的影响很实际。写可移植的高性能代码我有三条经验优先让编译器自动向量化。用简单的循环结构、避免循环内部分支、保证数据对齐、加编译指示提示无别名依赖很多时候编译器生成的代码已经接近手写水平。确实需要手写时把核心计算抽成独立函数按架构提供多份实现运行时做特性检测分派。C 语言可以用函数属性加条件编译Go 这类语言可以用构建标签分文件。数据布局比指令选择更重要。结构体数组和数组结构体的选择、是否按缓存行对齐、热点数据是否连续这些决定的性能差异经常比用不用 SIMD 大得多。还有一个经常被忽略的坑某些宽向量指令在某些实现上会导致频率下调持续跑重向量负载时整体吞吐反而不如窄向量。这不是所有实现都这样但选机器的时候值得实测一下。6.3 交叉编译与依赖真正卡住迁移的往往不是代码代码本身的架构适配通常只占迁移工作量的两三成。剩下的时间全耗在依赖上。环节常见问题处理办法原生扩展模块某些语言包含 C/C 扩展需要目标平台编译用目标架构容器构建准备好完整工具链预编译二进制第三方只提供单一架构的二进制找替代实现或自己从源码构建基础镜像官方镜像没有目标架构版本用多架构构建工具或自建基础镜像调试工具性能分析、调试器在目标平台缺失提前确认工具链可用性别等出问题才发现字节序假设代码里硬编码了内存布局假设大端架构上会直接崩做序列化时要小心我踩得最惨的一次是某个依赖的预编译产物只有 x86 版本源码构建又要一堆特定版本的系统库最后是在目标架构容器里从头编了一遍整条依赖链花了整整两天。经验就是迁移前先做依赖清单盘点把所有含原生代码的依赖列出来单独验证别等到部署那天才发现。6.4 怎么查清自己手上这台机器最后给一组实用命令排查问题时第一时间能确认环境。# 内核报告的架构 uname -m # x86 上查看详细型号、频率、缓存、特性标志 lscpu cat /proc/cpuinfo # 内核暴露的硬件能力标志做特性检测时很有用 grep -m1 flags /proc/cpuinfo # AArch64 上看这几个文件 cat /proc/cpuinfo | grep -m1 FeaturesAArch64 上还可以通过getauxval(AT_HWCAP)和AT_HWCAP2在程序运行时读取硬件能力位这比解析/proc/cpuinfo靠谱得多因为后者格式在不同内核版本上可能有差异。写可移植代码做特性分派时优先用系统提供的查询接口别自己解析文本。7. 几个反直觉的结论和踩坑记录写到这里我想把几条被反复验证过的经验单独拎出来它们和网上流传的常识往往相反。第一条指令集几乎从来不是性能瓶颈的决定因素。我做过一组对比同一份计算密集型代码在两个不同架构的同代芯片上跑差异在 15% 以内但把同一份代码的内存访问模式从随机改成顺序性能提升超过 3 倍。选机器的时候盯着架构名词不如盯着内存子系统和缓存配置。第二条“更省电”必须带前提条件。在低负载区间为移动场景设计的芯片优势明显但在满载区间这个优势可能消失甚至反转因为散热设计和供电能力完全不同。我见过把服务迁到低功耗平台后电费账单不降反升的案例原因是单核性能不足导致需要更多核并行总功耗上去了。第三条代码密度这件事方向可能和你想的相反。很多人以为定长编码更省空间实际上常用指令在变长编码里往往只用一两个字节整体代码体积反而更小。只有在指令分布非常均匀的极端情况下定长编码的体积优势才显现出来。这对指令缓存敏感的负载有实际影响。第四条兼容性成本最终会转嫁到每一个开发者身上。一个架构背的历史包袱越重你在底层调试时遇到的“诡异行为”就越多。这不是谁的错是时间的代价。做底层开发时遇到无法解释的行为先去查这个架构的历史遗留特性文档往往能省下几个小时。第五条别在群里用一句“XX 更先进”下结论。性能问题九成出在代码和配置上剩下一成才轮到硬件选型。先 profiling再看架构顺序反了就是浪费生命。最后分享一个我个人习惯每次要接触一个新架构我会先写一个最小可运行的程序把内存序、原子操作、向量化、线程同步这几件事各跑一遍确认行为符合预期再往上堆业务逻辑。这个习惯帮我提前发现了至少三次跨架构的隐患每次都是在问题还没进生产环境的时候。算是这些年在不同指令集之间来回折腾攒下的一点笨办法。