前幾天，我看到一則爆紅的推文，說那些抱怨 LLM 會產生又慢又臃腫的程式碼的人，等到所有東西都被重寫成超級最佳化的組合語言後就會被打臉。我們還沒到想把所有東西都用組合語言來寫的地步，但 Nolan Lawson 談測試時說的某個觀點的變形——你現在可以自己選擇要多少 bug，這點我之前也用比較拙劣的方式提過——在效能上正變得越來越貼切。

回應我在上一篇文章裡提到的一則留言——過去那種高度專業的效能工作成本已經下降了好幾個數量級，過去需要具備罕見技能的一個人或一整個團隊才能做的效能工作，現在任何會打幾句話的人都能做¹，這意味著，過去只有在規模最大或最賺錢的專案上才值得做的各種最佳化，現在都能做了——Marc Brooker 回應道

完全同意你最後的觀點。針對特定工作負載量身打造的動態客製化軟體，而非針對某一類工作負載，似乎是很可能出現的結果。（這本身也會帶來各種有趣的風險與機會）。這讓我想起 FFTW。以及一大堆奇怪、古老的 demoscene 技巧，那些技巧全都是為了在非常特定的問題（而且往往是非常特定的硬體）上做到極快、極小。例如，我記得有一個 demo 會把自己的程式碼重複利用當成材質，以獲得很好的快取局部性。

而 Michael Malis 則指出

最近有個迷因在流傳，說 AI 幫不上忙，因為「寫程式從來就不是困難的部分」。我覺得在某些領域這是真的，但在其他領域，寫程式絕對就是困難的部分。JIT 編譯器就是很好的例子。對很多軟體來說，JIT 編譯器會對加速很有幫助。JIT 編譯器之所以稀少，讓我相信過去實作一個 JIT 編譯器的難度太高，高到不值得做。LLM 降低了門檻，讓撰寫 JIT 編譯器變得容易許多。這就是 pgrust 背後的論點。資料庫過去是最難打造的軟體，也因此受到限制。現在，有了 AI，我們在打造的軟體類型上可以更有野心。

針對一類工作負載的最佳化

我們來用 FRE 試試看吧，這是我們在上一篇文章中打造的 regex 引擎。回想一下，它是讓一個 agent 在能夠存取 rebar regex 基準測試套件的情況下，循環跑了一個月、不斷改進 regex 引擎效能而產生的。結果就是 FRE 被嚴重過度擬合到 rebar 上，直到我們警告 agent 我們還有一個保留的基準測試，它才把最佳化泛化得足夠好，讓在保留測試上的表現變得還算可以。一個在保留基準上沒有打贏經過充分測試的 regex 引擎的「軟體工廠」式 regex 引擎，本來就沒有特別的理由去用，但 FRE 有一個值得注意的地方是，原生 AOT 編譯的版本在較長的搜尋上表現得相當好。我們提到過，很自然會想到，可以在 ripgrep 用一般的 matcher 執行時，同時在另一個執行緒裡跑原生碼編譯器，等編譯完成後再切換到原生碼，通常就能獲得更好的效能。當然，這通常會讓短查詢的效能變差，因為我們要分掉一個執行緒去做編譯，但比起只跑幾秒的情況，我更在意 ripgrep 跑上好幾秒甚至好幾分鐘時的耗時，所以我可以接受這個取捨。

就像我們能在幾分鐘的人工時間內建出一個 regex 引擎一樣，我們也能用幾分鐘的人工時間試試這個實驗。我打了幾句話，agent 就去把讓這件事成真所需的工作完成了（這對人類來說會是相當大規模的程式碼手術），並且用來自我的 codex 紀錄中實際的 ripgrep 查詢跑了基準測試。對於較長的查詢，我們在幾個非常簡單的查詢上看到了 2 到 4 倍的效能提升。但大多數查詢更為複雜，當我們用具代表性的保留查詢來跑時，對於那些應該啟用 AOT 的查詢²，我們得到了大約 7% 的加速。算不上驚天動地的成果，但考慮到只花了幾分鐘對 codex 打字（而且它還在繼續最佳化，之後還會再變快），也不算差了。

要不要建個索引？

