gildot

Topo
Sobre
FAQ
Tópicos
Autores
Preferências
Artigos
Sondagens
Propor artigo


8/3
gildicas
9/30
jobs
10/9
perguntas
10/25
press

 
GCC vs. Intel C++, mais um round
Contribuído por vd em 20-09-04 9:07
do departamento bentechi-marques
consultorio CrLf escreve "Muita gente jura a pés juntos que o GCC é péssimo em termos de performance do código gerado e que o Intel C++ é a melhor coisa desde o pão às fatias. Outros defendem o GCC com unhas e dentes. Pois bem, está no ar mais um benchmark que, desta vez, compara o Intel C++ 8.1 com o GCC 3.3.x, 3.4.x e o futuro GCC 4.0 (que finalmente substitui o g77 por um compilador de FORTRAN 95). Os testes foram realizados em Linux, num Opteron (em 64bits, onde não se fez comparação com o ICC, apenas entre diferentes versões do GCC) e num Pentium 4. Leiam e tirem as vossas conclusões. "

Lista em português sobre Ldap | República das bananas  >

 

gildot Login
Login:

Password:

Referências
  • Linux
  • Intel
  • CrLf
  • benchmark
  • Mais acerca consultorio
  • Também por vd
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    Comparando maçãs com laranjas? (Pontos:2)
    por blacksheep em 20-09-04 9:40 GMT (#1)
    (Utilizador Info) http://rpmcruz.planetaclix.pt/
    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...
    Re:Comparando maçãs com laranjas? (Pontos:2, Informativo)
    por Valjean em 20-09-04 10:25 GMT (#4)
    (Utilizador Info) http://republico.estv.ipv.pt/~lbruno/
    GCC == GNU Compiler Collection.

    O GCC deixou de ser apenas um compilador de C há algum tempo.

    --
    Luís Bruno

    Re:Comparando maçãs com laranjas? (Pontos:2)
    por 4Gr em 20-09-04 10:37 GMT (#5)
    (Utilizador Info) http://www.fe.up.pt/freefeup
    Na verdade, o GCC inclui o compilador de C++, g++.

    Paradoxo do ano: Microsoft Works!
    Dominus vobiscum
    Re:Comparando maçãs com laranjas? (Pontos:2)
    por blacksheep em 20-09-04 12:06 GMT (#11)
    (Utilizador Info) http://rpmcruz.planetaclix.pt/
    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.
    Re:Comparando maçãs com laranjas? (Pontos:2)
    por raxx7 em 20-09-04 12:19 GMT (#13)
    (Utilizador Info)
    O código dos benchmarks é C, com mais ou menos extensões do GCC.

    Re:Comparando maçãs com laranjas? (Pontos:2)
    por blacksheep em 20-09-04 12:40 GMT (#15)
    (Utilizador Info) http://rpmcruz.planetaclix.pt/
    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.
    Re:Comparando maçãs com laranjas? (Pontos:2)
    por raxx7 em 20-09-04 12:46 GMT (#17)
    (Utilizador Info)
    É um compilador de C e C++.

    Re:Comparando maçãs com laranjas? (Pontos:2)
    por PRE em 20-09-04 12:48 GMT (#18)
    (Utilizador Info) http://psantos.net
    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
    Re:Comparando maçãs com laranjas? (Pontos:2)
    por TarHai em 20-09-04 11:38 GMT (#7)
    (Utilizador Info) http://www.dilbert.com
    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...
    Re:Comparando maçãs com laranjas? (Pontos:2)
    por TarHai em 20-09-04 11:49 GMT (#8)
    (Utilizador Info) http://www.dilbert.com
    (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...
    Re:Comparando maçãs com laranjas? (Pontos:2)
    por blacksheep em 20-09-04 12:03 GMT (#10)
    (Utilizador Info) http://rpmcruz.planetaclix.pt/
    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.
    Re:Comparando maçãs com laranjas? (Pontos:2)
    por raxx7 em 20-09-04 12:17 GMT (#12)
    (Utilizador Info)
    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?

    Re:Comparando maçãs com laranjas? (Pontos:2)
    por PRE em 20-09-04 12:44 GMT (#16)
    (Utilizador Info) http://psantos.net
    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

    Re:Comparando maçãs com laranjas? (Pontos:2)
    por raxx7 em 20-09-04 13:13 GMT (#19)
    (Utilizador Info)
    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.

    Re:Comparando maçãs com laranjas? (Pontos:2)
    por PRE em 20-09-04 13:28 GMT (#20)
    (Utilizador Info) http://psantos.net
    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

    Re:Comparando maçãs com laranjas? (Pontos:3, Informativo)
    por CrLf em 20-09-04 14:47 GMT (#22)
    (Utilizador Info) http://tudo-sobre-nada.blogspot.com
    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
    Re:Comparando maçãs com laranjas? (Pontos:2)
    por PRE em 20-09-04 18:15 GMT (#26)
    (Utilizador Info) http://psantos.net
    Ups... queria dizer métodos virtuais e não estáticos como fiz.
    ____________________
    Pedro Santos :: psantos.net
    ah! (Pontos:4, Engraçado)
    por grumpy bulgarian em 20-09-04 10:07 GMT (#2)
    (Utilizador Info) http://10.10.11.2
    [...] é 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)

    Re:ah! (Pontos:2)
    por TarHai em 20-09-04 11:35 GMT (#6)
    (Utilizador Info) http://www.dilbert.com
    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)
    por BlueRibbon em 20-09-04 18:01 GMT (#25)
    (Utilizador Info)
    Acho que existe mesmo em todos os Carrefours

    KISS - Keep It Simple, Stupid!

    Compiladores GNU e Intel (Pontos:1)
    por Noviço em 20-09-04 10:24 GMT (#3)
    (Utilizador Info)
    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

    Re:Compiladores GNU e Intel (Pontos:1)
    por Perky_Goth em 22-09-04 1:16 GMT (#32)
    (Utilizador Info) http://www.fe.up.pt/freefeup
    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.
    Lendo o artigo atentamente... (Pontos:3, Interessante)
    por fhc em 20-09-04 12:00 GMT (#9)
    (Utilizador Info)

    ... 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.

    Re:Lendo o artigo atentamente... (Pontos:2)
    por raxx7 em 20-09-04 12:24 GMT (#14)
    (Utilizador Info)
    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.

    Re:Lendo o artigo atentamente... (Pontos:2)
    por CrLf em 20-09-04 15:52 GMT (#24)
    (Utilizador Info) http://tudo-sobre-nada.blogspot.com
    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
    Re:Lendo o artigo atentamente... (Pontos:2)
    por raxx7 em 20-09-04 18:55 GMT (#27)
    (Utilizador Info)
    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.

    Re:Lendo o artigo atentamente... (Pontos:2)
    por CrLf em 20-09-04 19:54 GMT (#28)
    (Utilizador Info) http://tudo-sobre-nada.blogspot.com
    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
    Re:Lendo o artigo atentamente... (Pontos:2)
    por raxx7 em 21-09-04 1:50 GMT (#29)
    (Utilizador Info)
    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

    Re:Lendo o artigo atentamente... (Pontos:2)
    por CrLf em 21-09-04 9:56 GMT (#30)
    (Utilizador Info) http://tudo-sobre-nada.blogspot.com
    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
    Re:Lendo o artigo atentamente... (Pontos:2)
    por raxx7 em 21-09-04 12:41 GMT (#31)
    (Utilizador Info)
    Ó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.

    Sim mas, (Pontos:3, Interessante)
    por chbm em 20-09-04 13:53 GMT (#21)
    (Utilizador Info) http://chbm.net/
    vamos ao que interessa, qual é a velocidade do código do ICC num Athlon32 ? ;)
    Re:Sim mas, (Pontos:2)
    por raxx7 em 20-09-04 14:56 GMT (#23)
    (Utilizador Info)
    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.

    Re:Sim mas, (Pontos:2)
    por MacLeod em 22-09-04 11:36 GMT (#33)
    (Utilizador Info)
    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)
    por raxx7 em 22-09-04 16:20 GMT (#34)
    (Utilizador Info)
    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.

    Re:Aviso (Pontos:1)
    por Noviço em 22-09-04 21:26 GMT (#35)
    (Utilizador Info)
    [...] 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

     

     

    [ Topo | FAQ | Editores | Contacto ]