問題タブ [gil]

それで、Python Global Interpreter Lock (GIL) http://blip.tv/file/2232410でこの講演を見終わったところです。

その要点は、GIL がシングル コア システムにとって非常に優れた設計であるということです (Python は基本的に、スレッドの処理/スケジューリングをオペレーティング システムに任せています)。しかし、これはマルチコア システムでは深刻な裏目に出る可能性があり、IO 集中型スレッドが CPU 集中型スレッドによって大幅にブロックされ、コンテキスト切り替えの費用がかかり、ctrl-C の問題 [*] などが発生する可能性があります。

したがって、GIL は基本的に 1 つの CPU で Python プログラムを実行するように制限しているため、これを受け入れて Linux でタスクセットを使用して、プログラムのアフィニティをシステムの特定のコア/CPU に設定しないでください (特に、マルチコア システムで実行されている複数の Python アプリなど)?

最終的に私の質問は次のとおりです。PythonアプリケーションでLinuxでタスクセットを使用しようとした人はいますか（特に、Linuxシステムで複数のアプリケーションを実行して、特定のコアにバインドされた1つまたは2つのPythonアプリケーションで複数のコアを使用できるようにする場合）。結果でしたか？やる価値はありますか？特定のワークロードで事態が悪化することはありますか? 私はこれを実行してテストする予定です (基本的に、プログラムの実行にかかる時間が長いか短いかを確認します) が、あなたの経験について他の人から聞きたいです.

追加: David Beazley (リンクされたビデオで講演を行っている人物) は、一部の C/C++ 拡張機能が GIL ロックを手動で解放し、これらの拡張機能がマルチコア (つまり、科学的または数値データ分析など) 用に最適化されている場合、数を計算するためのマルチコアの利点を得るのではなく、拡張機能は単一のコアに制限されているという点で効果的に機能しなくなります (したがって、プログラムが大幅に遅くなる可能性があります)。一方、このような拡張機能を使用していない場合

マルチプロセッシング モジュールを使用しない理由は、(この場合) プログラムの一部がネットワーク I/O バウンド (HTTP 要求) に大きく依存しているためです。スレッドが HTTP リクエストを開始し、I/O を待機しているため、GIL を放棄し、別のスレッドがそれを実行できるため、プログラムの一部は、CPU に大きな負担をかけずに 100 以上のスレッドを簡単に実行でき、実際に使用できるようになります。利用可能なネットワーク帯域幅。スタックレス Python/etc に関しては、プログラムを書き直したり、Python スタックを置き換えたりすることにあまり関心がありません (可用性も懸念事項です)。

[*] シグナルを受信できるのはメイン スレッドだけなので、ctrl-C を送信すると、Python インタープリターは基本的にシグナルを処理できるようにメイン スレッドを実行させようとしますが、どのスレッドを実行するかを直接制御しないため (これはオペレーティング システムに任されています) 基本的に、最終的にメイン スレッドに到達するまでスレッドを切り替え続けるように OS に指示します (運が悪い場合は、しばらく時間がかかる場合があります)。

C++マルチスレッド統合に対するPython3.1のグローバルインタープリターロックの運命を知っている人はいますか

グローバル インタープリター ロックとは何ですか? なぜ問題なのですか?

Python から GIL を削除することに関して多くの騒ぎがありましたが、なぜそれがそれほど重要なのかを理解したいと思います。私は自分でコンパイラやインタープリターを書いたことがないので、詳細を倹約しないでください。おそらく理解する必要があるでしょう。

SWIG を使用してラップし、Python で使用する C++ で記述されたライブラリがあります。一般に、いくつかのメソッドを持つ 1 つのクラスがあります。問題は、これらのメソッドの呼び出しに時間がかかることです。アプリケーションがハングする可能性があります (これらのメソッドを呼び出すときに GIL は解放されません)。だから私の質問は：

これらのメソッド呼び出しのために GIL を解放する最も簡単な方法は何ですか?

（Cライブラリを使用した場合、これを追加のCコードでラップできることは理解していますが、ここではC++とクラスを使用しています）

GIL は Python インタープリターごとであると話している人をよく見かけます (ここでも stackoverflow でさえ)。

しかし、ソースコードで見たところ、GIL はグローバル変数であるため、各 Python プロセスのすべてのインタープリターに対して 1 つの GIL があるようです。lua や TCL のように渡されるインタープリター オブジェクトがないため、彼らがこれを行ったことはわかっています。最初は適切に設計されていませんでした。また、スレッド ローカル ストレージは、Python 関係者が使用するには移植性がないようです。

これは正しいです？ここでプロジェクトで使用している 2.4 バージョンを簡単に見てみました。

これは後のバージョン、特に 3.0 で変更されましたか?

python GIL の存在は、python マルチスレッドで同じ操作が単一スレッドでの繰り返しとそれほど変わらないことを意味しますか?

たとえば、2 つのファイルをアップロードする必要がある場合、1 つずつアップロードするのではなく、2 つのスレッドで行う利点は何ですか?

私は両方の方法で大きな数学演算を試みました。しかし、完了するまでにほぼ同じ時間がかかるようです。

これは私には不明確なようです。誰かがこれについて私を助けることができますか?. ありがとう。

Unladen Swallow のドキュメントのこのセクションがHacker News に掲載されているのを見たところです。基本的に、GIL の削除について楽観的ではないと言っているのは Google のエンジニアです。しかし、GIL についてのこの話が散在しているガベージ コレクターについての議論があるようです。誰か私との関係を説明してくれませんか?

Python 3.2 で見つかった、または見つかる予定の新しい GIL に関するこのページを読んでいて、Python 2.x から 3.x への移行をトリガーするのが「キラー機能」であるかどうか疑問に思っていました。

皆さんはどう思いますか？

Python C 拡張機能で GIL を操作する最も簡単な方法は、提供されているマクロを使用することです。

これはうまく機能し、コードの大部分については GIL を解放できますが、GIL を必要とする小さなコードについては GIL を再取得します。

問題は、これを gcc でコンパイルすると、次のようになることです。

Py_BEGIN_ALLOW_THREADS は次のように定義されているため:

だから、3つの質問：

1. gccの警告を抑制することはできますか?
2. _save宣言の直後に割り当てられているため、gccが初期化されていない可能性があると考える理由を誰かが知っていますか?
3. 問題を回避するために、1 つのステートメントで変数を宣言して初期化するようにマクロが定義されていないのはなぜですか?

(最後の 2 つは、私自身の好奇心のためだけのものです)。

マクロを使用せず、すべて自分で実行することで問題を回避できますが、むしろ避けたいと思います。