Quanto devo preocupar com o compilador Intel C ++ emissor de código abaixo do ideal para a AMD?

StackOverflow https://stackoverflow.com/questions/839667

Pergunta

Sempre fomos uma loja Intel. Todos os desenvolvedores usam máquinas Intel, a plataforma recomendada para usuários finais é Intel, e se os usuários finais deseja executar em AMD é a sua vigia. Talvez o departamento de teste tinha um lugar máquina AMD para verificar que não enviar qualquer coisa completamente quebrado, mas que era sobre isso.

Até alguns anos atrás, a apenas utilizado o compilador MSVC e uma vez que realmente não oferecem um monte de opções de ajuste do processador além do nível SSE, ninguém preocupado muito sobre se o código pode favorecer um x86 fornecedor em detrimento de outro. No entanto, mais recentemente, temos sido utilizando o Intel compilador muito. Nosso material definitivamente recebe alguns benefícios de desempenho significativos a partir dele (em nosso hardware Intel), e as suas capacidades de vectorização significa menos necessidade de ir para asm / intrínsecos. No entanto as pessoas estão começando a ficar um pouco nervoso sobre se o compilador Intel pode realmente não estar fazendo tal bom trabalho para hardware AMD. Certamente, se você entrar no Intel CRT ou IPP bibliotecas você ver um monte de consultas CPUID para aparentemente criadas tabelas de salto para funções otimizadas. Parece improvável Intel ir até demais para fazer qualquer coisa boa para AMD fichas embora.

Qualquer pessoa pode com alguma experiência neste comentário área sobre se é um grande negócio ou não na prática? (Temos ainda para realmente fazer qualquer teste de desempenho em AMD nós mesmos).

Atualização 2010-01-04 : Bem, a necessidade de apoiar AMD nunca se tornou bastante concreto para mim fazer qualquer me testando. Há algumas interessantes leituras sobre o tema aqui , aqui aqui embora.

Atualização 2010-08-09 : Parece que o acordo Intel-FTC tem algo a dizer sobre esta questão - veja "Compiladores e sujo Tricks" seção do este artigo .

Foi útil?

Solução

Comprar uma caixa de AMD e executá-lo sobre isso. Que parece ser a única coisa responsável a fazer, ao invés de confiar em estranhos na internet;)

Além disso, acredito que parte da ação da AMD contra a Intel é baseada na alegação de que o compilador de Intel especificamente produz código que é executado de forma ineficiente em processadores AMD. Eu não sei se isso é verdade ou não, mas a AMD parece acreditar assim.

Mas, mesmo que não intencionalmente fazer isso, não há dúvida de que compilador da Intel otimiza especificamente para processadores Intel e nada mais.

Ao que se diz, duvido que iria fazer uma enorme diferença. AMD CPU de ainda beneficiar de toda a auto-vetorização e outros recursos inteligentes do compilador.

Outras dicas

O que temos visto é que onde quer que o compilador Intel deve fazer uma escolha runtime sobre o conjunto de instruções disponíveis, se não reconhecer um Intel CPU, ele vai em seu código "padrão" (que, como você poderia esperar, pode não ser o ideal).

Note que, mesmo que eu usei a palavra "compilador" acima, isso acontece principalmente em suas bibliotecas fornecidos (pré-compilados) e intrínsecos que verificam o conjunto de instruções e chamar o melhor código.

Eu estou seguramente afirmar o óbvio, se o desempenho é crucial para a sua aplicação, então você faria melhor alguns testes - em todas as combinações de hardware / compilador. Não há garantias. Como estranhos, só podemos dar-lhe nossas suposições / preconceitos. Seu software pode ter características únicas que são ao contrário do que temos visto.

A minha experiência:

Eu costumava trabalhar na Intel, e desenvolveu um (++ C) aplicação in-house onde o desempenho foi fundamental. Tentamos usar compilador Intel C ++, e sempre sob gcc realizado - mesmo depois de fazer corridas em seu perfil, recompilar usando as informações de perfil (que ICC usa supostamente para otimizar) e re-execução em exatamente o mesmo conjunto de dados (isso foi em 2005-2007, as coisas podem ser diferentes agora). Assim, com base na minha experiência, você pode querer tentar gcc (além de ICC e MSVC), é possível que você irá obter um melhor desempenho dessa forma e side-passo a pergunta. Não deve ser muito difícil de compiladores de comutação (se o seu processo de construção é razoável).

Agora eu trabalho em uma empresa diferente, e as pessoas de TI fazer testes de hardware extensa, e por um tempo Intel e hardware AMD foi relativamente comparáveis, mas a última geração de hardware Intel significativamente out-realizada a AMD. Como resultado, eu acredito que eles compraram quantidades significativas de CPUs Intel e recomendar o mesmo para nossos clientes que dirigem o nosso software.