這件事可以說有點蠢，因為如果我們是在電腦上反覆搜尋文字，要加速最直覺的做法不是為 regex 比對寫一個原生碼編譯器，而是建立一個索引。但這裡的重點只是在於，這種過去需要花費大量時間與專業知識的技術工作，現在可以輕而易舉地完成。而如果我們想建一個文字索引，剛好我曾參與過 BitFunnel，也就是那個專為持續、快速文字寫入而特化的 Bing 搜尋索引，它還拿過 SIGIR 的最佳論文獎，所以對於要在整台機器上建一個快速的本地索引，我能想到幾個可以嘗試的實驗（我看過的那些專案似乎都是打算索引你的程式碼目錄，但真正拖垮我機器效能的，是 codex 決定對著一堆含大量生成檔案的巨大暫存目錄跑 ripgrep，沒找到後又擴大搜尋到整台機器，所以我會想要的是整顆硬碟的索引，而不只是某些專案的程式碼）。

如果我是在 AI 實驗室工作，能用到像跑在 Cerebras 晶片或其他加速器上的 SOTA 模型、因而大幅提高 tok/s 進而加重搜尋的負載／需求，我或許真的會去檢視現有的索引器夠不夠快，或是考慮自己打造一個客製化的。但 BitFunnel 的開源版本「只有」包含一個 bytecode 直譯器和一個 JIT，Bing 的版本則包含多個 JIT 編譯器。過去要做到那種程度的最佳化的專案會是一項重大工程，但「我週末就能做完」現在對這類專案來說真的成真了。以我一個月 200 美元的低階帳號來說，我覺得稍微快一點的 ripgrep 加上任何現成的索引就夠用了，所以這個能快速寫入、涵蓋整台機器的索引專案，或許就留作「給（在 AI 實驗室工作的）讀者的習題」吧。

最佳化變便宜了

最佳化成本的大幅下降，早在 2025 年 11 月就已成真，甚至用公開模型的話可能還要更早一點（而對於在 AI 實驗室裡能拿到內部模型的人來說，肯定更早）。舉一個 GPT-5.1 或 5.2 時代的例子，在對遊戲 AI 一無所知的情況下，我試著做了一個 Azul 的 AI。結果它成了世界上最強的 Azul AI，而且還領先不少。從描述第二強 AI 的論文來看，我覺得我的 AI 在「AI」本身這方面或許好一點，但它真正勝出的地方是在最佳化上，儘管我花的時間看起來可能少了兩個數量級（透過閱讀論文、觀察其流程並與我的流程對比所估計），而且大多是在我的筆電上完成，而非擁有一整個機器叢集可用（這意味著能用來跑實驗、做參數調校等的頻寬要少得多）。舉例來說，那個另一個 AI 是單執行緒的，而我的 AI 是多執行緒的。由於我有一個原生碼版本以及一個可怕的 shared wasm memory + javascript 版本，還有兩種不同搜尋架構給兩個不同版本，分別「需要」完全不同的多執行緒演算法（一個給非常小、非常快的網路用 minimax，另一個給較大的網路用 MCTS），如果用人手來做，這本來會是相當龐大的工程。而且，因為我曾幾次讓 LLM 根據它自己（錯誤的）推理來挑選多執行緒演算法，之後才自己花了 30 分鐘去讀了遊戲 AI 的多執行緒演算法，我最後還重寫（讓 codex 重寫）了好幾次多執行緒演算法。

對於這類東西，有一大堆標準做法可以用來除錯和驗證多執行緒演算法，例如從除錯日誌中重播，以便在演算法本身具非決定性的情況下仍能重現 bug。光是做這件事，如果用人手做，大概就要花上幾天到一週的時間，但這正是 agent 可以輕鬆地在循環中自動完成的那種事（只要讓它嘗試重播日誌，每次無法完美重播時就插入針對非決定性的日誌即可）。過去為了讓這種棘手的最佳化真正運作起來所需的許多繁瑣工作，已經消失了。

