pyを長い間使っていないので注意してください~~
「Python の GIL はもう存在しません。これは人工知能エコシステムの分野における大きな勝利です。」と PyTorch コア メンテナの Dmytro Dzhulgakov 氏は感情を込めて述べました。
GILとは何ですか？GIL の正式名称は Global Interpreter Lock (グローバル インタープリター ロック) で、Python に固有のものではなく、CPython (Python インタープリター) を実装する際に導入された概念です。GIL は、Python のオブジェクトを保護し、複数のスレッドが Python バイトコードを同時に実行するのを防ぎ、スレッドの安全性を確保するために使用されるミューテックスとして理解できます。
ただし、GIL には欠点があります。1 つの CPU 上では一度に 1 つのスレッドしか実行できず、複数のスレッドを複数の CPU にマッピングできないため、Python は真のマルチスレッド同時実行を実現できず、実行効率が低下します。
現在、Python チームは GIL を削除するという提案を正式に受け入れ、それをオプション モード にしました。これは開発者にとって良いことです。
この貢献は、Meta のソフトウェア エンジニア、Sam Gross によって行われ、プロジェクトを完了するまでに 4 年以上かかりました。
このニュースを聞いた後、誰もが拍手を送り、深層学習の 3 人の巨人の 1 人である Yann LeCun 氏は、「GIL なしで Python コードは自由にマルチスレッドを実行できるようになりました」と祝福のメッセージを送りました。
「ついに Python では GIL が不要になりました!」
「これはコーディングコミュニティが待ち望んでいた画期的な決定です。」
詳細は以下をご覧ください。ワオソフト アイオット http://143ai.com
CPython のコア開発者である Thomas Wouters は、Python での GIL フリーの詳細を説明し、将来の開発を期待する記事を書きました。
GIL なしの提案に対する皆様のフィードバック、全体的に前向きなサポートに感謝いたします。運営委員会は、GIL なしの提案を受け入れるつもりであり、以下で具体的な詳細を共有する予定です。
私たちの基本的な仮定は次のとおりです。
-
長期 (約 5 年以上) では、GIL なしのビルドが唯一のビルドになるはずです。
-
下位互換性については細心の注意を払っていきたいと考えています。GIL なしのビルドに対応するために必要なサードパーティのコード変更が、GIL ありのビルドにのみ適用される必要があるという Python 3 の状況はもう望んでいません (ただし、古い Python バージョンとの下位互換性の問題にはまだ対処する必要があります)。これは Python 4 では機能しません。これら 2 つのビルドの ABI 互換性の要件とその他の詳細、および下位互換性への影響についてはまだ検討中です。
-
no-GIL への完全な移行に取り組む前に、コミュニティのサポートを確認する必要があります。私たちは単にデフォルトを変更することはできません。それをサポートするためにコミュニティが何をする必要があるかを理解してもらいたいと考えています。私たちのコア開発チームは、新しいビルド モードとそれに関連するすべての経験を積む必要があります。既存のコードのスレッド セーフをクリーンアップしているため、新しい C API と Python API を理解する必要があります。また、これらの洞察を Python コミュニティの他の人々に伝え、私たちが加えたい変更と、彼らに加えてもらいたい変更が望ましいものであることを確認する必要があります。
-
デフォルトの no-GIL 設定に移行する前の任意の時点で、それがあまりにもメリットが少なく、破壊的すぎることが判明した場合には、考えを変更できるようにしたいと考えています。これは、すべての作業をロールバックすることも意味するため、GIL をデフォルトにしないと決定するまでは、GIL を使用しないコードはある程度識別できるはずです。
現在、今後の道のりは 3 つのフェーズに分かれていると考えられます。
-
短期的には、おそらく 3.13 で、実験的なビルド モードとして no-GIL ビルドが提供される予定です (おそらく 3.14 まで延期される可能性があります)。私たちのコア開発チームはこのビルド モードをサポートしていますが、コミュニティ全体がこのモードをサポートすることを期待していないため、これは実験的です。コミュニティのサポートを得られるように、少なくとも API 設計、パッケージ化、配布に関して何をしたいのかを理解する時間が必要です。また、ディストリビューターが実験的な no-GIL ビルドをデフォルトのインタープリターとしてリリースすることも推奨しません。
-
中期的には、本番環境での no-GIL の利用を実現するのに十分なコミュニティのサポートがあると確信した後、デフォルトではなく、特定の目標日または特定の Python バージョンで no-GIL ビルドをサポートする予定です。を使用するのがデフォルトの方法になります。正確なタイミングは、API の変更が最終的にどの程度互換性を持つか、コミュニティがまだ行う必要があると考えている作業量など、多くの要因によって異なります。これには少なくとも 1 ～ 2 年かかると予想しています。サポートを発表したら、一部のディストリビューターがデフォルトで no-GIL の出荷を開始することが予想されます。
-
長期的には、GIL なしをデフォルトにし、GIL の痕跡をすべて削除したいと考えています (ただし、下位互換性を不必要に壊すことはありません)。結局のところ、一般的に使用される 2 つのビルド モードが同時に存在すると、コミュニティに大きな負担がかかることになるため、あまり長く待ちたくないのです (リソースのテストとシナリオのデバッグを二重に行う必要があるなど)。しかし、急ぎすぎることはできません。このプロセスには5年かかると考えています。
もちろん、プロセス全体を通じて、開発チーム全体がリアルタイムで進捗状況を評価し、タイムラインを調整する必要があります。
コメント欄の皆さん、GIL がオプションになることについてどう思いますか?
参考リンク：
https://discuss.python.org/t/a-steering-council-notice-about-pep-703-making-the-global-interpreter-lock-optional-in-cpython/30474
https://twitter.com/dzhulgakov/status/1685667015800066048