Lançado Python 3.0 :^)

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Re: Lançado Python 3.0 :^)

Felipe Ferreri Tonello
Em Sex, 2008-12-05 às 18:53 +0000, Luciano Ramalho escreveu:

> --- Em [hidden email], "Lauro Moura"
> <lauromoura@...> escreveu
> >
> > 2008/12/5 Felipe Ferreri Tonello <fftonello@...>:
> > > Em Sex, 2008-12-05 às 02:16 -0300, Humberto Diogenes escreveu:
> > >> On 04/12/2008, at 14:26, Davi Vercillo C. Garcia (ダヴィ) wrote:
> > >>
> > >> > Sobre a performance, só fiquei um pouco decepcionado pois
> esperava um
> > >> > aumento de performance, já que a linguagem estaria mais enxuta
> e sem
> > >> > as ambiguidades.
> > >>
> > >> Dá para entender seu raciocínio, mas é raro que algo fique mais
> > >> rápido "automaticamente". Otimizar muitas vezes requer truques que
> > >> deixam o código bem complexo.
> > >>
> > >> Aos que consideram a performance tão importante, um lembrete: há
> > >> muito espaço para otimização e o código-fonte tá lá, só
> > >> esperando... Em vez de chorar, que tal tentar ajudar? ;)
> > >
> > > Eu acho que muito da questão não é essa. A grande maioria dos usuários
> > > de python não sabe e não quer saber como que funciona CPython a
> nível de
> > > editar o código e arrumar algum bug. Mas a questão é: espera-se que
> > > essas otimizações sejam feitas pelos core developers.
> > >
> >
> > O que Luciano quis dizer, é que para aqueles que têm a performance
> > como um ponto muito importante, o melhor a fazer é tentar ajudar de
> > alguma forma, como realizando medições, algo que não é necessário ter
> > um grande conhecimento de como o interpretador funciona.
>
> Lauro, apenas um detalhe: não fui eu que disse "Em vez de chorar, que
> tal tentar ajudar?", foi o grande Humberto Diógenes, com quem eu concordo.
>
> Felipe, eu entendo perfeitamente que a maioria dos usuários de Python
> não quer nem saber como são as entranhas do CPython, mas a atitude
> "espera-se que estas otimizações sejam feitas pelos core developers"
> não está muito afinada com a maneira como o software livre funciona. E
> olha que o software livre funciona *muito bem*, mas funciona de um
> jeito diferente, e neste contexto essa cobrança não ajuda em nada. É
> uma atitude passiva, e a grande graça do software livre é dar a todos
> a chance de assumirem papéis ativos.

Realmente, o que eu disse não está condizendo com o software livre de
maneira alguma. Mas, acho que me expressei mal. O que quis dizer foi
que quando há uma atualização, ainda mais de 2.5 para 3.0, espera-se
que ela seja melhor do que a anterior. Não estou, de maneira alguma,
dizendo que está pior. Mas essa perda de performance com certeza não
foi algo esperado por nós.
Talvez seria melhor dizer: "esperava-se que estas otimizações fossem
feitas pelos core developers"


> Por exemplo, qualquer pessoa que identificar um gargalo de performance
> pode documentar e reportá-lo como um bug. Se sabe resolver o gargalo,
> pode até enviar um patch, que aumenta bastante as chances de ter a
> solução incorporada mais rapidamente.
>
> Por sinal, uma das coisas mais legais que a gente fez no GruPy-SP foi
> promover dois encontros durante Python Bug Days, que são mutirões para
> resolver bugs registrados. Eu participei do primeiro destes encontros,
> e mesmo sendo todos marinheiros de primeira viagem, conseguimos
> terminar o dia com alguns consertos realizados e aceitos pelos core
> developers.

Com certeza. Essa é uma das maiores vantagens do software livre.
Eu tive a oportunidade de acompanhar o segundo desses dias pelo IRC
também.

> [ ]s
> Luciano


