2

ファイルから 8 ビット データの分散読み取りを実行しています (64 チャンネルの Wave ファイルのインターリーブ解除)。次に、それらを結合して単一のバイト ストリームにします。私が抱えている問題は、書き出すデータの再構築にあります。

基本的に、私は 16 バイトを読み取り、それらを単一の __m128i 変数に構築し、_mm_stream_ps を使用して値をメモリに書き戻しています。ただし、いくつかの奇妙なパフォーマンス結果があります。

最初のスキームでは、_mm_set_epi8 組み込み関数を使用して __m128i を次のように設定します。

    const __m128i packedSamples = _mm_set_epi8( sample15,   sample14,   sample13,   sample12,   sample11,   sample10,   sample9,    sample8,
                                                sample7,    sample6,    sample5,    sample4,    sample3,    sample2,    sample1,    sample0 );

基本的に、最高のパフォーマンスを得るためにどのように最適化するかはコンパイラに任せています。これにより、最悪のパフォーマンスが得られます。MY テストは ~0.195 秒で実行されます。

2 番目に、4 つの _mm_set_epi32 命令を使用してマージし、それらを圧縮しようとしました。

    const __m128i samples0      = _mm_set_epi32( sample3, sample2, sample1, sample0 );
    const __m128i samples1      = _mm_set_epi32( sample7, sample6, sample5, sample4 );
    const __m128i samples2      = _mm_set_epi32( sample11, sample10, sample9, sample8 );
    const __m128i samples3      = _mm_set_epi32( sample15, sample14, sample13, sample12 );

    const __m128i packedSamples0    = _mm_packs_epi32( samples0, samples1 );
    const __m128i packedSamples1    = _mm_packs_epi32( samples2, samples3 );
    const __m128i packedSamples     = _mm_packus_epi16( packedSamples0, packedSamples1 );

これにより、パフォーマンスが多少向上します。私のテストは現在、約 0.15 秒で実行されます。とにかくこれがまさに _mm_set_epi8 が行っていることだと思いますので、これを行うことでパフォーマンスが向上するという直感に反するようです...

私の最後の試みは、4 つの CC を昔ながらの方法で (シフトと or を使用して) 作成し、単一の _mm_set_epi32 を使用してそれらを __m128i に配置したコードを使用することでした。

    const GCui32 samples0       = MakeFourCC( sample0, sample1, sample2, sample3 );
    const GCui32 samples1       = MakeFourCC( sample4, sample5, sample6, sample7 );
    const GCui32 samples2       = MakeFourCC( sample8, sample9, sample10, sample11 );
    const GCui32 samples3       = MakeFourCC( sample12, sample13, sample14, sample15 );
    const __m128i packedSamples = _mm_set_epi32( samples3, samples2, samples1, samples0 );

これにより、さらに優れたパフォーマンスが得られます。テストの実行に約 0.135 秒かかります。私は本当に混乱し始めています。

そこで、単純な読み取りバイト書き込みバイト システムを試してみましたが、最後の方法よりもわずかに高速です。

それで、何が起こっているのですか？これはすべて直感に反するように思えます。

データの供給が速すぎるため、_mm_stream_ps で遅延が発生しているという考えを検討しましたが、何をしてもまったく同じ結果が得られます。最初の 2 つの方法は、16 の負荷がループを介して分散されず、レイテンシが隠蔽されていないことを意味している可能性はありますか? もしそうなら、これはなぜですか？確かに、組み込み関数により、コンパイラーは好きな場所で最適化を行うことができます..それが全体のポイントだと思いました...また、16回の読み取りと16回の書き込みを実行すると、SSEジャグリングの束で16回の読み取りと1回の書き込みよりもはるかに遅くなります。命令...結局のところ、読み取りと書き込みが遅いビットです!

何が起こっているのかアイデアを持っている人なら誰でも大歓迎です！:D