這也適用於許多其他棘手的最佳化。從寫過 CPU 微碼、做過 CPU 驗證、做過搜尋引擎索引的最佳化等經驗來看，我有很多次看著某個最佳化，心想「嗯，這會讓效能提升 2%，但要驗證這個棘手的最佳化真的能動，需要花 N 個人天」，然後根據是否值得花時間去讓這個最佳化上線來做決定。現在這個 N 已經以驚人的幅度下降（幅度不一，但以人工時間來說，經常是 1000 倍／10000 倍／1000000 倍，如果以按量計費的 token 成本來比當初寫搜尋索引所用 JIT 的那位 Bing 工程師的成本，大概更像是 1000 倍），值得去做的這類最佳化的數量就大幅增加了。對於那些還不確定是否真的會有效果的最佳化，情況也是一樣。以前我有時會看著一個不確定能否加速的最佳化，心想「要做到能有足夠好的測量來推測效能影響的程度，需要花 M 小時來實作」。現在更多這類最佳化也值得一試了。

回到遊戲 AI 的例子，至少就我試過的這個 AI 而言，速度每翻一倍，似乎就能多獲得大約 100 Elo（比西洋棋多，我猜是因為和局非常少）。光是加上多執行緒，就足以在一台大型機器上徹底打敗一個其他方面相當的 AI。如果再疊加 10 到 20 個大多數人覺得用人手做太麻煩的最佳化，實力差距會變得非常巨大，用人手寫的 AI 根本沒法跟上³。

遊戲 AI 的情況比大多數軟體要麻煩一點，因為許多你想做的最佳化實際上會改變結果，而且沒有便宜、簡單的方法能判斷速度提升加上結果改變後，實際效果在實務上是變好還是變壞。而且，如同我們之前提到的，目前公開可用的 SOTA 模型在實驗設計上很不擅長，所以我得自己架好它們用來判斷某個最佳化是否有效的框架，但一旦架好之後，就跟其他任何最佳化問題一樣了。我猜做 LLM 最佳化的人也得處理這類問題，但大多數最佳化問題要單純得多。

再舉另一個例子，為了準備效能面試，Jamie Brandon 嘗試了 Anthropic 現在已公開的效能回家作業。在他嘗試過後，他讓 Claude 接手他停下的地方繼續做，結果得到了好得多的成果。當他檢視 Claude 做了哪些他沒做的事時，他說很多最佳化是他有想到但還沒來得及做的，「其他的根本就是瘋狂的點子，除非我花上好幾週來做這個，否則我根本不會去嘗試」⁴。他算是個稱職的效能工程師，也拿到了他想要的那份效能工作的 offer，但在一個定義明確的最佳化問題上，他對上一個還不錯的模型是毫無勝算的（我自己沒試過那個題目，但我猜在時間條件相近的情況下，我大概也毫無勝算）。

針對特定工作負載的最佳化

針對特定工作負載量身打造的動態客製化軟體，而非針對某一類工作負載，似乎是很可能出現的結果。

這似乎相當無可避免。在另一則對我文章的回應中，做 pgrust 的 Michael Malis 也說了類似的話：

[關於 pgrust 最佳化的討論] …… 我覺得要做出這些最佳化已經夠容易了，我們完全可以看看客戶的工作負載，然後按需加上它們

在沒有任何框架或準備的情況下，就在開始寫這篇文章之前，我讓一個 agent 針對我的 ripgrep 查詢做了特定工作負載的最佳化（不是原生碼編譯器的切換，只是針對一組基準對一般 FRE 引擎做的最佳化），這花了我大約 2 分鐘來啟動。這些最佳化在一組查詢上執行，然後會再用之後保留的一組查詢來驗證。那個還在跑，但初步結果看起來很有希望。經過一輪最佳化後，針對工作負載最佳化的版本在保留測試上比標準的 ripgrep 快了 2%，而且還在持續變快。2% 對我本地的 ripgrep 使用來說不算什麼大事，但考慮到這只花了幾分鐘的時間，而且這裡做的最佳化是從我開始寫這一段時才啟動、還在持續改進，我願意接受這 2% 的提升（注意，這還沒跟原生碼編譯器結合，如果正確地結合起來，整體提升會更大）。也請記得，這是利用了 FRE 這個 regex 引擎⁵，它在保留基準上原本大幅落後於 Rust 的 regex crate，而且在保留測試上的改進一直卡住，因為在完全不了解 regex 工作負載、且 SOTA LLM 在實驗設計上還不夠好、無法進行無引導的開放式自我改進循環的情況下，我們沒有好方法能在保留測試上提升效能。但如果我關心的是在我自己工作負載上的效能，我有大量的資料，而且還在不斷產生更多。就像 Marc Brooker 在上面提到的，如果出現舊資料中沒有的情境轉變等等，我們確實得小心過度擬合，但即便如此，我們的處境仍比以前好得多。

