Eu não disse que o compilador fica mais lento, eu disse que compilar Perl
com suporte a threads deixa tudo mais lento. 'Alguns processos em XS rodando
mais rápido' não resolve o meu problema...
Cheers!
2011/10/9 Daniel de Oliveira Mantovani daniel.oliveira.mantov...@gmail.com
2011/10/9 Andre
2011/10/9 Andre Carneiro andregarciacarne...@gmail.com
O meu problema com threads é memória. Usa-se muita memória trabalhando com
threads. E recentemente tive problemas sérios de vazamento de memória, e tem
90% de chance de ser nas threads, embora isso não seja conclusivo. Eu estou
sabendo
Se não me engano cada thread do perl usa 10 MB de memória no linux e 16MB no
windows, se o problema for a quantidade de memória de cada thread e se tua
thread não precisa de muita memória, tu pode modificar o tamanho da stack:
1. use http://perldoc.perl.org/functions/use.html threads
2011/10/9 Daniel de Oliveira Mantovani daniel.oliveira.mantov...@gmail.com:
André, threads não deixa o compilador do Perl em si mais lento, a diferença
é que o compilador de C vai demorar um pouco mais para construir um código
Perl compilado com threads, porque o código é mais complexo. Alguns
Lembrando também que Threads em Perl, assim como em qualquer linguagem
interpretada, sofrem do mal do GIL -
http://en.wikipedia.org/wiki/Global_Interpreter_Lock
O que, na minha opnião, só reforça o uso de Fork para programação paralela
com linguagens interpretadas, acho que atende 95% dos casos.
2011/10/9 Lindolfo Lorn Rodrigues l...@lornlab.org
Lembrando também que Threads em Perl, assim como em qualquer linguagem
interpretada, sofrem do mal do GIL -
http://en.wikipedia.org/wiki/Global_Interpreter_Lock
O que, na minha opnião, só reforça o uso de Fork para programação paralela
com
2011/10/9 Tiago Peczenyj tiago.pecze...@gmail.com
2011/10/9 Lindolfo Lorn Rodrigues l...@lornlab.org
Lembrando também que Threads em Perl, assim como em qualquer linguagem
interpretada, sofrem do mal do GIL -
http://en.wikipedia.org/wiki/Global_Interpreter_Lock
O que, na minha opnião, só
2011/10/9 Daniel de Oliveira Mantovani daniel.oliveira.mantov...@gmail.com
2011/10/9 Tiago Peczenyj tiago.pecze...@gmail.com
AnyEvent, POE, etc
Achei que fosse algum exclusivo para IO. como o NIO para o java.
--
http://noticiasglobal.com
If you’ve never written anything
2011/10/9 Tiago Peczenyj tiago.pecze...@gmail.com
2011/10/9 Daniel de Oliveira Mantovani
daniel.oliveira.mantov...@gmail.com
2011/10/9 Tiago Peczenyj tiago.pecze...@gmail.com
AnyEvent, POE, etc
Achei que fosse algum exclusivo para IO. como o NIO para o java.
Ah, tipo
To: saopaulo...@mail.pm.org
Subject: Re: [SP-pm] Software livre em Perl
X-BeenThere: saopaulo-pm@pm.org
X-Mailman-Version: 2.1.14
Precedence: list
Reply-To: saopaulo...@mail.pm.org
List-Id: The Sao Paulo Perl Mongers List saopaulo-pm.pm.org
List-Unsubscribe: http://mail.pm.org/mailman/options
+c1pTK08RGf6YcJ8q8uSDM9YBUM=fy...@mail.gmail.com
Date: Fri, 7 Oct 2011 08:19:59 -0300
Message-ID:
cabou2p0t30ugapvuyqfjerazw9z0ej-a7un237tofdhyxbw...@mail.gmail.com
From: Andre Carneiro andregarciacarne...@gmail.com
To: saopaulo...@mail.pm.org
Subject: Re: [SP-pm] Software livre em Perl
X-BeenThere
Não, Mantovani.
Quase tudo! Se você precisar compartilhar variáveis, terá problemas!
Cheers!
2011/10/6 Daniel de Oliveira Mantovani daniel.oliveira.mantov...@gmail.com
Só mais uma coisa,
6º Se fosse *eu* abstrairia tudo o que você usou threads com Any::Event, as
pessoas geralmente não tem
Pelo que eu entendi o Mantovani estava generalizando o problema de
paralelizar coisas, substituindo threads pelo AnyEvent. Eu só lembrei que
compartilhar variáveis com o AnyEvent exige mais esforço do que com
threads(até onde eu sei). Nesse caso eu estava sim me referindo ao fork_call
do
2011/10/6 Andre Carneiro andregarciacarne...@gmail.com:
Pelo que eu entendi o Mantovani estava generalizando o problema de
paralelizar coisas, substituindo threads pelo AnyEvent. Eu só lembrei que
compartilhar variáveis com o AnyEvent exige mais esforço do que com
threads(até onde eu sei).
Olá pessoal,
Em junho deste ano criei o meu primeiro projeto de software livre
(Uniscan), o Uniscan é um scanner de vulnerabilidades multi-threaded escrito
em Perl para ser executado a partir do linux(não testei em outras
plataformas).
Estou enviando este e-mail para que vocês possam conhecer,
On Wed, Oct 05, 2011 at 11:04:37AM -0300, Douglas Poerschke Rocha wrote:
Ola pessoal,
Em junho deste ano criei o meu primeiro projeto de software livre
(Uniscan), o Uniscan e um scanner de vulnerabilidades multi-threaded
escrito em Perl para ser executado a partir do linux(nao
Fala, poerschke! Você por aqui hahahah.
O projeto evoluiu muito desde que comentei sobre ele lá no forum-invaders.
Parabéns! :-)
Coloca no github pra galera poder forkar.
Mais uma vez, parabéns. Evoluiu muito mesmo desde a última vez que o vi!
[]'s
Em 5 de outubro de 2011 11:02, Thiago Rondon
Parabéns \o!
Li o seu código fonte e tenho algumas dicas essenciais para o seu software,
1º Não use expressões regulares para lidar com o html.
https://metacpan.org/module/HTML::TreeBuilder::XPath
Você pode reescrever todo o seu Uniscan::Crawler usando 90% do código que
você usou. ;)
2º Use o
s/bani/bati/;
2011/10/6 Daniel de Oliveira Mantovani daniel.oliveira.mantov...@gmail.com
Parabéns \o!
Li o seu código fonte e tenho algumas dicas essenciais para o seu software,
1º Não use expressões regulares para lidar com o html.
https://metacpan.org/module/HTML::TreeBuilder::XPath
Só mais uma coisa,
6º Se fosse *eu* abstrairia tudo o que você usou threads com Any::Event, as
pessoas geralmente não tem o compilador com a opção de threads porque deixa
o compilador mais lento[1] :S. Com Any::Event você faria o que você fez mais
sem usar threads, o Any::Event se viraria. Olha
20 matches
Mail list logo
