技術的には、なぜErlangのプロセスはOSスレッドよりも効率的ですか？

アーランの特徴

以下からのErlangプログラミング（2009）：

Erlangの並行性は高速でスケーラブルです。そのプロセスは軽量であり、Erlang仮想マシンは、作成されたすべてのプロセスに対してOSスレッドを作成しません。これらは、基盤となるオペレーティングシステムに関係なく、VMで作成、スケジュール、および処理されます。その結果、プロセスの作成時間はマイクロ秒のオーダーであり、同時に存在するプロセスの数とは無関係です。これをJavaおよびC＃と比較してください。すべてのプロセスについて、基盤となるOSスレッドが作成されます。Erlangが両方の言語よりもはるかに優れているため、いくつかの非常に競争力のある比較が得られます。

同時実行アーラン（PDFファイル）に指向プログラミング （スライド）（2003年）：

Erlangプロセスの作成にかかる時間は1µsから2,500プロセスまで一定であることがわかります。その後、最大30,000プロセスで約3µsに増加します。JavaとC＃のパフォーマンスは、図の上部に示されています。少数のプロセスでは、プロセスの作成に約300µsかかります。2,000を超えるプロセスを作成することは不可能です。

最大30,000プロセスの場合、2つのErlangプロセス間でメッセージを送信する時間は約0.8µsであることがわかります。C＃の場合、メッセージごとに約50µs、最大プロセス数（約1800プロセス）までかかります。Javaはさらに悪く、最大100のプロセスでメッセージあたり約50µsかかった後、約1000のJavaプロセスがあるとメッセージあたり10msに急速に増加しました。

私の考え

Erlangプロセスが新しいプロセスの生成においてはるかに効率的であり、プロセスごとのメモリフットプリントがはるかに小さい理由を技術的に完全には理解していません。OSとErlang VMの両方は、スケジューリング、コンテキストスイッチを実行し、レジスタの値を追跡する必要があります。

単に、OSスレッドがErlangのプロセスと同じ方法で実装されていないのはなぜですか？彼らはもっと何かをサポートする必要がありますか？そして、なぜ彼らはより大きなメモリフットプリントを必要とするのですか？そしてなぜ彼らは産卵とコミュニケーションが遅いのですか？

技術的に、スポーンと通信に関して、ErlangのプロセスがOSスレッドよりも効率的であるのはなぜですか？また、OSのスレッドを同じ効率的な方法で実装および管理できないのはなぜですか。また、OSスレッドのメモリフットプリントが大きく、生成と通信が遅いのはなぜですか？

もっと読む

• SMPに焦点を当てたErlang VMの内部（2008）
• JavaとErlangでの並行性（pdf）（2004）
• JavaのスレッドとErlangのプロセスのパフォーマンス測定（1998）

いくつかの要因があります。

1. ErlangプロセスはOSプロセスではありません。これらは、軽量の協調スレッドモデルを使用してErlang VMによって実装されます（Erlangレベルではプリエンプティブですが、協調的にスケジュールされたランタイムの制御下にあります）。これは、既知の制御されたポイントでのみ切り替わるため、CPU状態全体（通常、SSEおよびFPUレジスタ、アドレス空間マッピングなど）を保存する必要がないため、コンテキストを切り替えるほうがはるかに安価であることを意味します。
2. Erlangプロセスは動的に割り当てられたスタックを使用します。スタックは非常に小さく始まり、必要に応じて大きくなります。これにより、使用可能なすべてのRAMを消費することなく、何千、さらには何百万ものErlangプロセスを生成できます。
3. Erlangは以前はシングルスレッドでした。つまり、プロセス間でスレッドの安全性を確保する必要はありませんでした。現在はSMPをサポートしていますが、同じスケジューラ/コア上のErlangプロセス間の相互作用は非常に軽量です（コアごとに個別の実行キューがあります）。

さらに調査を行った後、ジョーアームストロングのプレゼンテーションを見つけました。

Erlangから-並行世界のためのソフトウェア（プレゼンテーション）（13分）：

[Erlang]は並行言語です。つまり、スレッドはプログラミング言語の一部であり、オペレーティングシステムに属していません。これは、JavaやC ++などのプログラミング言語の実際の問題です。スレッドはプログラミング言語ではなく、オペレーティングシステムにあるものであり、オペレーティングシステムに存在するすべての問題を継承しています。問題の1つは、メモリ管理システムの粒度です。 オペレーティングシステムのメモリ管理はメモリのページ全体を保護するため、スレッドの最小サイズはページの最小サイズです。 それは実際には大きすぎます。