在更一般的情況下，如果你是像在 Amazon 的 Marc Brooker 或在做 pgrust 的 Michael Malis 那樣的人，與其把這當成一次性的嘗試，不如與客戶合作試點一個利用他們的資料來為他們做最佳化的計畫，然後再想辦法將其規模化推廣給一般客戶。我不是在那種把時間花在這上面最划算的公司工作⁶，但很神奇的是，你可以看到這對規模更大的公司來說即將到來，而且鑑於我只花幾分鐘就能為我的個人工作流程跑這些實驗，在個人專案上玩玩這類東西是相當合理的。

感謝 Jamie Brandon、Michael Malis、andrea (@s__video)、Artyom Bologov 和 Max Bittker 提供的意見／更正／討論。

附註：如同我在前一篇提到的，有了 coding agent，跑一個實驗並看到足以滿足我好奇心的初步結果所需的時間已經大幅縮短，而要讓結果真正嚴謹所需的時間則沒有變，甚至變長了，所以如果用我以前的方式來寫文章，相對於我擁有的頻寬，能跑的實驗數量就會非常少。因此，我就只是跑這些實驗，然後把結果分享給幾個朋友。作為一個實驗，我試著用這種非常快速、非嚴謹的方式把它們寫出來，而不是讓這些實驗在好幾年內只有少數朋友知道。跟上一篇文章一樣，我給自己設了半小時內完成這篇文章及所有整理的目標，雖然沒計時，但我確定有稍微超時。

即便如此，寫這些東西所花的時間還是長到讓我在分享最新結果的進度上落後了，但我目前還不想換成用 LLM 來寫文章，而且我不覺得我真的能把整理資料、寫成像這樣一篇文章所需的時間再壓低到能在半小時內搞定。光就這篇文章的長度來說，打這些字就應該要花個 20 到 30 分鐘，還包括停下來思考要寫什麼的時間，然後當我檢視資料時，有時會看到某些看起來不太對勁的地方，需要更仔細地追查，看看是否有需要修正的問題（這在這裡就發生了好幾次，而且我預期，因為我沒有花更多時間，還有其他我沒發現的資料問題）。

總之，如果你對這些快速（而且肯定更常出錯）的寫法有什麼想法，歡迎告訴我（X Bsky Mastodon）！

附錄：軟體已經沒有理由再慢下去了

我一直以來都公開強烈不同意那種「X 的開發者很爛、應該感到羞愧」的大眾看法，認為他們寫出慢吞吞的程式碼就該自責，因為程式設計的專業有非常多種，不僅大多數程式設計師本來就沒有什麼效能專業，甚至從他們去發展這種專業是否划算的角度來看（從公司在乎什麼、就業市場長什麼樣子等等），可能本來就不該去發展，所以當然大多數專案的效能跟效能專家能做到的相比，會非常糟糕。我能理解為什麼效能專家會看著這個越來越大的差距——程式可以有多快與程式實際上有多快之間——覺得這很荒謬。我並不否認這之中有荒謬之處，但如果我去想想 UI 可以有多好跟我（親手）能做出的 UI 有多好之間的差距，我不覺得那看起來有比較不荒謬，但我也不覺得我真的該花時間去學怎麼打造一個很棒的 UI，甚至是一個還不錯的 UI，原因跟大多數人不該花時間去學怎麼做好效能工作是一樣的。

