本篇文章更新時間：2026/03/18
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
內容目錄
Python 3.15 JIT 重生之路：一場由人、運氣與架構組成的逆襲故事
編輯前言：本文整理自原文 Python 3.15’s JIT is now back on track，作者 Ken Jin 分享了 CPython JIT 在 3.15 的大幅進步背後，不只是技術，而是人、社群與一連串幸運選擇交織出的成果。如果你關心 Python 效能演進，這篇值得細讀。
核心觀點 (Key Takeaways)
- CPython JIT 在 3.15 的表現終於達成目標，macOS AArch64 約快 11-12%，x86_64 Linux 快 5-6%。
- 進步的關鍵，不只是技術突破，而是「拆分任務」「擴大貢獻者」「幸運的架構決策」等組合拳。
- Trace recording 的採用、參考計數分支的消除，是兩個帶來巨大提升的幸運押注。
深入解析
原文描述的不是單純的技術報告，而是一次從困境逆轉的 JIT 專案復甦記錄。Ken Jin 回顧，在 3.13 與 3.14 時期，CPython JIT 基本上「沒有速度優勢」，甚至經常比解譯器更慢。再加上 Faster CPython 團隊在 2025 年失去主要贊助，使得整個 JIT 項目前景不明。
但 3.15 的結果卻完全不同。
“The JIT is now back on track.”
這段進步背後，Ken 認為不是什麼「英雄式技術突破」，反而更多要歸功於「運氣與團隊」。
- 人員擴充策略帶來轉機：透過把複雜任務拆成可行的小步驟、撰寫明確指南，吸引到更多新貢獻者加入中端（optimizer），成功把 JIT「去黑箱化」。
- 每日效能監測的基礎設施（四台放在 Savannah 衣櫥裡的機器） 提供了快速迭代的重要回饋。
Trace Recording：誤解帶來的突破
其中最戲劇化的轉折是 JIT frontend 重寫成 tracing 版本。Ken 原本只是想證明該做法不行，但意外發明了「dual dispatch」：
“…I misunderstood and came up with an even more extreme version… This turned out to be a really really good choice.”
透過將所有 tracing 行為統一到一個指令，避免 interpreter 膨脹，最終讓 trace recording 成為推動 JIT 整體效能的核心，JIT code coverage 因此提升了 50%。
Reference Count Elimination：把「一個小分支」當大事處理
另一個大膽賭注，是嘗試消除 JIT 產生碼中每次 refcount 減少所附帶的分支判斷。這看似微小，但因為 Python 幾乎每條指令都會調整 refcount，累積起來居然有明顯收益。
Ken 指出，這項工作既能平行化，也適合新手切入 JIT 開發，是 3.15 的關鍵社群任務之一。
筆者心得與啟發
讀完這篇，我最大的感受是：高效能技術專案的成功，往往不是來自單一天才式突破，而是來自社群、流程以及一連串微小但關鍵的選擇。
這篇文章深刻揭示幾個值得其他開源專案借鏡的點：
- 把大問題拆成新手能參與的小任務，是社群永續的核心。
- 基礎設施（例如自動效能回報）比我們想像中更重要。
- 幸運與試誤是工程進展的一部分，擁抱它，而不是回避它。
- 跨專案交流（如向 PyPy 學習）能讓開發者「長肌肉」。
Python 社群往往被視為務實與溫暖，而這篇文章正好呈現了那份文化如何轉化成技術成果。對我而言，它提醒了一件事：開源專案的效能提升，通常不是靠一個天才，而是靠一群願意一起變好的普通人，再加上一點運氣。