Reply | Threaded
Open this post in threaded view
|

Re: Re: Lançado Python 3.0 :^)

Rafael Buy

> Realmente, o que eu disse não está condizendo com o software livre de
> maneira alguma. Mas, acho que me expressei mal. O que quis dizer foi
> que quando há uma atualização, ainda mais de 2.5 para 3.0, espera-se
> que ela seja melhor do que a anterior. Não estou, de maneira alguma,
> dizendo que está pior. Mas essa perda de performance com certeza não
> foi algo esperado por nós.
> Talvez seria melhor dizer: "esperava-se que estas otimizações fossem
> feitas pelos core developers"

Python 3.0 é melhor do que Python 2.5, o que você não quer entender é que performance não faz parte da filosofia da linguagem, mas isso não quer dizer que não de pra melhorar e com certeza vai melhorar.

E não generalize ao dizer que "perda de performance com certeza não foi algo esperado por nós", alguns esperavam por isso sim como o próprio Luciano comentou.

Um abraço.
Rafael Buy



      Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
Reply | Threaded
Open this post in threaded view
|

Re: Re: Lançado Python 3.0 :^)

Marcelo Andrade
2008/12/5 Rafael Buy <[hidden email]>:
> (..)

Vale a pena discutir tanto por causa de 10% de
performance?  Se um algoritmo demorava 10s para
rodar em Python 2.5, no 3.0 deveria demorar 11s.
E...

Se houve um problema similar de escalabilidade,
aí acho até que vale o debate.

Atenciosamente.

--
MARCELO DE F. ANDRADE (aka "eleKtron")
Belem, PA, Amazonia, Brazil
Linux User #221105

[gus@pará ~]# links http://pa.slackwarebrasil.org/
Reply | Threaded
Open this post in threaded view
|

Re: Lançado Python 3.0 :^)

Luciano Ramalho
In reply to this post by Rafael Buy
--- Em [hidden email], Rafael Buy <rafaelbuy@...>
escreveu
> Python 3.0 é melhor do que Python 2.5, o que você não quer entender
é que performance não faz parte da filosofia da linguagem, mas isso
não quer dizer que não de pra melhorar e com certeza vai melhorar.

Rafael, eu não diria que performance não faz parte da filosofia da
linguagem Python; eu diria que Python coloca a produtividade do
programador em primeiro lugar, o que significa que numa escolha entre
conveniência e performance a conveniência vai levar a vantagem.
Considerando a Lei de Moore, esta é uma excelente filosofia.

Mas até independente da Lei de Moore, na minha experiência
profissional sempre foi muito raro algum cliente reclamar que o
software estava lento; 99% do tempo eles reclamam que o custo é muito
alto ou que o prazo de desenvolvimento é longo demais. Então, ao menos
na minha experiência profissional, a aposta que Python faz na
produtividade do desenvolvedor está alinhada com as necessidades dos
clientes.

> E não generalize ao dizer que "perda de performance com certeza não
foi algo esperado por nós", alguns esperavam por isso sim como o
próprio Luciano comentou.

Sinceramente, eu não esperava que o Python 3.0 fosse mais lento que o
Python 2.5, mas também não fiquei surpreso, confio no taco do Guido &
Cia. e acredito que isso vai ser resolvido.

De qualquer modo, acho que 10% menos performance é um ótimo preço a se
pagar quando a linguagem que já era excelente ficou ainda melhor, mais
elegante e mais consistente.

[ ]s
Luciano



Reply | Threaded
Open this post in threaded view
|

Re: Re: Lançado Python 3.0 :^)

Humberto Diogenes-2

On 05/12/2008, at 18:06, Luciano Ramalho wrote:

> (...) menos performance é um ótimo preço a se
> pagar quando a linguagem que já era excelente ficou ainda melhor, mais
> elegante e mais consistente.


   Até considerei levar a discussão adiante, mas admito que essa frase  
