私は、メッセージパッシングで最高のパフォーマンスとスケーリングを実現するためのリソースを見つけようとしていました。参照ではなく値でメッセージを渡すと、NUMAスタイルのセットアップで適切に機能し、特定のメモリアドレスの競合が減少するため、スケーラビリティが向上する可能性があると聞きました。
値ベースのメッセージパッシングは「小さい」メッセージでのみ機能すると思います。「小さい」とは何と定義されますか？どの時点で参照が良くなるでしょうか？この方法でストリーム処理を行うでしょうか？
この種の質問に役立つヒントやリソースを探しています。
ありがとう ：-）
PS私はC＃で作業していますが、この種の設計の質問ではそれほど重要ではないと思います。
ジェレミーの優れたアドバイスに追加するいくつかの要因：
1）値の受け渡しは、小さなメッセージに対してのみ効率的に機能します。誤った共有を避けるために、データの最初に[cache-line-size]の未使用領域がある場合は、参照による受け渡しがより効率的なサイズにすでに近づいています。
2）キューの幅が広いと、キューが占めるスペースが増え、メモリ使用量に影響します。
3）ワイドキュー構造へのデータのコピー/ワイドキュー構造からのデータのコピーには時間がかかります。データ移動中の実際のCPU使用とは別に、コピー中はキューがロックされたままになります。これにより、キューでの競合が増加し、キュー幅に依存する全体的なパフォーマンスの低下につながります。コードにデッドロックの可能性がある場合、ロックを長期間保持しても問題は解決しません。
4）値を渡すと、データサイズに固有のコードが生成される傾向があります。コンパイル時に修正されます。テンプレートの厄介な蔓延は別として、これは実行時にバッファサイズなどを調整することを非常に困難にします。
5）メッセージが参照によって渡され、malloced / freed / newed / disposed / GCされた場合、これはメモリマネージャーでの過度の競合と頻繁で無駄なGCにつながる可能性があります。私は通常、特にこれを回避するために、起動時に割り当てられるメッセージの固定プールを使用します。
6）バイトストリームの処理は、参照を渡すときに扱いにくい場合があります。バイトストリームが単一バイトの頻繁な配信によって特徴付けられる場合、参照によるパスは、バイトがチャンクアップされている場合にのみ意味があります。これにより、部分的に埋められたメッセージがタイムリーに次のスレッドにディスパッチされるようにするためのタイムアウトが必要になる可能性があります。これにより、複雑さと遅延が発生します。
7）参照渡しの設計は、本質的にリークする可能性が高くなります。これにより、テスト時間が長くなり、valgrindの過剰摂取につながる可能性があります。これは、特に痛みを伴う依存症です（固定サイズのメッセージオブジェクトプールを使用するもう1つの理由）。
8）複雑なメッセージ。他のオブジェクトへの参照を含むものは、値によって渡された場合、所有権とライフタイム管理に恐ろしい問題を引き起こす可能性があります。例-サーバーソケットオブジェクトには、さまざまなサイズのバッファインスタンスの配列を含むバッファリストオブジェクトへの参照があります（実際の例はIOCPサーバーからのものです）。それを値で渡してみてください。
9）多くのOS呼び出しは、ポインター以外は処理できません。1回の呼び出しで値が256バイトの構造体であっても（2つのwParam、lParam整数しかありません）、PostMessage（これはWindows APIです）はできません。非同期コールバックを設定する呼び出しでは、多くの場合、「コンテキストデータ」をコールバックに送信できます。ほとんどの場合、ポインタは1つだけです。このようなOS機能を使用する予定のアプリは、ほとんどの場合、参照渡しを強いられます。
マーティン・ジェームスのポイントも良いですが、これは新しいエリアであるため、ジェレミー・フリースナーのコメントは最高のようです。コアが増えるにつれ、Microsoftが将来のカーネルのメッセージパッシングを検討していることを私は知っています。
メッセージパッシングを処理するフレームワークがあるようで、現在の.Netプロデューサー/コンシューマージェネリックよりもはるかに優れたパフォーマンスを備えていると主張しています。4.5の.Netのデータフローと比較してどうなるかわかりません