Os compiladores da Intel são realmente melhores que os da Microsoft? [fechadas]

AVISO: Responda com base na própria experiência - YMMV

Se o código for realmente computacionalmente caro, sim, definitivamente . Eu tenho visto uma melhoria de mais de 20x vezes com o antigo Intel C ++ Compiler (agora Intel Studio se bem me lembro) vs o Microsoft Visual C ++ Compiler padrão. É verdade que o código estava muito longe da perfeição e que pode ter desempenhado um papel (na verdade é por isso que nos incomodamos em usar o compilador Intel, foi mais fácil do que refatorar o gigante codebase), também o processador usado para rodar o código era um Intel Core 2 Quad, que é o processador perfeito para isso, mas os resultados foram chocantes. O próprio compilador contém inúmeras maneiras de otimizar o código, incluindo o direcionamento de uma CPU específica em termos de, digamos, recursos de SSE . Isso realmente faz com que -O2 / -O3 fique com vergonha. E isso foi antes usando o profiler.

Note que, no entanto, ativar otimizações realmente agressivas fará com que a compilação leve algum tempo, duas horas para um grande projeto não é impossível. Além disso, com altos níveis de otimizações, há uma chance maior de um erro no código se manifestar (isso também pode ser observado com o gcc -O3 ). Para um projeto que você conhece bem, isso pode ser uma vantagem, já que você encontrará e consertará qualquer bugs que você não tenha detectado antes, mas ao compilar uma bagunça, você apenas cruza os dedos e reza para os deuses x86. / p>

Algo sobre desempenho em máquinas AMD: Não é tão bom quanto os processadores Intel, mas ainda é caminho melhor que o compilador MS C ++ (novamente, da minha experiência). O motivo é que você também pode segmentar uma CPU genérica com suporte para SSE2 (por exemplo). Então, os processadores AMD com SSE2 não serão muito discriminados. O compilador da Intel no CPU Intel realmente rouba o show, no entanto. Não são todos os arco-íris duplos e unicórnios brilhantes, no entanto. Tem havido algumas acusações pesadas sobre binários que não rodam em todos os processadores não GenuineIntel e (este é admitido) um desempenho inferior induzido artificialmente em CPUs de outros fornecedores . Observe também que esta é uma informação de pelo menos 3 anos atrás e sua validade a partir de agora é desconhecida, MAS as novas descrições de produtos dão aos binários uma carta branca para rodar tão lentamente quanto a Intel julgar adequada em CPUs não Intel.

Eu não sei o que é sobre a Intel e por que eles fazem tão boas ferramentas de computação numérica, mas dê uma olhada nisso também: link . Há uma comparação e se você olhar para a última linha, MATLAB brilha ao derrotar tanto o código C como Julia , o que me impressiona é que os autores acham que o motivo é a Intel Biblioteca de Kernel Matemático .

Eu percebo que isso soa muito como um anúncio para o kit de ferramentas Intel Compiler, mas na minha experiência ele realmente fez o trabalho bem, e até a lógica simples dita que os caras que fazem CPUs deveriam saber como programar para eles. IMO, o compilador Intel C ++, extrai o máximo possível de ganho de desempenho.

O Intel Compiler tem a reputação de produzir códigos numéricos muito eficientes:

link

link

link

Por favor, note que eu não reivindico que seja o compilador mais rápido, mas certamente goza de uma reputação de eficiência muito boa. Observe que os autores de binários "oficiais" do LAPACK para Windows usam o compilador Intel Fortran para criá-los: link e eles devem saber uma coisa ou duas sobre eficiência.

Nós tentamos isso no trabalho há algum tempo. A maior parte de nossa base de código está no Delphi, mas temos algumas funcionalidades altamente computacionalmente intensivas que alguém achou que seria uma boa ideia fazer em uma DLL de C ++ desde quando. E um dos meus colegas de trabalho tinha ouvido falar muito sobre o compilador Intel, então ele decidiu experimentá-lo. Nós reconstruímos a DLL no compilador da Intel e fizemos alguns testes de velocidade, e os resultados o surpreenderam tanto que ele achou que deveria estar fazendo algo errado.

A DLL tem que calcular alguns problemas muito difíceis com componentes de topologia e combinatória, que estão tecnicamente na classe de dificuldade NP-hard se os fizermos "right", mas usamos várias heurísticas para evitar o desempenho do NP. Mesmo assim, há muita coisa acontecendo. E para os testes que executamos, a diferença entre o compilador VS e o compilador Intel estava dentro do epsilon, ou o compilador Intel era visivelmente mais lento, geralmente em algum lugar na vizinhança de 20%. E ficou assim, independente das alterações que ele fez nas configurações de compilação para tentar fazer com que o compilador da Intel produzisse um código mais rápido. Então acabamos não mudando para ele.

