2026.09.03 —— 今日 10 則
TODAY'S THREAD 今天三篇深入文章都是把一件已經算解決的事再量一次，然後量出不一樣的數字——Cloudflare 把已經進 cache 的物件再壓一次，平均縮到原本的三分之一；shnatsel 把 stdlib 的 fma 再算一次，撿到 subnormal 的捨入錯誤；boringsql 把 replica 的讀再驗一次，一千次讀有九成九讀不到自己剛寫的那筆。
把工具輸出壓短，整趟任務反而更貴
GitHub 拿 A/B 量了四項改動對 Copilot coding agent 的成本影響：移除 view 的行號前綴省 3.1%、選擇性輸出壓縮 5.5%、精簡 task-tool prompt 2.9%、減少通知往返 2.3%。他們一開始把工具輸出壓得更激進，結果是「when the omitted text mattered, the model sometimes reopened the original output or reran the command to recover what it needed」，成本不降反升。真正有用的判準不是輸出長度，而是量 agent 有沒有重開存檔、重跑指令、重複探索。
Meta 把專家判斷編譯成知識層，而不是重訓模型
這套系統由三塊組成：200 多個檔案構成的知識架構（positions、taxonomy、routing index）、把「知道什麼」與「怎麼推理」拆開的 composable recipe，以及把專家回饋編譯成已驗證更新的自我改進迴圈。六週後領域專家對輸出的評價是「useful almost all the time」，原本以天計的評估縮到分鐘，改進循環回報「zero regressions across improvement cycles」。值得記住的是整條路徑都沒有動模型權重，變動全部發生在知識層與流程層。
把上限寫死在啟動參數，讓崩潰提早發生
matklad 把兩條互補的規矩擺在一起講：static allocation 是啟動時就照 --orders-max=1_000_000 這種上限一次配好，執行期不再動態配置；constant work 則是每輪都做固定份量的工作，用中性或保留狀態把分支拉平，讓 CPU 有機會預取與向量化。這樣換到的不是省記憶體，是把失敗從執行期搬到啟動期，順帶少掉一整類 use-after-free。驗收條件文中寫得很白：「If the maximum amount of orders is active, does the system have acceptable performance? If not, that is a bug!」
Wasmi 2.0 重寫引擎，純直譯器追到 2.2 倍
Wasmi 2.0 在 wasmi-benchmarks 上以幾何平均計是「~2.2x faster than Wasmi 1.0」（Apple M2 Pro）。加速來自四種 dispatch 模式（direct-threaded、indirect-threaded、switch-loop、call-loop）、把值留在硬體暫存器而非 stack slot 的 accumulator register、改成連續佈局的 instance 存取，以及能把函式指標烘進 bytecode 的 lock-free code map。單一影響最大的改動其實來自 Rust 1.92 的 DestinationPropagation 修正，光是這一項就把 Wasmi 2.0 自己的 CoreMark 分數從約 2800 推到 4200 以上。作者給的定位是「the fastest portable Wasm interpreters」這一級，同時保住跨 instance 共用 module bytecode 的能力。
寫一個 FMA，順手撿到 stdlib 的 bug
作者本來只是要替 fearless_simd 實作向量化的 fused multiply-add，比對參考實作時發現 Rust 的 compiler-builtins 與 musl libc 都「fail to properly handle rounding for subnormals」。Rust 端是 issue #1262 配 PR #1270，失敗輸入 a = 0x97000800、b = 0x1cfff001、c = 0x00010002 應該回 0x00010001 卻回了 0x00010002；另有一個影響 32-bit ARM 上 f128 的 rustc ABI bug 記在 issue #1271。musl 那份實作源出 2005 到 2011 年的 FreeBSD，同一個 subnormal 缺陷可能早已散進大量嵌入式工具鏈。
快取裡的東西，值得再壓一次嗎
Cloudflare 在 Pingora 裡把進 cache 的資源先用 zstd level 3 編碼再落盤，送給 client 時才解開，跨資料中心走 Tiered Cache 的期間也維持壓縮狀態。原型上符合條件的資源平均「shrunk to ⅓ of their original on-disk size」，測試語料的壓縮比是 2.834x。代價量得很清楚：編碼 4.31 ns per byte、解碼 1.56 ns per byte，在測試流量下額外 CPU 只有「a few percent」。
三個網域生出 21 萬頁，專門餵給 AI 引用
Trellner 分析了 Perplexity 在 380 個軟體分類裡的 7,534 筆引用，結論是「59.8% of the sources behind grounded AI recommendations sit outside the 100,000 most-visited websites」。三個註冊於 2023 年 12 月到 2024 年 5 月間的網域，合計產出 215,128 頁 best 某分類的頁面，其中兩個站在 HTML metadata 裡把自己標成「Facts & Grounding Page」——這句話是講給機器聽的。GuideFlow 的行銷部落格以 194 次引用排到整體第三，而它根本不是評測站。
繞了一圈，瀏覽器裡最快的編輯器還是 textarea
dbushell 試了三條路做瀏覽器文字編輯器：canvas 渲染在無障礙上直接出局，contenteditable="plaintext-only" 過了一定字數就掉效能，最後回到 textarea。過程中他量到 spellcheck 這類屬性會造成「input latency spikes」，UTF-16 的編碼細節也得自己接。收尾的判斷不是勸人別自己寫，而是 textarea 配外部語法高亮已經是可以往下長的地基。
讀自己剛寫的資料，不必回主庫
把讀流量切到 replica 之後，作者的測試裡有 99.2% 的近期寫入讀不到，staleness 從毫秒級跳到秒級，取決於讀流量跟 WAL replay 搶資源的程度。PostgreSQL 19 的 WAIT FOR LSN 讓 standby 阻塞到追上指定位置：commit 後在 primary 用 pg_current_wal_flush_lsn() 取位置存下來，讀之前在 replica 執行 WAIT FOR LSN 並帶上 MODE 'standby_replay' 與 TIMEOUT。1,000 次測試裡 stale read 歸零，代價是各個百分位上都比直接走 primary 慢一到兩毫秒，而且等待中的連線會一直佔著 pool，lag 全面拉高時流量會整批倒回 primary。
Postgres 的 regex 有了兩個外掛引擎
pg_tre 帶來 Levenshtein 距離的模糊比對，pg_re2 則把 Google 的 RE2 接進來並支援 GIN 索引。簡單樣式 (su){3} 上，內建引擎配 trigram 索引跑 1.6 秒，pg_re2 走自己的索引是 958.857 ms；複雜樣式的差距更大，2267.799 ms 對上 39356.895 ms。代價各有各的：pg_tre 建索引花了 7 小時、吃掉 21 GB，pg_re2 則因為 RE2 的設計取捨不支援 (?<=e.) 這類 lookbehind。