Porque é que o python tem poucos utilizadores?

[falco]

Na altura era raro haver, mas existia. Existiam bastantes PCs com mais de 1 núcleo de processamento (fosse com 1+1, 2, 2+2, 1+1+1+1, wtv), não acessíveis ao público em geral é verdade, por isso se se queria um número maior de potenciais utilizadores (ou tinha 2 dedos de testa), pensava "hey, um dia n-cores vão ficar acessível ao público em geral, é importante estar preparado para isso!".

Não creio que isso fosse assim tão previsível de acontecer pelo menos à velocidade que aconteceu. Agora que já aconteceu é fácil afirmar que sim, mas na altura a coisas era diferente. A questão dos cores não estava na cabeça de ninguém há mais de uma década, quando haviam coisas muito mais importantes para fazer.

[Triton]

Mesmo assim, o Python lançou agora o 3.0, era a altura ideal para fazer uma alteração ao funcionamento das entranhas.

[djthyrax]

Não creio que isso fosse assim tão previsível de acontecer pelo menos à velocidade que aconteceu. Agora que já aconteceu é fácil afirmar que sim, mas na altura a coisas era diferente. A questão dos cores não estava na cabeça de ninguém há mais de uma década, quando haviam coisas muito mais importantes para fazer.

Certo. Então e nos últimos 5-6 anos ninguém se lembrou da questão? Ou lembraram mas o GvR cagou d'alto?

[Tharis]

Referes a um patch amador que nem sequer faz parte do repositório do CPython? Acho que serve de exemplo fantástico...

Não Betovsky, não falo de um patch amador. É que eu não entendo a vossa escala para medir a credibilidade/qualidade dos pessoas/produtos. Eu falei da patch de um senhor chamado Greg Stein. E caso não saibas, e tenho o maior gosto em informar-te, este senhor, é um director da Apache Software Foundation. Se (ainda) achas (e reforço o "se") que isso não significa muito, ele é membro da Python Software Foundation, tendo chegado a ser director de 2001 a 2002, tendo sido um "maintainer" da implementação CPython. Posto isto, podemos tirar duas conclusões:

- ou ele é um nabo do carago, é um programador da treta e enganou todas as empresas onde trabalhou, os milhares de pessoas que ouviram as suas palestras e o camandro;

- ou então é uma pessoa que percebe (percebia?) da implementação CPython e que o seu trabalho não foi um Hello World feito assim às 3 pancadas.

Para responder-te à parte dos repositórios... Será que existe a necessidade de colocar algo que não funciona (devidamente) neles?

Ao invés de agora, que em dual core corre MUITO MAIS LENTO que num core.

Epá, mas é necessário eu estar a repetir-me? É MUITO MAIS LENTO em dois cores, porque se existem duas realidades (e para ser mais fácil, deixa-me pôr isto matematicamente, onde t é o runtime):

Without GIL: Single Core corre em 2*t e em Dual Core corre em t
With GIL: Single Core corre em t e em Dual Core corre em 2*t

Ora bem, qual das duas escolher?

Sem o GIL, o DUAL CORE corre no mesmo tempo que o SINGLE CORE com GIL. Então se com menos um CORE podemos ter a mesma performance, é óbvio que se deve escolher a melhor relação performance/cores. Mas espera... Com o GIL, o DUAL CORE corre no DOBRO (ou mais) do tempo que o SINGLE CORE...

GIL 1 - 1 NoGIL

A solução está que com DUAL CORE, nós podemos utilizar apenas um CORE e ter a performance normal com GIL, mas se tivermos apenas UM CORE (como ainda existe muita gente que tem, inclusive eu até há pouco tempo) não podemos ter a performance t sem GIL, porque sem GIL, só os DUAL CORE têm performance normal.

Sim, de facto ter as threads a correr só sobre 1 core quando tem-se mais não traz vantagem nenhuma....

Hmm... Para as pessoas que querem pôr os seus ALL-MIGHTY MULTI-GOOGOL-CORES a funcionar, o GvR deu uma solução que é usar processos...

Só dei exemplo dessas duas porque tem uma data de nascimento muito similar. Mas podes usar outra linguagem qualquer. Perl por exemplo. Se o factor utilização tens Java por exemplo.

Não percebi.

Mesmo assim, o Python lançou agora o 3.0, era a altura ideal para fazer uma alteração ao funcionamento das entranhas.

O GvR é o que manda... E se fores ler os objectivos do Py3k, não fala em GILs nem outras coisas, ele delineou (em conjunto com o resto da equipa de developers) que o Py3k teria outros objectivos...

Certo. Então e nos últimos 5-6 anos ninguém se lembrou da questão? Ou lembraram mas o GvR cagou d'alto?

Podia ter sido há 5-6, 10 anos. Se não existe uma BOA solução para o problema, o que se pode fazer?

