VC ++ SSE странная оптимизация странности - PullRequest
Новая
       30

VC ++ SSE странная оптимизация странности

2 голосов
/ 05 января 2010

Я выполняю разрозненное чтение 8-битных данных из файла (устранение чередования 64-канального волнового файла). Затем я объединяю их в один поток байтов. У меня проблема с восстановлением данных для записи.

Обычно я читаю 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 );

По сути, я оставляю все это на усмотрение компилятора, чтобы решить, как оптимизировать его, чтобы обеспечить лучшую производительность. Это дает худшую производительность. МОЙ тест длится ~ 0,195 секунды.

Во-вторых, я попытался объединиться, используя 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 в любом случае ...

Моя последняя попытка состояла в том, чтобы использовать немного кода, который я имею, сделать четыре CC по старинке (со сдвигами и ор), а затем поместить их в __m128i, используя один _mm_set_epi32. 

    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 операций записи будет намного медленнее, чем 16 операций чтения и 1 записи с использованием множества SSE-жонглирования. инструкции ... После всего чтения и записи, которые являются медленным битом!

Любой, у кого есть идеи, что происходит, будет высоко оценен! : 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 секунды. Sitll не так хорош, как прямая реализация 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 ... Я все еще смущен этим, но ... хм-ха.

Ответы [ 3 ]

2 голосов
/ 05 января 2010

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.

Я что-то не так делаю? Разве это не код, который вы используете? Что мне не хватает? Это только для меня?

2 голосов
/ 05 января 2010

Возможно, компилятор пытается поместить все аргументы встроенного в регистры сразу. Вы не хотите обращаться к такому количеству переменных одновременно, не организовав их.

Вместо того, чтобы объявлять отдельный идентификатор для каждого образца, попробуйте поместить их в char[16]. Компилятор будет выдавать 16 значений в регистры так, как считает нужным, до тех пор, пока вы не берете адрес чего-либо в массиве. Вы можете добавить тег __aligned__ (или то, что использует VC ++) и, возможно, вообще избежать встроенного. В противном случае вызов встроенной функции с ( sample[15], sample[14], sample[13] … sample[0] ) должен облегчить работу компилятора или, по крайней мере, не причинить вреда.

Редактировать: Я почти уверен, что вы боретесь с разлитым регистром, но это предположение, вероятно, будет просто хранить байты индивидуально, а это не то, что вам нужно. Я думаю, что мой совет состоит в том, чтобы чередовать вашу последнюю попытку (с использованием MakeFourCC) с операциями чтения, чтобы убедиться, что она запланирована правильно и без обращений в стек. Конечно, проверка объектного кода - лучший способ убедиться в этом.

По сути, вы передаете данные в файл реестра, а затем возвращаете их обратно. Вы не хотите перегружать его, пока не пришло время сбросить данные.

0 голосов
/ 05 января 2010

Использование встроенных функций нарушает оптимизацию компилятора!

Весь смысл встроенных функций состоит в том, чтобы вставить коды операций, о которых не знает компилятор, в поток кодов операций, о которых этот компилятор знает и сгенерировал. Если компилятору не предоставлены некоторые метаданные о коде операции и о том, как он влияет на регистры и память, компилятор не может предположить, что какие-либо данные сохраняются после выполнения встроенного кода. Это действительно вредит оптимизирующей части компилятора - он не может переупорядочивать инструкции внутри встроенного, он не может предполагать, что регистры не затронуты и т. Д.

Я думаю, что лучший способ оптимизировать это - взглянуть на более широкую картину - вам нужно рассмотреть весь процесс от чтения исходных данных до написания окончательного результата. Микрооптимизации редко дают большие результаты, если только вы не делаете что-то действительно плохое для начала.

Возможно, если вы детализируете требуемый ввод и вывод, кто-то здесь может предложить оптимальный способ справиться с этим.

...