Quanta aceleração na conversão de matemática 3D para SSE ou outro SIMD?

Question

Estou usando extensivamente matemática 3D em meu aplicativo.Quanta aceleração posso obter convertendo minha biblioteca de vetores/matrizes para SSE, AltiVec ou um código SIMD semelhante?

Answer 1

Na minha experiência, normalmente vejo sobre uma melhoria 3x ao levar um algoritmo de x87 para SSE, e um Melhor da melhoria de 5x para ir para o VMX/Altivec (devido a problemas complicados relacionados à profundidade do pipeline, programação etc.). Mas geralmente faço isso apenas nos casos em que tenho centenas ou milhares de números para operar, não para aqueles em que estou fazendo um vetor por vez ad hoc.

Answer 2

Essa não é a história toda, mas é possível obter mais otimizações usando o SIMD, dê uma olhada na apresentação de Miguel sobre quando ele implementou instruções SIMD com o mono que ele manteve PDC 2008,

_{(fonte: Tirania.org)}

Imagem da entrada do blog de Miguel.

Answer 3

Para alguns números muito aproximados:Eu ouvi algumas pessoas ompf.org reivindique acelerações de 10x para algumas rotinas de rastreamento de raios otimizadas manualmente.Eu também tive algumas boas acelerações.Estimo que consegui algo entre 2x e 6x em minhas rotinas, dependendo do problema, e muitas delas tinham alguns armazenamentos e cargas desnecessárias.Se você tiver uma grande quantidade de ramificações em seu código, esqueça isso, mas para problemas que são naturalmente paralelos aos dados, você pode se sair muito bem.

No entanto, devo acrescentar que seus algoritmos devem ser projetados para execução paralela de dados.Isso significa que se você tiver uma biblioteca matemática genérica como mencionou, ela deverá usar vetores compactados em vez de vetores individuais ou você estará apenas perdendo seu tempo.

Por exemplo.Algo como

namespace SIMD {
class PackedVec4d
{
  __m128 x;
  __m128 y;
  __m128 z;
  __m128 w;

  //...
};
}

A maioria dos problemas onde o desempenho é importante pode ser paralelizado, pois provavelmente você trabalhará com um grande conjunto de dados.Seu problema me parece um caso de otimização prematura.

Answer 4

Para operações 3D, cuidado com dados não iniciados no seu componente W. Eu vi casos em que o SSE Ops (_mm_add_ps) levaria 10x tempo normal por causa de dados ruins em W.

Answer 5

A resposta depende muito do que a biblioteca está fazendo e como é usada.

Os ganhos podem ir de alguns pontos percentuais a "várias vezes mais rápido", as áreas mais suscetíveis de ver ganhos são aquelas onde você não está lidando com vetores ou valores isolados, mas com múltiplos vetores ou valores que precisam ser processados ​​no da mesma maneira.

Outra área é quando você atinge os limites de cache ou memória, o que, novamente, requer o processamento de muitos valores/vetores.

Os domínios onde os ganhos podem ser mais drásticos são provavelmente aqueles de processamento de imagens e sinais, simulações computacionais, bem como operações matemáticas 3D gerais em malhas (em vez de vetores isolados).

Answer 6

Atualmente, todos os bons compiladores para x86 geram instruções SSE para matemática de flutuação SP e DP por padrão. É quase sempre mais rápido usar essas instruções do que as nativas, mesmo para operações escalares, desde que você as agenda corretamente. Isso será uma surpresa para muitos, que no passado acharam o SSE "lento", e os compiladores de pensamento não podiam gerar instruções escalares rápidas da SSE. Mas agora, você precisa usar um comutador para desligar a geração SSE e usar o x87. Observe que o x87 é efetivamente depreciado neste momento e pode ser removido de futuros processadores inteiramente. O único ponto de baixo disso é que podemos perder a capacidade de fazer flutuação de 80 bits em registro. Mas o consenso parece ser se você depende de 80 bits em vez de flutuadores de 64 bits para a precisão, deve procurar um algoritmo de tolerante a perdas com mais precisão.

Tudo acima foi uma surpresa completa para mim. É muito contra -intuitivo. Mas os dados falam.

Answer 7

Provavelmente, você verá apenas uma aceleração muito pequena, se houver, e o processo será mais complicado do que o esperado. Para mais detalhes, consulte A onipresente classe vetorial SSE Artigo de Fabian Giesen.

A onipresente classe vetorial SSE: desmembrando um mito comum

Não é tão importante

Em primeiro lugar, sua classe vetorial provavelmente não é tão importante para o desempenho do seu programa quanto você pensa (e, se for, é mais provável porque você está fazendo algo errado do que porque os cálculos são ineficientes). Não me interpretem mal, provavelmente será uma das classes mais usadas em todo o seu programa, pelo menos ao fazer gráficos 3D. Mas apenas porque as operações vetoriais serão comuns não significa automaticamente que elas dominarão o tempo de execução do seu programa.

Não tão quente

Díficil

Agora não

Nunca