あなたがあなたのマシンにメモリを追加した場合-あなたは、ページテーブルの粒度が上がるように、メモリを保護し、同じビット数を持っている - あなたは数百バイトで実行している知っているプロセスのために言うの64kBのを使用して終了します。

すべてではないにしても、少なくとも私の質問のいくつかはそれで答えると思います

アセンブラーにコルーチンを実装し、パフォーマンスを測定しました。

最新のプロセッサーでは、コルーチン（別名Erlangプロセス）間の切り替えに約16命令と20ナノ秒かかります。また、切り替え先のプロセスをよく知っている（例：キューでメッセージを受信するプロセスは、呼び出しプロセスから受信プロセスへの直接のハンドオフとして実装できる）ので、スケジューラーは機能しません。これはO（1）操作です。

OSスレッドを切り替えるには、カーネルを呼び出すため、約500〜1000ナノ秒かかります。OSスレッドスケジューラはO（log（n））またはO（log（log（n）））時間で実行される場合があります。これは、数万または数百万のスレッドがある場合に顕著になります。

したがって、Erlangプロセスは高速であり、切り替えの基本的な操作が高速であり、スケジューラーの実行頻度も低いため、スケーリングが向上します。

Erlangプロセスは、他の言語のグリーンスレッドに（ほぼ）対応しています。プロセス間にOSによる強制分離はありません。（言語による分離もあるかもしれませんが、Erlangが他よりも優れた仕事をしているにもかかわらず、保護は低くなります。）それらは非常に軽量であるため、はるかに広範囲に使用できます。

一方、OSスレッドは、さまざまなCPUコアで単純にスケジュールすることができ、（ほとんど）独立したCPUバウンド処理をサポートできます。OSプロセスはOSスレッドに似ていますが、OSによる分離がはるかに強力です。これらの機能の代償は、OSスレッドと（さらにそうであれば）プロセスがより高価になることです。

違いを理解する別の方法はこれです。JVMの上にErlangの実装を書くつもりだとしたら（特におかしな提案ではありません）、各Erlangプロセスを何らかの状態のオブジェクトにすることになります。次に、Erlangプロセスを実行するスレッドインスタンスのプール（通常は、ホストシステムのコアの数に応じたサイズに設定されます。これは、実際のErlangランタイムBTWの調整可能なパラメーターです）です。次に、実行される作業を、使用可能な実際のシステムリソース全体に分散します。それは物事を行うのにかなりきちんとした方法ですが、完全に依存しています個々のErlangプロセスはそれぞれあまり機能しないという事実についてです。もちろんそれで問題ありません。Erlangは、プログラムを実行するのはそれらの全体的な集合体であるため、それらの個々のプロセスが重いものである必要がないように構成されています。

多くの点で、本当の問題は用語の1つです。Erlangがプロセスを呼び出すもの（およびCSP、CCS、特にπ計算の同じ概念に強く対応するもの）は、Cの遺産を持つ言語（C ++、Java、C＃、および他の多く）プロセスまたはスレッドを呼び出します。いくつかの類似点はありますが（すべて同時実行の概念が含まれます）、同等のものはありません。だから誰かがあなたに「プロセス」を言うときは注意してください。彼らはそれを全く異なる何かを意味すると理解するかもしれません…

Jonasは、OSスレッドをErlangプロセスと比較する際にいくつかの数値を求めていたと思います。プログラミングアーランの作者であるジョーアームストロングは、しばらくの間、OSスレッドへのアーランプロセスの生成のスケーラビリティをテストしました。彼はErlangで単純なWebサーバーを作成し、マルチスレッドApacheに対してテストしました（ApacheはOSスレッドを使用しているため）。1998年にさかのぼるデータを含む古いウェブサイトがあります。私はそのサイトを正確に1回しか見つけることができませんでした。そのため、リンクを提供できません。しかし、情報はそこにあります。調査の主なポイントは、Apacheが手書きのErlangサーバーが10K以上のプロセスを処理している間に、Apacheが8Kプロセスのすぐ下に達したことを示しました。

Erlangインタープリターはそれ自体を心配する必要があるだけなので、OSには他にも多くの心配事項があります。

その理由の1つは、erlangプロセスがOSではなくevm（erlang仮想マシン）で作成されるため、コストが小さくなることです。