去年的 2022 Python 語言峰會上,開發(fā)者 Sam Gross 帶來了新提案:刪除全局解釋器鎖 GIL,解放多線程性能。但由于 GIL 歷史悠久,許多官方 / 非官方的 Python 包和模塊都深度融合了 GIL 模塊,徹底移除 GIL 功能可能會對生態(tài)造成影響。在 2023 年 1 月 9 日, Sam Gross 又創(chuàng)建了另一個 Python 提案 PEP 703:使全局解釋器鎖成為構(gòu)建 Python 的可選項。
CPython 的全局解釋器鎖(“GIL”)防止多個線程同時執(zhí)行 Python 代碼,GIL 是 Python 有效使用多核 CPU 的障礙。
向 CPython 添加一個構(gòu)建配置 ( --without-gil) ,使其可在沒有全局解釋器鎖的情況下運行 Python 代碼,并進行必要的更改,以使解釋器線程安全。
這條 PEP 提案的內(nèi)容可謂是論文級別。提案中先闡述了 GIL 對 Python 并發(fā)的性能阻礙,隨后詳細分析了抽離 GIL 需要對 Python 內(nèi)部進行哪些改動:
移除全局解釋器鎖需要對 CPython 內(nèi)部進行大量更改,但對公共 Python 和 C API 的更改相對較少。
實施的變更大約分為以下四類:
引用計數(shù)、內(nèi)存管理、容器線程安全、鎖和 atomic API
由于該提案內(nèi)容實在太多,感興趣的朋友請在 PEP 703 詳情頁(https://peps.python.org/pep-0703)和 Cpython 核心開發(fā)者對該提案的討論帖(https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional/22606/10)中細閱。
目前此 PEP 已經(jīng)有了參考實現(xiàn),它的原型源于當(dāng)初為了移除 GIL 而開發(fā)的 nogil 項目,該原型對單線程代碼帶來較明顯 (~10%) 性能提升。
如果該提案通過,意味著默認情況下 CPython 不會刪除或關(guān)閉 GIL,也不會讓用戶有選擇地啟用 / 刪除 GIL。因為--without-gil是一個編譯時標志,可以在從源代碼構(gòu)建 Python 解釋器時進行設(shè)置。但如果棄用該配置,會導(dǎo)致對解釋器的構(gòu)建和運行方式的深度侵入性更改,PEP 中也對此進行了詳細介紹。
對用戶側(cè)來說,該改動意味著如果用戶使用任何帶有編譯擴展的包,將需要獲取或構(gòu)建一個專門針對 Python 解釋器的(不同的)ABI 編譯的版本,該版本在沒有 GIL 的情況下編譯。
關(guān)于 Python GIL
由于 CPython 的內(nèi)存管理非線程安全,因此設(shè)計了 CPython 的 GIL (Global Interpreter Lock - 全局解釋器鎖),以防止競爭條件并確保線程安全。GIL 是一個互斥鎖,只允許一個線程持有 Python 解釋器的控制權(quán),從而保護對 Python 對象的訪問,防止多個線程同時執(zhí)行 Python 字節(jié)碼。
但事后看來,GIL 并不理想,因為它阻止了多線程的 CPython 程序充分利用多核處理器的性能。
審核編輯 :李倩
-
python
+關(guān)注
關(guān)注
56文章
4825瀏覽量
86216 -
解釋器
+關(guān)注
關(guān)注
0文章
103瀏覽量
6701
原文標題:Python新提案:使全局解釋器鎖成為可選項
文章出處:【微信號:OSC開源社區(qū),微信公眾號:OSC開源社區(qū)】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
為什么在MCAL版本SW32K3_S32M27x_RTD_R21-11_5.0.0中,SPI的StartNotification是不可選項?
適用于MySQL和MariaDB的Python連接器:可靠的MySQL數(shù)據(jù)連接器和數(shù)據(jù)庫

Vivado之實現(xiàn)布局布線流程介紹

D鎖存器的基本實現(xiàn)
鎖存器的基本輸出時序
鎖存器與觸發(fā)器的狀態(tài)圖是一樣的嗎?為什么?
怎么根據(jù)sr鎖存器的輸入信息
d鎖存器解決了sr鎖存器的什么問題
pytorch和python的關(guān)系是什么
Python建模算法與應(yīng)用
rs鎖存器和sr鎖存器有什么區(qū)別嗎
手機存儲不夠用,“軟NAS”成為新的可選項

評論