do Luciano me "desarmou".
   O importante é isso mesmo: o Python 3.0 saiu, minha gente! Mesmo  
que fosse com metade da performance do 2.x, continuaria sendo a ótima  
notícia que me fez sorrir os últimos dois dias inteiros! :D
   Só temos que comemorar! (e enviar alguns bug reports, claro :o)


--
Humberto Diógenes
http://humberto.digi.com.br

Reply | Threaded
Open this post in threaded view
|

Re: Re: Lançado Python 3.0 :^)

Rafael Buy
In reply to this post by Luciano Ramalho

>> Python 3.0 é melhor do que Python 2.5, o que você não quer entender
>> é que performance não faz parte da filosofia da linguagem, mas isso
>> não quer dizer que não de pra melhorar e com certeza vai melhorar.

> Rafael, eu não diria que performance não faz parte da filosofia da
> linguagem Python; eu diria que Python coloca a produtividade do
> programador em primeiro lugar, o que significa que numa escolha entre
> conveniência e performance a conveniência vai levar a vantagem.
> Considerando a Lei de Moore, esta é uma excelente filosofia.

Foi o que eu tentei dizer Luciano. :) O foco principal é outro, ou seja, a produtividade do programador.

Um abraço.
Rafael Buy


      Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
Reply | Threaded
Open this post in threaded view
|

Re: Re: Lançado Python 3.0 :^)

Tiago Fassoni A. A. Leite
In reply to this post by Luciano Ramalho
Sim, eu cortei (boa) parte da mensagem e deixei só a parte mais relevante
para o tópico que vou falar.

2008/12/5 Luciano Ramalho <[hidden email]>

>
>
> Mas até independente da Lei de Moore, na minha experiência
> profissional sempre foi muito raro algum cliente reclamar que o
> software estava lento; 99% do tempo eles reclamam que o custo é muito
> alto ou que o prazo de desenvolvimento é longo demais. Então, ao menos
> na minha experiência profissional, a aposta que Python faz na
> produtividade do desenvolvedor está alinhada com as necessidades dos
> clientes.


Os 10% de performance são um problema na parte de aplicações numéricas.
Muitos programas numéricos, por exemplo, simulação de ativos em bolsa de
valores, conseguem facilmente superar 30 horas numa máquina. (eu já amarguei
um exemplo desses).

Aí os 10% se tornam importantes. Outro detalhe, ONDE são esses 10%? Se eu
bem me lembro, a perda de desempenho fica no fato de int agora ter precisão
maior.

Se o seu programa NUMÉRICO só usa float, não tem problema.

Se você tenta deixar tudo em int para aumentar a velocidade (evitar ponto
flutuante), ferrou!

My 2 cents,
                 Tiago


[As partes desta mensagem que não continham texto foram removidas]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Lançado Python 3.0 :^)

Leonardo Santagada

On Dec 6, 2008, at 5:37 AM, Tiago Fassoni A. A. Leite wrote:

> Os 10% de performance são um problema na parte de aplicações  
> numéricas.
> Muitos programas numéricos, por exemplo, simulação de ativos em  
> bolsa de
> valores, conseguem facilmente superar 30 horas numa máquina. (eu já  
> amarguei
> um exemplo desses).


Bom se tu tem um programa desses que não usa numpy nem usa o psyco ele  
já demora umas 20horas a mais do que deveria. Se ele usa qualquer uma  
dessas bibliotecas não te preocupa que elas só serão portadas e  
ficarão estaveis lá pelo python 3.1 que provavelmente já terá fechado  
essa gap de 10%.

Eu não me impressionei com a queda de 10% de performance nem um pouco.  
A VM do python tem a velocidade que tem pq muita gente mexeu nela para  
deixa-la melhor. Agora no python 3.0 muita coisa foi escrita do zero  
ou reescrita, era óbvio que a versão .0 não seria perfeitamente  
otimizada. Acho que a gente deveria ficar feliz que foi feita uma  
versão .0 bem sólida e não como estamos acostumados com a maioria dos  
softwares por ai.

