Claudeが生成したCコンパイラとGCCの比較

 (harshanu.space)
14 ポイント 投稿者 GN⁺ 2026-02-10 | 5件のコメント | WhatsAppで共有
  • AnthropicのClaude Opus 4.6が全面的に作成したCCC(Claude’s C Compiler) が、Linuxカーネルをコンパイルできると主張して公開された
  • Rustで書かれたスタンドアロンコンパイラで、フロントエンドからリンカまで全コンポーネントを独自実装しているが、GCCと比べて性能と最適化品質は大きく劣る
  • SQLiteとLinuxカーネルを対象にしたベンチマークで、CCCはすべてのCファイルをエラーなくコンパイルしたものの、リンカ段階で4万件超の参照エラーによりビルドに失敗
  • SQLiteの実行性能は最大158,000倍遅く、バイナリサイズは3倍以上大きく、最適化オプション（-O2など）は無効
  • AIが完全なCコンパイラを生成した点は技術的に意義があるが、実用可能な水準の効率性と互換性にはまだ達していない

CCCの概要と構造

  • CCCはAnthropicがClaudeを使って全面的にAIが作成したCコンパイラで、x86-64、i686、AArch64、RISC-V 64をサポート
    • Rustで実装され、SSAベースのIR、オプティマイザ、コード生成器、アセンブラ、リンカ、DWARFデバッグ情報生成まで含む
  • コンパイラ・アセンブラ・リンカの役割を分けて説明しており、リンカが最も複雑でエラーが発生しやすいと述べている
  • LinuxカーネルはGCC拡張と複雑なリンカスクリプトを使うため初期テスト対象には不向きで、代わりにSQLiteを主要ベンチマークに選定

テスト環境と方法

  • 2つの**DebianベースVM（6 vCPU、16GB RAM）**で同一条件のもと、GCC 14.2.0とCCCを比較
  • 比較項目: コンパイル時間、バイナリサイズ、実行速度、メモリ使用量、安定性
  • CCCはgcc_m16機能で16ビットのブートコードのみGCCに委譲し、それ以外はCCCで処理
  • SQLiteベンチマークはCPU中心に設計され、42個のSQL操作を10段階で実行

主な結果の要約

  • Linuxカーネル 6.9: CCCは2,844個のCファイルをすべてコンパイルしたが、リンカ段階で40,784件のundefined referenceエラーにより失敗
    • エラー原因: __jump_table、__ksymtab セクションの誤ったrelocationおよびシンボル生成
  • SQLiteコンパイル: CCCはGCCより1.3倍遅く、バイナリサイズは2.7〜3倍、メモリ使用量は5.9倍
  • SQLite実行性能: GCC -O0比で737倍、-O2比で1,242倍遅い
    • 単純なクエリは1〜7倍、ネストしたループクエリでは最大158,000倍遅い
  • Crashテスト5種をすべて通過し、機能的な正確性は確保

性能低下の原因

  • レジスタスピリング過多: 大半のローカル変数をスタックに保存するため、メモリアクセスが過剰に発生
    • sqlite3VdbeExec 関数では100個超の変数をスタックで処理し、コード長が3倍に増加
  • 最適化オプションが無効: -O0 と -O2 の結果が完全に同一で、15個のSSAパスがすべてのレベルで同じように実行
  • フレームポインタ破損によりGDBデバッグ不可
  • コードサイズ膨張: SQLiteバイナリは4.27MBでGCC比2.78倍、命令キャッシュミスが増加
  • シンボルテーブル未生成: 内部関数シンボルがなく、プロファイリング不可

CCCの強みと限界

  • 強み
    • Linuxカーネルの全Cファイルをエラーなくコンパイル
    • SQLite結果の正確性・安定性を確保し、セグメンテーションフォルトなし
    • GCC互換のコマンドラインインターフェースをサポート
  • 限界
    • 実行速度が極端に低下（最大158,000倍）
    • リンカ非互換によりカーネルビルドに失敗
    • バイナリサイズとメモリ使用量が過大
    • 最適化・デバッグ情報の欠如、-O オプション無効
    • コンパイル速度もGCCより25%遅い

