Странная внутренняя оптимизация VC++ SSE

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

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

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

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

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.

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

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

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

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

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