[Betovsky]

Não Betovsky, não falo de um patch amador. É que eu não entendo a vossa escala para medir a credibilidade/qualidade dos pessoas/produtos. Eu falei da patch de um senhor chamado Greg Stein. E caso não saibas, e tenho o maior gosto em informar-te, este senhor, é um director da Apache Software Foundation. Se (ainda) achas (e reforço o "se") que isso não significa muito, ele é membro da Python Software Foundation, tendo chegado a ser director de 2001 a 2002, tendo sido um "maintainer" da implementação CPython. Posto isto, podemos tirar duas conclusões:

Então podias ter dito logo não? Não faço a mínima ideia do que esse gajo fez, quando falaste de um patch pensei que estavas a referir a uma experiência de um gajo qualquer na net à cerca de 1 ou 2 anos atrás, que tinha sido alto falhanço. Infelizmente não estou a par desse gajo, portanto não posso comentar nas habilidades dele. Mas só por ser director do Apache significa alguma coisa? Director exige qualidades diferentes de programador. Dei uma vista de olhos rápida e não encontrei nada relevante, uma extensão do HTTP e esteve presente no inicio do subversion. Pelas áreas que trabalhou nada é no âmbito do GIL. Portanto não dá para averiguar se é competente ou não para efectuar tal tarefa.

- ou ele é um nabo do carago, é um programador da treta e enganou todas as empresas onde trabalhou, os milhares de pessoas que ouviram as suas palestras e o camandro;

Pois, não sei. Se calhar como programador é mesmo nabo. Nas empresas pelo que estive a ver ele não trabalhou como programador...

- ou então é uma pessoa que percebe (percebia?) da implementação CPython e que o seu trabalho não foi um Hello World feito assim às 3 pancadas.

Até podia perceber de CPython, o que demonstra é que não percebia muito de schedulling e concorrência.

Para responder-te à parte dos repositórios... Será que existe a necessidade de colocar algo que não funciona (devidamente) neles?

Obviamente que não. Mas se foi feito alguma coisa que nem sequer consta nos repositórios das duas uma. Ou foi só para a experiência, tipo algo na brinca. Ou então é um trabalho tão mau que nem sequer tinha hipótese de entrar no repositório pela falta de qualidade...

Epá, mas é necessário eu estar a repetir-me? É MUITO MAIS LENTO em dois cores, porque se existem duas realidades (e para ser mais fácil, deixa-me pôr isto matematicamente, onde t é o runtime):

Without GIL: Single Core corre em 2*t e em Dual Core corre em t
With GIL: Single Core corre em t e em Dual Core corre em 2*t

Ora bem, qual das duas escolher?

Sem o GIL, o DUAL CORE corre no mesmo tempo que o SINGLE CORE com GIL. Então se com menos um CORE podemos ter a mesma performance, é óbvio que se deve escolher a melhor relação performance/cores. Mas espera... Com o GIL, o DUAL CORE corre no DOBRO (ou mais) do tempo que o SINGLE CORE...

GIL 1 - 1 NoGIL

A solução está que com DUAL CORE, nós podemos utilizar apenas um CORE e ter a performance normal com GIL, mas se tivermos apenas UM CORE (como ainda existe muita gente que tem, inclusive eu até há pouco tempo) não podemos ter a performance t sem GIL, porque sem GIL, só os DUAL CORE têm performance normal.

Mas tu és cruomo ou fazes de propósito. A tua comparação até deita a perder o GIL, e como seria com 4 cores? E com 8?
E depois estás a fazer uma comparação errada, estás a comparar uma má implementação com outra má implementação. Algo em condições teria uma performance similar à actual em 1 core, provavelmente 1/3 mais rápida em 2 cores, 2/3 mais rápido em 4 cores e por ai fora...

Hmm... Para as pessoas que querem pôr os seus ALL-MIGHTY MULTI-GOOGOL-CORES a funcionar, o GvR deu uma solução que é usar processos...

Isso é como se alguém queixar que uma linguagem não suporta funções e então o outro gajo diz para fazer copy/paste que também funciona. Processos é a solução ideal para certo tipos de problemas, Threads é a solução ideal para outros.

Não percebi.

Eu tinha comparado com Haskell por terem idades similares. Tu discordaste e disseste que o mais importante era o factor de utilização. Então eu dei-te exemplo de outras 2 linguagens com mais ou menos a mesma idade mas também com elevado factor de utilização, Perl e Java.

Podia ter sido há 5-6, 10 anos. Se não existe uma BOA solução para o problema, o que se pode fazer?

 O problema é que já há uma BOA solução a décadas. Um excelente exemplo de que é possível ter um bom scheduller é Erlang que por sinal é mais antigo que Python. O problema é que não há uma BOA IMPLEMENTAÇÃO no CPython.

