一行除法，快了近两倍：编译器里那场没人看见的性能革命

一场发生在编译器深处的“小手术”

如果把现代计算机比作一辆高性能跑车，大家通常会盯着发动机、轮胎和变速箱：也就是 CPU、GPU、内存和工艺制程。很少有人会去关心拧紧某颗螺丝是不是更科学。但现实是，很多性能提升，恰恰就藏在这些“螺丝”里。

这篇来自 Shigeo Mitsunari 和 Takashi Hoshino 的论文，研究的正是这样一个听起来极其细碎的问题：在 64 位处理器上，如何更高效地执行“32 位无符号整数除以常数”。别被这个标题吓跑。把它翻译成人话，就是程序里像 x / 7、x / 10 这种操作，编译器其实早就不会老老实实用“除法指令”去做，而是会尽量改写成乘法、移位和少量修正，因为后者通常更快。

这套思路并不新。早在很多年前，Granlund 和 Montgomery 就提出过经典方法，后来又被不断改进，如今 GCC、Clang、微软编译器、Apple Clang 都在用。问题在于，这些成熟方法有一个历史包袱：它们很多时候仍然像是在“替 32 位 CPU 着想”。而今天的现实是，桌面、服务器和手机旗舰芯片，几乎都已经是彻底的 64 位世界了。

论文作者的核心观点很直接：既然目标机器是 64 位，就别再拿老办法凑合。比如 x/7 这样的表达式，生成的代码不该停留在 32 位时代的思路上，而应该主动利用 64 位乘法路径、更宽的寄存器和当代 CPU 的执行特性。说白了，这不是发明全新的数学，而是让编译器别再“守旧”。

为什么一个 /7 值得写论文？

很多非技术读者会有一个很自然的问题：一个除法优化，真的值得这么认真吗？我的答案是，太值得了。因为软件世界里最昂贵的，往往不是大招，而是那些被执行了几十亿次的小动作。

在图像处理、压缩解压、哈希计算、数据库执行器、网络协议栈，甚至游戏引擎和音视频编解码器里，这类“除以固定常数”的操作非常常见。有人可能会想，真正重的活不是都交给 SIMD、GPU 或专用加速器了吗？但现实中的大量系统仍然由无数标量整数运算拼起来，尤其在热路径上，哪怕只快几个周期，乘上调用次数，最后都会变成真金白银。

更关键的是，编译器优化有一种“普惠性”。芯片升级，用户得花钱买新机器；手工汇编优化，开发者得投入大量人力，还不一定能跨平台复用。但编译器变聪明一点，收益会自动落到整个软件生态头上。开发者不用改业务代码，重新编译一次，程序可能就快了。这种提升是最“安静”的，也是最有性价比的。

论文里给出的结果相当亮眼：在文中设计的微基准测试里，Intel Xeon w9-3495X（Sapphire Rapids）上获得了 1.67 倍加速，Apple M4 上则达到 1.98 倍。接近翻倍的提升，放在底层优化里其实很少见。当然，必须提醒一句，微基准不等于真实应用整体都能快这么多。现实程序中，这类除法只是整体运行时间的一部分，所以最终体感不会直接“翻倍”。但对编译器研究来说，这已经是非常扎实、而且有工程价值的结果。

这件事最有意思的地方，在于它已经不是“论文”了

很多论文的命运，是留在 PDF 里。写得精彩，引用不少，但工程世界并不买账。这篇工作最让我觉得有分量的地方，是作者不仅给 LLVM 和 GCC 做了补丁，而且 LLVM 的补丁已经合入主线。

这意味着什么？意味着它不是实验室里一段“理论上可行”的伪代码，而是已经通过了真实编译器项目的工程审视。LLVM 的代码生成链路牵一发动全身，能被合并，说明这套方法在正确性、维护成本、平台兼容性以及收益/复杂度比上，至少已经过了社区那道很苛刻的门槛。

这也是当下技术新闻里很值得强调的一种趋势：真正影响普通开发者体验的，未必是最热闹的 AI 模型发布会，也可能是编译器、链接器、运行时、内存分配器这些“幕后角色”的持续进化。今天很多程序员在 Mac 上、Linux 服务器上写代码，他们未必会去读这篇论文，但未来某一天更新工具链后，服务的吞吐量多了几个百分点，或者某段数据处理代码突然没那么拖后腿了，这背后可能就是这类工作在默默生效。

