Projeto busca quintuplicar desempenho do Python
Um novo projeto lançado pelos engenheiros de Python do Google, pode tornar a popular linguagem de programação cinco vezes mais rápida. O projeto, que é chamado de Unladen Swallow, procura substituir a máquina virtual do interpretador Python por um novo mecanismo de compilação just-in-time (JIT) construído sobre o LLVM.
O primeiro lançamento, anunciado na PyCon, já oferece um aumento de performance de 15 a 25% acima do CPython. O código fonte está disponível em http://code.google.com/p/unladen-swallow/ (via noticiaslinux.com.br)
Saiba mais (arstechnica.com).
• Publicado por Augusto Campos em
2009-03-30
@brlinuxblog
Feed RSS
Opa! Boa notícia!
Só resta saber se é uma andorinha africana ou européia… :D
Como ou sem carga?
Finalmente meu.Quando tempo o povo demorou pra se tocar.
O antigo author do psyco tem o pypy ,mas com isso ele quis ser audacioso demais em fazer um projeto deste tamanho.
@jonatas
Pelo nome do projeto, é sem carga. Mas continua a questão: é uma andorinha africana ou européia? :)
Algum tempo atrás tinha lido que o Python estava mais rápido do que o C++, acho que agora querem que ele fique mais rápido que o assembler. :) :)
@Welington Braga: Leu isso aonde? Na Caras?
Sinceramente hoje em dia, ser mais rapido que C/C++ não é uma tarefa tão dificil…
Com a quantidade de VM’s por ai… que são capazes de auto-profiling e gerar cada vez codigo mais otimizado com seus JIT’s…
Como sempre digo , uma VM não é um problema a ser tratado, é uma solucao.
JRuby é um bom exemplo disso.
@Lucas de Marchi: Se fosse na caras hoje 90% dos programadores Java já teriam mudado de linguagem ;)
Só encontrei esse link que refere-se a ser mais rápido que o C, mas senão me engano a notícia que me referia, tinha sido publicada aqui mesmo no BR-Linux.
http://www.noticiaslinux.com.br/nl1083203802.html
ops: Me equivoquei quando, no comentário anterior, disse que era mais rápido que o C++, o correto seria mais rápido que o C.
@welrbraga
Então, ou programa feito em C deve ser um exemplo puro de POG ou tem umas duzentas camadas.
É até fácil fazer com que um programa complexo feito em JRuby fique mais rápido que um programa complexo em assembly, só basta colocar um cara incompetente para programar um sistema em assembly sem respeitar os ciclos do processador.
Em C é mais fácil ainda só basta colocar um POGueiro qualquer para programar em C, ou mesmo usar um RAD quaalquer para gerar programas em C.
Lembrem-se as famosas VMs das maiorias das liguagens são feitas em 90% em C/C++ e 10% em assembly, não podemos comparar um tecnologia que roda em uma VM escrita em C com tecnologias escritas em C (a menos que as mesmas sejam feitas em POG).
A lógica é simples se a tecnologia Python/Java/Ruby/… está mais rápida é que porque o JIT e a VM foi bem programada usando C/C++/Assembly.
@Hell,
Paciencia , mas a pura realidade é que hoje em dia ser mais rapido que C/C++ não é mais um desafio.
@Dyego Souza do Carmo
Se isso é verdade eu gostaria de saber por que continuo trabalhando com sistemas embarcados em C… Ou por que nenhuma empresa nunca desenvolveu um SO feito em Ruby… Ou ainda por que a Texas Instruments nunca lançou um SDK java para seus PICs…
Sinceramente até hoje nunca encontrei um comparativo bom que me me fizesse acreditar que uma dessas linguagens é mais eficiente.
@Carcará
Agora sim , estamos até agora discutindo microcomputação… e não dispositivos embarcados…
Te digo que existem milhares de alternativas a C puro para dispositivos embarcados…
Te digo que o S.O. é o MEIO e dificilmente nunca é o FIM… o MEIO pode ser dificil e complicado… mas o fim tem que ser mais facil e de manutencao descomplicada…
Quanto ao Java… existe varias versoes que rodam em microdispositivos… desde microondas até kits ARM… entao não me venha com uma realidade só sua dizendo que “a texas bla bla bla”… olha o mercado… veja os ARM’s , veja os novos Spots de mercado e verá que Java está lá , muito bem por sinal…
Nao estou aqui defendendo o Java… e sim defendendo algo que não seja C/C++… prq eu acho que o mundo já é bem chato para voce ter que ficar programando em C/C++ para embarcados.
Carcará, verdade, nenhum celular hoje roda JavaME, não?
Dyego,
“Te digo que existem milhares de alternativas a C puro para dispositivos embarcados…”
Milhares? hehehe… me cita aqui 5, em uso **comercialmente**, e talvez eu dê algum crédito pro resto das besteiras que escreveste.
E antes de discutir sobre SO com gente que possivelmente desenvolve SOs, vai ler alguns artigos a respeito.
Cadu,
Java, Python, Ruby , Lua, Perl… mais alguma cadu ?
Cada vez mais os celulares estão poderosos… cada vez mais processamento… tem certos celulares que rodam até o java SE default… VAAAAAARIOS ARM’s tmb…
Possivelmente desenvolve SO ? Por favor… voce antes tem que se informar melhor de alternativas a este mundo de dor que é o C/C++…
é conmo eu sempre falo…
C/C++ é que nem picina fria…
O primeiro que usa , logo fala para os outros, “entra… a agua esta quentinha”…
@Paul
Pensei que estivéssemos discutindo desempenho, J2ME é apenas para aplicativas básicos, talvez não eu tenha sido claro. Desculpe minha ignorância.
@Dyego
Até o momento não tinha falado, nem você, em de facilidade de desenvolvimento e manutenção. Nisso C e C++ estão longe de serem as campeãs. Discutíamos desempenho.
Sobre microcomputadores vs dispositivos embarcados, a diferença básica é a disponibilidade de recursos. Você não pode desenvolver da forma que quer esperando que o processador aguente e que se pode fazer qualquer coisa sem faltar memória. As alternativas que você citou só compreendem aplicativos e são usados por causa da portabilidade. Em celulares os aplicativos nativos são feitos em C ou C++.
Acredite, trabalho com desenvolvimento/manutenção de software embarcado (C puro), de software de base, iclusive já mexi em uma implementação da J2ME. Não tem jeito, ainda não existe, e provavelmente vai demorar para existir, alternativas para C/C++, e tem que se pagar o preço da complexidade. E a propósito, meu trabalho não é chato.
“Texas bla bla bla”
putz, isso me fez pensar se realmente vale a pena ter continuado essa discussão.
Ou exemplo que ia passando. por que você acha que as empresas de jogos desenvolvem os motores de renderização em C++? essas empresas gostam de pagar por funcionários caros? gostam de gastar muito para obter portabilidade?
Carcará nao contrarie o Dyego! já estao até mudando a cryengine para python! hahaha