「ソフトウェアが遅い理由はもうない」——LLMが変えたパフォーマンス最適化の常識
There's no reason for software to be slow anymore
Dan Luu氏は、LLMの登場により、かつては専門家だけが行えた高度なパフォーマンス最適化が、誰でも数文のプロンプトで実行できるようになったと論じる。例として、ripgrepのクエリを2〜4倍高速化した実験や、世界最強のAzul AIを短期間で開発した経験を挙げ、最適化のコストが1000倍から100万倍も低下したと指摘。マーク・ブルッカー氏やマイケル・マリス氏の見解も引用し、特定のワークロードに特化した動的ソフトウェアの可能性を探る。
「かつては専門的なパフォーマンス作業のコストが何桁も下がり、まれなスキルを持つ人やチームを必要としていたパフォーマンス作業が、数文を入力できる人なら誰でもできるようになった」
HNでの議論
489- ehnto
遅さの最大の原因の一つは、単にウェブリクエストを待つことです。多くのソフトウェアがオンラインであるか、たとえそうでなくても同じスタックで構築されているという事実は、そのすべてのソフトウェアを使用中に常にブロック/待機状態に置きます。
米国外にいる人は、オンラインの多くが米国ホストであるため、これをさらに強く感じます。小さな操作ごとに300msかかると、すぐに積み重なります。
ソフトウェアのUIコントロールの多くに待機ダイアログやローディングホイールの余裕がある場合、デフォルトでブロックされることを前提に構築しています。たとえウェブベースのものを構築している場合でも、それが本当に必要なのか、それともUIのブロックを避けるために別の方法で構築できないかを自問してください。
- eaftan
私はSafeREという同様のエージェント工学を使った正規表現プロジェクトに取り組んでいます：
https://github.com/eaftan/safere
https://eaftan.github.io/safere-intro/
私のはJava向けで、本番グレードを目指しています。最初の目標は、ReDoS攻撃を防ぐために線形時間の動作を保証することです。私の共同研究者と私は最近、ネイティブRE2のパフォーマンスを超えるために最適化を進めています。
最適化はエージェントループに非常に適していることがわかりました。具体的な受け入れ基準（ベンチマークケースで意味のある改善を示すこと、テストに合格すること）があります。エージェントはプロファイラや逆アセンブラなどのツールを使うのが非常に得意で、私（20年間やってきた）よりも得意です。また、JavaのVector（SIMD）APIのインキュベーション中のような、私が学ぶのに時間がかかることを乗り越えてくれます。概念は理解していますが、Javaの実装を理解するには時間がかかります。エージェントはドキュメントを読んでそのまま進めます。
重要なのは、良いベンチマークスイートを作成し、エージェントがベンチマークケースに特化しすぎたり狭すぎたりする最適化を出荷しないようにすることです。また、正しさを後退させないように、非常に強力なテストスイートも必要です。SafeREには数十億のテストがあり、その一部の数百万がCIで実行され、残りはオンデマンドで実行されます。
- mccoyb
これを要約すると：
> プログラム空間S上の実行可能な最適化目的を持つ確率的探索プロセスは、目的を維持または改善することしかできない
これはスーパーオプティマイゼーションです。これは80年代から知られています（Massalin、STOKEはより最近：https://github.com/StanfordPL/stoke）。唯一の新しさは、提案者がLMによってはるかに優れていることです。
さらに、エージェントによって書かれたソフトウェアが遅くなる理由は多数あります：
- LMはまだデータやハードウェア指向の設計をすぐにはうまく行えず、したがって、非常に理解されたプログラムとワークロードを移植する以上の真剣な新しい作業に従事する場合、悪い割り当て決定（TigerBeetleがエージェントを使わない理由を参照）を追跡するのに何時間も費やすことになります。これらはしばしば悪の根源です（さらに何かに手を伸ばす前に）。
- 真剣なパフォーマンスを得るために必要なノブは、LMが得意とする言語ではほとんど到達できません（Rustでさえ、デフォルトの言語が強制しない規律が必要です）。低い領域に落ちると、これらのレバーにアクセスするために消費コンテキストを交換することになります。レバーも「ソフト」です：規律を強制するために、多くのスキルやツールを書くことになります。
現実には、エージェントから（迅速に）高性能なコードを得るには、高性能なコードの書き方を知っている必要があります（そして、そのようなものの検証器を作成するために使用する情報を[…]に表面化する方法を知っている必要があります）。
- hunterpayne
「LLMは遅くて肥大化したコードを引き起こしているが、すべてを超最適化されたアセンブリで書き直せば、彼らは後悔するだろう。」
この人は効率的なコードの作り方を理解していません。私は（いくつかの例外を除いて）ほぼすべての言語で、「超最適化されたアセンブリ」を上回るコードを書くことができます。効率的なコードを書くことは言語の問題ではなく、しばしば最良のアルゴリズムの問題でもありません（しかし時々そうでもあります）。それはメモリとキャッシュの使用を最適化することです。そしてそれは著者が書いていることとは直交しています。また、LLMはメモリ利用の最適化が苦手です。それをうまく行うトレーニングコードは少なすぎ、うまく行わないコードが多すぎます。
証拠として、私は文字通りウェブが遅くなっているのを感じます。他の多くの人も感じているでしょう。
- dkersten
ChatGPT MacOSXは、私のマシンで定期的にクラッシュする唯一のソフトウェアで、理由もなくメモリ消費が50GBに向かって急増します。
そしてそのソフトウェアは、世界で最も高給のソフトウェアエンジニアの一部によって、世界のすべてのLLM計算への完全なアクセスを持って構築されています。
- chvid
私は40年間コンピュータを使ってきました。それらは速くなっていません。1989年に構築した原子力プラントのコンピュータシステムは、選択した画面を1秒で表示する必要がありました。今日使っているアプリでそれができるものはないと思います。
- intrasight
私にとっての比較は常に3DsMaxとBlenderです。同じ種類のソフトウェアで、同じような機能ですが、Blenderの方がはるかに速いです。
アーキテクチャ上の決定は常に重要でした。
- jjcm
今では、ほとんどのソフトウェアが遅い理由は、リソースを制御する必要があるコテナンシーの理由、または単に競争から安全に隔離されているためだと理解しています。例えば、GitHubは前者です：自分自身でgitホストとCI/CDシステムを提供でき、ソーシャル機能を使わないので、はるかに高品質なものを自分で作れます。Appleの5本指内側ジェスチャーは後者だと思います。以前はそれを行うとすぐに入力できましたが、今ではキーストロークが登録される前にアニメーションなどをレンダリングする必要があります。このソフトウェアは、MacOSで置き換えられないため遅いのです。
しかし、これらすべては時間とともに変わるでしょう。地獄は他人のソフトウェアです。