2

Ruby と Python の Global Interpreter Lock (GIL) 全体が Java から来ているのは、ちょっと驚くべきことです。問題を少し読んだところ、Python のドキュメントで次の抜粋が見つかりました。

Global Interpreter Lock を取り除くことはできませんか?

グローバル インタープリター ロック (GIL) は、ハイエンドのマルチプロセッサ サーバー マシンに Python を展開する際の障害と見なされることがよくあります。マルチスレッドの Python プログラムは、(ほとんど) すべての Python コードは、 GILが保持されている間に実行されます。

Python 1.5 の時代に、Greg Stein は実際に包括的なパッチ セット (「フリー スレッド」パッチ) を実装して、GIL を削除し、きめ細かなロックに置き換えました。残念ながら、(ロックが非常に効率的な) Windows でも、通常の Python コードの実行速度は、 GIL を使用するインタープリターの約 2 倍遅くなりました。Linux では、pthread ロックがそれほど効率的ではないため、パフォーマンスの低下はさらに悪化しました。

私が見つけられなかったのは、パフォーマンスへの影響の背後にある説明です。私は技術的な理由が何であるかを見つけようとしましたが、それを突き止める良い議論を見つけることができませんでした.

Ruby と同様に、ここではさらに少ない情報しか見つかりませんでした。理由は同じですか？

4

2 に答える 2

3

簡単に言えば、多くの錠を施錠および解錠することは、単一の錠を施錠および解錠するよりも費用がかかります。これは驚くべきことではありません.1回ではなくN回実行すると、より多くの時間がかかります（他のすべてが等しい場合）。そして、この種のことでは、規模の経済は実際には適用されません。すべてのロック操作で償却するための大きな 1 回限りのコストはありません。

編集: 原則として、Java にも同じ問題がありますが、関係者全員の焦点、歴史、およびおそらく他の要因が異なるため、Java はきめの細かいロックでかなりうまくいきます。要するに、シングルスレッドのパフォーマンスはそれほど重要ではないと考えられており、マルチスレッドのパフォーマンスはおそらく仮想のフリースレッド CPython よりも優れています。

歴史的に、GIL を備えた JVM は存在しなかったと思います (ただし、最初は単一の OS スレッドで実行されるグリーン スレッドでしたが、これはずっと前のことです)。そのため、GIL を保持し、ベースを保持しない歴史的な理由はありません。人々がロックを嫌うほどのシングル スレッド パフォーマンスを実現します。代わりに、Java をマルチスレッドに適したものにするために多大な努力が払われ、この機能は広く使用されています。対照的に、単一スレッドの Python または Ruby プログラムのパフォーマンス コストなしで GIL の問題を解決したとしても、そこにあるほとんどのコードはその恩恵を受けず、ライブラリは... ひどいものではありませんが、java.util.concurrentどちらとも正確には同等ではありません。 .

Java には (現在) 明示的に多くの保証を与えないメモリ モデルがあるため、Java プログラムの多くの一般的な操作では、一般に、いかなる種類のロックも必要ありません。もちろん欠点は、Java プログラマーが必要に応じて手動でロックやその他の同期を追加しなければならないことです。さらに、Java のロックでは、ロックに対して多くの最適化 (独自の研究であり、JVM で最初に導入されたものもあります) が見られました (シン ロック、ロック省略など)。これにより、競合のあるロックが非常に安価になります。

もう 1 つの要因は、Java プログラムがほぼ完全に Java コードを実行し (上記で説明したように、明示的に要求されない限り、同期はほとんど必要ありません)、ランタイム ライブラリへの呼び出しがほとんどないことです。結果として、フリースレッドの JVM は、ほとんどの Java プログラムにあまり影響を与えずに、JIT やクラスローダなどに対してグローバル ロック (またはいくつかの粗いロックのみ) を持つことさえできます。対照的に、Python プログラムは、組み込みモジュールまたはサードパーティの拡張モジュールのいずれかで、C コードに多くの時間を費やします。

于 2013-08-21T23:44:13.677 に答える