編集：以下のコメントに加えて、バイトを定数としてプリロードするのをやめ、これに変更しました：

    const __m128i samples0      = _mm_set_epi32( *(pSamples + channelStep3), *(pSamples + channelStep2), *(pSamples + channelStep1), *(pSamples + channelStep0) );
    pSamples    += channelStep4;
    const __m128i samples1      = _mm_set_epi32( *(pSamples + channelStep3), *(pSamples + channelStep2), *(pSamples + channelStep1), *(pSamples + channelStep0) );
    pSamples    += channelStep4;
    const __m128i samples2      = _mm_set_epi32( *(pSamples + channelStep3), *(pSamples + channelStep2), *(pSamples + channelStep1), *(pSamples + channelStep0) );
    pSamples    += channelStep4;
    const __m128i samples3      = _mm_set_epi32( *(pSamples + channelStep3), *(pSamples + channelStep2), *(pSamples + channelStep1), *(pSamples + channelStep0) );
    pSamples    += channelStep4;

    const __m128i packedSamples0    = _mm_packs_epi32( samples0, samples1 );
    const __m128i packedSamples1    = _mm_packs_epi32( samples2, samples3 );
    const __m128i packedSamples     = _mm_packus_epi16( packedSamples0, packedSamples1 );

これにより、パフォーマンスが最大 0.143 秒に向上しました。そのままの C 実装ほど良くはありません ...

もう一度編集：これまでに得た最高のパフォーマンスは

    // Load the samples.
    const GCui8 sample0     = *(pSamples + channelStep0);
    const GCui8 sample1     = *(pSamples + channelStep1);
    const GCui8 sample2     = *(pSamples + channelStep2);
    const GCui8 sample3     = *(pSamples + channelStep3);

    const GCui32 samples0   = Build32( sample0, sample1, sample2, sample3 );
    pSamples += channelStep4;

    const GCui8 sample4     = *(pSamples + channelStep0);
    const GCui8 sample5     = *(pSamples + channelStep1);
    const GCui8 sample6     = *(pSamples + channelStep2);
    const GCui8 sample7     = *(pSamples + channelStep3);

    const GCui32 samples1   = Build32( sample4, sample5, sample6, sample7 );
    pSamples += channelStep4;

    // Load the samples.
    const GCui8 sample8     = *(pSamples + channelStep0);
    const GCui8 sample9     = *(pSamples + channelStep1);
    const GCui8 sample10    = *(pSamples + channelStep2);
    const GCui8 sample11    = *(pSamples + channelStep3);

    const GCui32 samples2       = Build32( sample8, sample9, sample10, sample11 );
    pSamples += channelStep4;

    const GCui8 sample12    = *(pSamples + channelStep0);
    const GCui8 sample13    = *(pSamples + channelStep1);
    const GCui8 sample14    = *(pSamples + channelStep2);
    const GCui8 sample15    = *(pSamples + channelStep3);

    const GCui32 samples3   = Build32( sample12, sample13, sample14, sample15 );
    pSamples += channelStep4;

    const __m128i packedSamples = _mm_set_epi32( samples3, samples2, samples1, samples0 );

    _mm_stream_ps( pWrite + 0,  *(__m128*)&packedSamples );

これにより、約 0.095 秒で処理できます。これはかなり優れています。私はSSEに近づくことができないようですが...私はまだそれに混乱していますが..うーん。

4

3 に答える 3

2

おそらく、コンパイラは、組み込み関数へのすべての引数を一度にレジスタに入れようとしています。整理せずに一度に多くの変数にアクセスしたくはありません。

サンプルごとに個別の識別子を宣言するのではなく、それらをに入れてみてくださいchar[16]。コンパイラは、配列内のアドレスを取得しない限り、16個の値を適切と思われるレジスタにプロモートします。タグ（またはVC ++が使用するもの）を追加して__aligned__、本質的なものを完全に回避することができます。それ以外の場合は、組み込み関数をwithで呼び出すと( sample[15], sample[14], sample[13] … sample[0] )、コンパイラーの作業が簡単になるか、少なくとも害はありません。

編集：あなたはレジスターの流出と戦っていると確信していますが、その提案はおそらくバイトを個別に格納するだけであり、それはあなたが望むものではありません。私のアドバイスは、最後の試行（MakeFourCCを使用）を読み取り操作とインターリーブして、正しくスケジュールされ、スタックへのラウンドトリップがないことを確認することだと思います。もちろん、オブジェクトコードの検査はそれを確実にするための最良の方法です。

