Cの最適化されてない状態がどれだけ遅いかを見るのは本当に面白いね。Cが他の言語に比べてパフォーマンスで圧倒的に優れているのを見慣れているから、まるでそれが言語自体に内在する特性だと思っちゃう。でもベンチマークを見ると、SQLite3の最適化されてないビルドはCCCで12倍遅く、最適化されたビルドでも20倍遅いんだ。これはすごい！CCCをディスってるわけじゃなくて、GCCが本来は速いとされる言語からどれだけスピードを引き出しているかに感心してるんだ。

これはこの議論の両方の視点を示す良い例だと思う。LLMコーディングエージェント支持派：「ほら！エージェントが数時間で作った動くコンパイラだ！すごい！」反対派：「でも、これは動くコンパイラじゃないよ。それに、どれだけ少ない時間で作ったかは関係ない。動かないんだから、無意味だよ。」支持派：「確かに、でもエージェントにそれを直させられるよ。」反対派：「本当にできるの？コードベースが複雑になるほど、エージェントのパフォーマンスは悪くなるのを見てきたよ。コンパイラの複雑な問題を直すのはエージェントには難しいと思う。それに、もし直せるなら、なんで直してないの？」支持派：「今はそうかもしれないけど、次の世代が直すよ。」反対派：「そうかもね。最近の世代はどんどん良くなってるけど、まだこの種の複雑さにうまく対処できてるわけじゃない。」支持派：「でも、見て！これはすごい！数時間でコンパイラができたんだ！GCCをここまで持ってくるのに何百万時間もかかったんだよ？こんな風に比較するのはフェアじゃない！」反対派：「AnthropicはLinuxカーネルをコンパイルできる動くコンパイラを作ったと言った。GCCは通常Linuxカーネルをコンパイルするために使うものだから、比較は招かれたものだよ。結果的に（理由はどうあれ）CCCはGCCができるLinuxカーネルのコンパイルに失敗した。AIの期待が現実に合わないってことだね。」支持派：「でも、LLMを使い始めて数年、エージェントを使い始めてからも1年しか経ってないんだ。これはまだ始まりに過ぎない！」反対派：「それは本当だけど、これは面白いね。でもこの技術には他にもたくさんの疑問がある。急いで進めて全部台無しにしないようにしよう。」

ビルドはリンカーステージで失敗した > コンパイラはちゃんと仕事をした > CCCが成功した点 正確性：カーネルのすべてのCファイルをコンパイルした（エラーは0） それは成り立たないと思う。コンパイラがカーネルコードの一部に対してゴミのアセンブリを生成した可能性は十分にあるし、たとえリンクできたとしても全く動かないかもしれない。（SQLiteのコードが自己テストを通過したからといって、LinuxカーネルがSQLiteよりもはるかに高度で低レベルな特徴を使っているから、私を納得させるものではない。）

「奇跡はクマが上手に踊れることではなく、クマがそもそも踊れることだ。」 - 古いロシアのことわざ。

ここで気になるのは、Anthropicがブログ記事でLinuxカーネルがx86でブートできると主張してたけど、これって本当にそうじゃないの？ それとも、ただその部分をでっち上げたの？ ブログ記事からは、カーネルが3つのアーキテクチャ全てでブートできると言っているように見えたけど、カーネルの設定オプションでかなりの手を抜かない限り、それは真実じゃないよね。リポジトリをよく見ると、RISC-VでのLinuxブートしか示してないし、だから… [0]: https://www.anthropic.com/engineering/building-c-compiler - "x86、ARM、RISC-Vでブート可能なLinux 6.9を構築する。" [1]: https://github.com/anthropics/claudes-c-compiler/blob/main/B... - RISC-Vのテストしか示してない。

