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

Anos atrás, fiquei surpreso ao descobrir que a Intel vende compiladores compatíveis com o Visual Studio. Eu tentei em particular para C / C ++, bem como ferramentas de diagnóstico fantásticas. Mas o código simplesmente não era tão computacionalmente intenso para perceber a diferença. A única impressão foi: a Intel realmente fez isso por mim agora? Uau, ferramentas incríveis com resolução de nanossegundos, inacreditável. Mas o julgamento terminou e a equipe nunca considerou seriamente uma compra.

Pela sua experiência, se o custo da licença não importa, qual fornecedor é o vencedor?

Não é uma pergunta ampla ou vaga, nem uma tentativa de desencadear uma guerra santa. Esse tipo de pergunta é sobre duas ferramentas muito visíveis. Ninguém gosta quando as ferramentas têm mistérios ou surpresas. E as escolhas entre o melhor e o melhor são sempre a dor. Eu também entendo que a grama é sempre um argumento mais verde . Eu quero ouvir todas as histórias "e se".

E se a Intel o otimizar localmente para a etapa de chips do mês, e nem todo destino de hardware funcione tão bem quanto a Microsoft compilado? E se o hardware da AMD for o alvo e tudo desacelerar sem motivo? Ou, por outro lado, e se o hardware da Intel tiver tantas oportunidades imperceptíveis, que os escritores de compiladores da Microsoft são muito lentos para adotar e nunca o implementam no compilador? E se os dois forem exatamente iguais, na verdade, uma única base de código agrupada em duas caixas diferentes e licenciada a ambos os fornecedores por alguma loja de terceiros?

E assim por diante. Mas alguém sabe algumas respostas.

AVISO: Resposta baseada na própria experiência - YMMV

Se o código é realmente caro computacionalmente, sim, definitivamente . Vi uma melhoria de mais de 20 vezes com o antigo Intel C ++ Compiler (agora Intel Studio, se bem me lembro) em relação ao Microsoft Visual C ++ Compiler padrão. É verdade que o código estava longe de ser perfeito e isso pode ter desempenhado um papel (na verdade, foi por isso que nos preocupamos em usar o compilador Intel, era mais fácil do que refatorar a gigante base de código), também a CPU usada para executar o código era um Intel Core 2 Quad, que é o CPU 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, por exemplo, recursos SSE . Realmente deixa -O2/ -O3envergonha-se. E isso foiantes de usar o criador de perfil.

Observe que, no entanto, ativar otimizações realmente agressivas fará com que a compilação leve algum tempo, duas horas para um projeto grande não são impossíveis. 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 no gcc -O3). Para um projeto que você conhece bem, isso pode ser uma vantagem, já que você encontrará e corrigirá eventuais erros que não detectou anteriormente, mas ao compilar uma bagunça peluda, basta cruzar os dedos e orar aos deuses x86.

Algo sobre desempenho em máquinas AMD: não é tão bom quanto os processadores Intel, mas ainda é muito melhor do que o compilador MS C ++ (novamente, pela minha experiência). O motivo é que você também pode direcionar uma CPU genérica com suporte a SSE2 (por exemplo). Os processadores AMD com SSE2 não serão muito discriminados. O compilador Intel na CPU Intel realmente rouba a cena. No entanto, nem tudo são arco-íris duplos e unicórnios brilhantes. Houve algumas acusações pesadas sobre binários que não estão sendo executados em CPUs não-GenuineIntel e (este é admitido) induziu artificialmente um desempenho inferior nas CPUs por outros fornecedores. Observe também que são informações de pelo menos três anos atrás e sua validade a partir de agora é desconhecida, mas as novas descrições de produtos oferecem aos binários uma carta branca para que funcionem tão lentamente quanto a Intel considerar adequado em CPUs que não sejam da Intel.

Não sei o que é a Intel e por que elas são tão boas ferramentas de computação numérica, mas veja também: http://julialang.org/ . Há uma comparação e, se você olhar para a última linha, o MATLAB brilha ao derrotar o código C e a Julia , o que me impressiona é que os autores pensam que o motivo é a Biblioteca de Kernel de Matemática da Intel .

Percebo que isso soa muito como um anúncio para o kit de ferramentas do Intel Compiler, mas, na minha experiência, ele realmente fez o trabalho bem, e até a lógica simples determina que os caras que fazem CPUs devem saber melhor como programar para eles. Na IMO, o compilador Intel C ++ reduz todos os ganhos de desempenho possíveis.

O Intel Compiler tem a reputação de produzir código numérico muito eficiente:

https://stackoverflow.com/questions/1733627/anyone-here-has-benchmarked-intel-c-compiler-and-gcc

http://www.open-mag.com/754088105111.htm

http://www.freewebs.com/godaves/javabench_revisited/

Observe que não afirmo que seja o compilador mais rápido do mercado, mas certamente goza de uma reputação muito boa de eficiência. Observe que os autores dos binários "oficiais" do LAPACK para Windows usam o compilador Intel Fortran para construí-los: http://icl.cs.utk.edu/lapack-for-windows/ e devem saber um ou dois aspectos sobre eficiência.

