号称能编译Linux内核,结果慢了158,000倍?Anthropic的AI编译器翻车实录

158,000倍。

这不是什么夸张的修辞，这是实打实的性能差距数据。

当 Anthropic 宣布他们的 AI 模型 Claude 写出了一个能编译 Linux 内核的 C 编译器（CCC）时，整个科技圈都炸了。100% AI 生成代码，这听起来像是程序员失业倒计时的钟声。

但老实讲，现实往往比营销文案要骨感得多。

有人真的把这个 AI 编译器拉出来溜了一圈，和行业霸主 GCC 正面硬刚。结果呢？GCC 跑完一个 SQLite 查询只要 0.047 秒，CCC 花了 7,432 秒。

这就像是你开法拉利，对面骑蜗牛，而且还是一只背着房贷的蜗牛。

AI 的“壮举”与注水

Anthropic 的博客写得确实漂亮。他们说 CCC（Claude's C Compiler）不仅能跑，还能编译 Linux 内核，支持 x86-64、AArch64 等多种架构。

这听起来很吓人。要知道，写编译器可是编程领域的皇冠明珠之一，GCC 可是人类几千个工程师花了快 40 年磨出来的剑。

CCC 确实做到了一些惊人的事。

在测试中，它成功编译了 Linux 6.9 内核的 2,844 个 C 源文件，编译错误数为 0。这点我个人觉得必须给掌声，让 AI 理解 C 语言的复杂语法并正确翻译，本身就是一个巨大的技术里程碑。

而且，它编译出来的 SQLite 在功能上是正确的。所有的查询结果都对，崩溃测试全过，没有 Segfault。

这看起来是个完美的故事，直到我们开始看那个“但是”。

“能编译”不等于“能跑”

Anthropic 说 CCC“能编译 Linux 内核”，这话只说了一半。

确实，C 代码它都编过去了，但在最后一步——链接阶段，直接崩了。

测试结果显示，CCC 生成了 40,784 个链接错误。原因很尴尬：CCC 生成的重定位条目和内核需要的对不上号。

简单说，AI 把砖头都烧好了，但盖房子的时候，发现砖头尺寸全是错的，根本砌不上墙。

这就导致了一个很滑稽的局面：CCC 编译内核很快，只用了 42.5 分钟（GCC 用了 73.2 分钟），但最后你什么也得不到。GCC 慢是慢了点，但至少它给你交出了一个能启动的系统 vmlinux。

更有意思的是，项目刚发出来没几个小时，GitHub 上就有人提了 Issue #1——“Hello World 编译不过”。

那个示例代码直接在 Fedora 和 Ubuntu 上报错，连最基础的系统头文件路径都找不到。有人调侃这像极了“本科生编译器大作业”的质量。

性能灾难：从慢到无法用

如果说链接失败还能用“兼容性问题”来洗，那运行时的性能表现就是彻底的“车祸现场”。

测试者选用了 SQLite 进行基准测试，这是一个 CPU 密集型的任务。

数据非常残酷：

• GCC 编译的 SQLite：跑完测试只要 10.3 秒（无优化）或者 6.1 秒（-O2 优化）。
• CCC 编译的 SQLite：耗时 2 小时 6 分钟。

你没看错，是小时。

在个别涉及嵌套循环的复杂查询上，CCC 甚至慢了 158,129 倍。

为什么会慢成这样？这就要说到编译器的核心技术——寄存器分配。

现代 CPU 有很少量的高速存储区叫寄存器，好的编译器会尽量把变量放在这里面，因为快得飞起。GCC 就像个老练的管家，把东西安排得井井有条。

而 CCC 呢？它像个只会把东西扔地上的搬运工。

CCC 几乎把所有变量都“溢出”到了内存栈里。每次运算都要从慢得多的 RAM 里读数据，算完再写回去。

代码里全是这种操作：stack -> rax -> stack。CPU 寄存器 %rax 成了唯一的搬运工，在那儿不停地把数据从栈的一个位置搬到另一个位置。

这导致 CCC 生成的二进制文件体积膨胀了 2.7 到 3 倍。

简单的 INSERT 操作还好，只慢了 1.7 倍。但一旦遇到复杂的 JOIN 或子查询，这种内存搬运的代价会被指数级放大，直接把性能拖进泥潭。

-O2 只是个装饰品

最让我觉得“被忽悠”的一点，是关于优化的。

通常我们给编译器加 -O2 或 -O3 参数，是希望它开启激进的优化模式，比如循环展开、内联函数、向量化等等。GCC 开启 -O2 后，虽然编译时间变长了，但运行速度快了 1.7 倍。

这是程序员几十年的智慧结晶。

但 CCC 呢？你给它传 -O0 还是 -O2，它生成的汇编代码一字不差。

CCC 虽然内置了 15 个 SSA 优化通道，但它在所有优化级别下都会运行这些通道，或者说，这些优化根本没起到什么实质性作用。

那个 -O 标志，就像车里的一个不连接任何电线的假按钮，按下去只会听到“咔哒”一声，然后什么也没发生。

谁赢了？

这事儿其实挺有意思。

如果你是 Anthropic 的粉丝，你会看到一个 AI 在极短时间内写出了一个能正确解析 C 语言的编译器，这证明了大模型在处理复杂逻辑和生成大规模代码上的潜力。

但如果你是个需要交付产品的工程师，你会看到：

• 编译速度：GCC 胜（CCC 慢 25%）。
• 二进制体积：GCC 胜（CCC 肿胀 3 倍）。
• 运行速度：GCC 完胜（CCC 慢几百倍）。
• 内存占用：GCC 胜（CCC 编译 SQLite 吃掉了 1.6GB 内存，是 GCC 的 6 倍）。
• 调试支持：GCC 胜（CCC 连基本的函数符号表都没生成，调试器看了想报警）。

写在最后

Anthropic 的这次实验，确实展示了 AI “写代码”的能力，但也无情地暴露了 AI “不懂代码”的短板。

写出一个能跑的编译器，和写出一个高效的编译器，中间隔着几十年的计算机科学积累。

AI 目前更像是一个只会模仿句式的新手作家，它能写出语法通顺的文章，但读起来味同嚼蜡，甚至逻辑不通。

至于那句“能编译 Linux 内核”的宣传语？

下次听到这种话，咱们还是让子弹再飞一会儿。毕竟，一个连 Hello World 都可能编译不过的编译器，离接管世界还差了 158,000 个 SQLite 查询。

参考链接：
https://harshanu.space/en/tech/ccc-vs-gcc/