ようこそ ゲスト さん、新規登録(無料)して気になる疑問を解決しませんか?

質問

質問者:moritan2 AF_UNIXのsocketと共有メモリを使ったリングバッファーの速度比較
困り度:
  • すぐに回答を!
いま、仕事でlinux上で2つのプロセスを動かし、プロセスの間で、高速で大量のデータの受け渡しが必要なプログラムを作っています。プロセス間の通信は普通の socket で AF_UNIX を使っています。
 できるだけ速度を上げたいのですが、AF_UNIXのsocketのかわりに共有メモリを使ってリングバッファーでキューを作ってデータを送るという案が出ました。この方法によって速度の向上は期待できるでしょうか?
質問投稿日時:08/04/19 01:00
質問番号:3958666
この質問に対する回答は締め切られました。
最新から表示回答順に表示良回答のみ表示

回答

 

回答者:hidebun 共有メモリを使って速度の向上は期待できると私も思います。
が、そもそも送り側と受け側のプロセスが同一マシン上で
同時に動作できるのか?ということは考慮されているのでしょうか。

送り側・受け側が同一マシン上で動くと、双方の動作によって、
CPUの奪い合いになり、動作速度が上がらない可能性があります。

仮に、その実装でOKだったとしても、受け側のプロセスが2つに
なったら、破綻するようなシステムで良いのかなど、後々のことまで
考えて設計したほうが良いと思います。

2プロセスなら、DualCoreなら問題ないかもしれませんが。
種類:アドバイス
どんな人:一般人
自信:参考意見
回答日時:08/04/20 23:00
回答番号:No.3
この回答へのお礼この回答にお礼をつける(質問者のみ)

回答

良回答20pt

回答者:aid-u プロセスAからプロセスBへソケットを使用してデータを送信する場合、以下のようにメモリへのread/writeが発生すると思います。

1)プロセスA上のバッファへ送信データを書き込む
2)プロセスA上のバッファよりカーネル上のバッファへコピー
3)カーネル上のバッファよりプロセスB上のバッファへコピー
4)プロセスB上のバッファの受信データを読み込む

共用メモリを使用した場合は、2)および3)のread/write部分を省略できます。
2)および3)の部分は実際にはsend()/recv()を使用して行いますが、send()/recv()はデータのコピーだけではなく送信の制御のための作業を行います(当たり前ですが)。
send()/recv()の制御機構の処理時間と自前の排他制御の処理時間が同程度であれば、大量データのコピー処理を削減できるので速度の向上を期待できるのではないでしょうか。
種類:アドバイス
どんな人:経験者
自信:参考意見
回答日時:08/04/20 22:37
回答番号:No.2
この回答へのお礼ご回答ありがとうございました。
今すでにテストを開始していて、速度が向上していることを確認しました。

回答

良回答10pt

回答者:notnot 大容量データということで、ソケットのバッファを十分大きく取っていたとして、ソケットの場合、送り側の送信バッファと受け側の受信バッファが必要ですが(プロセスの特性によっては同じサイズを確保する必要はないわけですが)、共有メモリを使った場合だと1つでいいので、同じメモリ使用量の場合だと2倍の大きさのバッファを取れることになります。また、排他制御も自分ですることになるので、プロセスの実行状態と待ち状態を自分で細かく制御できるわけですから、速くできると思います。

データ量とバッファサイズの比にもよるのかな。ソケットでも、データが全部入りきれるだけのバッファが取れるのであれば、共有メモリ化による速度向上は、プログラムが複雑になるデメリットを上回らないのではないかなあ。
種類:回答
どんな人:一般人
自信:参考意見
回答日時:08/04/19 07:17
回答番号:No.1
この回答への補足脱字でした
それなりの効果は期待できるのでね。

それなりの効果は期待できるのですね。
この回答へのお礼ご回答ありがとうございます。
それなりの効果は期待できるのでね。
期待ができるのならやってみたいと思います。手間は、sendとrecvの代用品を作って、同じ名前で使えるようにしてやれば、ソケットの生成部分だけなので、たいしたことはないと思います。
しかし、最初から共有メモリを使うようにシステム全体を設計していればもっとシンプルにできたのですが、いまから変更だとsendとrecvをエミュレーションするような仕様にしなければならないので、その分は効率が悪いですね。
 
最新から表示回答順に表示良回答のみ表示