5

現在、画像データ（8ビット符号付きおよび符号なし）が16として割り当てられた16整列整数の配列に格納されているビデオ処理ソフトウェアを扱っています。

__declspec(align(16)) int *pData = (__declspec(align(16)) int *)_mm_malloc(width*height*sizeof(int),16);

一般に、次のようなsigned / unsigned char配列を使用すると、読み取りと書き込みが高速になりませんか？：

__declspec(align(16)) int *pData = (__declspec(align(16)) unsigned char *)_mm_malloc(width*height*sizeof(unsigned char),16);

キャッシュラインのサイズとデータ転送の最適化についてはほとんど知りませんが、少なくともそれが問題であることはわかっています。それを超えて、SSEは将来使用される予定であり、その場合、char-arrays（int配列とは異なり）はすでにパック形式になっています。では、どちらのバージョンが高速でしょうか？

4

4 に答える 4

5

SSE の使用を計画している場合は、データをネイティブ サイズ (8 ビット) で格納する方がほぼ確実に良い選択です。これは、解凍せずに操作の負荷を実行できるためです。また、pmaddwd などのために解凍する必要がある場合でも同様です。より少ないデータをロードする必要があるため、さらに高速です。

スカラー コードであっても、movzx/movsx の速度は mov と変わらないため、8 ビットまたは 16 ビットの値のロードは 32 ビットのロードよりも遅くはありません。したがって、メモリを節約するだけで、確実に害はありません。

于 2008-09-26T08:31:19.217 に答える
1

それは本当にターゲットCPUに依存します.仕様を読んで、誰もがすでに提案しているように、いくつかのベンチマークを実行する必要があります. 多くの要因がパフォーマンスに影響を与える可能性があります。私の頭に浮かぶ最初の明らかなことは、intの配列がcharの配列よりも2〜4倍大きいため、配列が十分に大きい場合、データキャッシュヒットが少なくなり、間違いなく遅くなるということですパフォーマンスを下げます。

于 2008-09-26T08:53:28.227 に答える
-1

逆に、パッキングとアンパッキングは CPU コマンドの負荷が高くなります。

多くのランダムなピクセル操作を行いたい場合は、各ピクセルが独自のアドレスを持つように int の配列にする方が高速です。

ただし、画像を順番に反復処理する場合は、chars 配列を作成してサイズを小さくし、ページ フォールトが発生する可能性を減らします (特に大きな画像の場合)。

于 2008-09-26T08:28:42.390 に答える
-1

Char 配列は、場合によっては遅くなる可能性があります。非常に一般的な経験則として、ネイティブ ワード サイズが最適であり、4 バイト (32 ビット) または 8 バイト (64 ビット) になる可能性が高くなります。さらに良いのは、既に行ったようにすべてを 16 バイトに揃えることです...これにより、SSE 命令 (MOVNTA) を使用すると、より高速なコピーが可能になります。アイテムの移動のみに関心がある場合、これは配列で使用されるタイプよりもはるかに大きな影響を与えます...

于 2009-02-03T12:15:20.393 に答える