問題タブ [memcpy]

new で取得した char 配列にデータを格納する単純なバイト バッファを作成しています。memcpy および memmove 関数が、new で取得したメモリで使用すると奇妙なことが起こるかどうか、または代わりに推奨する何かがあるかどうか疑問に思っていました。 ?

時々大量のメモリを複製しなければならないリアルタイムシステムを設計しています。メモリは非小さな領域で構成されているため、コピーのパフォーマンスは、関連するコンポーネント（CPU、RAM、MB）が実行できる最大帯域幅にかなり近いと思います。これにより、現代のコモディティマシンはどのような生のメモリ帯域幅を集めることができるのだろうかと思いました。

私の古いCore2Duoは、1つのスレッドを使用すると1.5 GB / sにmemcpy()なります（両方のコアを同時に使用する場合は当然少なくなりmemcpy()ます）。1.5GBはかなりの量のデータですが、作業中のリアルタイムアプリケーションには1/50秒のようなもので、30MBを意味します。基本的に、ほとんど何もありません。そしておそらく最悪の場合、複数のコアを追加すると、必要な複製ステップのパフォーマンスを向上させることなく、より多くのデータを処理できます。

しかし、最近のローエンドのCore2Dueは必ずしもホットなものではありません。現在および近い将来のハードウェアのrawメモリ帯域幅に関する実際のベンチマークなどの情報を提供しているサイトはありますか？

さらに、メモリ内の大量のデータを複製するためのショートカットはありますか、それともmemcpy()それが得られるのと同じくらい良いですか？

短時間でできるだけ多くのメモリを複製する以外に何もすることがないコアの束を考えると、私ができる最善のことは何ですか？

編集：私はまだ生のメモリコピーのパフォーマンスに関する良い情報を探しています。古いmemcpy()ベンチマークを実行しました。同じマシンと設定で、2.5GB/秒になります...

memcpyはあまり使用されていませんが、これが機能しない私のコードです。

（enginebase + 0x74C9D）は、パッチを適用するバイトのアドレスへのポインターの場所です。

（void *）0xEBは、必要な種類のjmpのオペコードです。

唯一の問題は、これが回線を実行しようとした瞬間にクラッシュすることです。何が間違っているのかわかりません。

私は使用しています：

メモリのセクションをバイトの配列に格納するには、同じアドレス空間にいるため、これがずさんであることに気付きましたが、memcpy で同じことを行う方法がわかりません。

long のサイズは、特定の CPU アーキテクチャの WORD サイズと常に等しいことがわかりました。すべてのアーキテクチャに当てはまりますか? CでWORDサイズの変数を表すポータブルな方法を探しています.

メモリ アロケータを作成していますが、メモリのチャンク内に整数を格納する方法が必要です。この整数はブロックのサイズを表すため、先頭へのポインターを指定して末尾に移動できます。

これが私のテスト例です：

// 編集: testInt int* testInt = new int の宣言されたスペース。

これにより、最後から 2 番目の行でセグメンテーション違反がスローされます。

私がやろうとしていることは理にかなっていますか？

もしそうなら、正しいアプローチは何ですか？

お世話になりました皆様、本当にありがとうございました!! 問題が解決しました ：-）

私は混合モードで作業しています (1 つのアセンブリで C++ と C++ を管理しています)。私はこのような状況にあります。

次に、以下の「メソッド」を呼び出して「& managedStructure」に渡します

このシナリオについて次の質問があります。

1) このように memcpy を使用しても安全ですか? そうでない場合、同じ機能を実現するための代替手段は何ですか? (「メソッド」の定義を変更することはできません)

2) 両方の構造が管理されているため、メモリを解放していません。大丈夫ですか？

クラス プロジェクトとして、ファイルのログ ベースのファイル システムの実装に取り​​組んでいます。私の 64 ビット OS X ラップトップではかなりの量のコードが動作していますが、CS 部門の 32 ビット Linux マシンでコードを実行しようとすると、セグ フォールトが発生します。

与えられた API では、一度に DISK_SECTOR_SIZE (512) バイトを書き込むことができます。私たちのログ レコードは、ユーザーが書き込みたい 512 バイトといくつかのメタデータ (書き込み先のセクター、操作の種類など) で構成されています。

全体として、「レコード」オブジェクトのサイズは 528 バイトです。これは、各ログ レコードがディスク上の 2 セクタにまたがることを意味します。

最初のレコードは、セクター 0 に 0 から 512 を書き込み、セクター 1 に 0 から 15 を書き込みます。2 番目のレコードは、セクター 1 に 16 から 512 を書き込み、セクター 2 に 0 から 31 を書き込みます。セクター 3 の 0-47。ETC。

したがって、変更する 2 つのセクタを 2 つの新たに割り当てられたバッファに読み込み、レコードから buf1+512 オフセット バイトの計算されたオフセットにコピーします。これは両方のマシンで正しく機能します。

ただし、2 番目の memcpy は失敗します。具体的には、以下のコードの「record+DISK_SECTOR_SIZE-offset」は segfaults ですが、Linux マシンでのみ発生します。いくつかのランダムなテストを実行すると、さらに興味深いものになります。Linux マシンは、sizeof(Record) が 528 であると報告します。したがって、record+500 から buf に 1 バイトの memcpy を実行しようとしても、問題はないはずです。

実際、レコードから取得できる最大のオフセットは 254 です。つまり、memcpy(buf1, record+254, 1) は機能しますが、memcpy(buf1, record+255, 1) は segfault になります。

誰かが私が欠けているものを知っていますか?

int配列を別の配列にコピーしたいint。それらは長さに対して同じ定義を使用するため、常に同じ長さになります。

size パラメーターの次の 2 つの代替案の長所と短所は何memcpy()ですか?

また

2 番目のオプションは常に機能しますか? 内容に関係なく？

最後のものを支持することの 1 つは、配列が変更された場合、memcpy().

http://en.cppreference.com/w/cpp/string/byte/memcpyによると、c++memcpyは宛先、ソース、およびサイズ/バイトの 3 つのパラメータを取ります。また、ポインタも返します。どうしてこんなことに？データを入力およびコピーするのに十分なパラメーターではありません。

または私は何かを誤解していますか？例では戻り値を使用していません