摘要:酷睿代在年取代了奔騰,主頻遠低于此。該詞被敏捷開發團隊使用較多,含義與形式會略有不同,更改已經開始將垃圾收集器的狀態轉到解釋器,因此每個子解釋器將擁有它自己的本該如此。結論死亡了嗎對于單線程的應用程序,仍然存活。
本文原創并首發于公眾號【Python貓】,未經授權,請勿轉載。
原文地址:mp.weixin.qq.com/s/8KvQemz0S…
花下貓語: Python 中最廣為人詬病的一點,大概就是它的 GIL 了。由于 GIL 的存在,Python 無法實現真正的多線程編程,因此很多人都把這視作 Python 最大的軟肋。
PEP-554 提出后(2017年9月),大伙似乎看到了一線改善的曙光。然而,GIL 真的可以被徹底殺死么,如果可以的話,它會怎么實現呢,為什么等了一年多還沒實現,仍需要我們等待多長時間呢?
英文 | Has the Python GIL been slain);
作者 | Anthony Shaw
譯者 | 豌豆花下貓
聲明 :本文獲得原作者授權翻譯,轉載請保留原文出處,請勿用于商業或非法用途。
2003 年初,Intel 公司推出了全新的奔騰 4 “HT” 處理器,該處理器的主頻(譯注:CPU 內核工作的時鐘頻率)為 3 GHz,采用了“超線程”技術。
在接下來的幾年中,Intel 和 AMD 激烈競爭,通過提高總線速度、L2 緩存大小和減小芯片尺寸以最大限度地減少延遲,努力地實現最佳的臺式機性能。3Ghz 的 HT 在 2004 年被“Prescott”的 580 型號取代,該型號的主頻高達 4 GHz。
似乎提升性能的最好方法就是提高處理器的主頻,但 CPU 卻受到高功耗和散熱會影響全球變暖的困擾。
你電腦上有 4Ghz 的 CPU 嗎?不太可能,因為性能的前進方式是更高的總線速度和更多的內核。Intel 酷睿 2 代在 2006 年取代了奔騰 4 ,主頻遠低于此。
除了發布消費級的多核 CPU,2006 年還發生了其它事情,Python 2.5 發布了!Python 2.5 帶來了人見人愛的 with 語句的 beta 版本 。
在使用 Intel 的酷睿 2 或 AMD 的 Athlon X2 時,Python 2.5 有一個重要的限制——GIL 。
什么是 GIL?GIL 即全局解釋器鎖(Global Interpreter Lock),是 Python 解釋器中的一個布爾值,受到互斥保護。這個鎖被 CPython 中的核心字節碼用來評估循環,并調節用來執行語句的當前線程。
CPython 支持在單個解釋器中使用多線程,但線程們必須獲得 GIL 的使用權才能執行操作碼(做低級操作)。這樣做的好處是,Python 開發人員在編寫異步代碼或多線程代碼時,完全不必操心如何獲取變量上的鎖,也不需擔心進程因為死鎖而崩潰。
GIL 使 Python 中的多線程編程變得簡單。
GIL 還意味著雖然 CPython 可以是多線程的,但在任何給定的時間里只能執行 1 個線程。這意味著你的四核 CPU 會像上圖一樣工作 (減去藍屏,但愿如此)。
當前版本的 GIL 是在2009年編寫的 【2】,用于支持異步功能,幾乎沒被改動地存活了下來,即使曾經多次試圖刪除它或減少對它的依賴。
所有提議移除 GIL 的訴求是,它不應該降低單線程代碼的性能。任何曾在 2003 年啟用超線程(Hyper-Threading)的人都會明白為什么 這很重要 【3】。
在 CPython 中避免使用 GIL如果你想在 CPython 中使用真正的并發代碼,則必須使用多進程。
在 CPython 2.6 中,標準庫里增加了 multiprocessing 模塊。multiprocessing 是 CPython 大量產生的進程的包裝器(每個進程都有自己的GIL)——
from multiprocessing import Process
def f(name):
print hello, name
if __name__ == __main__:
p = Process(target=f, args=(bob,))
p.start()
p.join()
進程可以從主進程中“孵出”,通過編譯好的 Python 模塊或函數發送命令,然后重新納入主進程。
multiprocessing 模塊還支持通過隊列或管道共享變量。它有一個 Lock 對象,用于鎖定主進程中的對象,以便其它進程能夠寫入。
多進程有一個主要的缺陷:它在時間和內存使用方面的開銷很大。CPython 的啟動時間,即使沒有非站點(no-site),也是 100-200ms(參見 這個鏈接 【4】)。
因此,你可以在 CPython 中使用并發代碼,但是你必須仔細規劃那些長時間運行的進程,這些進程之間極少共享對象。
另一種替代方案是使用像 Twisted 這樣的三方庫。
PEP-554 與 GIL 的死亡?小結一下,CPython 中使用多線程很容易,但它并不是真正的并發,多進程雖然是并發的,但開銷卻極大。
有沒有更好的方案呢?
繞過 GIL 的線索就在其名稱中,全局 解釋器 鎖是全局解釋器狀態的一部分。 CPython 的進程可以有多個解釋器,因此可以有多個鎖,但是此功能很少使用,因為它只通過 C-API 公開。
在為 CPython 3.8 提出的特性中有個 PEP-554,提議實現子解釋器(sub-interpreter),以及在標準庫中提供一個新的帶有 API 的 interpreters 模塊。
這樣就可以在 Python 的單個進程中創建出多個解釋器。Python 3.8 的另一個改動是解釋器都將擁有多帶帶的 GIL ——
因為解釋器的狀態包含內存分配競技場(memory allocation arena),即所有指向 Python 對象(局地和全局)的指針的集合,所以 PEP-554 中的子解釋器無法訪問其它解釋器的全局變量。
與多進程類似,在解釋器之間共享對象的方法是采用 IPC 的某種形式(網絡、磁盤或共享內存)來做序列化。在 Python 中有許多方法可以序列化對象,例如 marshal 模塊、 pickle 模塊、以及像 json 和 simplexml 這樣更標準化的方法 。這些方法褒貶不一,但無一例外會造成額外的開銷。
最佳方案是開辟一塊共享的可變的內存空間,由主進程來控制。這樣的話,對象可以從主解釋器發送,并由其它解釋器接收。這將是 PyObject 指針的內存管理空間,每個解釋器都可以訪問它,同時由主進程擁有對鎖的控制權。
這樣的 API 仍在制定中,但它可能如下所示:
import _xxsubinterpreters as interpreters
import threading
import textwrap as tw
import marshal
# Create a sub-interpreter
interpid = interpreters.create()
# If you had a function that generated some data
arry = list(range(0,100))
# Create a channel
channel_id = interpreters.channel_create()
# Pre-populate the interpreter with a module
interpreters.run_string(interpid, "import marshal; import _xxsubinterpreters as interpreters")
# Define a
def run(interpid, channel_id):
interpreters.run_string(interpid,
tw.dedent("""
arry_raw = interpreters.channel_recv(channel_id)
arry = marshal.loads(arry_raw)
result = [1,2,3,4,5] # where you would do some calculating
result_raw = marshal.dumps(result)
interpreters.channel_send(channel_id, result_raw)
"""),
shared=dict(
channel_id=channel_id
),
)
inp = marshal.dumps(arry)
interpreters.channel_send(channel_id, inp)
# Run inside a thread
t = threading.Thread(target=run, args=(interpid, channel_id))
t.start()
# Sub interpreter will process. Feel free to do anything else now.
output = interpreters.channel_recv(channel_id)
interpreters.channel_release(channel_id)
output_arry = marshal.loads(output)
print(output_arry)
此示例使用了 numpy ,并通過使用 marshal 模塊對其進行序列化來在通道上發送 numpy 數組 ,然后由子解釋器來處理數據(在多帶帶的 GIL 上),因此這會是一個計算密集型(CPU-bound)的并發問題,適合用子解釋器來處理。
這看起來效率低下marshal 模塊相當快,但仍不如直接從內存中共享對象那樣快。
PEP-574 提出了一種新的 pickle 【5】協議(v5),它支持將內存緩沖區與 pickle 流的其余部分分開處理。對于大型數據對象,將它們一次性序列化,再由子解釋器反序列化,這會增加很多開銷。
新的 API 可以( 假想 ,并沒有合入)像這樣提供接口:
import _xxsubinterpreters as interpreters
import threading
import textwrap as tw
import pickle
# Create a sub-interpreter
interpid = interpreters.create()
# If you had a function that generated a numpy array
arry = [5,4,3,2,1]
# Create a channel
channel_id = interpreters.channel_create()
# Pre-populate the interpreter with a module
interpreters.run_string(interpid, "import pickle; import _xxsubinterpreters as interpreters")
buffers=[]
# Define a
def run(interpid, channel_id):
interpreters.run_string(interpid,
tw.dedent("""
arry_raw = interpreters.channel_recv(channel_id)
arry = pickle.loads(arry_raw)
print(f"Got: {arry}")
result = arry[::-1]
result_raw = pickle.dumps(result, protocol=5)
interpreters.channel_send(channel_id, result_raw)
"""),
shared=dict(
channel_id=channel_id,
),
)
input = pickle.dumps(arry, protocol=5, buffer_callback=buffers.append)
interpreters.channel_send(channel_id, input)
# Run inside a thread
t = threading.Thread(target=run, args=(interpid, channel_id))
t.start()
# Sub interpreter will process. Feel free to do anything else now.
output = interpreters.channel_recv(channel_id)
interpreters.channel_release(channel_id)
output_arry = pickle.loads(output)
print(f"Got back: {output_arry}")
這看起來像極了很多樣板
確實,這個例子使用的是低級的子解釋器 API。如果你使用了多進程庫,你將會發現一些問題。它不像 threading 那么簡單,你不能想著在不同的解釋器中使用同一串輸入來運行同一個函數(目前還不行)。
一旦合入了這個 PEP,我認為 PyPi 中的其它一些 API 也會采用它。
子解釋器需要多少開銷?簡版回答 :大于一個線程,少于一個進程。
詳版回答 :解釋器有自己的狀態,因此雖然 PEP-554 可以使創建子解釋器變得方便,但它還需要克隆并初始化以下內容:
在 main 命名空間與 importlib 中的模塊
sys 字典的內容
內置的方法(print、assert等等)
線程
核心配置
核心配置可以很容易地從內存克隆,但導入的模塊并不那么簡單。在 Python 中導入模塊的速度很慢,因此,如果每次創建子解釋器都意味著要將模塊導入另一個命名空間,那么收益就會減少。
那么 asyncio 呢?標準庫中 asyncio 事件循環的當前實現是創建需要求值的幀(frame),但在主解釋器中共享狀態(因此共享 GIL)。
在 PEP-554 被合入后,很可能是在 Python 3.9,事件循環的替代實現 可能 是這樣(盡管還沒有人這樣干):在子解釋器內運行 async 方法,因此會是并發的。
聽起來不錯,發貨吧!額,還不可以。
因為 CPython 已經使用單解釋器的實現方案很長時間了,所以代碼庫的許多地方都在使用“運行時狀態”(Runtime State)而不是“解釋器狀態”(Interpreter State),所以假如要將當前的 PEP-554 合入的話,將會導致很多問題。
例如,垃圾收集器(在 3.7 版本前)的狀態就屬于運行時。
在 PyCon sprint 期間(譯注:PyCon 是由 Python 社區舉辦的大型活動,作者指的是官方剛在美國舉辦的這場,時間是2019年5月1日至5月9日。sprint 是為期 1-4 天的活動,開發者們自愿加入某個項目,進行“沖刺”開發。該詞被敏捷開發團隊使用較多,含義與形式會略有不同),更改已經開始 【6】將垃圾收集器的狀態轉到解釋器,因此每個子解釋器將擁有它自己的 GC(本該如此)。
另一個問題是在 CPython 代碼庫和許多 C 擴展中仍殘存著一些“全局”變量。因此,當人們突然開始正確地編寫并發代碼時,我們可能會遭遇到一些問題。
還有一個問題是文件句柄屬于進程,因此當你在一個解釋器中讀寫一個文件時,子解釋器將無法訪問該文件(不對 CPython 作進一步更改的話)。
簡而言之,還有許多其它事情需要解決。
結論:GIL 死亡了嗎?對于單線程的應用程序,GIL 仍然存活。因此,即便是合并了 PEP-554,如果你有單線程的代碼,它也不會突然變成并發的。
如果你想在 Python 3.8 中使用并發代碼,那么你就會遇到計算密集型的并發問題,那么這可能是張入場券!
什么時候?Pickle v5 和用于多進程的共享內存可能是在 Python 3.8(2019 年 10 月)實現,子解釋器將介于 3.8 和 3.9 之間。
如果你現在想要使用我的示例,我已經構建了一個分支,其中包含所有 必要的代碼 【7】
References[1] Has the Python GIL been slain);
公眾號【Python貓】, 本號連載優質的系列文章,有喵星哲學貓系列、Python進階系列、好書推薦系列、技術寫作、優質英文推薦與翻譯等等,歡迎關注哦。后臺回復“愛學習”,免費獲得一份學習大禮包。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/7134.html
摘要:酷睿代在年取代了奔騰,主頻遠低于此。該詞被敏捷開發團隊使用較多,含義與形式會略有不同,更改已經開始將垃圾收集器的狀態轉到解釋器,因此每個子解釋器將擁有它自己的本該如此。結論死亡了嗎對于單線程的應用程序,仍然存活。showImg(https://user-gold-cdn.xitu.io/2019/5/19/16ad09f554fdf443); 本文原創并首發于公眾號【Python貓】,未經授...
摘要:酷睿代在年取代了奔騰,主頻遠低于此。該詞被敏捷開發團隊使用較多,含義與形式會略有不同,更改已經開始將垃圾收集器的狀態轉到解釋器,因此每個子解釋器將擁有它自己的本該如此。結論死亡了嗎對于單線程的應用程序,仍然存活。 showImg(https://segmentfault.com/img/remote/1460000019229774); 本文原創并首發于公眾號【Python貓】,未經授...
摘要:二這些內容都很有意思,本文唯獨想聊聊它內置電池。這樣做的預期效果是內置電池會變得輕量小型化高質量,同時三方庫的生態系統也能得到進化。目前,該仍處于草案狀態,但已基本成為社區共識。 showImg(https://segmentfault.com/img/remote/1460000019489233?w=1880&h=1253); 本文原創并首發于公眾號【Python貓】,未經授權,請...
摘要:二這些內容都很有意思,本文唯獨想聊聊它內置電池。這樣做的預期效果是內置電池會變得輕量小型化高質量,同時三方庫的生態系統也能得到進化。目前,該仍處于草案狀態,但已基本成為社區共識。 showImg(https://segmentfault.com/img/remote/1460000019489233?w=1880&h=1253); 本文原創并首發于公眾號【Python貓】,未經授權,請...
閱讀 713·2023-04-25 19:43
閱讀 3910·2021-11-30 14:52
閱讀 3784·2021-11-30 14:52
閱讀 3852·2021-11-29 11:00
閱讀 3783·2021-11-29 11:00
閱讀 3869·2021-11-29 11:00
閱讀 3557·2021-11-29 11:00
閱讀 6105·2021-11-29 11:00