Eu estou começando a minha lista de coisas que eu odeio no python 3.0  
pq a minha lista do 2.5 foi quase eliminada por completo. Meu primeiro  
item é o os.environ interpretar variaveis de ambiente com o locale da  
maquina e converte-las para unicode. Mas isso talvez eles consertem  
pro python 3.1 então estou fazendo a lista com lapis por enquanto.

[]'s
--
Leonardo Santagada
santagada at gmail.com



Reply | Threaded
Open this post in threaded view
|

Re: Re: Lançado Python 3.0 :^)

Joao S. O. Bueno Calligaris
In reply to this post by Tiago Fassoni A. A. Leite
On Saturday 06 December 2008, Tiago Fassoni A. A. Leite wrote:

> Sim, eu cortei (boa) parte da mensagem e deixei só a parte mais relevante
> para o tópico que vou falar.
>
> 2008/12/5 Luciano Ramalho <[hidden email]>
>
> > Mas até independente da Lei de Moore, na minha experiência
> > profissional sempre foi muito raro algum cliente reclamar que o
> > software estava lento; 99% do tempo eles reclamam que o custo é muito
> > alto ou que o prazo de desenvolvimento é longo demais. Então, ao menos
> > na minha experiência profissional, a aposta que Python faz na
> > produtividade do desenvolvedor está alinhada com as necessidades dos
> > clientes.
>
> Os 10% de performance são um problema na parte de aplicações numéricas.
> Muitos programas numéricos, por exemplo, simulação de ativos em bolsa de
> valores, conseguem facilmente superar 30 horas numa máquina. (eu já
> amarguei um exemplo desses).
>
> Aí os 10% se tornam importantes. Outro detalhe, ONDE são esses 10%? Se eu
> bem me lembro, a perda de desempenho fica no fato de int agora ter precisão
> maior.
>
> Se o seu programa NUMÉRICO só usa float, não tem problema.
>
> Se você tenta deixar tudo em int para aumentar a velocidade (evitar ponto
> flutuante), ferrou!

Oi Tiago

Se você vai fazer um porgrama que faz muita conta, e o tempo de execução
conta, para fazer em python, você __deve__ utilizar os módulos de computação
cientifica apropriados - por exemplo, o NumPY e mais algum módulo sdo SciP
que sirva.

Esses mődulos são bastante otimiazdos, e usam números nativos da arquitetura
(e não objetos python) em seus cálculos -  o ganho de velocidade deve ser de
pelo menos duas ordens de grandeza.

Eu não sei qual é o status do numpy para o python 3.0 - ams certametne o
desempenho do interpretador principal não é correlacionado diretamente com o
desempenho das rotinas numéricas do NumPY.

Só peço a devia atençaõ ao "__deve__"  ali: issso é sério: se performance do
código, e tarta-0se de código computacionalemtne intenso, é uma questão para
o seu programa, você tem memso que usar módulos que façam os cálculos tirando
vantagem do hardware nativo, ou não usar python (e sim, alguma linguagem que
faça efetivamente as contas usando tipos numéricos nativos).

Ou seja: para esses casos que você cita, esse 10% de performance não faz  am
neor diferença mesmo. E sim, você está certo ao dizer que esse caso é
justamente onde os 10% de tempo de execução a mais seria algo significativo.

(Se você tem uma aplicação servidora web, onde no tempo de requisição por
página de 10% a mais faz diferença: ai sim é hora de otimizar a aplicação, e
ver oq ue pode ser cacheado comoc onteúdo estático, e pensar em upgrade de
hardware)

        js
        -><-

> My 2 cents,
>                  Tiago
>


Reply | Threaded
Open this post in threaded view
|

Re: Re: Lançado Python 3.0 :^)

Tiago Fassoni A. A. Leite
2008/12/6 Joao S. O. Bueno <[hidden email]>

