Python 3.1のGIL

Question

C ++マルチスレッド統合に対するPython 3.1のグローバルインタープリターロックの運命を誰もが知っていますか

Answer 1

GILはCPython 3.1にまだあります。 Unladen Swallow プロジェクトは、（他の多くのパフォーマンス向上の中でも）最終的に削除することを目指していますが、それはまだその目標からの道であり、2.yバージョンが完了したとみなされるまでに現在のxが何であれ、最終的に3.xに移植する意図で2.6に取り組んでいます。現在のところ、CPythonで複数のコアを使用するには、（スレッドではなく）マルチプロセッシングが引き続き選択されます（IronPythonとJythonも問題ありませんが、現在Python 3をサポートしておらず、C ++との統合もそれほど簡単ではありません;- ）。

Answer 2

Python 3.2のGILで大幅な変更が発生します。 Python 3.2の新機能をご覧ください。およびメーリングリストでそれを開始したスレッド。

変更はGILの終了を意味するものではありませんが、パフォーマンスの大幅な向上を予告します。

Update0

• Antoine Pitrouによる3.2の新しいGILによる一般的なパフォーマンスの向上はごくわずかであり、代わりに競合の問題の改善特定の場合に発生します。
• CPUとIOのパフォーマンスを大幅に向上させるスケジューラを実装するために、David Beazleyによる見事な努力が行われました。バインドされたスレッドが混在していますが、残念ながら撃shotされました。
• Unladen Swallowの作業は、Python 3.3ではマージの提案でしたが、これは、そのプロジェクトの結果が不足しているため撤回されました。 PyPy が優先プロジェクトになり、現在資金を要求してPython3kサポートを追加します。 PyPyが現在デフォルトになる可能性はほとんどありません。

CPythonからGILを削除する努力が過去15年間行われましたが、予見可能な将来のためにここに留まります。

Answer 3

GILは、Pythonオブジェクトを使用しないコードには影響しません。 Numpyでは、計算コード（線形代数呼び出しなど）のGILをリリースし、基盤となるコードはマルチスレッドを自由に使用できます（実際、これらは一般的に、Pythonについて何も知らないサードパーティライブラリです）

Answer 4

GILは良いことです。

C ++アプリケーションがマルチスレッド処理を行っている間にGILを解放するだけです。 Pythonコードは、他のスレッドでそのまま実行されます。 pythonオブジェクトに触れる必要がある場合にのみGILを取得します。

Answer 5

GILは常に存在すると思います。 その理由はパフォーマンスです。すべての低レベルアクセススレッドを安全にする-つまり、各ハッシュ操作にミューテックスを配置するなどの作業が重くなります。

self.foo(self.bar, 3, val)

現在、少なくとも3つ（valがグローバルの場合）ハッシュテーブルルックアップを持っている可能性があり、メソッドキャッシュがホットでない場合はさらに多くの可能性があります（クラスの継承の深さによる）

高額-それが、Javaがアイデアを落とし、「Java Is Slow」を取り除くためにモニター呼び出しを使用しないハッシュテーブルを導入した理由です。商標。

Answer 6

私が理解しているように、「brainfuck」はスケジューラーはPython 3.2のGILを置き換えます

BFS bainfuckスケジューラ

Answer 7

GILが邪魔になる場合は、マルチプロセッシングモジュールを使用してください。 。新しいプロセスを生成しますが、スレッドモデルと（ほとんどの）APIを使用します。つまり、スレッドベースの方法でプロセスベースの並列処理を実行できます。