ruby - Ruby Enterpriseはグリーンスレッドを使用していますか？

Question

私はこれを不思議に思っていて、これ以外は何も見つかりませんでした

「スレッドスケジューラのバグ修正とパフォーマンスの改善。RubyEnterpriseEditionでのスレッド化は、公式のRuby1.8よりも10倍以上高速になる可能性があります。」

Answer 1

REEはMRI1.8.7から派生しています。そのため、グリーンスレッドのみを使用しました。REEは、1.8.7の一部を変更します（特に、メモリ管理とガベージコレクションの領域で）。ただし、それでもアップストリームMRI（元のMatzのRubyインタープリター）の設計に広く準拠しています。

YARV（1.9）はOSネイティブスレッドに切り替えましたが、グローバルインタープリターロックがあり、一度にこれらのスレッドの1つだけが実行されるようになっています。

OSネイティブスレッドを使用し、GILを使用しないRuby実装がいくつかあります。最も有名なのは、JRuby（JVMに基づく）とRubinius（独自のVMを使用）です。これらの実装は、「実際の」並行スレッドを提供します。

Answer 2

インタプリタロックを完全に取り除いたJRubyとRubiniusに加えて、CRuby/MRIの状況も並行性に関してある程度進歩しています。

注目すべき機能の1つは、中村成弘によるビットマップマーキングGCにより、Ruby 2.0以降、CRubyに対するREEのもう1つの利点が失われることです。 ）スレッドではなく。新しいビットマップマーキングGCには、新しいプロセスをフォークするときにメモリの不要なコピーを節約できるという同じ利点があります。

GIL（または正式に呼ばれるGVL）も、最初に聞こえるほど悪くはありません。たとえば、RubyはIOを実行するときにインタプリタロックを解放します。最近よく見られるもう1つの機能は、C拡張機能の開発者が、を呼び出すことで手動でロックを解放できることrb_thread_blocking_regionです。これにより、GILが解放された状態でCレベルの関数が実行されます。これは、副作用がないことを確認できるCでの操作を実行する場合に、大きな影響を与える可能性があります。良い例はRSAキーの生成です。これはOpenSSLによって割り当てられたメモリを使用してCで完全に実行されるため、GILをリリースしても安全に実行できます。

1.9またはCelluloidのような最近のプロジェクトで導入されたファイバーも、数年前と比較して、今日のRubyの並行性の状態にはるかに友好的な光を投げかけています。

最後になりましたが、CRubyのVMの作成者である笹田耕一氏はMVMテクノロジーに積極的に取り組んでおり、単一のRubyプロセスで複数のVMを実行できるため、さらに別の方法で同時実行性を実現できます。

他のすべてのパフォーマンスの向上を考慮に入れると、REEを使用するための議論はますます少なくなります。特に、1.8シリーズはもはや積極的に開発されておらず、多くの人気のあるプロジェクトがあるため、リリース後は1.9.3または2.0.0に安全に切り替えることができます。 1.8のサポートを間もなく終了することを発表しました。

編集：

Holgerが指摘したように、REEもEOLされており、1.9以降への移植はありません。したがって、切り替えるのは安全であるだけでなく、正しいことでもあります:)