以上面的例子來說，Jamie Brandon 拿到了 Anthropic 的 offer，除非你是 OpenAI，否則你大概請不起他，但你請得起在有明確範圍的最佳化問題上能打敗他的 coding agent。這個 agent 沒有他那樣的判斷力，在開放式問題上會表現得比較差（回想一下，當我們試著打造一個最佳化的 regex 引擎、只告訴它不要過度擬合時，它在我們的保留基準上比最好的 regex 引擎差了一個數量級以上，但也請記得，在告訴 agent 它在保留測試上表現很差之後，它把 regex 引擎的效能提升到足以大致匹敵第二梯隊的 regex 引擎，就一般程式碼現在普遍的最佳化水準來看，這已經非常好了），但這已經足以在各種問題上達到還不錯的效能。這篇文章大致上討論的是後端效能問題，但如果你想壓低像 LCP 和 CLS 這類指標，agent 在前端效能上似乎也不差。事實上，在把我最近一直在用的互動式圖表放進文章後，我發現我的前端效能數據變差了，所以我就讓 LLM 花了我每週額度的 1% 去做最佳化，數據就又恢復到不錯的水準了。這是個非常簡單的網站，但人們在要交付給數百萬使用者的相當複雜的應用程式上做這類最佳化，也同樣可行，雖然確實會多花一點 token。

我仍然不覺得有人如果軟體效能很差就是很爛、應該感到羞愧，但我確實認為，一個對效能一無所知、卻是個還算會用 LLM 的人（泛指一般使用，而非特別針對效能問題），應該大致上都能做出效能還不錯的軟體。如果你只是叫 LLM 去做最佳化，它常常會做出各種錯誤且非常糟糕的事情，你得去抓出來，但這本來就是有效使用 LLM 的常態，所以要獲得還不錯的效能，已經不再是一項專門技能了。

附錄：codex 是怎麼跑 ripgrep 的？

以下是關於我機器上 ripgrep 查詢分布的一些資訊。我不聲稱這在任何其他地方有任何代表性。搜尋樣式長度的分布中，長樣式的數量比我預期的要多得多。中位數是 55 個 Unicode 碼位（為簡單起見我就稱之為字元），這已經比我用人手去 grep 時會打的東西還長，而 p90 是 119！

我們也可以看看 regex 中 alternation 分支的數量，也同樣比我用人手操作時複雜得多。

另一種觀點是看看這兩者之間的相關性。隨著 regex 變長，alternation 的分支會變多嗎？會的。

那這些真的很長的 regex 到底是什麼呢？如果我們檢視它們，最長的大多是針對函式或測試名稱的長 alternation，例如下面這個 regex，它看起來跟 FRE 的開發有關。

  fn (hot_byte_compiler_is_generic_only_and_anonymous_count_uses_auto_count|
  one_pattern_count_spans_uses_the_retained_complete_span_session|
  formal_compact_state_byte_visitors_coexist_with_native_count|
  fixed_boundary_record_visit_matches_line_relative_reference_and_is_atomic|
  unbounded_languages_refuse_finite_extraction_before_allocation|
  formal_single_raw_span_sweep_preflight|
  assert_exact_fixture_uses_formal_large_continuation_sweep|
  url_only_compile_identity_binds_language_and_owner_mode|
  url_only_compile_exact_limits_and_runtime_refusals_close|
  url_only_compile_post_plan_allocation_faults_close|
  url_only_owner_discriminator_is_stable_and_precharged|
  url_only_compile_owner_is_strategy_and_operation_scoped|
  formal_rebar_url_owner_is_compile_only_and_matches_oracle|
  formal_rebar_url_exact_fixture_uses_certified_execution|
  formal_fixed_schema_materialization_matches_both_record_oracles_and_controls|
  formal_single_count_selects_compact_state_byte_complete_bound_visitors|
  authenticated_bound_line_total_lf_free_domain_opportunity_exceeds_five_percent|
  prepared_absolute_onepass_fuses_slots_and_preserves_pre_source_fallback|
  authenticated_word_boundary_russian_compact_lowering_public_canary|
  ordered_nfa_x86_epsilon_edges_bypass_the_assertion_call|
  ordered_nfa_aarch64_epsilon_edges_bypass_the_assertion_call|
  ordered_edge_dispatch_v2_is_target_neutral_deterministic_and_relocation_free|
  ordered_edge_dispatch_v2_copies_canonical_tables_and_cap_falls_back_to_v1|
  ordered_nfa_v3_composes_terminal_range_and_dispatch_without_data_relocations|
  ordered_nfa_x86_terminal_range_emits_authenticated_reverse_scan|
  ordered_nfa_aarch64_terminal_range_emits_authenticated_reverse_scan|
  ordered_nfa_x86_boundary_assertion_cache_is_lazy_and_boundary_scoped|
  ordered_nfa_aarch64_caches_repeated_assertions_once_per_boundary|
  boundary_assertion_cache_requires_dense_exact_kind_reuse|
  boundary_assertion_cache_selection_is_compiler_only_and_deterministic)