「皮肉なことに、4つの段階の中で、コンパイラ（アセンブリへの翻訳）がAIが構築するのに最もアプローチしやすいものです。主にパターンマッチングとルール適用に関するもので、Cの構造を取り、アセンブリパターンにマッピングします。アセンブラは見た目よりも難しいです。ターゲットアーキテクチャの各命令の正確なバイナリエンコーディングを知っておく必要があります。x86-64だけでも、複雑なエンコーディングルールを持つ何千もの命令バリアントがあります（REXプレフィックス、ModR/Mバイト、SIBバイト、ディスプレースメントサイズ）。1ビットでも間違えると、CPUは全く予期しない動作をします。リンカーはおそらく最も難しいです。リロケーション、複数のオブジェクトファイル間のシンボル解決、異なるセクションタイプ、位置独立コード、スレッドローカルストレージ、動的リンク、ELFバイナリのフォーマット特有の詳細を処理しなければなりません。Linuxカーネルのリンカースクリプトだけでも、リンカーが正確に処理しなければならないレイアウト指示が何百行もあります。」私はコンパイラ、アセンブラ、リンカーに関わってきたけど、これはほぼ逆だね。

SQLiteの158,000倍の遅延がここで重要な数字であって、Cを正しくパースできるかどうかではない。パースは解決された問題だ — すべてのCSの学部生は再帰降下パーサーを書く。コンパイラの面白い（そして難しい）部分は、レジスタの割り当て、命令の選択、最適化パスで、まさにそこが崩れているところなんだ。それを踏まえると、「CCC対GCC」という枠組みは間違っていると思う。GCCには何千人ものエンジニアの年数が注ぎ込まれている。実際に印象的なのは、LLMがCの非自明なプログラムをコンパイルできる程度のコンパイラを作ったことだ。たとえそれがひどいものであっても。5年前には考えられなかったことだよ。みんなが注目すべきゴールポストは「GCCに匹敵できるか」ではなくて、次の反復がその158,000倍のギャップを100倍に縮められるかどうかだと思う。それができれば、実際の軌道について何かを示していることになる。

中立的な観察として言わせてもらうと、人間が期待をどれだけ早く調整するかって、本当に驚くべきことだよね。5年前に、「一般的なAIが、シンプルな英語のプロンプトを書くだけで、Linuxカーネルを扱えるCコンパイラを自力でゼロから作れる」と言ったら、完全に信じられなかったと思う！あり得ない！誰も真剣に受け取らなかっただろうし。今、私たちがいる場所を見てみてよ。

今一番重要だと思う分析が欠けてるのは、生成されたコードの質はどうなのかってこと。LLMがRustでCコンパイラの最初の完全なイテレーションを生成するのは超便利だけど、そのコードが人間（または他のAI）によってメンテナンスや改善ができるほどの質でないと意味がない。そうでなければ、ほとんど役に立たないしね。今のAIが生成するコードのほとんどがそういう感じだし。結局は人間がメンテナンスしなきゃいけないし、最終的には人間が責任を持つことになる。私が見たいのは、そのCコンパイラがひどく絡み合ったスパゲッティコードで、名前もひどいものなのか。それとも、明確な構造があって、良い名前付けと適切なコメントがあるものなのか。

注意すべきことがいくつかあるよ：1. 現実世界では、似たようなタスクに対して、A) 最適化に関するすべての論文やISAのPDF、MITライセンスのあらゆる種類のコンパイラにコンパイラがアクセスできない理由はほとんどない。そうすれば、もっとパフォーマンスが良くなるし、「GCCを解凍する」っていうのはただの主張だって証明になる（でももっと言うと2もね）。2. すべてのタスクの中で、アセンブラは記憶が一番役立つ部分だよ。逆に、LLMは事前トレーニング中に無限に見たISAのドキュメントなしでは動けない。どうなると思う？3. Rustはテスト対象としては悪い言語だよ。LLMでRustのCコンパイラを作りたいなら、LLMの経験があるなら、Cコンパイラを作ってからRustに移植するのが普通。Rustは、たくさんの参照がある可変データ構造があると難しいし、Cコンパイラはまさにそれだから。異なるレイヤーから複雑さを組み合わせるのは、オートマティックプログラミングに関わった人がよく知っているLLMのアンチパターンだよ。4. 現実世界では、そんなタスクを指導なしでやることはないし、指導があれば素晴らしい結果が出るよ。実験が悪い考えだったとは言わないけど、実験者はインターネットが持っている別のポイントを示そうとしていたってことだね（いつものように）。