英特尔APX，终于等到你

最新推荐文章于 2025-12-21 21:47:42 发布

原创最新推荐文章于 2025-12-21 21:47:42 发布 · 548 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#java #linux #开发语言 #运维 #服务器

大约10年前，我以英特尔员工的身份到腾讯公司做技术分享，在提问环节里，第一个抢到话筒的同行以急切的语调提出了一个非常急切地问题：“Intel的硬件断点寄存器数量太少了，什么时候能增加啊？”

听到这个问题，我立刻知道这位同行的技术水平很深，他不仅知道很多软件工程师不知道的硬件断点，而且还知道这个功能的原理是依赖CPU硬件的，而且他知道X86 CPU的硬件断点寄存器数量很少，每个逻辑CPU只有4个地址寄存器，最多只支持4个硬件断点。这个设计是1985年推出的80386所定义的，几十年没有变化。

演讲是在腾讯大楼的一个大会议室里（如今记不清是哪一层了），台下的听众很多，我远远地能望见这个提问的同行，我清楚地听到了他的问题，也完全理解了他的问题。我对他的专业深度表示敬佩，而且对他的述求深表赞同，但是我却无法给他一个让他满意的答案，比如，“下一代CPU就会增加一倍...”。

事实上，在这个演讲之前，我曾经通过Intel公司内部的正式渠道，提交了正式的技术方案，详细设计了如何扩展调试寄存器，包括如何与老的设计保持兼容。但是方案发出后，经过一些人的review后，最终的结果是消极的。后来到美国出差时，我和一位资深的老同事聊天谈起这个问题，他说：“任何对经典386特征的修改都难推动......”

这几年创业，我仔细学习了ARM，当我越深的了解ARM时，我越感觉到X86的不足。X86多年停滞不前，已经被ARM超越了很远。

最近，因为要准备9月份的纳秒级优化训练营，我不得不又把注意力转回到x86上，因为在纳秒级优化所针对的听众里，他们主要还是用x86的。

首先，我把熟悉的几份经典技术文档更新了一下，特别是著名的SDM（软件开发者手册）和SOM（软件优化手册）。

在更新这些文档时，我意外地发现了一份新文档，Intel® Advanced Performance Extensions (Intel® APX) Architecture Specification（《英特尔高级性能扩展（APX）架构规约》）。

打开这份文档，读了几句后，我意识到这是个大动作（Big Thing），是我期待许久的。

这几天在改进庐山研习班的讲义时，我把APX加入到了寄存器一讲的讲义里。

APX引入了多项变革，排在最前面的就是通用寄存器。经典386只有8个通用寄存器，AMD扩展的X64把8个扩展为16个。

APX把通用寄存器的数量从16个扩展为32个。

寄存器是CPU工作时可以快速访问到的临时空间，用图灵的话来说叫“

Quick reference temporary storage units (TS)”。

准备讲义时，我特意查阅了图灵写于1946年的ACE设计报告，在这个报告里，图灵将寄存器列在ACE的关键部件里，并且给出了建议的数量，50个，每个32位。

在今天流行的ARM64架构里，通用寄存器的数量是32个，每个64比特，总容量为256字节，与图灵当年的估计（200字节）竟然出奇的接近。

某种程度来说，影响CPU速度的关键因素是访问要计算的数据。当数据在寄存器中时，是最容易访问的。通用寄存器多，就可以让CPU把更多的数据放到寄存器里。

根据英特尔的官方资料，APX增加寄存器后对性能的改进是非常明显的。

Intel® APX doubles the number of general-purpose registers (GPRs) from 16 to 32. This allows the compiler to keep more values in registers; as a result, APX-compiled code contains 10% fewer loads and more than 20% fewer stores than the same code compiled for an Intel® 64 baseline.2 Register accesses are not only faster, but they also consume significantly less dynamic power than complex load and store operations.

除了通用寄存器，APX还引入了几个重磅特征：三操作数指令和谓词指令。