Claudeが作ったCコンパイラ(CCC) vs GCC性能ベンチマーク: AIコーディングの現在地

最近Anthropicは、Claude Opus 4.6が100%作成したCコンパイラ、別名**CCC (Claude's C Compiler)**を公開しました。このコンパイラがLinuxカーネルをコンパイルできるという主張は、開発者コミュニティに大きな波紋を呼びました。

果たしてAIが作ったコンパイラは、数十年間最適化された産業標準であるGCCと比較して、どの程度の性能を示すのでしょうか？ 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などの再配置(relocation)情報を誤って生成したため、最終バイナリの生成には失敗しました。

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