Que técnicas padrão estão lá para usar específico cpu recursos em DLLs?

Question

A versão curta: eu estou querendo saber se é possível, ea melhor forma, para utilizar específica CPU instruções dentro de uma DLL?

Um pouco mais versão: Ao fazer o download (32bit) DLLs de, digamos, a Microsoft parece que um tamanho único para todos os processadores.

Isso significa que eles são estritamente construído para o menor denominador comum (ie. A plataforma mínima suportada pelo OS)? Ou há alguma técnica que é usada para exportar uma única interface dentro da DLL, mas utilizam código específico CPU nos bastidores para obter o desempenho ideal? E se sim, como isso é feito?

Answer 1

Eu não sei de nenhuma padrão técnica, mas se eu tivesse que fazer tal coisa uma, eu iria escrever algum código na função DllMain () para detectar o tipo de CPU e preencher uma tabela salto com ponteiros de função para versões otimizadas de CPU de cada função.

Há também precisa ser uma função menor denominador comum para quando o tipo de CPU é desconhecida.

Você pode encontrar informações atuais de CPU no registro aqui:

HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor

Answer 2

O DLL é esperado para o trabalho em cada computador Win32 é executado em, então você está preso ao conjunto i386 instrução em geral. Não há nenhum método oficial de expor a funcionalidade / código para conjuntos de instruções específicas. Você tem que fazê-lo manualmente e de forma transparente.

A técnica utilizada, basicamente, é a seguinte: - determinar recursos da CPU como MMX, SSE em tempo de execução - se estiverem presentes, usá-los, se não, ter código fallback pronto

Porque você não pode deixar seu otimizar compilador para qualquer outra coisa do que i386, você terá que escrever o código usando os conjuntos de instruções específicas em inline assembler. Eu não sei se existem kits de ferramentas de linguagem maior para isso. Determinando apresenta a CPU é para a frente, mas poderia também precisa ser feito em assembler.

Answer 3

Uma maneira fácil de obter as otimizações SSE / SSE2 é usar apenas o argumento /arch para MSVC. Eu não me preocuparia com fallback -. Não há nenhuma razão para apoiar qualquer coisa abaixo que a menos que você tem uma aplicação muito nicho

http://msdn.microsoft.com/en-us/library /7t5yh4fd.aspx

Eu acredito gcc / g ++ têm bandeiras equivalentes.

Answer 4

ICC da Intel pode compilar o código duas vezes, de diferentes arquiteturas. Dessa forma, você pode ter seu bolo e comê-lo. (OK, você recebe dois bolos - a DLL será maior). E mesmo MSVC2005 pode fazê-lo para casos muito específicos (por exemplo memcpy () pode usar SSE4)

Existem muitas maneiras de alternar entre diferentes versões. Uma DLL é carregado, porque o processo de carregamento tem funções a partir dele. Nomes de funções são convertidos em endereços. Uma solução é deixar essa pesquisa dependem não apenas o nome da função, mas também recursos do processador. Outro método utiliza o fato de que o nome a função de endereço utiliza uma tabela de ponteiros em um passo intermediário; você pode alternar a tabela inteira. Ou você poderia mesmo ter um ramo dentro de funções críticas; assim foo () chama foo__sse4 quando isso é mais rápido.

Answer 5

DLLs que você baixar da Microsoft são direcionados para a arquitetura x86 genérico pela simples razão de que ele tem para trabalhar em toda a multidão de máquinas lá fora.

Até o Studio 6.0 quadro Visual tempo (não sei se ele mudou) Microsoft usado para otimizar suas DLLs para o tamanho, em vez de velocidade. Isso ocorre porque a redução do tamanho total do DLL deu um aumento de desempenho superior a qualquer outra otimização que o compilador poderia gerar. Isso ocorre porque ups de velocidade de micro otimização seria decididamente baixo em comparação com velocidade ups de não ter a espera da CPU para a memória. Verdadeiras melhorias na velocidade vêm de redução de I / O ou de melhorar o algoritmo de base.

Apenas algumas voltas críticas que rodam no coração do programa poderia beneficiar de micro otimizações simplesmente por causa do grande número de vezes que eles são chamados. Apenas cerca de 5-10% do seu código pode cair nesta categoria. Você pode estar certo de que tais laços críticos já seria otimizado em assembler pelos engenheiros de software da Microsoft para algum nível e não deixar muito para trás, para o compilador de encontrar. (Eu sei que está esperando muito, mas espero que eles fazem isso)

Como você pode ver, não haveria únicos inconvenientes a partir do código DLL que inclui versões de código adicionais que estão sintonizados para diferentes arquiteturas, quando a maior parte deste código é raramente utilizado aumentado / não fazem parte do código crítico que consome a maior parte seus ciclos de CPU.