問題タブ [zero-copy]

アプリケーションのプロファイリングにより、CPU 時間の 5% 近くを文字列の割り当てに費やしていることがわかりました。多くの場所で、64MB の char バッファから C++ std::string オブジェクトを作成しています。問題は、プログラムの実行中にバッファが変更されることはありません。呼び出しの私の分析はstd::string(const char *buf,size_t buflen)、文字列が作成された後にバッファが変更される可能性があるため、文字列がコピーされているということです。それはここの問題ではありません。この問題を回避する方法はありますか?

EDIT：私はバイナリデータを扱っているので、単に渡すことはできませんchar *s. さらに、常に NULL をスキャンすることでかなりのオーバーヘッドが発生しますが、これはstd::string回避できます。

ゼロコピーを利用した CUDA アプリケーションのパフォーマンスを分析した経験のある人はいますか (ここを参照: Default Pinned Memory Vs Zero-Copy Memory ) メモリ モデル?

ゼロコピー機能を使用するカーネルがあり、NVVP を使用すると、次のように表示されます。

平均的な問題サイズでカーネルを実行すると、0.7% の命令リプレイ オーバーヘッドが発生するため、大きな問題はありません。そして、この 0.7% はすべてグローバル メモリ リプレイ オーバーヘッドです。

問題のサイズを実際に大きくすると、95.7% の命令リプレイ オーバーヘッドが発生します。これはすべて、グローバル メモリのリプレイ オーバーヘッドによるものです。

ただし、通常の問題サイズのカーネル実行と非常に大きな問題サイズのカーネル実行の両方のグローバル ロード効率とグローバル ストア効率は同じです。この指標の組み合わせをどうするかはよくわかりません。

主に確信が持てないのは、NVVP のどの統計が、ゼロ コピー機能で何が起こっているかを確認するのに役立つかということです。どのタイプの統計を見ればよいかについてのアイデアはありますか?

splice（）を使用して複数のソケットに書き込むために、tee（）で「マスター」パイプを複製しています。当然、これらのパイプは、宛先ソケットにsplice（）できる量に応じて、さまざまなレートで空になります。したがって、次に「マスター」パイプにデータを追加してからもう一度tee（）すると、パイプに64KBを書き込むことができるが、「スレーブ」パイプの1つに4KBしか書き込むことができない状況が発生する可能性があります。その場合、すべての「マスター」パイプをソケットにsplice（）すると、残りの60KBをそのスレーブパイプにtee（）できなくなると推測しています。本当？「unteed」データの先頭に設定したtee_offset（0から開始）を追跡し、それを超えてsplice（）しないようにすることができると思います。したがって、この場合、tee_offsetを4096に設定し、それ以上スプライスしないようにします。他のパイプにすべてにティーすることができます。私はここで正しい方向に進んでいますか？私へのヒント/警告はありますか？

Java では、java.nioライブラリを使用FileChannel.transferTo()し、 and を使用しFileChannel.transferFrom()ます。(具体的には) C# に似たようなものはありますか? それとも、管理されていない .dll をどこかからロードする必要がありますか? この場合、Google は役に立ちませんでした。

編集: .NET 3.5 をターゲットにしていることに注意してください。

したがって、約 5.12Gb/s (約 320e6 パケット/秒) のデータ レートで 272 バイトのパケットで構成される受信 UDP ストリームがあります。このデータは、FPGA ベースのカスタム ボードによって送信されています。パケット サイズは実行中のデジタル デザインの制限であるため、理論的にはそれを増やして効率化することは可能ですが、多大な作業が必要になります。受信側で、これらのパケットはネットワーク スレッドによって読み取られて解釈され、バッファリング スレッドと共有される循環バッファに配置されます。バッファリング スレッドは、このデータを GPU にコピーして処理します。

受信側の上記のセットアップは、単純な呼び出しを使用して 4096 KB パケット (別の設計で使用) の 5.12Gb/s に対処できますがrecv、現在のパケット サイズでは、パケット フローについていくのにも苦労しています。コンテキストの切り替えと、カーネル空間からユーザー空間への小さなデータセグメントのコピーに多くの時間が「無駄」になっています。を使用する簡単なテスト実装を行いましたがrecvmmsg、あまり改善されませんでした。平均して、着信パケットの約 40% を処理できます。

それで、アプリケーション (mmap スタイル) 用にカーネルの UDP データ バッファのハンドルを取得できるかどうか、またはカーネルからユーザー空間への何らかのゼロ コピーを使用できるかどうか疑問に思っていました。または、このオーバーヘッドを削減し、必要な処理を実行できる他の方法を知っていますか?

これは、C コードを使用して Linux マシン (カーネル 3.2.0-40) で実行されています。

画像/ビデオストリームを処理するためにDjangoでWebサービスを作成していますが、ほとんどが外部プログラムで行われています. 例えば：

1. クライアントのリクエスト/1.jpg?size=300x200
2. 300x200django (または他の WSGI アプリ) でのpython コードの解析
3. パラメータ300x200で、モジュールを使用してpython呼び出しconvert（Imagemagickの一部）subprocess
4. convertローカル ディスクから 1.jpg を読み取り、それに応じてサイズを変換します
5. 一時ファイルへの書き込み
6. Django はHttpResponse()、一時ファイルのコンテンツ全体を本体としてビルドして読み取ります

ご覧のとおり、一時ファイルの読み取りと書き込みのプロセス全体は非効率的です。このような同様の外部プログラムを処理するための一般的な方法が必要convertです.cjpegffmepg

私はこの方法でそれを実装したい:

1. python は子プロセスの stdoutfdを取得しますconvert
2. 出力のためにWSGIソケットfdにチェーンします

私は宿題をしました.Googleは、この種のゼロコピーはシステムコールで実行できると言いますsplice(). ただし、Python では使用できません。では、この種のシナリオで Python のパフォーマンスを最大化するにはどうすればよいでしょうか?

1. ctypes?を使用して splice() を呼び出します。
2. memoryview() または buffer() をハックしますか?
3. subprocess has stdoutwhich has readinto()、これを何とか利用できますか?
4. WSGI アプリの fd 番号を取得するにはどうすればよいですか?

私はこれらの初心者です。どんな提案でも大歓迎です、ありがとう!

サーバーから大量のデータを受信するクライアント プログラムにゼロ コピー アプローチを実装しようとしています。クライアント プログラムは次のとおりです: //Client.h

//Client.cpp

readanydata() は他の API に置き換える必要があります。read() と readall() はメモリ コピーを使用するため、ゼロ コピー アプローチには適していません。クライアントは QTcpsocket のインスタンスです。 APIを取得するか、独自の関数を作成する必要があります.独自の関数を作成する必要がある場合、どのようにtransmitfile（）APIを呼び出しますか.