基本的に、データをレジスタファイルにストリーミングしてから、ストリーミングして戻します。データをフラッシュする前にオーバーロードしたくないでしょう。

于 2010-01-05T10:19:24.953 に答える
2

VS は組み込み関数の最適化が苦手です。特に、SSE レジスターとの間でデータを移動する場合。しかし、組み込み関数自体はかなりよく使われています ... .

あなたが見ているのは、このモンスターでSSEレジスタを埋めようとしているということです:

00AA100C  movzx       ecx,byte ptr [esp+0Fh]  
00AA1011  movzx       edx,byte ptr [esp+0Fh]  
00AA1016  movzx       eax,byte ptr [esp+0Fh]  
00AA101B  movd        xmm0,eax  
00AA101F  movzx       eax,byte ptr [esp+0Fh]  
00AA1024  movd        xmm2,edx  
00AA1028  movzx       edx,byte ptr [esp+0Fh]  
00AA102D  movd        xmm1,ecx  
00AA1031  movzx       ecx,byte ptr [esp+0Fh]  
00AA1036  movd        xmm4,ecx  
00AA103A  movzx       ecx,byte ptr [esp+0Fh]  
00AA103F  movd        xmm5,edx  
00AA1043  movzx       edx,byte ptr [esp+0Fh]  
00AA1048  movd        xmm3,eax  
00AA104C  movzx       eax,byte ptr [esp+0Fh]  
00AA1051  movdqa      xmmword ptr [esp+60h],xmm0  
00AA1057  movd        xmm0,edx  
00AA105B  movzx       edx,byte ptr [esp+0Fh]  
00AA1060  movd        xmm6,eax  
00AA1064  movzx       eax,byte ptr [esp+0Fh]  
00AA1069  movd        xmm7,ecx  
00AA106D  movzx       ecx,byte ptr [esp+0Fh]  
00AA1072  movdqa      xmmword ptr [esp+20h],xmm4  
00AA1078  movdqa      xmmword ptr [esp+80h],xmm0  
00AA1081  movd        xmm4,ecx  
00AA1085  movzx       ecx,byte ptr [esp+0Fh]  
00AA108A  movdqa      xmmword ptr [esp+70h],xmm2  
00AA1090  movd        xmm0,eax  
00AA1094  movzx       eax,byte ptr [esp+0Fh]  
00AA1099  movdqa      xmmword ptr [esp+10h],xmm4  
00AA109F  movdqa      xmmword ptr [esp+50h],xmm6  
00AA10A5  movd        xmm2,edx  
00AA10A9  movzx       edx,byte ptr [esp+0Fh]  
00AA10AE  movd        xmm4,eax  
00AA10B2  movzx       eax,byte ptr [esp+0Fh]  
00AA10B7  movd        xmm6,edx  
00AA10BB  punpcklbw   xmm0,xmm1  
00AA10BF  punpcklbw   xmm2,xmm3  
00AA10C3  movdqa      xmm3,xmmword ptr [esp+80h]  
00AA10CC  movdqa      xmmword ptr [esp+40h],xmm4  
00AA10D2  movd        xmm4,ecx  
00AA10D6  movdqa      xmmword ptr [esp+30h],xmm6  
00AA10DC  movdqa      xmm1,xmmword ptr [esp+30h]  
00AA10E2  movd        xmm6,eax  
00AA10E6  punpcklbw   xmm4,xmm5  
00AA10EA  punpcklbw   xmm4,xmm0  
00AA10EE  movdqa      xmm0,xmmword ptr [esp+50h]  
00AA10F4  punpcklbw   xmm1,xmm0  
00AA10F8  movdqa      xmm0,xmmword ptr [esp+70h]  
00AA10FE  punpcklbw   xmm6,xmm7  
00AA1102  punpcklbw   xmm6,xmm2  
00AA1106  movdqa      xmm2,xmmword ptr [esp+10h]  
00AA110C  punpcklbw   xmm2,xmm0  
00AA1110  movdqa      xmm0,xmmword ptr [esp+20h]  
00AA1116  punpcklbw   xmm1,xmm2  
00AA111A  movdqa      xmm2,xmmword ptr [esp+40h]  
00AA1120  punpcklbw   xmm2,xmm0  
00AA1124  movdqa      xmm0,xmmword ptr [esp+60h]  
00AA112A  punpcklbw   xmm3,xmm0  
00AA112E  punpcklbw   xmm2,xmm3  
00AA1132  punpcklbw   xmm6,xmm4  
00AA1136  punpcklbw   xmm1,xmm2  
00AA113A  punpcklbw   xmm6,xmm1