> On Saturday 06 December 2008, Tiago Fassoni A. A. Leite wrote:
> > Sim, eu cortei (boa) parte da mensagem e deixei só a parte mais relevante
> > para o tópico que vou falar.
> >
> > 2008/12/5 Luciano Ramalho <[hidden email]>
> >
> > > Mas até independente da Lei de Moore, na minha experiência
> > > profissional sempre foi muito raro algum cliente reclamar que o
> > > software estava lento; 99% do tempo eles reclamam que o custo é muito
> > > alto ou que o prazo de desenvolvimento é longo demais. Então, ao menos
> > > na minha experiência profissional, a aposta que Python faz na
> > > produtividade do desenvolvedor está alinhada com as necessidades dos
> > > clientes.
> >
> > Os 10% de performance são um problema na parte de aplicações numéricas.
> > Muitos programas numéricos, por exemplo, simulação de ativos em bolsa de
> > valores, conseguem facilmente superar 30 horas numa máquina. (eu já
> > amarguei um exemplo desses).
> >
> > Aí os 10% se tornam importantes. Outro detalhe, ONDE são esses 10%? Se eu
> > bem me lembro, a perda de desempenho fica no fato de int agora ter
> precisão
> > maior.
> >
> > Se o seu programa NUMÉRICO só usa float, não tem problema.
> >
> > Se você tenta deixar tudo em int para aumentar a velocidade (evitar ponto
> > flutuante), ferrou!
>
Oi Tiago

>
> Se você vai fazer um porgrama que faz muita conta, e o tempo de execução
> conta, para fazer em python, você __deve__ utilizar os módulos de
> computação
> cientifica apropriados - por exemplo, o NumPY e mais algum módulo sdo SciP
> que sirva.
>
> Esses mődulos são bastante otimiazdos, e usam números nativos da
> arquitetura
> (e não objetos python) em seus cálculos -  o ganho de velocidade deve ser
> de
> pelo menos duas ordens de grandeza.
>
> Eu não sei qual é o status do numpy para o python 3.0 - ams certametne o
> desempenho do interpretador principal não é correlacionado diretamente com
> o
> desempenho das rotinas numéricas do NumPY.
>
> Só peço a devia atençaõ ao "__deve__"  ali: issso é sério: se performance
> do
> código, e tarta-0se de código computacionalemtne intenso, é uma questão
> para
> o seu programa, você tem memso que usar módulos que façam os cálculos
> tirando
> vantagem do hardware nativo, ou não usar python (e sim, alguma linguagem
> que
> faça efetivamente as contas usando tipos numéricos nativos).
>
> Ou seja: para esses casos que você cita, esse 10% de performance não faz
>  am
> neor diferença mesmo. E sim, você está certo ao dizer que esse caso é
> justamente onde os 10% de tempo de execução a mais seria algo
> significativo.
>
> (Se você tem uma aplicação servidora web, onde no tempo de requisição por
> página de 10% a mais faz diferença: ai sim é hora de otimizar a aplicação,
> e
> ver oq ue pode ser cacheado comoc onteúdo estático, e pensar em upgrade de
> hardware)
>
>        js
>        -><-
>
> > My 2 cents,
> >                  Tiago
> >
>

Olha, perdão,  o que eu falei foi uma resposta para "os 10% nunca importam".
Era mais para falar acerca da fala de "10% não é problema porque o cliente
não reclama" e responder com um exemplo em que os 10% importam.

E eu não tinha outro exemplo à mente para falar na hora, desculpem...

E sim, eu uso o NumPy. Mesmo assim, obrigado pelas dicas. Legal saber que
existe um pessoal que te dá (e praticamente grita) dicas para você mesmo
quando voce não as pede. Isso pode parecer uma ofensa, mas não é. E sério,
isso é MUITO útil.

Obrigado!


[As partes desta mensagem que não continham texto foram removidas]

12