号称能编译Linux内核？AI写的C编译器实测慢了15万倍

Anthropic最近搞了个大新闻，声称利用Claude Opus 4.6全自动构建了一个C编译器，命名为CCC（Claude's C Compiler）。官方甚至放话，这个由AI生成的编译器已经强大到可以编译Linux内核。

这就有点惊人了。要知道，编译器是计算机科学皇冠上的明珠之一，GCC经过近40年的迭代才有今天的地位。一个AI模型写的代码就能挑战工业标准？

技术博主Harshanu决定对这个CCC进行一次彻底的“体检”，并将它与GCC 14.2.0进行了正面对决。测试结果既展示了AI的惊人潜力，也极其残酷地暴露了它的局限性——尤其是当你看到慢了15万倍的数据时。

并没有真正跑通Linux内核

首先得验证Anthropic最引以为傲的宣称：编译Linux内核。

测试中，CCC确实展现出了令人咋舌的代码理解能力。它成功编译了Linux 6.9内核中的每一个C源文件（共2844个），期间没有报出一个编译错误。对于一个完全由AI生成的工具来说，能正确处理内核级别的复杂C语法，这本身就是一个奇迹。

但是，故事在最后一步烂尾了。当进入链接（Linker）阶段时，CCC崩溃了，抛出了超过4万个未定义引用错误。问题主要出在内核的跳转表（__jump_table）和符号表生成上。换句话说，CCC读懂了所有的C代码，但它生成的中间产物无法被正确组装成一个可启动的内核。

所谓的“能编译”，在工程上其实是“能编译通过，但无法生成成品”。

性能惨案：SQLite测试

既然内核跑不起来，博主退而求其次，用SQLite这个标准C库来测试生成的二进制文件性能。SQLite代码量适中且自包含，是绝佳的测试对象。

这一次，CCC终于成功生成了可执行文件，并通过了所有的功能正确性测试。没有任何崩溃，查询结果也完全正确。但在性能数据面前，GCC简直是在对CCC进行降维打击。

在基准测试中，GCC编译出的SQLite跑完所有测试仅需10.3秒（无优化模式-O0），而CCC编译的版本足足跑了2小时6分钟。

你没看错，整体运行速度慢了737倍。如果你开启GCC的-O2优化，差距会拉大到1242倍，因为CCC完全忽略了所有的优化参数，无论你传-O2还是-O3，它生成的代码都是一模一样的。

为什么会慢15万倍？

更深入的分析发现，在某些涉及嵌套循环的复杂查询中，CCC的性能甚至比GCC慢了158,000倍。

造成这种“史诗级”性能灾难的核心原因在于寄存器分配（Register Allocation）。

现代CPU的速度非常快，但前提是你得把数据放在寄存器里。GCC极其擅长规划哪些变量该进寄存器，哪些该扔进内存（堆栈）。

而CCC生成的代码似乎患上了“寄存器恐惧症”。它几乎把所有的变量都扔在堆栈里，每次运算都要先把数据从内存搬到寄存器，算完立刻扔回内存。

博主分析汇编代码发现，CCC生成的函数甚至会用单一的寄存器作为“摆渡车”，在不同的栈地址之间来回搬运数据。

这种操作导致了极其惊人的指令冗余和内存访问开销。GCC编译出的SQLite二进制大小只有1.55MB，而CCC搞出了4.27MB，代码膨胀了近3倍，进一步挤爆了CPU缓存。

也就是个“本科生作业”水平

除了性能问题，CCC在工程细节上也显得很稚嫩。

就在发布后不久，有人发现CCC甚至连最简单的“Hello World”都编译不过，原因是预处理器找不到标准库头文件。这个问题在GitHub上引发了大量围观，有人戏称这代码质量“让我想起了本科生的编译原理作业”。

虽然这个评价听起来很刻薄，但从寄存器溢出（Spilling）的处理方式来看，确实符合初学者的特征。它实现了功能，但完全不懂优化。

结论

Claude Opus 4.6编写的CCC是一个极具象征意义的技术展示。它证明了AI已经能够理解并生成极其复杂的系统级软件逻辑——能编译通过几千个内核文件就是铁证。

但从“能用”到“好用”，中间隔着几十年的工程积累。CCC生成的代码在运行效率上是灾难级的，它更像是一个逻辑正确的玩具，而不是一个生产力工具。

目前的AI还无法取代那些秃顶的编译器工程师。如果你想跑程序，还是老老实实用来GCC吧；如果你想看AI表演“虽然慢但它是对的”，那CCC倒是个不错的乐子。

信息来源：

• • https://harshanu.space/en/tech/ccc-vs-gcc/