これははるかにうまく機能し、（はず）簡単に高速になります：

__declspec(align(16)) BYTE arr[16] = { sample15, sample14, sample13, sample12, sample11, sample10, sample9, sample8, sample7, sample6, sample5, sample4, sample3, sample2, sample1, sample0 };

__m128i packedSamples = _mm_load_si128( (__m128i*)arr );

自分のテストベッドを構築します:

void    f()
{
    const int steps = 1000000;
    BYTE* pDest = new BYTE[steps*16+16];
    pDest += 16 - ((ULONG_PTR)pDest % 16);
    BYTE* pSrc = new BYTE[steps*16*16];

    const int channelStep0 = 0;
    const int channelStep1 = 1;
    const int channelStep2 = 2;
    const int channelStep3 = 3;
    const int channelStep4 = 16;

    __int64 freq;
    QueryPerformanceFrequency( (LARGE_INTEGER*)&freq );
    __int64 start = 0, end;
    QueryPerformanceCounter( (LARGE_INTEGER*)&start );

    for( int step = 0; step < steps; ++step )
    {
        __declspec(align(16)) BYTE arr[16];
        for( int j = 0; j < 4; ++j )
        {
            //for( int i = 0; i < 4; ++i )
            {
                arr[0+j*4] = *(pSrc + channelStep0);
                arr[1+j*4] = *(pSrc + channelStep1);
                arr[2+j*4] = *(pSrc + channelStep2);
                arr[3+j*4] = *(pSrc + channelStep3);
            }
            pSrc += channelStep4;
        }

#if test1
// test 1 with C
        for( int i = 0; i < 16; ++i )
        {
            *(pDest + step * 16 + i) = arr[i];
        }
#else
// test 2 with SSE load/store    
        __m128i packedSamples = _mm_load_si128( (__m128i*)arr );
        _mm_stream_si128( ((__m128i*)pDest) + step, packedSamples );
#endif
    }

    QueryPerformanceCounter( (LARGE_INTEGER*)&end );

    printf( "%I64d", (end - start) * 1000 / freq );

}

私にとって、テスト 2 はテスト 1 よりも高速です。

私は何か間違ったことをしていますか？これはあなたが使用しているコードではありませんか？何が恋しいですか？これは私のためだけですか？

于 2010-01-05T12:46:36.707 に答える
-3

組み込み関数を使用すると、コンパイラの最適化が中断されます!

組み込み関数の要点は、コンパイラが認識していないオペコードを、コンパイラが認識して生成したオペコードのストリームに挿入することです。オペコードと、オペコードがレジスタとメモリにどのように影響するかについてのメタデータがコンパイラに与えられない限り、コンパイラは、組み込みの実行後にデータが保持されていると想定できません。これは、コンパイラの最適化部分を本当に傷つけます-組み込みの周りで命令を並べ替えることができず、レジスタが影響を受けていないと仮定することができません.

これを最適化する最善の方法は、全体像を見ることだと思います。ソース データの読み取りから最終出力の書き込みまでのプロセス全体を考慮する必要があります。最初から非常に悪いことをしていない限り、マイクロ最適化が大きな結果をもたらすことはめったにありません。

おそらく、必要な入力と出力を詳しく説明すれば、ここにいる誰かがそれを処理する最適な方法を提案できるでしょう。

于 2010-01-05T11:30:56.577 に答える