从行业视角看，这也反映出 Apple 和 Intel 之外的另一个主角：编译器基础设施本身正在重新成为竞争高地。过去几年，我们总说“软硬协同”，很多人想到的是 AI 编译栈、张量图优化、CUDA、MLIR。其实传统 CPU 世界也一样。硬件已经很复杂，单靠程序员手写最优代码越来越不现实，谁能让编译器更贴近微架构，谁就能把同一块硅榨出更多性能。

64 位时代到了，可很多优化思路还停在过去

这篇论文还有一个更大的启发：计算平台早已进入新阶段，但一些基础优化策略还在沿用旧时代默认值。历史上，很多编译器技巧是在 32 位 CPU 盛行时形成的，当时寄存器宽度、乘法开销、除法延迟、指令调度模型，都跟今天差别很大。老方法能工作，不代表它仍然最优。

这一点在 Apple M 系列芯片上尤其有意思。论文里 Apple M4 的提速更接近 2 倍，说明不同架构对这类代码生成的敏感度并不一样。过去十几年，x86 世界长期主导桌面和服务器，编译器很多优化路径天然会先照顾它；但现在 ARM 阵营在笔记本、手机、云端都越来越强，优化策略如果还按“单一主流架构”的习惯写，迟早会暴露天花板。

换句话说，这篇论文表面上在讨论“32 位除以常数”，骨子里谈的是一个更现实的问题：编译器到底有没有真正理解当代 CPU。对编译器来说，正确只是底线，生成“差不多”的代码也不够了，接下来比拼的是谁更懂硬件的脾气。

不过，这里也有一个值得思考的争议点。编译器优化越来越复杂，会不会让工具链变成一个只有极少数专家才能维护的黑盒？答案恐怕是会，至少会更严重。今天的高性能代码生成已经不只是几条漂亮的 peephole 规则，而是数学推导、目标架构特性、性能模型和回归验证系统的综合体。收益很诱人，但复杂度也在上升。这对开源社区是好事，因为改进可以共享；但对小型编译器项目和教学体系来说，门槛确实在变高。

真正的启示：别低估“无聊技术”的力量

在 AI 热浪席卷一切的 2026 年，一篇讲整数除法优化的论文，乍看像是科技新闻版面里最不抓人的那一类。但我恰恰觉得，它提醒了我们一个经常被忽略的事实：计算世界的进步，不只有大模型参数翻倍、显卡功耗再创新高，也包括把一条看似普通的指令序列打磨得更合理。

这种进步没有舞台灯光，没有 CEO 站台，也不会在社交媒体上刷屏。可它非常真实。数据库更省电一点，服务集群能少买几台机器，手机上的某些系统组件执行得更利落，云账单少一点——它们常常就来自这些不性感、甚至有点枯燥的基础工作。

我一直觉得，科技行业最迷人的地方之一，就是它允许“细节”改变世界。一个 /7 的优化，看起来像冷知识，实际上却是现代软件工业的缩影：历史遗产会拖住今天的性能，真正的创新不一定是颠覆式发明，也可能是重新审视那些大家默认“已经够好了”的东西。

如果接下来 GCC 相关补丁也被更广泛采用，这类优化很可能会悄悄进入无数应用的二进制文件里。届时没有人会在发布会上鼓掌，但服务器机会替你鼓掌——风扇转得没那么凶，任务跑得更快，延迟曲线再低一点。这种朴素的进步，往往最经得起时间考验。

从更长远看，我也很好奇一个问题：当 CPU、编译器和自动化性能分析工具结合得越来越紧密，未来的编译器会不会变成一种“持续学习的性能系统”？今天它只是更聪明地处理常数除法，明天它也许会根据真实硬件反馈，自动改写更多看似普通但高频的代码路径。那时，优化将不再只是静态规则，而是软件和硬件之间一场长期、细密的协商。

这听上去不如 AI 炫目，但它可能更接近计算世界真正的日常。毕竟，大多数程序的命运，不是靠一次惊天动地的重构决定的，而是由成千上万次不起眼的小操作共同写成。