9

Pythonインタープリターから完全に独立した何かを行うC拡張関数があるとしましょう。GILをリリースしない理由はありますか？

たとえば、このようなコードを書かない理由はありますか（読みやすさやマイクロ最適化の回避などの問題は別として、重要ですが、私の質問にはあまり関係ありません）？

Py_BEGIN_ALLOW_THREADS
    a = 1 + 1;
Py_END_ALLOW_THREADS

明らかに、これはパフォーマンスがそれほど重要ではない些細なコードです。しかし、ここでGILをリリースしないパフォーマンス上の理由はありますか？または、GILは、CPUを集中的に使用するコードに対してのみリリースする必要がありますか？

4

4 に答える 4

9

GILは通常のミューテックスです。競合していないミューテックスをロックまたはロック解除するコストは非常に低く、グローバル変数を変更するコストをはるかに上回りません。ただし、競合するミューテックスを頻繁にロックおよびロック解除すると、ミューテックスのコストが大きくなる可能性があります。

したがって、これは通常は良い考えではありません。

Py_BEGIN_ALLOW_THREADS
    a = 1 + 1;
Py_END_ALLOW_THREADS

ここで起こっているのは、ミューテックスのロックを解除し、その直後に再度ロックしようとしていることです。これがコードの2つの大きなチャンク間の中断である場合、別のスレッドに実行の機会を与えます。ただし、スレッドの細分性に問題がない場合は、ロックを維持してください。

したがって、このコンテキストでは良い考えです。

very_long_computation_requires_gil();
Py_BEGIN_ALLOW_THREADS;
a = a + i;
Py_END_ALLOW_THREADS;
very_long_computation_also_requires_gil();

コンテキストを知らずに知識に基づいた推測を行うことは本当に不可能であり、テストを実行せずにそれでも難しいことがよくあります。

于 2011-10-22T00:15:40.717 に答える
1

専門家はまだGILについて微調整とテストを行っています。

これは古い問題についての新しいアイデアです： inside-look-at-gil-removal-patch

Stackless Python（GILなし）またはPyPy（Just-In-Timeコンパイラーを備えたPython）を試すことも検討できます。

于 2011-11-20T13:43:54.823 に答える
1

Pythonインタープリターから完全に独立した何かを実行するC拡張関数がある場合は、通常、GILをリリースすることをお勧めします。唯一の欠点は、GILを取り戻すのを待っていることです。Python 3.2では、少なくとも1/20秒待つ必要があります。

于 2011-10-22T01:57:52.233 に答える
0

GILをリリースしない理由はありますか？

C拡張機能が非再入可能コードを呼び出す場合、複数のPythonスレッドが同時に拡張機能を呼び出すと、問題が発生する可能性があります。したがって、このような拡張機能でGILをリリースしないようにして、これを防ぐことができます（もちろん、PythonレベルまたはCレベルで独自のミューテックスを作成して、他のスレッドに影響を与えずにこれを実現できます）。

または、GILは、CPUを集中的に使用するコードに対してのみリリースする必要がありますか？

GILを解放するもう1つの主な理由は、他のスレッドを実行できるようにするためにブロックするC拡張機能（ソケットでの読み取りのブロックなど）を呼び出す場合です。これは、Pythonインタープリター自体がスレッドでブロッキング操作を実行したときに発生することとまったく同じです。

于 2011-10-31T04:56:54.197 に答える