Este é apenas um exemplo do mundo real, é claro. Sua milhagem pode variar.

Em um aplicativo incorporado no qual trabalhei uma vez, um teste de um compilador da Intel mostrou que isso nos pouparia de ter que girar um novo hardware com maior desempenho. O custo do novo hardware foi de cerca de US $ 10 / unidade, as vendas projetadas de 1 milhão de unidades, Adicionar custo de desenvolvimento e atrasos do projeto. A opção 2 foi um perfil / micro otimização de uma base de código razoavelmente bem perfilada / otimizada - resultados desconhecidos, tempo desconhecido.

O que você acha que o chefe disse quando pedimos os fundos para comprar o compilador .......

No entanto - esse foi um caso de borda muito mais sortudo e raro - a saída de código 10% mais rápida do compilador da Intel nos empurrou de volta para o lado correto do desempenho. Se já estivéssemos do lado direito, ou estivéssemos 10% acima, isso não teria feito diferença. Se tivéssemos os engenheiros, provavelmente poderíamos ter otimizado o código e economizado o giro do hardware, não precisando do compilador da Intel, mas o risco era alto e o compilador da Intel funcionava mais barato do que o tempo de engenharia.

No balanço, eu diria que é uma forma de micro otimização - não faça isso até que você saiba que precisa, e só depois de ter perfilado e encontrado a causa real dos problemas. É uma escolha particularmente boa do seu perfil, mostra que você é lento em todos os lugares e não tem gargalos identificados.

Eu só encontrei três vantagens:

1. Tem suporte para recursos dos processadores Intel mais recentes, muito mais cedo do que outros compiladores.

2. É um ótimo compilador adicional para emitir avisos e detectar problemas que outros compiladores não percebem. O GCC pega algumas coisas que o ICC não faz e vice-versa. O Visual Studio pega algumas coisas que o ICC não faz e vice-versa.

3. Ele faz um trabalho muito melhor de loops de paralelização automática (distribuindo-os em vários segmentos automaticamente) do que qualquer outro compilador. Não há muito o código que se beneficie disso, mas quando você tem código, isso pode fazer uma grande diferença.

Usamos o compilador Intel para cada projeto critial de desempenho de nossa base de código. O melhor de tudo é que isso torna o código de otimização realmente sustentável. Em vez de adicionar manualmente chamadas __mm em todos os lugares e dizer ao compilador para buscar dados antecipadamente, todos os quais serão sub-ótimos na próxima versão novamente, você apenas reorganizará seu código e obterá um aumento de velocidade insano.

Muitas vezes, o código otimizado é mais fácil de seguir do que a mão otimizada, é mais rápido que a mão otimizada e, quando um novo conjunto de instruções é lançado, o compilador usará esse conjunto de instruções. É fantástico.

O mesmo vale para o compilador de braço (de braço, não de intel), se você soltar o braço, faz um ótimo trabalho em vetorização para você.

Verifique esta página de benchmark. Em resumo, a Intel vence.

Mas a margem pode não ser tão grande: se você compilar para 32 bits, e seu sistema de construção não puder suportar otimização orientada por perfil, o ganho será da ordem de 10%. Essa melhoria vale o esforço e os tempos de compilação mais longos?

Dizem que a Intel lançou o Intel C ++ Compiler v13.0 para Android OS, sua primeira tentativa de oferecer um compilador C / C ++ otimizado projetado especificamente para a plataforma móvel do Google.

Os desenvolvedores podem usar o compilador em sistemas baseados no Linux * para criar aplicativos para dispositivos Android baseados em processadores Intel, incluindo o processador Intel® Atom ™. O compilador Intel é compatível com o GNU C ++ e as ferramentas de desenvolvimento do Android Native Development Kit (NDK) Você não pode usar o compilador em qualquer máquina de desenvolvimento. Nem o Windows nem o OS X são suportados; as ferramentas só são certificadas para uso com o Ubuntu 10.04 ou 11.04

A versão atual do Android NDK usa a versão 4.6 do conjunto de ferramentas de Gnu Compiler Collection (GCC) de código aberto por padrão. Mas os compiladores da Intel incluem muitas otimizações proprietárias para seus próprios chips, e muitas vezes podem produzir um código executável com desempenho melhor do que o produzido por compiladores de terceiros, como o GCC.