與 Python 之父聊天：更快的 Python！

在今年5月的 Python 語(yǔ)言峰會(huì)上，Guido van Rossum 作了一場(chǎng)《Making CPython Faster》的分享，宣告他加入了激動(dòng)人心的“香農(nóng)計(jì)劃”，旨在 4 年內(nèi)提升 Python 性能至 5 倍。近日，Guido 上了一檔英文播客節(jié)目（時(shí)長(zhǎng) 30 分鐘），談?wù)摿怂谧龅呐c高性能相關(guān)的工作，解答了幾個(gè)問(wèn)題。播客作者整理了一份內(nèi)容紀(jì)要，本文是對(duì)該紀(jì)要的翻譯

1、為什么你會(huì)對(duì)研究 Python 的性能感興趣？

Guido：在某種意義上，它對(duì)我來(lái)說(shuō)是一個(gè)相對(duì)舒服的話題，因?yàn)檫@意味著與 Python 的核心打交道，而我對(duì)這方面還算熟悉。當(dāng)我在微軟工作時(shí)，我曾短暫地關(guān)注過(guò) Azure，但我意識(shí)到我在谷歌或 Dropbox 時(shí)就不喜歡這類(lèi)工作。然后我關(guān)注了機(jī)器學(xué)習(xí)，但這需要花很多時(shí)間來(lái)做一些與 Python 無(wú)關(guān)的事情，甚至它與 Python 相關(guān)的部分就很少。

2、Mark Shannon 關(guān)于 Python 性能的那些想法有何不同，怎么能說(shuō)服你去實(shí)現(xiàn)它們的呢？

Guido：我喜歡他思考問(wèn)題的方式。大多數(shù)其它聚焦于 Python 性能的方法，如 PyPy 和 Cinder，并不適用于所有的使用場(chǎng)景，因?yàn)樗鼈儾荒芟蚝蠹嫒輸U(kuò)展模塊。Mark 具有 CPython 開(kāi)發(fā)者的視角和經(jīng)驗(yàn)，并且有一種可行的方法來(lái)維持向后兼容性，這是最難解決的問(wèn)題。Python 的字節(jié)碼解釋器經(jīng)常要在小版本之間（例如 3.8→3.9）進(jìn)行修改，原因有很多，比如新的操作碼，所以修改它是一種相對(duì)安全的方案。

3、你能給我們解釋一下 Python 解釋器的分層執(zhí)行的概念么？

Guido：當(dāng)執(zhí)行一個(gè)程序時(shí)，你不知道它會(huì)在運(yùn)行了幾分之一毫秒后崩潰，還是會(huì)持續(xù)運(yùn)行三周時(shí)間。因?yàn)閷?duì)于同一份代碼，在第一種情況下，它可能觸發(fā)了一個(gè) bug。如果運(yùn)行程序需要三周時(shí)間，也許提前半小時(shí)優(yōu)化所有待運(yùn)行的代碼是有意義的。

但很明顯，特別是在像 Python 這樣的動(dòng)態(tài)語(yǔ)言中，我們盡可能多地做，而不要求用戶告訴我們他們到底需要怎么做，你只是想盡快開(kāi)始執(zhí)行代碼。所以，如果有一個(gè)小腳本，或者一個(gè)大程序，它碰巧執(zhí)行失敗了或者因?yàn)槟承┰蛱崆巴顺隽耍憔筒挥没ㄙM(fèi)時(shí)間去優(yōu)化全部的代碼了。

所以，我們要做的就是保持字節(jié)碼編譯器的簡(jiǎn)單化，以便能盡快地開(kāi)始執(zhí)行代碼。如果有某些函數(shù)被多次執(zhí)行，那么我們就稱其為 hot 函數(shù)。“hot”存在多種定義。在某些情況下，如果一個(gè)函數(shù)被調(diào)用超過(guò)一次，或者超過(guò)兩次，或者超過(guò) 10 次，那么它被定義成一個(gè)熱門(mén)函數(shù)。而在其它保守的情況下，你可能說(shuō)“只有被調(diào)用 1000 次才算 hot”。

