Projeto de kernel linux de alta perfomance – LinuxDNA
“Novo projeto, chamado LinuxDNA, quer manter árvore paralela do kernel Linux para compilar com o ICC da Intel. Eles já conseguiram sucesso compilando o kernel com o Gentoo e conseguiram ganhos de desempenho de até 40% em certas partes do kernel [e pretendem alcançar ganhos de 8% a 9% em média]. Um dos objetivos do grupo é fornecer um kernel para clusters, jogos e computação científica.”
Enviado por Filipi Vianna (fviannaΘgmail·com) – referência (slashdotptbr.blogspot.com).
• Publicado por Augusto Campos em
2009-02-27
@brlinuxblog
Feed RSS
Se os ganhos forem realmente bons eu compro o ICC. Seria um passo para o Kernel otimizado para Desktop? Como queria Kolivas.
Não seria para desk, mas pelos três motivos apresentados, claro que jogos está incluído no desk. Porém cluster e computação científica não são lá desk, são mais serv.
Complementando deve ser mais amplo do que visar um melhoramento do desk.
esse tipo de notícia, deveria ficar só no meio bit. já que foi escrita só para criar polêmica e gerar acessos.
Imagine uma distribuição inteira compilada com o ICC…
Daqui a pouco alguém inicia esse projeto…
Eu gostaria de ver um Slackware ou Ubuntu compilado inteiramente com ICC…
Muito bom, pena que só serviria apenas para processadores Intel, pois foi um compilador feito exclusivamente para possuir melhor perfomance em processadores Intel, se compilar de forma generica não possuirá o mesmo desempenho.
Uma vez baixei o ICC, o compilador até que é interessante, mas são 300 mb só de compildor, quem quiser pega-lo gratuitamente é só baixar do site da Intel, mas lembrando que só é isento de pagamento qualquer projeto sem fins lucrativos, se caso esteja desenvolovendo algum projeto opensource pode baixa-lo efetuando o cadastro lá no site da Intel de forma gratuita.
Há tempos o GCC come poeira do ICC no Linux, e do compilador da MS no Windows. Lembram do artigo que comparava o desempenho do Firefox no Linux e Windows? Mesmo habilitando as nova otimizações, os desenvolvedores falaram que boa parte do desempenho ainda se devia ao fato do FF no Win ser compilado com o compilador da MS.
O ICC gera binários compatíveis com processadores AMD sim! Para isso, basta selecionar as flags corretas. Leiam a documentação, poxa…
http://www.intel.com/software/products/compilers/docs/clin/main_cls/index.htm
Cuidado com a generalização. ICC gera códigos que, em média, são de 8 a 9% mais rápidos que o GCC. Só faltou um detalhe pequeno: só para plataforma x86.
Quero ver o GCC compilar para PowerPC, ARM, S/390, compilar Fortran, Java, Objective-C e mais um montão de plataformas e linguagens que o GCC atende. Quando ICC fizer isso, aí será uma alternativa ao GCC, até lá é alternativa apenas para x86 e em alguns casos. Aliás, quem reclama do GCC, já aproveitou para doar uma graninha para ajudar os caras a ter mais gente, mais equipamentos, etc? Humm … Imaginei que não.
Claro, o GCC pode melhorar? Deve! Tem muitos problemas mas, com os recursos limitados que o projeto tem, o GCC já faz muito. às vezes é bom ter um parâmetro para medir seu produto, sabendo que tem o ICC fazendo melhor, pode incentivar a galera a fazer melhor ainda.
E todos ganharão com isso.
Flávio
Como hell comentou para os processadores Intel deve ser melhor mesmo, são os caras que desenvolvem o processador se eles não conseguirem fazer um bom compilador que vai fazer.
Acho engraçado esses caras que reclamam do GCC.
Fui baixar ontem e tinha compilador pra Fortran. E o compilador novo da Apple baseado no GCC, alguém sabe se é bom?
É clang o nome do compilador da Apple.
Mas vocês esquecem que o ICC nao é livre e é muito dependente da x86.
Nao gosto da intel e não gosto de coisas muito homogeneas.O SPARC e o power pc devem ser respeitados também .Principalmente o SPARC que tem mesmo até plataforma aberta.
Atualmente estou observando a LLVM com o compilador clang.
http://clang.llvm.org/
Alguém aí já tentou usar outros compiladores c no Linux? Tipo o TinyC, o pcc? Instalei o PCC estes dias e não consegui compilar nem um hello world.
Sem dúvida o grande mérito do gcc é ser multiplataforma. Alguém aí sabe se o Linux compilado em embarcados é compilado no gcc?
E que bom que agora sabemos que o Linux poderia ser mais rápido do que já é. Eu sinceramente não gostaria que o ICC virasse padrão no Linux, já que é proprietário (a intel teria poder sobre a distribuição do compilador, que certamente não poderia vir incluído nas distribuições), embora eu tenha que ler a licença da coisa para ter certeza :-) Quem sabe o pessoal não pense mais em desempenho – em todas as plataformas – de agora em diante agora que percebem que há um competidor à altura (não que antes não houvesse).
Além disso ao que parece o ICC funciona só no Windows, OS X e Linux, enquanto que o gcc funcioan em trocentos sistemas diferentes. E o compilador da MS? Bem… funciona em cinco versões do Windows…
E isso criaria uma fonte de poder muito forte ,pois deixaria todo o código dependente da x86 .E com isso as outras arquiteturas seriam marginalizadas .
E a intel iria adorar isso.A intel nao tem o hardware aberto igual ao projeto que o opensSPARC faz.
Se eu pudesse eu usaria sparc.Mas é dificil ,mesmo com todo o suporte que o software livre oferece.
Prefiro continuar tentando usar o clang.
O GCC é extremamente grande, complexo e lento. Apesar de suportar muitas arquiteturas, ele não é muito portável e o suporte a algumas arquiteturas tem sido abandonado. Por isso eu nunca mandaria meu dinheiro para esse projeto.
Quem reclama do GCC está desenvolvendo alternativas sãs, para as quais sim eu enviaria doações:
http://undeadly.org/cgi?action=article&sid=20070915195203&pid=52
http://www.thejemreport.com/content/view/369/
P.S. O ICC não suporta somente x86, ele suporta também as arquiteturas IA64, AMD64 e ARM. Longe de querer defender o ICC, só fazendo uma pequena correção…
Puxa, como o pessoal se exalta aqui.
a verdade é que muitas pessoas são injustas com o GCC, é um compilador muito bom, a otimização do código é boa e suporta muitas arquiteturas. Para quem duvida procure benchmarks entre o GCC e o Sun Studio.
Agora, não adianta ficar lutando contra os fatos, o ICC é fantástico. E não é só a otimização de código que é melhor, a implementação da biblioteca padrão também é melhor.
Comparações com compilações entre compilações no windows entre MSVC em GCC não me parecem adequadas dado que o gcc fica meio alien no windows.
Me esqueci de comentar: o ICC apresenta ganhos de performance em relação ao GCC quando testado em processadores AMD também.
O Linux deveria ser compilável com qualquer compilador C que segue os padrões da linguagem. Quem é o pivô desta incompatibilidade? Do código do kernel? Do compilador Intel?
Pesquisando na Internet, achei um benchmark comparando o desempenho do GCC, do ICC e do Visual Studio 2008 (todos no Windows). O GCC venceu na maioria dos testes!
Mas isso não importa, porque todo mundo sabe que Java é mais rápido que C! :D
“Jack Ripoff (usuário não registrado) em 27/02/2009 às 1:56 pm
O GCC é extremamente grande”
O download do ICC em tgz são meros 590 MB para IA-32 e 475 MB para IA-64!
Vamos ver o GCC:
$ ls -lh /usr/bin/gcc-4.2
-rwxr-xr-x 1 root root 189K 2008-10-10 16:41 /usr/bin/gcc-4.2
O binário é pequeno. Vamos ver as dependências dele:
$ ldd /usr/bin/gcc-4.2
linux-gate.so.1 => (0xb7f54000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7df2000)
/lib/ld-linux.so.2 (0xb7f55000)
$ du -hs /usr/lib/gcc
20M /usr/lib/gcc
$ ls -lh /lib/tls/i686/cmov/libc-2.7.so
-rwxr-xr-x 1 root root 1.4M 2008-09-12 11:33 /lib/tls/i686/cmov/libc-2.7.so
Enfim, GCC e relacionados dá aí por volta de uns 22MB. Descompactado! Você não sabe do que fala.
O fato é que neguinho quer porque quer derrubar e enterrar o Stallman e todas suas contribuições para o cenário do software livre e remover seu nome da História.
Someone, para mim ficou bem claro que o comentário do Jack estava comparando o gcc à alternativa livre PCC – ele até inseriu links interessantes a respeito!
E, comparado ao PCC (já mencionado outras vezes em notícias por aqui), o gcc também me parece muito grande e complexo. Torço para que o PCC se torne uma alternativa completa, sólida e largamente adotada logo. E o fato de o binário do compilador da Intel ser ainda maior não muda isso em nada, mesmo aceitando que existe mesmo relação direta entre o tamanho do binário para alguma arquitetura e o tamanho do projeto.
Mas trazer para esta crítica ou comparação técnica algum argumento adicional que a transforme em debate ideológico sobre alguma personalidade histórica envolvida acrescenta pouco, me parece.
o launchpad foi rejeitado pelo debian *porque não é livre*. e o ICC tem o mesmo problema: é fechado o.o
Outra coisa:
“Why don’t I use the Intel compiler on my Opteron system? The simple answer is that Intel’s compiler does not produce code that takes advantage of the Opteron’s features. Intel’s compiler also produces executable code that disables some of its optimizations on non-Intel hardware. It’s unrealistic to expect that Intel will create a compiler that works well on their competitor’s hardware. ”
http://www.coyotegulch.com/reviews/linux_compilers/
Quem não sabe do que fala é você! O tamanho dos binários não me interessa nem um pouco. O que me interessa é o tamanho do código fonte, porque a manutenção e o desenvolvimento do software são feitos com o código fonte e não com o código binário.
E outra, se você quiser posso escrever dois programas curtos em C para você. Um vai ter menos linhas mas vai gerar um binário maior, e o outro vai ter mais linhas mas vai gerar um binário menor. Portanto sua comparação está furada. Além disso, quem disse que aquele pacote compactado da Intel não inclui documentação? Ali também deve ter um linker, um assembler, entre muitas outras coisas. Sua comparação caiu por terra.
E como disse o Augusto, a verdade é que eu nem posso (e não quero) comparar o GCC com o ICC pois não tenho o código fonte do ICC.
Se você visitar os links que eu deixei, vai ver que os líderes do projeto OpenBSD (que são os caras que mantém a versão do GCC do OpenBSD) concordam: o GCC é complicado e difícil de manter. Então se você quiser, não precisa confiar em mim. Confie neles, os sujeitos sabem do que falam. Ou não confie neles, veja com seus próprios olhos: baixe e examine o código fonte!
Você está errado, eu não quero derrubar e enterrar o Stallman. Eu não preciso, ele já está derrubado e enterrado. Sempre esteve. O crime não foi meu de tentar derrubá-lo, foi dele de erguer um grande boneco de palha em seu lugar para parecer que está mais alto do que realmente está – mas na verdade ele continua lá no fundo.
Você pode pensar o que quiser, mas “todas suas contribuições para o cenário do software livre” na verdade não são muitas. Faz anos que ele não escreve uma linha de código e ele é um grande mentiroso e hipócrita. Não há nada que faça Richard Stallman melhor do que os outros desenvolvedores que se esforçam tanto para fazer software livre de qualidade.
Eu poderia até acusá-lo de ter transformado o mundo num lugar menos seguro e de dividir a comunidade do software livre, mas eu vou deixar os comentários mais profundos sobre as realizações de Stallman para uma ocasião mais propícia. Afinal, já desvirtuamos o assunto aqui mais do que o suficiente.
E aquele compilador da Borland? Alguma informaçao? Algum Benchmarck?
Augusto Campos:
“Someone, para mim ficou bem claro que o comentário do Jack estava comparando o gcc à alternativa livre PCC – ele até inseriu links interessantes a respeito!”
O que ficou claro é que ele estava reclamando do tamanho do GCC. Eu expus então que, tamanho por tamanho, o ICC é ainda mais drástico. Porém, nem tanto: fui dar uma espiada agora no pacote que baixei ontem. Além de alguns “serviços” de ativação e libs customizadas para o bicho, infelizmente tive a desagradável surpresa de ver que lá dentro só se encontram pacotes RPM e eu uso Ubuntu. Um download imenso pra nada. Os cinco rpms contabilizam 550MB!
“E, comparado ao PCC (já mencionado outras vezes em notícias por aqui), o gcc também me parece muito grande e complexo.”
É, realmente. Pra quantas arquiteturas o pcc gera código mesmo? Pra quantas linguagens ele serve de backend? GCC gera binários para programas escritos em C, C++, Fortran, ADA, Pascal e Java, para diversas arquiteturas de computador. Código otimizado como o pcc ainda nem sonha.
“Torço para que o PCC se torne uma alternativa completa, sólida e largamente adotada logo.”
Eu torço para que o pcc não fique tão pesado e complexo quanto o gcc quando tiver o mesmo tanto de recursos.
“Mas trazer para esta crítica ou comparação técnica algum argumento adicional que a transforme em debate ideológico sobre alguma personalidade histórica envolvida acrescenta pouco, me parece.”
Ora, Augusto, você é um dos que não espera a hora de ver o Stallman sair de cena…
Eu não, o Dr. Stallman é uma figura histórica importantíssima, faz parte do folclore da informática, serve como termo de comparação em muitas situações, é um integrante do panteão canônico em determinados contextos, e espero que ele continue colhendo com saúde por muito tempo os frutos do trabalho tão admirado que ele ajudou a fazer em décadas anteriores.
Percebo que para você ficou claro só um subconjunto do que foi dito no comentário original, e que você de fato não dissocia a crítica ao GCC de um matiz ideológico sobre uma personalidade, o que certamente dificulta a discussão.
De uma forma ou de outra, me parece que uma das razões para a menor complexidade do PCC é que ele não busca ser também um compilador de Fortran, ADA, Pascal e Java. Acredito que é bom ter alternativas de código aberto a projetos importantes, e não acho que seja uma ofensa ao Stallman (nem que traga a Questão Stallman automaticamente à baila) apontar o tamanho e complexidade do GCC.
Você não parece entender que a diferença essencial entre os dois não está na quantidade de arquiteturas que eles rodam, está na facilidade de portar. O GCC vem perdendo suporte a algumas arquiteturas nas últimas versões devido à dificuldade de manutenção, tanto é que o OpenBSD ainda mantém uma versão antiga do GCC por causa disso.
O PCC (cujo nome significa “portable C compiler”) possui muito pouco código dependente de arquitetura. Ah, e a resposta à sua pergunta é: quase todas as arquiteturas em que o OpenBSD e o NetBSD rodam.
E graças às otimizações o GCC demora 5 vezes mais do que o PCC para compilar o mesmo código e gera código com mais bugs. Parafraseando Donald Knuth (alguém muito mais importante do que o Stallman, diga-se de passagem), otimização prematura é a raiz de todo o mal. Ironicamente, o código gerado pelo GCC perde em desempenho para vários compiladores proprietários justamente por causa de seu suporte monolítico (isto é, sem separação entre backend e frontend) a várias linguagens, apesar das arriscadas otimizações.
Não ficará, pois não está sendo feito pelos incompetentes do projeto GNU.
Acho que o problema são as otimizações excessivas mesmo. Ao contrário do GCC, o PCC é dividido em backend e frontend. Somente a porção do código que faz a interpretação, checagem de tipos e a árvore de construção é que depende da linguagem. Essa arquitetura mais ou menos modular permite que possa ser adicionado suporte a outras linguagens sem a complexidade absurda do GCC, a custo das otimizações. Mas eu não sou um especialista em compiladores, então desconfie do que eu acabei de falar…
Jack, o PCC usa um arquitetura de frontend e backend diferente do GCC?
Vi na wikipédia que o GCC também usa (http://tinyurl.com/b34smu).
Mas projetos como o PCC e clang são importantes. Trabalhar com uma base de código de mais de 20 anos não é sopa no mel.
Eu já usei bastante tanto o gcc quanto o icc em diversas versões e usando diversos flags de otimização em programas científicos com muito cálculo de ponto flutuante que rodavam durante horas e tinham muitos laços for aninhados.
O que verifiquei é que o icc geralmente gerava um código mais rápido mas também não era sempre que isso acontecia. E na maioria das vezes o ganho de desempenho não era significativo a ponto de compensar o tempo bem maior de compilação de programas grandes.
As primeiras versões da série 3.x do gcc não foram muito boas em gerar código otimizado mas depois com o tempo foi melhorando visivelmente e a diferença em relação ao icc foi diminuindo.
Não testei a série 4.x do gcc e nem as séries mais recentes do icc a ponto de dizer qual é a melhor, mas pelo desempenho das distribuições mais recentes do linux e das versões do KDE mais recentes eu acho que o gcc 4.x está ainda melhor do que o gcc 3.x.
O icc é muito bom em fazer vetorização mas é importante também ser justo na comparação com o gcc usando os flags de otimização de forma correta. Muitos programas e distribuições não usam flags de otimização no valor máximo e nem geram código específico para processadores mais novos. Nos meus programas eu usava -O3 ou -O2 (otimizações altas), -mcpu=X -march=Y (para gerar código específico e otimizado para o processador da máquina) e ainda outras opções específicas de otimização para processadores Intel/AMD.
Na época eu também usava só processadores e distribuições linux de 32 bits. Eu gostaria de ver benchmarks mais detalhados, que explorassem programas de diversos tipos (com processamento de inteiros, ponto-flutuante de precisão simples e dupla, com e sem uso de extensões multimídia, etc) e com diversas otimizações, processadores e geração de código em 32 e 64 bits.
O compilador da Intel tem que ser melhor mesmo do que o gcc porque o foco é mais específico (somente sua arquitetura), porque eles fazem os processadores e portanto conhecem melhor do que ninguém a arquitetura e eles precisam realmente de algum diferencial que justifique o preço que cobram pelo produto.
A Intel poderia contribuir mais com o projeto gcc porque ele não compete diretamente com o seu produto e nem é a fonte principal do lucro da empresa. Com o sucesso dos netbooks e o provável aumento de uso de processadores x86 em dispositivos protáteis e eletrônicos é bem possível que isso aconteça mais cedo do que se pensa.
E isso é uma infelicidade pois a intel tem comportamentos microsoftianos e já domina a área pessoal .
Se dominar os embarcados e os netbooks ,as coisas pioram.
Jack Ripoff:
“E graças às otimizações o GCC demora 5 vezes mais do que o PCC para compilar o mesmo código e gera código com mais bugs.”
Nobre colega, demorar para compilar código extremamente é inevitável e o ICC demora ainda mais para compilar. Ou você prefere que o pcc se mantenha rápido e produzindo código lastimavelmente lento?
“Parafraseando Donald Knuth (alguém muito mais importante do que o Stallman, diga-se de passagem),”
Será? Será sua influencial compilação didática The Art of Computer Programming, sua idéia pouco aceita sobre literate programming e seu sistema TeX mais importantes do que os softwares que Stallman iniciou e a GPL no cenário do software atual?
“otimização prematura é a raiz de todo o mal.”
Prematura como, cára-pálida? Ou o GCC deveria esperar o HURD sair para começar a implementar otimizações? Já são anos de estrada, quando ele estaria pronto?
“Não ficará, pois não está sendo feito pelos incompetentes do projeto GNU.”
E os incompetentes da RedHat, Novell, IBM e todas as outras empresas que contribuem código e lideram o desenvolvimento.
Augusto Campos:
“Acredito que é bom ter alternativas de código aberto a projetos importantes, e não acho que seja uma ofensa ao Stallman (nem que traga a Questão Stallman automaticamente à baila) apontar o tamanho e complexidade do GCC.”
Não, também não acho que seja ofensa expor fraquezas existentes.
E a questão Stallman só foi trazida à baila porque há em curso um revisionismo histórico que busca diminuir sua importância, suas idéias e contribuições e uma das melhores formas de se fazer isso é sugerir trocar os softwares do projeto GNU por outros, ainda mais fechados, mesmo sendo mais pesados, ainda mais lentos e com menos recursos e suporte a menos plataformas.
Dito isso, espero que esse comentário não desapareça como o outro…
Leia-se “demorar para compilar código extremamente otimizado”