| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | compara o Intel C++ 8.1 com o GCC 3.3.x, 3.4.x e o futuro GCC 4.0
Ainda não li o artigo dos benchmarks, mas não estão a comparar compiladores de C++ e C?
Toda a gente sabe que o código em C é ligeiramente mais rápido durante a execução e durante a compilação...
|
| |
| |
| | | GCC == GNU Compiler Collection. O GCC deixou de ser apenas um compilador de C há algum tempo.
--
Luís Bruno |
| |
| | Na verdade, o GCC inclui o compilador de C++, g++.
Paradoxo do ano: Microsoft Works!
Dominus vobiscum |
| |
| | Eu sei, mas não é muito evidente qual deles foi o usado. Para além do mais, o código usado nem sequer é fornecido.
Este benchmarking não me parece de fiar.
|
| |
| | O código dos benchmarks é C, com mais ou menos extensões do GCC.
|
| |
| | O Intel C++ é um compilador de C++, certo?
Não me parece ser muito justo compararem a performance de código de C entre um compilador de C++ e outro de C.
|
| |
| | É um compilador de C e C++.
|
| |
| | Se for o mesmo código, não é por ai que o gato vai às filhoses. Além disso, quem disse que eles estão a usar um compilador de C?
____________________
Pedro Santos :: psantos.net |
| |
| | Nao e tao notorio como no caso Fortran X C, mas existem optimizacoes que se podem fazer em C que nao se podem fazer em C++ (e vice-versa). Isto e devido a propria linguagem.
## I should be working... |
| |
| | (agh, devia haver um edit contra a submissao precoce)
Tempo de compilacao e execucao podem ser tao importantes como o tempo de programacao e manutencao do programa. As diferencas na compilacao e execucao do C relativamente ao C++ por vezes sao tao marginais que mais que justificam o uso de uma linguagem de mais alto nivel. Isto em number crunching, que foi a unica coisa que fiz a serio em C e C++.
## I should be working... |
| |
| | As diferencas na compilacao e execucao do C relativamente ao C++ por vezes sao tao marginais que mais que justificam o uso de uma linguagem de mais alto nivel.
Concordo totalmente, sendo um programador de C++.
No entanto, num benchmarking, faz a diferença.
|
| |
| | No que diz respeito à performace do código gerado, o único aspecto que conheço do C++ são os métodos "virtual" -- que podes não usar. Há mais?
|
| |
| | | Mas qual é o problema dos métodos virtuais? São mais lentos? Do que quê, métodos normais? Sim, mas os métodos virtuais não têm o mesmo objectivo. Se tentares fazer o que eles fazem sem usares os mecanismos do C++ também vais ter código mais lento. Mas tens mais funcionalidades. Acho piada que o pessoal vem sempre falar no virtual... é uma feature, é natural que nem todas as features tenham o mesmo peso. Só faltava virem falar de float's. Também são mais lentos que os int's, mas têm mais funcionalidades. Seja como for, e voltando ao tópico inicial, o que é que interessa estes benchmarks? Por mais que tenhamos um compilador super rápido, serão sempre os programadores a fazer código lento.
____________________
Pedro Santos :: psantos.net |
| |
| | Tens toda a razão. Faz pouco sentido estar a comparar linguagens em termos de features que não existem numa delas.
Mas a minha ideia era mais ou menos esta: se houver razão para um dado algoritmo implementado em C++ ser mais lento que o mesmo algoritmo implementado em C (na medida em que as duas implementações possam ser consideradas o mesmo algoritmo), essa difereça há-de advir da utilização de métodos virtuais ou excepções (tinha-me esquecido delas). Ou do compilador, é claro.
Estava a perguntar se havia mais aspectos que merecessem este tipo de consideração.
Afinal, se não fosse a performance, não haveria razão para que todos os métodos não fossem virtuais.
|
| |
| | | Pois, essa das excepções então... ui. Assim de repende também não me lembro de mais nada. Seja como for, muitas vezes o polimorfismo pode ser emulado com programação genérica (templates) por isso irias estar a testar C++ com a Feature X ou Y na mesma. Afinal, se não fosse a performance, não haveria razão para que todos os métodos não fossem virtuais. Isso era o que o pessoal do Java pensava... ;-) Mas ter todos os métodos estáticos pode trazer outro tipo de problemas, além do peso, como referiste.
____________________
Pedro Santos :: psantos.net |
| |
| | No Java todos os métodos são virtuais, no entanto a VM é suficientemente inteligente para descortinar aqueles que merecem ser virtuais e os que não merecem. O caso do "final" em Java é uma daqueles mitos de performance clássicos (ver isto).
Mas, e respondendo ao teu outro post, as criticas aos métodos "virtual" em C++ são desporporcionadas pois, tal como dizes, é uma troca de funcionalidade por performance. Se eu quiser permitir polimorfismo uso "virtual", senão não uso. O que acontece é que há muito boa gente que mete virtual em tudo.
-- Carlos Rodrigues
|
| |
| | Ups... queria dizer métodos virtuais e não estáticos como fiz.
____________________
Pedro Santos :: psantos.net |
| |
| ah! (Pontos:4, Engraçado) |
| | | [...] é a melhor coisa desde o pão às fatias Para mim esta expressão deixou de fazer sentido desde que assisti a uma coisa revolucionária: num supermercado em Bruxelas, as pessoas pegam no pão da sua preferência, introduzem-no numa máquina, e sai todo às fatias, direitinho para o saco! sem corantes nem conservantes. fantástico! Entretanto, estava eu todo contente a pensar que "em Bruxelas é que é", quando vi no outro dia, na Av. Duque de Ávila nº 56D - 1000 Lisboa, uma padaria equipada com a dita máquina. É efectivamente a melhor invenção desde o pão às fatias.
Grumpy B) |
| |
| |
| | Existe uma no carrefour de Oeiras!
Oeiras, na vanguarda da tecnologia :P
Umm... com slogans destes talvez deva concorrer as autarquicas.
## I should be working... |
| |
| Re:ah! (Pontos:3, Informativo) |
| | Acho que existe mesmo em todos os Carrefours
KISS - Keep It Simple, Stupid! |
| |
| | | Seria igualmente interessante estender-se esta comparação aos compiladores de Fortran da GNU (g77) e da Intel (ifc/fort). Pela minha experiência pessoal, se o código a compilar tiver muito floating point e pouca manipulação inteira, o compilador da Intel pode facilmente bater o g77 em tempos de CPU. Mas isto foi apenas a minha percepção pessoal... Há mais experiências a compartilhar nesta área? All the best, Noviço
|
| |
| |
| | de acordo com o /., estás inteiramente correcto.
-----
Microsoft has funded 13 studies over the past year comparing Linux with its own products. Guess what: All of them come out in favor of Microsoft. |
| |
| | | ... fiquei com uma pungente impressão de que o gcc é algo pior na geração de código em vírgula flutuante. Algum dos meus colegas partilha desta opinião? Por outro lado, já agora, alguém consegue explicar ou avançar uma hipótese para a diferença na scimark, no segundo teste? Não imaginaria uma diferença de MIPS tão elevada, dadas as outras. Claro que eu usarei sempre gcc: mais linguagens, mais plataformas alvo, mais plataformas onde o correr, módulos interoperantes, sei lá mais que vantagens, e a cereja em cima do bolo: é livre. Francisco Colaço
Deus dê saúde aos meus inimigos para que assistam de pé à minha vitória. Lema inscrito num barco bandeirante. |
| |
| |
| | Sim, o ICC costuma destacar-se no campo da virgula flutuante.
No caso em particular, tens o facto de o ICC fazer vectorização de código e o facto de os Pentium4 favorecerem bastante o código vectorizado.
|
| |
| | A única justificação para gastar dinheiro num compilador é mesmo para aplicações sedentas de performance, e há poucas dessas que não sejam maioritariamente FPU-intensive. É natural que os tipos da Intel apliquem a sua vantagem de estar a produzir um compilador dependente do x86 para atacar onde realmente importa aos seus clientes. Mas não me parece que o GCC seja mau nessa área, apenas não é tão bom quanto o da Intel. E segundo já li algures, o GCC até vai ter vectorização em breve, portanto as diferenças esbatem-se.
-- Carlos Rodrigues
|
| |
| | Aplicações sedentas de performance (em termos de CPU) não faltam. E nem todas usam intensivamente FP. Mas é nas de FP que o ICC se destaca mais do GCC. Nas outras, a diferença é menor.
Mas de facto, muitas aplicações nunca são sequer optimizadas, quanto mais justificar a compra de um compilador
Ainda assim, há outras razões para usar o ICC, além das diferenças de performace:
- Suporte para standards recentes. C99, F95 (ainda estão em evolução no GCC). Não sei como anda o C++98 no GCC.
- Suporte para OpenMP e auto-paralelização de código.
- Capacidade de gerar binários optimizados para multiplos CPUs.
- Robustez.
- Estabilidade dos dialectos nativos e compatibilidade com outros compiladores. Não, nem toda a gente escreve código standard. O próprio GCC tem extensões a mais e anda a limpar a casa. O ICC pode ser uma plataforma mais estável e mais próxima de outros compiladores proprietários para Unix.
|
| |
| | Em termos de C99 e C++98 penso que o GCC não fica a dever nada ao ICC. Pelo menos no C99 penso que o suporte é completo.
-- Carlos Rodrigues
|
| |
| | O suporte do ICC para C99 mais completo e existe há mais tempo. O C++98 não sei.
http://gcc.gnu.org/c99status.html
http://www.intel.com/software/products/compilers/clin/docs/ug_cpp/lin1066.htm
|
| |
| | A página da Intel apenas refere que o compilador está conforme o standard C89 (1990) e suporta aquelas features do C99 que estão na tabela. Pela minha interpretação não é melhor que o suporte do GCC. Mas gostava de ver uma comparação do suporte relativo entre diversos compiladores, tanto para o C99 como para o CPP98.
-- Carlos Rodrigues
|
| |
| | Óvbio. Se o suporte é incompleto, não podem estar conforme o standard C99.
Além de features em falta, também lhes falta impor algumas restrições que tornam o C99 ligeiramente incompativel com o C89.
|
| |
| | vamos ao que interessa, qual é a velocidade do código do ICC num Athlon32 ? ;)
|
| |
| |
| | Suficiente para a AMD o usar nas submissões de SPEC CPU. Não sei se ainda o usam para as submissões dos Athon64/Opteron.
|
| |
| | De facto a questão do Opteron intriga-me. Neste momento tenho código que usa intensivamente FP, compilado com o g77 num dual Opteron. Mas não sei até que ponto o IFC compensará num AMD Opteron. Vou fazer uns testes e se tiver tempo posto aqui o resultado.
|
| |
| Aviso (Pontos:3, Informativo) |
| | O IFC não tem, obviamente, opção para compilar para um Opteron. Suspeito que optimizar para um Pentium-M deve dar os melhores resultados.
Mas a Intel foi sacana com os novos compiladores. Ao optimizar para certos processadores, os programas ou não correm em CPUs que não sejam Intel ou não aproveitam as optimizações.
Com o compilador de C resolve-se desde que a main não seja compilada com opções dessas. Com o de Fortran, não sei.
|
| |
| | | [...] Mas a Intel foi sacana com os novos compiladores. Ao optimizar para certos processadores, os programas ou não correm em CPUs que não sejam Intel ou não aproveitam as optimizações. Com o compilador de C resolve-se desde que a main não seja compilada com opções dessas. Com o de Fortran, não sei. A minha experiência é única e exclusivamente em Fortran, e pelo que me pude aperceber, em códigos com forte componente de vírgula flutuante, o ifc produziu um binário executável duas vezes mais rápido que o g77 em AMD Athlon. Num Intel P4 Prescott a diferença ainda é maior. All the best, Noviço
|
| |
