アクター メッセージ パッシング セマンティクスの忠実な実装は、不変型であっても、論理的な観点からメッセージ コンテンツがディープ コピーされることを意味します。メッセージ コンテンツのディープ コピーは、アクター モデルの実装のボトルネックのままであるため、一部の実装では、パフォーマンスのためにゼロコピー メッセージ パッシングをサポートしています (ただし、プログラマの観点からはディープ コピーです)。
Erlangでは、ゼロコピー メッセージ パッシングはまったく実装されていますか? ノード間では明らかにそのままでは実装できませんが、同じノード上のプロセス間ではどうでしょうか? この質問は関連しています。
あなたの主張はまったく正しいとは思いません。プロセス間メッセージのディープ コピーは Erlang のボトルネックではありません。デフォルトの VM ビルド/設定では、これはまさにすべての Erlang システムが行っていることです。
Erlang プロセス ヒープは互いに完全に分離されており、メッセージ キューはプロセス ヒープ内にあるため、メッセージをコピーする必要があります。これは、データがプロセス ヒープとは別の割り当て領域に格納されるため、ETS テーブルとの間でデータを転送する場合にも当てはまります。
ただし、多くの共有データ構造があります。大きなバイナリ (>64 バイトの長さ) は通常、ノード全体の領域に割り当てられ、参照カウントされます。Erlang プロセスは、これらのバイナリへの参照を格納するだけです。これは、大きなバイナリを作成して別のプロセスに送信すると、参照のみが送信されることを意味します。
プロセス間でデータを送信することは、割り当てサイズの点で想像以上に悪いものです。ターム内の共有は、コピー中に保持されません。これは、メモリ消費を減らすために共有を使用して用語を慎重に作成すると、他のプロセスで共有されていないサイズに拡張されることを意味します。OTP Efficiency Guideで実用的な例を見ることができます。
Nikolaus Gradwohl が指摘したように、VM には実験的なハイブリッド ヒープ モードがあり、プロセス間で用語を共有し、ゼロコピー メッセージ パッシングを有効にしていました。私が理解している限り、これは特に有望な実験ではありませんでした.追加のロックが必要になり、プロセスが独立してガベージコレクションを行う既存の機能が複雑になります. したがって、プロセス間メッセージのコピーは、Erlang システムの通常のボトルネックではないだけでなく、実際にパフォーマンスを低下させます。
私の知る限り、-shared または -hybrid モデルを使用した erlang でのゼロコピー メッセージ パッシングの実験的サポートがありました/あります。2009 年に smp マシンでは壊れていると主張するブログ記事を読みましたが、現在の状況についてはわかりません
here および他の質問で述べたように、Erlang の現在のバージョンは基本的に、より大きなバイナリを除くすべてをコピーします。SMP 以前の古い時代には、参照をコピーせずに渡すことが可能でした。これにより、メッセージの受け渡しが非常に高速になりましたが、実装に他の問題が生じました。主に、ガベージ コレクションの実装がより困難で複雑になりました。今日、参照を渡したり、データを共有したりすると、過度のロックと同期が発生する可能性があると思いますが、これはもちろん良いことではありません。
あなたが参照している他の質問に対する受け入れられた回答を書きました。その中で、このコード行への直接のポインターを提供します。
message = copy_struct(message, msize, &hp, &bp->off_heap);
これは、Erlang ランタイム システムがメッセージを送信する必要があるときに呼び出される関数内にあり、スキップされる原因となるような "if" 内にはありません。したがって、私が知る限り、答えは「はい、常にコピーされています」です。(厳密にはそうではありません。「if」はありますが、通常のコード フロー パスではなく、例外的なケースを扱っているようです。)
(Nikolaus によって持ち出されたハイブリッド ヒープ オプションは無視しています。彼は正しいように見えますが、これは通常の Erlang の構築方法ではなく、独自のペナルティがあるため、ヒープ ヒープとして検討する価値があるとは思えません。あなたの懸念に答える方法。）
ただし、10 GByte/秒をボトルネックと考えている理由はわかりません。コンピュータではレジスタや CPU キャッシュが高速化されますが、これらのメモリは小さいため、それ自体が一種のボトルネックになります。それに加えて、あなたが提案しているゼロコピーのアイデアは、マルチコアシステムでクロスCPUメッセージパッシングの場合にロックを必要とし、これもボトルネックです。この関数では、メッセージを他のプロセスのメッセージ キューにコピーするために、既にロック ペナルティが発生しています。そのプロセスがメッセージを読むようになったときに、後でもう一度支払うのはなぜですか？
要するに、それを高速化する方法についてのあなたのアイデアは、実際にはあまり役に立たないと思います。