「Hello World」問題

  • 公開直後に「Hello world does not compile」イシューが発生
    • stddef.h、stdarg.h を見つけられず、プリプロセッサ段階で失敗
    • GitHubで288件超のリアクションと200件超のコメントが付き話題に
    • 一部ユーザーは「学部生レベルのコンパイラ課題のようだ」と評価

結論

  • CCCはAIが完全なCコンパイラを生成できることを示した事例
    • Linuxカーネルの全Cファイルをエラーなく処理し、SQLiteを機能的に正確に実行
  • しかし実用には不向き
    • 実行性能が極めて低く、リンカ・最適化・デバッグ機能が未完成
  • 研究上の成果としては意義がある一方、実務向けコンパイラとしてはGCC・Clangなど既存ツールが依然として必須

関連記事

5件のコメント

 
roxie 2026-02-10

Hello world does not compile ミームの元ネタはこれなんですね（笑）
 
fantajeon 2026-02-13

最初は囲碁の雰囲気に少し似ていますね。
 
chcv0313 2026-02-12

ループを回し続けながら修正させれば、いずれはもっと優れたコンパイラが出てくるのではないでしょうか
 
t7vonn 2026-02-11

学部生の課題レベルには到達した……という点に意義を置くべきでしょう。
 
GN⁺ 2026-02-10
Hacker Newsの反応

  • 今回の論争は、LLMコーディングエージェントに対する賛否両論の見方をよく示す例だ
    賛成派は「数時間で動くコンパイラを作ったのは驚異的だ」と言い、反対派は「動かなければ意味がない」と言う
    コードベースが複雑になるほどエージェントは弱くなる点、そして「次の世代が直す」という繰り返しの主張に懐疑的だ
    AnthropicはLinuxカーネルをコンパイルしたとしたが実際には失敗しており、AIへの過剰な期待と現実の乖離が露わになった

    • 最近のOCamlの「vibe coded」事件を思い出させる
      テストを通り見た目が正しい出力を出すことと、そのコードが保守可能な品質を備えていることはまったく別問題だ
    • 「次世代モデルが全部直す」という理屈が繰り返されるたびにうんざりする
    • 「sufficiently smart LLM」というC2 wikiのページが必要かもしれない
    • この論争はまるでSpaceXの発展過程を見ているようだ
      最初は「小さな関数しか書けない」、次は「Linuxはコンパイルできない」、その次は「GCCレベルには達していない」と、基準が次々に動いていく
      だが進歩の速さを見ると、数人のコンパイラエンジニアを付けるだけでもすぐ追いつきそうだ
    • Cコンパイラは50年にわたって積み上げられたコードの成果物だ
      だからLLMが完全に新しい問題を解けるのかは依然として疑問だ

  • Anthropicはブログでx86でもLinuxカーネルが起動したと書いていたが、実際にはRISC-Vだけが成功したように見える
    公式ポストではx86/ARM/RISC-Vのすべてで動くとしていたが、
    リポジトリ文書にはRISC-Vのテストしかない

    • おそらくCCCはstatic keysやDKMSなどを無効化すれば動く可能性はある

  • 最適化されていないCの性能低下の大きさを見ると興味深い
    SQLite3ビルドではCCCは12倍、最適化版は20倍遅い
    これはGCCがどれほど多くの最適化の成果を出しているかを示している

    • Cの速さは今なおハードウェアと直接結びついた言語特性によるものだ
      だがレジスタのシャッフルが激しいコンパイラではこの結び付きが失われ、Pythonのように感じられる
    • TCCのような低最適化コンパイラでもCCCよりはるかに速い
      CCCは-O0よりも遅く、意外だった

  • CCCがカーネルのすべてのCファイルをエラーなくコンパイルしたからといって、正常な成果物を出したとは言えない
    SQLiteのテスト通過だけでは不十分だ

    • エラーがないことは正しいコンパイルを意味しない。/dev/nullに送ってもエラーにはならないのだから
    • LinkedInで見た投稿によれば、CCCはconstを無視し、型の再定義や誤った変換もそのまま通してしまう
      つまり「テスト通過」という目標のために、無効なコードまでコンパイルするごまかしを使ったわけだ

  • ある投稿では「コンパイラが最も簡単な段階」だと言っていたが、実際にはリンカが最も複雑な部分だ
    x86-64の何千もの命令エンコーディング、ELFの細かなレイアウトなどはAIには扱いにくい

    • リンク処理はルール適用に近く、アセンブラはパターンマッチングに近いという反論もある
      また、「1回の反復で4倍遅い → 10億回反復すると158,000倍遅い」という計算は成り立たない
    • Claudeがx86アセンブラとリンカを一度に作ってくれたという人もいる
      足りない命令は多かったが、データテーブルを埋めれば済む程度だったという
    • Anthropicが作ったのはコンパイラだけで、リンカまでは含まれていなかったはずだという認識もある

  • 人間の期待値がどれほど速く変わるのかに驚かされる
    5年前なら「AIが英語プロンプトでCコンパイラを作る」という話は突飛な冗談だっただろう

    • ただし、そのコードが既存コンパイラのソースにどれだけ依存していたかも考える必要がある
    • 文脈なしにこうした結果が出たのなら、実際には**複雑なコピペ(copy-pasta)**である可能性も高い
    • この進歩は驚くべきだが、それを根拠にAGIの到来を予測するのは早計な一般化だ
    • 結局はOverton windowが移動しただけだと思う
    • とはいえ、数十億ドルの学習コストとインターネット全体を学習した点は無視できない

  • HNの過度なシニシズムは理解できない
    3つのアーキテクチャ向けにCコンパイラを作るのは人間にとっても難しく、
    SQLiteを通るレベルであっても週末プロジェクト級の成果としては大したものだ
    ほとんどの企業にとって必要なのは高性能コンパイラではなく、ビジネスロジック向けのコードの接着剤を作ることだ
    問題は技術そのものよりも、それを使う人たちの態度にある

    • ただし、$20kのトークンコストと複数人の関与を考えると「週末プロジェクト」は誇張だ
    • CCCがエラーを無視してコンパイルする点、SQLiteのテストさえ完全ではない点は深刻だ
    • LLMが作ったコードは修正しにくく、脆弱な構造を持つという点で依然として限界がある
    • 結局のところ問題は技術ではなく、AIの成果を過大に包装する人たちだ
    • 「sour grapes」という表現はこの文脈ではしっくりこない

  • SQLiteでの158,000倍遅い性能が核心だ
    パースは簡単な問題で、本当に難しいのはレジスタ割り当てと最適化の段階だ
    GCCと比較するのは無意味だが、LLMがこのようなコンパイラを作ったこと自体は驚くべきことだ
    次の目標は、GCCとの差を158,000倍から100倍程度まで縮めることだ

    • ただし、この数値計算は信頼しにくい
      各反復が12倍遅いなら全体も12倍遅いはずで、158,000倍というのは誤りか誤解に見える
      SQLiteのテストが実際に正しく実行されているのかも検証不足だ
    • LLMはGCCやClangのソースコードを学習している可能性が高い
      それでも性能がここまで低いのは疑問だ
    • Cのパースは思ったより難しいという指摘もある
      Cは完全にパース可能な言語ではないという記事は参考になる

  • 「1回の反復で8倍遅いなら10億回繰り返しても8倍遅いだけ」という指摘の通り、
    158,000倍という数値は論理的に成り立たない
    おそらくレジスタスピリングがL3キャッシュを圧倒したか、不要なコードが実行されるバグがあるのだろう

    • GCC版が0.047秒で終わったのを見ると、「10億回反復」という主張自体も信頼しにくい

  • Cコンパイラを作るのは人間にとっても難しいが、
    これをLLMの知能の証拠と見るのは難しい
    すでによく知られた問題であり、数多くの実装や文書が学習データに含まれている
    つまりLLMは新しい設計を創造したのではなく、既存パターンを再構成したにすぎない
    それでもこうした道具は依然として有用であり、
    本当に印象的なのは既存OSSを複製することではなく、新しいアプローチを提示するモデルが現れたときだろう