Mas, de volta para a questão de saber se o compilador Intel visa especificamente hardware AMD para executar lentamente. Duvido incomoda Intel com isso. Pode ser que algumas otimizações que o uso de conhecimento sobre o funcionamento interno da arquitetura CPU Intel ou chipsets poderia ficar mais lento em hardware AMD, mas duvido que visam especificamente hardware AMD.

Desculpe se você bater meu botão geral.

Este é sobre o assunto de otimização de baixo nível, por isso só importa para o código que 1) o contador de programa gasta muito tempo em, e 2) o compilador realmente vê. Por exemplo, se o PC passa a maior parte de seu tempo em rotinas da biblioteca que você não compilar, ele não deve importar muito.

Quer ou não condições 1 e 2 estão satisfeitas, aqui é a minha experiência de como otimização vai:

várias iterações de amostragem e de fixação são feitas. Em cada um deles, um problema é identificado e na maioria das vezes não é sobre onde o contador de programa é. Pelo contrário, é que há chamadas de função em meados dos níveis da pilha de chamadas que, uma vez que o desempenho é fundamental, poderia ser substituído. Para encontrá-los rapidamente, eu faço isso .

Tenha em mente que, se houver uma instrução de chamada de função que está na pilha para uma fração significativa de tempo de execução, seja em algumas invocações longas, ou um grande número de curtas, essa chamada é responsável por essa fração de tempo , então removê-lo ou executá-lo com menos frequência pode economizar muito tempo. E, que a poupança excede qualquer otimização de baixo nível.

O programa pode agora ser muitas vezes mais rápido do que era para começar. Eu nunca vi qualquer programa de bom tamanho, não importa quão cuidadosamente escrito, que não poderão se beneficiar deste processo. Se o processo não tenha sido feito, não se deve presumir que a otimização de baixo nível é a única maneira de acelerar o programa.

Após este processo tem sido feito para o ponto onde ele simplesmente não pode ser feito mais, e se as amostras mostram que o PC está em código que o compilador vê, em seguida, a otimização de baixo nível pode fazer a diferença.

No momento esta discussão foi iniciada, Microsoft C ++ padrão para a geração de código que era bom em alguns casos para AMD e ruim para Intel. Seus compiladores mais recentes como padrão a opção de mistura que é bom para ambos, especialmente depois de ambas as marcas de CPUs tinha trabalhado seus erros de performance peculiar. Quando eu trabalhei pela primeira vez no Intel, seus compiladores reservados algumas otimizações para as configurações de arquitetura específica em Intel. Eu acho que poderia ter sido um tópico de alguns depoimentos FTC, apesar de não chegar em minhas 10 horas de testemunho, e a prática já estava a caminho fora devido a convergência dos requisitos de otimização entre até modelos data de CPU e do necessidade de uso mais produtivo do tempo de desenvolvimento do compilador. Se você usou um desses compiladores obsoletos em um atualizado Intel CPU, você pode ver algumas das deficiências mesmo desempenho.

É inútil se preocupar se você não pode agir. As ações possíveis são: Não comprar AMD, ou usando um compilador diferente. Então as coisas óbvias para fazer são:

(1) Comprar uma caixa AMD, e medir a velocidade do código compilado com o compilador Intel. É rápido o suficiente? Se sim, você está feito, você pode comprar AMD, não se preocupe.

(2) Se não: compilar o código com um compilador diferente e executá-lo na caixa de AMD. É rápido o suficiente? Se não, você está feito, você não pode comprar AMD, não se preocupe.

(3) Em caso afirmativo: Executar o mesmo código em uma caixa de Intel. É rápido o suficiente? Se sim, você está feito, você pode comprar AMD, mas tem que compiladores de switch, não se preocupe.

(4) Se não: As possibilidades são: não comprar AMD, jogar todos os computadores da Intel para fora, ou compilar com dois compiladores diferentes. Escolher um.

Eu experimentei diretamente incapacitante intencional de tecnologia quando um vendedor tentou impedir um produto Lotus de alcançar mercado antes de sua oferta. A tecnologia trabalho estava disponível, mas Lotus foi proibido de usá-lo. Ah, bem ...

Há alguns anos atrás, havia blogs que mostraram usuários que remendar um único byte no compilador Intel causou a emitir código "ideal" que não era aleijado quando usado em AMD. Eu não olhei para as entradas de blog em anos.

Estou inclinado a acreditar que tal comportamento competitivo continua. Eu não tenho nenhuma outra evidência para oferecer.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top