[djthyrax]

Vou-me embora para fazer o exame de FQ, mas quando voltar respondo a isso tudo Tharis. Mas antes de me ir embora Tharis, com o GIL, a execução em 1 core é xt+y (onde t é tempo de execução de uma thread, x o número de threads e y o overhead causado pela mudança de threads), enquanto que em 2 cores continua a ser xt+y quando podia ser xt/c+y (sendo c o número de cores), não há qualquer processamento útil feito pelo 2o core (e a constante tentativa de adquirir o lock faz aumentar o y de uma maneira completamente astronómica). Em dois cores não corre em t+t mas sim t+y (o overhead é que aumenta, não vais executar tudo 2 vezes).

[falco]

Mesmo assim, o Python lançou agora o 3.0, era a altura ideal para fazer uma alteração ao funcionamento das entranhas.

Talvez, não estou o suficiente por dentro, para validar isso. Mas isso também não invalida a minha afirmação anterior.

quando falaste de um patch pensei que estavas a referir a uma experiência de um gajo qualquer na net à cerca de 1 ou 2 anos atrás, que tinha sido alto falhanço

Isso aconteceu, ou apenas especulaste que aconteceu?
É que se apenas especulaste, não ajudou nada na conversa, só adicionou confusão e mais valia teres feito uma questão directa e objectiva.

Mas se foi feito alguma coisa que nem sequer consta nos repositórios das duas uma. Ou foi só para a experiência, tipo algo na brinca. Ou então é um trabalho tão mau que nem sequer tinha hipótese de entrar no repositório pela falta de qualidade...

Ou então não são só duas hipóteses e há mais...
Como por exemplo o trabalho ter sido bom, mas não ter por diversas razões produzido um resultado aceitável.

Então eu dei-te exemplo de outras 2 linguagens com mais ou menos a mesma idade mas também com elevado factor de utilização, Perl e Java.

O multi-threading no Perl também não é propriamente grande coisa... Isto dito pelo próprio Damian Conway numa formação que tive com ele.

O problema é que já há uma BOA solução a décadas. Um excelente exemplo de que é possível ter um bom scheduller é Erlang que por sinal é mais antigo que Python. O problema é que não há uma BOA IMPLEMENTAÇÃO no CPython.

De que estás à espera então?

[Betovsky]

Isso aconteceu, ou apenas especulaste que aconteceu?
É que se apenas especulaste, não ajudou nada na conversa, só adicionou confusão e mais valia teres feito uma questão directa e objectiva.

A única especulação foi na tentativa de saber a que caso o Tharis se referia. O único caso de tentativa de remoção do GIL que eu tinha conhecimento foi esse de há 2 anos atrás +-. Não tinha conhecimento do caso que o Tharis referiu. Portanto, quando o Tharis o referiu, eu associei automaticamente ao único caso que tinha ouvido falar. Pensei que tinha sido bastante explicito nesse aspecto.

Ou então não são só duas hipóteses e há mais...
Como por exemplo o trabalho ter sido bom, mas não ter por diversas razões produzido um resultado aceitável.

É possível que haja mais hipóteses não contempladas por mim. Mas a que referis-te não me parece válida. Se houvesse limitações de terceiros ainda aceitava, mas não é esse o caso, se não produz um resultado aceitável então é porque não foi um bom trabalho.

O multi-threading no Perl também não é propriamente grande coisa... Isto dito pelo próprio Damian Conway numa formação que tive com ele.

Que eu tenha conhecimento, o tempo de execução não aumenta exponencialmente conforme se vai adicionado cores.

De que estás à espera então?

LOL. Como deves saber, mais rapidamente punha-me a melhorar o GHC que o CPython

[falco]

Que eu tenha conhecimento, o tempo de execução não aumenta exponencialmente conforme se vai adicionado cores.

Os problemas são outros...

[fnds]

Os problemas são outros...

Quais?

[falco]

Por exemplo há problemas por os sistemas operativos comportarem-se de formas diferentes... Já não me lembro de detalhes... Mas o principais problemas têm a ver com a forma diferente como o window$ ser comporta. Alguns dos outros problemas foram resolvidos no 5.8...

[djthyrax]

Por exemplo há problemas por os sistemas operativos comportarem-se de formas diferentes... Já não me lembro de detalhes... Mas o principais problemas têm a ver com a forma diferente como o window$ ser comporta. Alguns dos outros problemas foram resolvidos no 5.8...

Repara no que disseste: alguns dos problemas foram resolvidos no 5.8. Mas no Python, alguma vez isso aconteceu em não sei quantos anos? O que se está a criticar aqui não é o facto de haver problemas, mas sim a inércia que existem em relação ao resolvê-los.

[falco]

Eu também não estou a defender o que quer que seja a esse respeito, abstenho-me dessa discussão, por não conhecer os factos.