但有些是有趣的數字構造，例如

:(13[0-9]|14[0-9]|15[0-9]|16[0-9]|17[0-9]|18[0-9]|19[0-9]|20[0-9]|21[0-9]|22[0-9]|23[0-9]|24[0-9]|25[0-9]|26[0-9]|27[0-9]|28[0-9]|29[0-9]|30[0-9]|31[0-9]|32[0-9]|33[0-9]|34[0-9]|35[0-9]|36[0-9]|37[0-9]|38[0-9]|39[0-9]|40[0-9]|41[0-9]|42[0-9]|43[0-9]|44[0-9]|45[0-9]|46[0-9]|47[0-9]|48[0-9]|49[0-9]|50[0-9]|51[0-9]|52[0-9]|53[0-9]|54[0-9]|55[0-9]|56[0-9]|57[0-9]|58[0-9]|59[0-9]|60[0-9]|61[0-9]|62[0-9]|63[0-9]|64[0-9]|65[0-9]|66[0-9]|67[0-9]|68[0-9]|69[0-9]|70[0-9]|71[0-9]|72[0-9]|73[0-9]|74[0-9]|75[0-9]|76[0-9]|77[0-9]|78[0-9]|79[0-9]|80[0-9]|81[0-9]|82[0-9]|83[0-9]|84[0-9]|85[0-9]|86[0-9]|87[0-9]|88[0-9]|89[0-9]|90[0-9]|91[0-9]|92[0-9]|93[0-9]|94[0-9]|95[0-9]|96[0-9]|97[0-9]|98[0-9]|99[0-9])[0-9]:

這相當於 :(?:1[3-9]|[2-9][0-9])[0-9]{2}:（如果用這個較短的 regex 對原始輸入跑 ripgrep，效能大致相同；較短的 regex 在真實查詢資料上技術上是快了一點點，但只快了非常少）。整個 pipeline 是

cargo clippy … | rg 'crates/fre-aot-regex/src/module.rs:' | rg NUMBER_REGEX | head -250

這對人類來說或許是件奇怪的事，但 agent 似乎一直都在做這種事。

換個話題，如果我們看看 ripgrep 查詢花了多久，會發現有相當多很慢的查詢，例如 p99 幾乎要 1 分鐘！而 p999 幾乎要 10 分鐘！而在這段時間內（在我這台筆電上大約一個月；查詢和分布在我在 AWS 主機上跑 agent 的情況等可能很不一樣，但我還沒檢查）的最大查詢接近 2 小時！

就命令列選項而言，我們看到如下情況。或許不令人意外，codex 經常想要行號，而且不知為何，它偶爾會使用 PCRE2 regex。

我不會為這些加上圖表或表格，但另一件值得注意的事是，搜尋的樣式本身局部性相當低（約 94% 的樣式只出現過一次），考慮到很多查詢都很長，這算合理。然而，被搜尋的檔案局部性則相當高，一個被搜尋過的檔案相對很有可能很快又被搜尋，顯示（對於夠小的檔案而言）它們很可能是在記憶體中被搜尋的。

另外，99% 的查詢是 regex 查詢（1% 是非 regex 的字串搜尋），而 99.9% 的搜尋查詢僅含 ASCII，但就被搜尋的檔案而言，大約 45% 僅含 ASCII、55% 包含 Unicode，這個 Unicode 的比例比我猜的還高。

在上一篇文章的草稿上，Peter Geoghegan 提到

一個 regex 實作也有可能因為支援較少的功能而變得更快。有些實作不支援反向參照等等。

這在這裡也同樣成立。這裡所做的針對特定工作負載的最佳化相當淺層，因為我只是給了 codex 一些簡短的指示，就讓它隨意發揮（這一般來說不是最有效率地使用 codex 的方式），但如果有更詳細的計畫，針對我查詢的常見使用情境做更聚焦的最佳化，應該能帶來更大的提升。