VC ++ SSE estranheza optimização intrínseca
https://stackoverflow.com/questions/2005160
-
18-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
estou realizando uma leitura de dispersão de dados de 8 bits a partir de um ficheiro (DE-A intercalação um arquivo de onda de 64 canais). Estou em seguida, combiná-los para ser um único fluxo de bytes. O problema que estou tendo é com a minha re-construção dos dados para escrever.
Basicamente eu estou lendo em 16 bytes e, em seguida, construí-las em uma única variável __m128i e em seguida, usando _mm_stream_ps para escrever o valor de volta para a memória. No entanto eu tenho alguns resultados de desempenho ímpar.
No meu primeiro esquema I usar o intrínseco _mm_set_epi8 para definir minha __m128i da seguinte forma:
const __m128i packedSamples = _mm_set_epi8( sample15, sample14, sample13, sample12, sample11, sample10, sample9, sample8,
sample7, sample6, sample5, sample4, sample3, sample2, sample1, sample0 );
Basicamente eu deixar tudo para o compilador para decidir como otimizá-lo para dar melhor desempenho. Isto dá pior desempenho. MEUS teste é executado em ~ 0,195 segundos.
Em segundo lugar eu tentei mesclar para baixo usando 4 _mm_set_epi32 instruções e, em seguida, embalá-los para baixo:
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 );
Este faz melhorar o desempenho um pouco. Meu teste agora é executado em ~ 0,15 segundos. Parece contra-intuitivo que o desempenho iria melhorar, fazendo isso como eu suponho que este é exatamente o que _mm_set_epi8 está fazendo de qualquer maneira ...
A minha última tentativa foi usar um pouco de código que eu tenho de fazer quatro CCs à moda antiga (com turnos e RUP) e, em seguida, colocá-los em uma __m128i usando um único _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 );
Isto dá desempenho ainda melhor. Tomando ~ 0,135 segundos para executar o meu teste. Estou realmente começando a ficar confuso.
Então, eu tentei um sistema de gravação byte leitura byte simples e que é sempre tão ligeiramente mais rápido do que até mesmo o último método.
Então, o que está acontecendo? Isso tudo parece contra-intuitivo para mim.
Eu considerei a ideia de que os atrasos estão ocorrendo nas _mm_stream_ps porque eu estou fornecendo dados muito rapidamente, mas então eu iria para obter exatamente os mesmos resultados para fora tudo o que faço. É possível que os primeiros 2 métodos significa que as 16 cargas não pode se distribuída através do laço para esconder a latência? Se assim por que é isso? Certamente uma intrínseca permite que o compilador para fazer otimizações como e onde ele agrada .. eu pensei que era o ponto inteiro ... Além disso certamente realizando 16 lê e escreve 16 será muito mais lento do que 16 lê e 1 de gravação com um monte de SSE malabarismo instruções ... Depois de toda a sua a leituras e gravações que estão a pouco lento!
Qualquer pessoa com qualquer o que está acontecendo idéias serão muito apreciados! : D
Editar: sequência do comentário abaixo parei pré-carregar os bytes como constantes e changedit a este:
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 );
e este melhor desempenho para ~ 0,143 segundos. Sitll não tão bom como a implementação C reta ...
Editar Novamente: O melhor desempenho Estou ficando até agora é
// 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 );
Isto dá-me o processamento em ~ 0.095 segundos, o que é consideravelmente melhor. Eu não parecem ser capazes de chegar perto com SSE embora ... Eu ainda estou confuso com isso, mas .. hum ho.
Solução
Talvez o compilador está tentando colocar todos os argumentos para a intrínseca em registros de uma só vez. Você não quer acesso que muitas variáveis ??ao mesmo tempo sem organizá-los.
Ao invés de declarar um identificador separado para cada amostra, tentar colocá-los em um char[16]. O compilador irá promover os valores 16 aos registos como lhe aprouver, contanto que você não tomar o endereço de qualquer coisa dentro do array. Você pode adicionar uma tag __aligned__ (ou qualquer usos VC ++) e talvez evitar a intrínseca completamente. Caso contrário, chamar o intrínseca com ( sample[15], sample[14], sample[13] … sample[0] ) deve tornar o trabalho do compilador mais fácil ou pelo menos não fazer mal.
Editar: eu tenho certeza que você está lutando contra um derramamento de registo, mas essa sugestão provavelmente só irá armazenar os bytes individualmente, o que não é o que você quer. Acho que o meu conselho é para intercalar a sua tentativa final (usando MakeFourCC) com as operações de leitura, para ter certeza que está programado corretamente e sem round-trips para a pilha. É claro, a inspeção de código objeto é a melhor maneira de garantir isso.
Essencialmente, você está streaming de dados no banco de registradores e depois de streaming-lo de volta. Você não quer sobrecarregar-lo antes do tempo para esvaziar os dados.
Outras dicas
VS é notoriamente ruim em otimizar intrínsecos. Especialmente mover dados de e para registradores SSE. Os intrínsecos em si são usados ??muito bem no entanto ....
O que você vê é que ele está tentando preencher o SSE registrar com este monstro:
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
Isso funciona muito melhor e (deve) ser facilmente mais rápido:
__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 );
construir o meu próprio banco de ensaio:
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 );
}
Para me testar 2 é mais rápido, em seguida, testá-1.
Do que eu fiz algo errado? Não é este o código que você está usando? O que eu perdi? É isto apenas para mim?
otimizações Usando intrínsecos breaks compilador!
O ponto central das funções intrínsecas é inserir opcodes o compilador não sabe sobre na corrente de opcodes o compilador sabe sobre e tem gerado. A menos que o compilador é dado alguns meta dados sobre o código de operação e como isso afeta os registros e memória, o compilador não pode assumir que todos os dados é preservada após a execução do intrínseca. Isso realmente dói a parte otimização do compilador -. Não pode instruções reordenar todo o intrínseca, não pode assumir registros não são afetados e assim por diante
Eu acho que a melhor maneira de otimizar isso é olhar para a foto maior - você precisa considerar todo o processo de leitura dos dados de origem para escrever a saída final. otimizações micro raramente dão grandes resultados, a menos que você está fazendo algo realmente mal para começar.
Talvez, se você detalhar a alguém entrada e saída necessária aqui poderia sugerir um método ideal para lidar com isso.