然后，當(dāng)參數(shù)的類(lèi)型是某些特定類(lèi)型時(shí)，專(zhuān)門(mén)化的自適應(yīng)編譯器（PEP-659 Specializing Adaptive Compiler）會(huì)嘗試用更快的字節(jié)碼來(lái)替換某些字節(jié)碼。一個(gè)簡(jiǎn)單的假想的例子是 Python 中的加號(hào)運(yùn)算符，它可以令很多對(duì)象相加，比如整數(shù)、字符串、列表，甚至元組。但是，你不能將整數(shù)與字符串相加。

因此，優(yōu)化的方法就是提供一個(gè)單獨(dú)的“兩個(gè)整數(shù)相加”的字節(jié)碼，它是一個(gè)對(duì)用戶隱藏的第二層字節(jié)碼。（“優(yōu)化”通常被稱為加速 quickening，但一般在我們的語(yǔ)境中，我們稱之為專(zhuān)門(mén)化 specializing）。這個(gè)操作碼假設(shè)它的兩個(gè)參數(shù)都是真正的 Python 整型對(duì)象，直接讀取這些對(duì)象的值，并在機(jī)器寄存器中將這些值相加，最后將結(jié)果推回堆棧。

兩個(gè)整數(shù)相加的操作仍然需要對(duì)參數(shù)進(jìn)行類(lèi)型檢查。因此，它不是完全不受約束的，但這種類(lèi)型檢查相比于完全泛化的面向?qū)ο蟮募犹?hào)操作，前者在實(shí)現(xiàn)上要快得多。

最后，有可能一個(gè)函數(shù)被整型參數(shù)調(diào)用了數(shù)百萬(wàn)次，然后突然一小段代碼用浮點(diǎn)型參數(shù)調(diào)用它，或者出現(xiàn)更糟的情況。此時(shí)，解釋器會(huì)直接執(zhí)行原始的字節(jié)碼。這是一個(gè)重要的部分，讓你始終能得到完整的 Python 語(yǔ)義。

Python貓注：“香農(nóng)計(jì)劃”的最終目標(biāo)是將解釋器的執(zhí)行過(guò)程分層，并對(duì)不同層做出定制的優(yōu)化。詳情請(qǐng)查閱 Github 項(xiàng)目的介紹（https://github.com/markshannon/faster-cpython/blob/master/tiers.md）。

4、通常你會(huì)在談 JIT（Just-In-Time）編譯器時(shí)聽(tīng)到這些技術(shù)，但官方 Python 現(xiàn)在還沒(méi)有實(shí)現(xiàn)。

Guido：即時(shí)編譯的方案有一大堆我們想要避免的情感包袱。比如，我們不清楚到底編譯什么，以及什么時(shí)候編譯。在程序開(kāi)始執(zhí)行之前，解釋器將源代碼編譯成字節(jié)碼，然后，再將字節(jié)碼轉(zhuǎn)換為專(zhuān)門(mén)的字節(jié)碼。這意味著，所有的事情都在運(yùn)行時(shí)的某個(gè)時(shí)刻發(fā)生，那么，哪個(gè)部分是所謂的即時(shí)（Just-In-Time）呢？

另外，人們通常認(rèn)為 JIT 會(huì)自動(dòng)地使所有代碼變得更好。不幸的是，你通常無(wú)法真正地預(yù)測(cè)代碼的性能。由于有現(xiàn)代的 CPU 和它們神奇的分支預(yù)測(cè)，我們已經(jīng)擁有了足夠的性能。例如，我們以一種本認(rèn)為能夠明顯減少內(nèi)存訪問(wèn)次數(shù)的方式，編寫(xiě)了一份代碼。但是，當(dāng)對(duì)它進(jìn)行基準(zhǔn)測(cè)試時(shí)，我們發(fā)現(xiàn)它的運(yùn)行速度與舊的未優(yōu)化代碼一樣快，因?yàn)?CPU 在沒(méi)有我們?nèi)魏螏椭那闆r下，計(jì)算出了優(yōu)化的訪問(wèn)模式。我希望我知道現(xiàn)代 CPU 在分支預(yù)測(cè)和內(nèi)聯(lián)緩存方面做了什么，因?yàn)檫@就像是魔法一般