Claude 的 C 編譯器把基準測試搞砸了

Chips and Cheese 在 2026 年 4 月做了一次很狠的測試。主角是 Claude 寫的 C compiler，也就是 CCC。它能編過 Linux kernel，但在 SPEC CPU2017 上，效能常常直接掉超過 70%。

更扯的是，有一個測項還在 Arm 的 Cortex X925 上當掉。這種結果很適合拿來提醒大家：能編譯，不等於能拿來跑真實工作負載。尤其是編譯器這種低階軟體，差一點點，整個結果就歪掉。

講白了，這篇測試不是在酸 AI。它是在說，AI 工具一旦碰到編譯器、最佳化、診斷訊息，問題就會很硬。你可以先看起來很會，最後卻把 benchmark 搞成災難。

CCC 到底把簡單測試改成什麼樣子

文章先拿一個很小的 dependent-load microbenchmark 開刀。這種測試常用來看記憶體延遲。程式很簡單。每次存取都會餵給下一次，所以編譯器很難靠排程偷吃步。

GCC 和 CCC 都能產生可執行程式。差別在於，CCC 會吐出更長的指令序列。它常把一個簡單動作拆成 shift、add、load，還多塞一些 register shuffling。看起來像有做事，實際上是在增加負擔。

在 x86-64 上，CCC 會把動作拆得更碎。到了 aarch64，情況也差不多，還會多經過 stack。結果不是小幅誤差，而是量到的延遲真的變了。這種差距在編譯器世界很致命。

• CCC 有時會把短依賴鏈拉長成約 9 條指令
• Zen 5 和 Lion Cove 會吃掉一部分額外成本
• Arm 核心對這種寫法更敏感
• In-order 核心最慘，因為沒什麼空間藏住額外指令

這裡很有意思。問題不只是「AI 寫出慢 code」。更像是 CCC 直接把 CPU 的微架構細節逼到台前。像 move elimination、store forwarding、decode width、reorder buffer，平常你不會一直想到它們。可是一旦編譯器亂搞，這些東西就變成主角。

我覺得這也是這篇測試最有價值的地方。它不是只看能不能跑。它在看編譯器是不是懂得尊重硬體。這兩件事差很多。

它連 type error 都會放行

Chester Lam 也拿一個故意寫壞的 C 範例測 CCC。GCC 直接擋下來，照規矩吐出 type mismatch 錯誤。CCC 卻產生了可執行檔。這聽起來很好笑，但其實很危險。

編譯器存在的理由之一，就是把錯誤擋在前面。Type checking 不是裝飾品。它是大型 C codebase 的保命機制。少了這層，很多 undefined behavior 會一路滑到 runtime 才爆。

“Our society has gone all-in on AI.” — Chester Lam

這句話在文章裡是帶點諷刺的語氣。可它背後的技術意思很實在。若 AI 編譯器喜歡把錯誤吞掉，你當下會覺得很方便。後面卻要付更多代價。像是 bug 更難追、相容性更差、問題更晚才爆。

所以這裡的重點不是「AI 不行」。而是說，編譯器品質不能只看能不能編過。你還得看診斷、最佳化、架構特化，甚至是它會不會亂放行錯碼。只看 build 成功，根本不夠。

SPEC CPU2017 給出比較殘酷的答案

真正的壓力測試來自 SPEC CPU2017。文章跑了 8 個純 C 工作負載。平台有三個：Arm Cortex X925、AMD Zen 5、Intel Lion Cove。桌機平台還關掉 boost，避免比較太亂。

結果很難看。502.gcc 在 Cortex X925 上直接 segmentation fault。x86-64 這邊雖然有跑完，但 CCC 版本的 502.gcc，只剩 GCC 的 23.6% 到 27.1%。把 8 個工作負載平均起來，退步超過 70%。

這種數字不是小瑕疵。這是整個評估方向都歪掉。CCC 最好的相對表現出現在 505.mcf，但慢幅度還是不到 35% 以內。其他測項更慘，尤其是 Arm 平台。