O Intel C ++ possui algumas vantagens sobre o gcc, além do gerador de código. Ambas derivam (em grande parte) do fato de serem baseadas no front-end do EDG . Para melhor ou pior, ambos estão (lentamente) corroendo, portanto as vantagens não são tão grandes quanto eram antes.

A primeira é que, em regra, emite mensagens de erro muito melhores. Você pode querer comparar as mensagens de erro entre Clang e gcc. O Intel C ++ (junto com a maioria dos outros baseados no front-end do EDG) emite diagnósticos semelhantes aos do Clang há anos.

Segundo, é que o front end EDG é tão conhecido por sua excepcional conformidade com a linguagem quanto o gerador de código Intel é para produzir código rápido. Por quase qualquer medida razoável, o front-end do EDG fornece melhor conformidade com C ++ 98, 03 ou (nas versões atuais) C ++ 0x do que qualquer outro compilador disponível.

Como eu disse, essas duas vantagens foram corroídas em vários graus ao longo do tempo. As versões recentes do gcc têm uma conformidade de idioma bastante decente. O Clang possui mensagens de erro substancialmente melhores e está fazendo um bom progresso na implementação de toda a linguagem C ++. No entanto, quando você se dedica a isso, o Intel C ++ ainda é melhor do que qualquer um dos dois aspectos, e é um pacote único que faz a maioria das coisas corretamente, em vez de precisar de um compilador para bons diagnósticos e outro para melhor conformidade e geração de código.

Tentamos isso no trabalho há um tempo. A maior parte de nossa base de código está em Delphi, mas temos algumas funcionalidades altamente intensivas em computação que alguém pensou que seria uma boa idéia fazer em uma DLL C ++ no passado. E um dos meus colegas de trabalho ouviu grandes coisas sobre o compilador da Intel, então ele decidiu testá-lo. Nós reconstruímos a DLL no compilador Intel e executamos alguns testes de velocidade, e os resultados o surpreenderam tanto que ele imaginou que devia estar fazendo algo errado.

A DLL precisa calcular alguns problemas muito difíceis com componentes combinatórios e de topologia, que estão tecnicamente na classe de dificuldade NP-hard se os fizermos "certo", mas usamos várias heurísticas para evitar o desempenho do NP. Mesmo assim, há muitas trocas de números acontecendo. E para os testes que realizamos, 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 faixa de 20%. E ficou assim, independentemente das alterações que ele fez nas configurações de compilação para tentar fazer com que o compilador Intel produzisse códigos mais rápidos. Então acabamos não mudando para ele.

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

Em um aplicativo incorporado em que trabalhei, uma avaliação de um compilador Intel mostrou que isso nos pouparia a necessidade de rodar novo hardware com maior desempenho. O custo do novo hardware foi de cerca de US $ 10 / unidade, vendas projetadas de 1 milhão de unidades, adicionar custos de desenvolvimento e atrasos no projeto. A opção 2 era um perfil / micro otimização, uma base de código já 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 muito sortudo e raro - a saída de código 10% mais rápida do compilador Intel nos levou de volta ao lado correto do desempenho. Se já estivéssemos do lado certo, ou estivéssemos 10% acima, isso não faria diferença. Se tivéssemos os engenheiros, provavelmente poderíamos otimizar o código e salvar a rotação do hardware e não precisaríamos do compilador Intel, mas o risco era alto e o compilador Intel funcionava mais barato que o tempo de engenharia.

Em resumo, eu diria que é uma forma de micro otimização - não faça isso até que você saiba que precisa e só depois de criar um perfil e encontrar a causa real dos problemas. É uma escolha particularmente boa do seu perfil que mostra que você está lento em todos os lugares e não tem gargalo de garrafa identificado.

Eu só encontrei três vantagens:

1. Ele suporta recursos de CPUs Intel mais recentes muito antes do que outros compiladores.

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

3. Ele realiza um trabalho muito melhor de loops de paralelismo automático (distribuindo-os automaticamente por vários threads) do que qualquer outro compilador. O código não se beneficia muito disso, mas quando você tem um código que faz isso, pode fazer muita diferença.

Usamos o compilador Intel para todos os projetos críticos de desempenho da 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 pedir ao compilador para buscar previamente dados, os quais serão subotimizados no próximo lançamento novamente, basta reorganizar seu código e obter uma aceleração insana.

Freqüentemente, o código otimizado é mais fácil de seguir do que o otimizado manualmente, é mais rápido que o otimizado manualmente e, quando um novo conjunto de instruções é liberado, o compilador usa esse conjunto de instruções. É fantástico.

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

Verifique esta página de referência. Em suma, a Intel vence.

Mas a margem pode não ser tão grande: se você compilar em 32 bits, e seu sistema de compilação não puder suportar otimização guiada por perfil, o ganho é da ordem de 10%. Essa melhoria vale a pena 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 fornecer 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 desenvolvedor no Android Native Development Kit (NDK). Você também 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ão certificadas apenas para uso com o Ubuntu 10.04 ou 11.04

A versão atual do Android NDK usa a versão 4.6 da cadeia de ferramentas Gnu Compiler Collection (GCC) de código aberto por padrão. Porém, os compiladores da Intel incluem muitas otimizações proprietárias de seus próprios chips e geralmente podem gerar códigos executáveis ​​com desempenho melhor que o produzido por compiladores de terceiros, como o GCC.