Claude自制的C编译器(CCC) vs GCC 性能基准测试：AI编码的现状

最近 Anthropic 公开了由 Claude Opus 4.6 100% 编写的 C 编译器，即 CCC (Claude's C Compiler)。 该编译器可以编译 Linux 内核的主张在开发者社区引起了巨大轰动。

那么，与经过数十年优化的行业标准 GCC 相比，AI 制作的编译器能展现出怎样的性能呢？我们基于 Harshanu의 심층 분석 整理了结果。

1. CCC 是什么？

CCC 是用 Rust 编写的 C 编译器，支持 x86-64、AArch64、RISC-V 等多种架构。 令人惊讶的是，从前端到代码生成器，再到链接器，所有组件都由 Claude Opus 4.6 编写。 人类只负责编写测试用例和提供指导。

2. 基准测试环境及对象

为了进行公平的比较，我们在以下环境中进行了测试。

• 对象：SQLite 3.46（单源文件），Linux Kernel 6.9
• 比较对象：GCC 14.2 vs CCC
• 环境：Debian VM (6 vCPU, 16GB RAM)

Linux 内核是复杂性的极致，SQLite 是验证标准 C 合规性和运行时性能的最佳对象。

3. 令人震惊的结果：158,000 倍的差异

总而言之，CCC 处于**“可以运行，但无法实际使用”**的水平。

✅ 成功之处 (Correctness)

• 准确性：通过了 SQLite 的所有查询测试。结果与 GCC 相同。
• 编译成功：无错误地编译了 Linux 内核的 2,844 个 C 文件。

❌ 失败之处 (Performance & Linking)

• 运行时速度：在 SQLite 基准测试中，比 GCC (-O0) 慢 737 倍，比优化后的 GCC (-O2) 慢 1,242 倍。
• 最坏的情况：在包含子查询的复杂 SQL 运算中，性能慢了高达 158,000 倍。 (GCC: 0.047 秒 vs CCC: 7,432 秒)
• 内核链接失败：C 文件编译成功，但在链接阶段，错误地生成了 __jump_table 等重定位信息，导致最终二进制文件生成失败。

4. 为什么这么慢？(Root Cause)

CCC 性能下降的原因在于缺少编译器优化。

1. 寄存器分配 (Register Allocation) 失败

现代 CPU 性能的关键在于有效使用寄存器。 但是，CCC 几乎没有寄存器分配算法，因此将所有变量存储在堆栈 (RAM) 中，并仅使用 rax 寄存器作为穿梭来传递数据。

• GCC：寄存器间运算 (cmpl %eax, %edx)
• CCC：重复内存读取 -> 寄存器 -> 内存写入（慢数千倍）

2. 徒有虚表的优化选项

CCC 接受 -O2、-O3 标志，但实际上没有任何作用。 生成与 -O0 完全相同的二进制文件，甚至精确到字节。 GCC 执行的循环展开 (Loop Unrolling)、内联函数 (Inlining)、向量化 (Vectorization) 等优化完全不存在。

5. 结论：AI 编码的现状

Claude's C Compiler 作为**“AI 可以从头到尾构建复杂的系统软件”**的概念验证 (PoC) 取得了巨大的成功。 解析 Linux 内核源代码并将其转换为目标代码对人类开发人员来说也是一项非常困难的任务。

但是，在产出**“高效和优化的结果”**方面，仍然存在明显的局限性。 编译器优化是数十年积累的研究和专业知识的结晶，与仅仅了解语法是不同层面的问题。

一句话总结：Claude 创造了一个出色的 C 解析器 (Parser)，但创造了一个糟糕的代码生成器 (Code Generator)。

---

Reference: CCC vs GCC by Harshanu

---