• 測試核心：Arm Cortex X925、AMD Zen 5、Intel Lion Cove
• 工作負載：8 個 C-only SPEC CPU2017 測項
• 最差結果：502.gcc 在 Cortex X925 當掉
• 最佳相對表現：505.mcf，但還是比 GCC 慢超過 35%
• 平均退步：略高於 70%

還有一個很值得注意的地方。用 GCC 跑時，Cortex X925 在幾個測項裡其實不差，甚至能跟 Zen 5、Lion Cove 打得有來有回。換成 CCC 後，這個平衡直接消失。Arm 幾乎每場都輸，少數例外也沒贏過 Intel。也就是說，編譯器會改變 chip 排名。

這件事很重要。因為 benchmark 從來不只是硬體的故事。編譯器、最佳化旗標、指令選擇，都會改寫最後的成績單。你如果只看數字，不看工具鍊，結論常常會歪。

為什麼不同核心反應差這麼多

文章裡的 top-down analysis 把原因拆得很清楚。Zen 5 和 Lion Cove 都有很強的 out-of-order 機制。它們的 execution engine 比較寬，對爛依賴鏈也比較能忍。Cortex X925 就沒那麼寬容，尤其碰到大量 register move 和 stack traffic 時。

Zen 5 還有很大的 op cache，前端通常比較能撐住。但文章提到一個例外，500.perlbench。CCC 讓 instruction footprint 變大，最後把前端推進 decoder bottleneck。這種例子很少見，但很有教訓味。

對做軟體的人來說，這句話很實際。編譯器可以是 correct 的，卻還是很爛。只要它把指令數拉高、把 locality 弄壞、把 stack traffic 弄多，CPU 就得一條一條吞下去。

• Zen 5 的 op cache 多半能撐住前端壓力
• Lion Cove 有更寬的 decoder 和較強的 OOO 資源
• Cortex X925 對 move 和 stack-heavy code 更敏感
• CCC 常常增加指令數，而不是只增加 branch 數

最後這點很關鍵。這也解釋了為什麼 branch prediction 不是主戰場。CCC 把 code 變大了，但不一定變得更常跳分支。結果瓶頸就跑去 retirement、backend execution，還有 memory behavior。

說真的，這種失敗模式才最值得怕。因為它很像很多 AI coding tool 的老問題。demo 看起來很順，kernel 也能過，結果一進入 benchmark 就露餡。尤其是低階軟體，細節真的會咬人。

這對 AI coding tool 代表什麼

這篇文章雖然帶點諷刺，但技術證據很硬。AI coding system 這幾年確實更會生出看起來合理的 code。不過編譯器是最不容許裝懂的地方之一。只要一個最佳化 pass 出錯，整個 benchmark 都會被拖下水。

對做產品的人來說，標準也要拉高。不是「大多時候能用」就算過關。你得確保它能保住 correctness，能抓出壞輸入，還不能把效能打爛。這對 low-level software 來說尤其難。

所以我會把這篇測試解讀成一個很直白的提醒。AI 工具可以幫忙，但別急著把它當成成熟的系統軟體工程師。尤其是編譯器、assembler、runtime 這類東西，真的不能只看表面。

我的判斷很簡單：AI 寫的 compiler 和 code generator 會繼續進步。可是真正敢放進 production 的團隊，還是得有人做 code review、benchmark gate、架構別驗證。你要先問的不是「它會不會寫」。而是「它會不會把硬體搞爛」。

接下來該怎麼看這類工具

如果你是工程團隊，最實際的做法不是先興奮。先把測試拉到最難的地方。像是 SPEC 類型的 workload、真實的 server workload、還有不同 CPU 架構。不要只看能不能 build 成功。

如果你是開發者，也可以把這件事當成提醒。AI 產生的 code 很適合當草稿。可是一碰到 performance-critical path，還是要回到人類工程師的判斷。編譯器、runtime、kernel 這些地方，沒有什麼捷徑。

我猜接下來 12 個月，大家會更常看到 AI 工具進入低階軟體流程。可是只要 benchmark 沒過，這些工具就還是只能算輔助。你要是問我值不值得用，我會說：可以用，但要非常兇地驗證。