ソフトウェアが遅い理由など、もはや存在しない

先日、LLMが遅くて肥大化したコードの原因だと言う人々は、すべてをスーパー最適化されたアセンブリで書き直せば、その間違いを悟るだろうというバイラルツイートを見た。私たちはまだすべてをアセンブリで書きたいという段階には達していないが、ノーラン・ローソンがテストについて述べたことの変種、つまり、バグの数を自分で選べるということが、より下品に私がここで述べたように、パフォーマンスに関しても真実になりつつある。私の前回の投稿へのコメントで、かつて専門的だったパフォーマンス作業のコストが何桁も低下し、稀なスキルセットを持つ個人またはチームを必要としていたパフォーマンス作業が、数文をタイプできる人なら誰でも行えるようになったという指摘に対し、マーク・ブルッカーは「あなたの締めくくりの点には完全に同意します。動的なカスタムソフトウェアは、ワークロードのクラスではなく、特定のワークロードに適合するようになる可能性が非常に高いです。（それはそれ自体で、多くの楽しいリスクと機会をもたらします）。FFTWや、非常に特定の問題（そしてしばしば非常に特定のハードウェア）で超高速かつ小型化することにすべてを賭けた、多くの奇妙な古いデモシーンのテクニックを思い出させます。例えば、キャッシュの局所性を高めるためにコードをテクスチャとして再利用したデモを覚えています。マイケル・マリスは、「AIは『コードは決して難しい部分ではなかった』という理由で役立たない」というミームが広まっていると指摘しています。これはいくつかのドメインでは真実だと思いますが、他のドメインでは、コードを書くことが間違いなく難しい部分でした。JITコンパイラはその良い例です。多くのソフトウェアでは、JITコンパイラはコードの高速化に大いに役立つでしょう。JITコンパイラが珍しいのは、歴史的にJITコンパイラの実装が、それに見合うだけの価値があるほど困難だったためだと考えられます。LLMは参入障壁を下げ、JITコンパイラを書くことをはるかに容易にしました。これはpgrustの背後にある論文です。データベースは歴史的に構築が最も困難なソフトウェアであり、そのために制限されていました。今、AIを使えば、構築するソフトウェアの種類について、より野心的になれるのです。 ワークロードのクラスに最適化する これを、前回の投稿で作成した正規表現エンジンであるFREで試してみましょう。エージェントがrebar正規表現ベンチマークスイートにアクセスして、正規表現エンジンのパフォーマンスを向上させるために1か月間ループした結果、FREはリバー（rebar）に過度に適合していましたが、ホールドアウトベンチマークがあることをエージェントに警告したところ、エージェントは最適化を一般化し、ホールドアウトでのパフォーマンスがまあまあになるようにしました。ホールドアウトベンチマークで、よくテストされた正規表現エンジンに勝てない「ソフトウェアファクトリ」正規表現エンジンを使用する特別な理由はありませんが、FREの注目すべき点は、ネイティブAOTコンパイルバージョンが長い検索で非常にうまく機能したことです。ネイティブコードコンパイラを別のスレッドで実行し、ripgrepが通常のマッチャーを実行している間に、コンパイルが完了したらネイティブコードに切り替えることで、一般的にパフォーマンスが向上する可能性があることに気づきました。もちろん、コンパイルにスレッドを1つ失うため、短いクエリではパフォーマンスが悪化しますが、数秒で実行される場合よりも、数秒または数分実行される場合のripgrepの実行時間の方がはるかに重要なので、そのトレードオフは許容できます。同様に、数分間の人間の時間で正規表現エンジンを構築できるだけでなく、数分間の人間の時間でこの実験を試すこともできます。私は数文をタイプし、エージェントが作業を行い、これを可能にしました（人間にとってはかなりのコード手術になるでしょう）。そして、私のコード履歴から来る実際のripgrepクエリでベンチマークを実行しました。長いクエリでは、非常に単純なクエリで2倍から4倍のパフォーマンス向上が見られます。しかし、ほとんどのクエリはより複雑であり、代表的なホールドアウトクエリで実行すると、AOTが有効になるはずのクエリでは、約7%のスピードアップが得られます。驚異的な結果ではありませんが、Codexに数分間タイプして得られた結果としては悪くありません（そして、それはまだ最適化を続けており、おそらくさらにスピードアップするでしょう）。 インデックスを構築する？ これは議論の余地があるほど愚かなことです。なぜなら、コンピューター上で繰り返しテキストを検索する場合、それを高速化するための明らかな方法は、正規表現マッチング用のネイティブコードコンパイラを書くことではなく、インデックスを作成することだからです。しかし、ここでのポイントは、かつてはかなりの時間と専門知識を要したこの種の技術作業が、今では簡単に実行できるということです。そして、テキストインデックスを構築したい場合、私はちょうどBitFunnel、SIGIRで最優秀論文賞を受賞した、定数/高速なテキスト取り込みに特化したBingの検索インデックスに取り組んだことがあります。そのため、コンピューター全体を高速ローカルインデックス構築する場合、試すべき実験がいくつか考えられます（私が知っているプロジェクトはコードディレクトリをインデックスすることを意図しているようですが、私のマシンのパフォーマンスを本当に低下させるのは、Codexが大量の生成ファイルを持つ巨大な一時ディレクトリに対してripgrepを実行し、見逃したときに私のマシン全体を見るように展開することです。そのため、一部のプロジェクトのコードだけでなく、ディスク全体をインデックスしたいのです）。AIラボで働き、Cerebrasチップやその他のアクセラレータで実行されるSOTAモデルのようなものにアクセスでき、トークン/秒を大幅に増加させ、それによって検索の負荷/需要を増加させることができる場合、既存のインデクサーが十分に高速かどうか、またはカスタムで何かを構築したいかどうかを調査するかもしれません。BitFunnelのオープンソースバージョンにはバイトコードインタープリターと1つのJITしか含まれていませんが、Bingバージョンには複数のJITコンパイラが含まれています。そのレベルの最適化を行ったプロジェクトはかつては大きな事業でしたが、「週末にできる」が今では実際にこれらの種類のプロジェクトの一部で真実になっています。私の貧弱な月額200ドルのアカウントでは、いくらか高速なripgrepと、市販のインデックスがあれば十分だと思います。そのため、この高速取り込みの全マシンインデックスプロジェクトは、「読者（AIラボで働く人）への演習」として残しておいてもよいでしょう。 最適化は安価である 最適化コストの劇的な低下は、2025年11月まで続いており、おそらくそれ以前の公開モデルでも（そしてAIラボの担当者がアクセスできたものについては、それ以前から間違いなく）真実でした。GPT-5.1または5.2時代の例として、ゲームAIの知識なしに、Azul AIを構築しようとしました。これは、そのゲームにおいて、かなりの差で世界で最も強力なAIとなりました。2番目に強力なAIを記述した論文を読むと、私のAIはおそらく「AI」の側面では少し優れていると思いますが、私が勝っている主な場所は最適化です。例えば、その他のAIはシングルスレッドですが、私のAIはマルチスレッドです。ネイティブコードバージョンと、ひどいwasm共有メモリ+JavaScriptバージョン、そして2つの異なる検索アーキテクチャ（非常に小さく高速なネット用のミニマックスと、より大きなネット用のMCTS）があるため、これらは手作業で行うとかなりの大事業になったでしょう。そして、ゲームAIのマルチスレッドアルゴリズムについて自分で30分間読む前に、LLMに（誤った）推論に基づいてマルチスレッドアルゴリズムを選ばせたため、マルチスレッドアルゴリズムを複数回書き直しました（Codexに書き直させました）。このようなもののマルチスレッドアルゴリズムをデバッグおよび検証するために行うべき標準的な作業がたくさんありますが、エージェントがループで簡単に実行できる種類の作業です（ログをリプレイし、非決定性に対処するためのロギングを挿入させるだけです。これだけでも手作業で行えば数日から1週間かかる作業だったでしょうが、エージェントがループで簡単に実行できるまさにその種の作業です。非決定性に対処するためにロギングを挿入するだけで済みます。