問題：Python的總體性能較慢，有限的線程與孱弱的多處理能力成為其未來發(fā)展的主要障礙。

Python長期以來一直更重視編程速度，而非運(yùn)行速度。考慮到很多開發(fā)者習(xí)慣于利用C或C++編寫高速外部庫(例如NumPy或者Numba)以執(zhí)行Python下的性能密集型任務(wù)，這樣的權(quán)衡似乎也沒什么大不了。但問題在于，Python的開箱性能仍然落后于其它語法同樣簡單、但能夠編譯為機(jī)器碼的語言，例如Nim或者Julia。

Python當(dāng)中歷史最悠久的性能問題之一，在于其對多核心或處理器的資源使用能力不佳。雖然Python確實(shí)具有線程功能，但卻僅限于單一核心。此外，Python也會(huì)嘗試通過啟動(dòng)其運(yùn)行時(shí)的子實(shí)例以支持多處理，但是針對這些子進(jìn)程結(jié)果的調(diào)度與同步往往效率不高。

解決方案：目前，還沒有某一種自上而下的整體性解決方案，能夠直接搞定Python的性能問題。不過，現(xiàn)在已經(jīng)出現(xiàn)了一系列用于加速Python的嘗試，其各自都在特定領(lǐng)域做出了一定改進(jìn)。

下面來看例子：

改善CPython的內(nèi)部行為。CPython改進(jìn)帶來了幅度有限但卻覆蓋面廣泛的加速效果。例如，Python3.8的Vectorcall協(xié)議為Python對象帶來了更快的調(diào)用約定。雖然改進(jìn)效果不算顯著，但足以帶來具有可測量且可預(yù)測的性能提升，而且完全不會(huì)破壞向下兼容性;此外，現(xiàn)有Python應(yīng)用程序可直接受益，無需任何代碼重寫。

改進(jìn)CPython的子解釋器功能。Python解釋器實(shí)例的新編程接口現(xiàn)在可以時(shí)在各解釋器之間實(shí)現(xiàn)優(yōu)雅的數(shù)據(jù)共享，從而實(shí)現(xiàn)多核處理。現(xiàn)在，這項(xiàng)提案已經(jīng)確定將在Python3.9中面世，相信其還將在后續(xù)版本中繼續(xù)發(fā)揮重要作用。

改進(jìn)多個(gè)進(jìn)程之間的對象共享。Python當(dāng)中的多處理機(jī)制會(huì)為每個(gè)核心啟動(dòng)一個(gè)新的解釋器實(shí)例，用以獲取最佳性能;但當(dāng)多個(gè)解釋器嘗試對同一內(nèi)存對象進(jìn)行操作時(shí)，大部分性能提升都會(huì)瞬間作廢。目前，以SahredMemory類以及新的pickle協(xié)議為代表的新功能，可以減少解釋器之間數(shù)據(jù)傳遞所需要的復(fù)制或者序列化過程，從根本上消除相關(guān)性能問題。

在Python之外，也有不少外部項(xiàng)目帶來了新的性能提升方法——但同樣僅限于特定問題：

PyPy。另一種Python解釋器，PyPy能夠?qū)ython即時(shí)編譯為本機(jī)機(jī)器碼。它在純Python項(xiàng)目當(dāng)中發(fā)揮出色，現(xiàn)在也能很好地兼容比較流行的二進(jìn)制相關(guān)庫——例如NumPy。但其一般更適合長期運(yùn)行的服務(wù)，而非一次性應(yīng)用程序。

Cython。Cython允許用戶逐步將Python代碼轉(zhuǎn)換為C代碼。該項(xiàng)目最初是專為科學(xué)與數(shù)值計(jì)算所設(shè)計(jì)的，但卻能夠在大多數(shù)場景下起效。Cython最大的缺點(diǎn)在于語法，其使用了獨(dú)有的語法設(shè)置，且轉(zhuǎn)換只能單向進(jìn)行。Cython最適合處理“熱點(diǎn)”部分代碼，這種有針對性的優(yōu)化方式往往比應(yīng)用程序整體優(yōu)化要更合理、也更可行。

Numba。Numba的即時(shí)編譯功能可以面向選定功能將Python代碼編譯為機(jī)器碼。與Cython類似，Numba同樣主要用于科學(xué)計(jì)算，其比較適合就地運(yùn)行而非對代碼進(jìn)行重新發(fā)布。

Mypyc。Mypyc項(xiàng)目目前仍在開發(fā)當(dāng)中，其希望將帶有mypy類型注釋的Python代碼轉(zhuǎn)換為C代碼。Mypyc很有前途，因?yàn)槠涫褂玫絇ython中的眾多原生類型，但目前距離生產(chǎn)應(yīng)用還有很長的路要走。

經(jīng)過優(yōu)化的Python發(fā)行版。某些第三方Python版本(例如英特爾的Python發(fā)行版)擁有可充分發(fā)揮英特爾處理器擴(kuò)展(例如AVX512)優(yōu)勢的數(shù)學(xué)與統(tǒng)計(jì)庫。需要注意的是，盡管其能夠顯著加快特定數(shù)學(xué)函數(shù)的執(zhí)行速度，但卻無法實(shí)現(xiàn)全面的速度提升。

有經(jīng)驗(yàn)的Python程序員一定還會(huì)提到全局解釋器鎖(GIL)的問題，其負(fù)責(zé)對指向?qū)ο蟮脑L問進(jìn)行序列化，以確保不同線程不會(huì)彼此影響到對方的工作負(fù)載。從理論上講，放棄GIL可以提高性能。然而，無GILPython基本上喪失了向下兼容能力(特別是在PythonC擴(kuò)展方面)。因此到目前為止，所有移除GIL的嘗試要么已經(jīng)走進(jìn)死胡同，要么反而降低了Python的性能。

目前另一個(gè)正在推進(jìn)的Python計(jì)劃有望解決不少速度方面的問題，即重構(gòu)Python內(nèi)部的CAPI實(shí)現(xiàn)。眾長遠(yuǎn)來看，提升API集的有序程度可以帶來諸多性能改進(jìn)：重新設(shè)計(jì)或者剔除GIL、提供可實(shí)現(xiàn)強(qiáng)大即時(shí)編譯的hook、在解釋器實(shí)例之間使用更好的數(shù)據(jù)聯(lián)合方法等等。

以上內(nèi)容為大家介紹了Python多線程與速度，希望對大家有所幫助，如果想要了解更多Python相關(guān)知識(shí)，請關(guān)注IT培訓(xùn)機(jī)構(gòu):千鋒教育。http://www.mobiletrain.org/

上一篇

Python 3.0 的修改

下一篇

Python的函數(shù)式