pybind26: 從頭刻一個 HPC bridge 有多難

一、緣起:從「陰暗角落」到「動手重造輪子」

去年的《Python FFI 的陰暗角落》有講者診斷:把 binding layer、calling convention、GIL 與 runtime 邊界的隱性成本攤開來看,並意外發現在某些 hot path 上 pybind11 甚至會輸給 PyO3。那場 talk 留下一個沒回答的問題：到底是 C++ 慢,還是 Python–C++ bridge 背了太多歷史包袱與通用性成本?

今年我想回答是治療:既然 2026 年我們有 LLM 輔助、能負擔得起「reinventing the wheel」的成本,那就從零寫一個 binding layer,看看當前提換掉之後,效能天花板能拉到哪裡。這個專案叫 pybind26。

二、整場 talk 的主軸:前提決定作法

這不是一場「我做了一個比較快的 library,大家來看」的炫技 talk。真正想傳達的觀念是:

pybind11 不是寫得不好,是它的前提逼它必須付出某些成本。當你換掉前提,合理的作法就會跟著變,而且能換到結構性的效能優勢。

pybind11 的前提是:要支援 CPython 3.7 以上一整排版本、要相容 abi3 / 舊 limited API、要能跑在 C++11、GIL 是世界的中心、而且要功能「無所不包」(例外處理、直譯器嵌入、Eigen…)。這些前提每一條都很合理,但合起來就強迫它必須有抽象層、macro 機械、per-call 的查表與鎖。

pybind26 換掉的前提是:

1. 只支援 CPython 3.14+：拋棄所有向後相容,直接吃 vectorcall、multi-phase init、per-interpreter state、3.14 新的快速轉換 API。
2. 只用 C++26：用 static reflection、expansion statements、NTTP、[[gnu::flatten]] 取代 macro 與 descr mini-language。
3. free-threading 是 tier-zero：每個設計都先過「GIL 關掉會怎樣」這關,而不是事後補。
4. performance is king,且給出 no-exception guarantee：事先定義 error handling model 很重要，任意拋擲未處理的異常狀況，不僅是 antipattern 更是效能損失的來源。
5. 不追求 pybind11 API 相容：語法可以不一樣,目標是覆蓋大多數功能,不是 copy API。

整場 talk 會反覆回到這條線:每一個我們做得不一樣的地方,都對應到一條被我們換掉的前提。 讓 TA「看懂一個 FFI bridge 的成本來自哪些前提、怎麼判斷自己的 binding 到底慢在哪、未來該怎麼選」。