C++マルチスレッド統合に対するPython3.1のグローバルインタープリターロックの運命を知っている人はいますか
13267 次
7 に答える
25
GILはまだCPython3.1にあります。Unladen Swallowプロジェクトは、（他の多くのパフォーマンス向上の中でも）最終的にそれを削除することを目的としていますが、それでも目標からの道のりであり、最初に2.6に取り組んでおり、最終的には、現在のxが何であれ3.xに移植することを目的としています。 2.yバージョンが完了したと見なされる時間。今のところ、（スレッド化の代わりに）マルチプロセッシングがCPythonで複数のコアを使用するための選択肢として残っています（IronPythonとJythonも問題ありませんが、現在Python 3をサポートしておらず、C++統合もそれほど簡単ではありません;- ）。
于 2009-08-03T15:25:03.777 に答える
17
GIL forPython3.2では重要な変更が行われます。Python 3.2の新機能と、それを開始したスレッドをメーリングリストで確認してください。
この変更はGILの終了を意味するものではありませんが、パフォーマンスが大幅に向上する可能性があることを示しています。
アップデート
- Antoine Pitrouによる3.2の新しいGILによる一般的なパフォーマンスの向上はごくわずかであり、代わりに、特定のコーナーケースで発生する競合の問題の改善に焦点を合わせました。
- 残念ながら、CPUとIOバウンドのスレッドが混在している場合に、パフォーマンスを大幅に向上させるスケジューラーを実装するために、DavidBeazleyによる素晴らしい努力がなされました。
- Unladen Swallowの作業は、Python 3.3にマージするために提案されましたが、そのプロジェクトでの結果が不足しているため、これは取り下げられました。PyPyは現在優先プロジェクトであり、現在Python3kサポートを追加するための資金を要求しています。現在、PyPyがデフォルトになる可能性はほとんどありません。
過去15年間、CPythonからGILを削除するための努力がなされてきましたが、当面の間、ここにとどまります。
于 2010-01-26T04:51:43.343 に答える
9
GILは、Pythonオブジェクトを使用しないコードには影響しません。Numpyでは、計算コード（線形代数呼び出しなど）用のGILをリリースし、基盤となるコードはマルチスレッドを自由に使用できます（実際、これらは通常、Pythonについて何も知らないサードパーティのライブラリです）
于 2009-08-04T01:17:51.500 に答える
4
GILは良いことです。
マルチスレッド作業を行っている間に、C++アプリケーションにGILをリリースさせるだけです。Pythonコードは、他のスレッドでそのまま実行され続けます。Pythonオブジェクトに触れる必要がある場合にのみGILを取得します。
于 2009-08-03T20:39:39.280 に答える
1
GILが邪魔になっている場合は、マルチプロセッシングモジュールを使用してください。新しいプロセスを生成しますが、スレッドモデルと（ほとんどの）APIを使用します。つまり、スレッドのような方法でプロセスベースの並列処理を行うことができます。
于 2011-02-11T04:05:27.563 に答える
1
いつもGILがあると思います。その理由はパフォーマンスです。すべての低レベルアクセススレッドを安全にする-各ハッシュ操作などの周りにミューテックスを配置することは重いことを意味します。次のような簡単なステートメントを覚えておいてください
self.foo(self.bar, 3, val)
現時点ですでに少なくとも3つ（valがグローバルの場合）のハッシュテーブルルックアップを持っている可能性があり、メソッドキャッシュがホットでない場合はさらに多くの可能性があります（クラスの継承の深さに応じて）
それは高価です-そのため、Javaはそのアイデアを捨て、「JavaIsSlow」の商標を取り除くためにモニター呼び出しを使用しないハッシュテーブルを導入しました。
于 2009-09-21T21:36:43.193 に答える
1
私が理解しているように、「brainfuck」スケジューラーはpython3.2のGILに取って代わります
于 2011-02-11T03:54:50.567 に答える