[Rio-pm] Multi threads

thiagoglauco em ticursos.net thiagoglauco em ticursos.net
Terça Março 13 10:51:27 PDT 2012 

Realmente nao tive problemas de desempenho do Perl no Windows (nem  
quando busco dados em planilhas loucas do excel).

Citando Aureliano Guedes <guedes_1000 em hotmail.com>:

>
> Windows deve ser evitado a todo custo... hahaha... não me lembro  
> onde, mas ja li sobre o desempenho de Perl no Windows
> e chega a ser ate 10x menor.
>
> From: creaktive em gmail.com
> Date: Mon, 12 Mar 2012 17:58:41 -0300
> To: rio-pm em pm.org
> Subject: Re: [Rio-pm] Multi threads
>
> 0) Forks usam cores distintos e os processos não se comunicam  
> diretamente;1) Pthreads usam cores distintos e os processos se  
> comunicam diretamente (um porém: depois de um tempo, os hemisférios  
> do seu cérebro não se comunicarão diretamente);
>
>
> 2) ithreads são uma aberração e devem ser evitados a todo custo  
> (Perl em Windows emula fork via ithreads, consequentemente,  
> Perl2Windows deve ser evitado a todo custo);3) Coro(utines) é uma  
> gambiarra nervosíssima que serve para espremer até o último ciclo de  
> uma única CPU por processo (lembra um pouco a operação do  
> Terminate-Stay-Resident do DOS? se não lembra, sorte a sua);
>
> 4) Eventos servem em primeiro lugar para multiplexar I/O,  
> essencialmente, é um "while (1) { if ($this) { ... } elsif ($that) {  
> ...} }" que tem dó da CPU.
> Quase a mesma coisa, descrita de forma mais objetiva:  
> http://d.hatena.ne.jp/tokuhirom/20090630/1246324092
>
>
> ABS()
>
>
>
>
> On Mon, Mar 12, 2012 at 17:36, Tiago Peczenyj  
> <tiago.peczenyj em gmail.com> wrote:
>
>
> Ola
> Entre threads, forks e eventos até hoje eu não tenho muita  
> experiência em Perl. Eu lembro que threads possuem alguns problemas  
> devido ao Global Interpreter Lock. Agora eu consigo utilizar mais de  
> um core de CPU com um processo perl?
>
>
>
>
> Eu tenho a tendência de pensar em Eventos, mesmo sabendo que não são  
> para o mesmo propósito.
> Att
> Tiago
>
>
>
> On Mon, Mar 12, 2012 at 10:13 AM, Stanislaw Pusep  
> <creaktive em gmail.com> wrote:
>
>
> Mas será que depende tanto assim de CPU? ;)Veja essa tabela (aliás,  
> o artigo em si é excelente): http://norvig.com/21-days.html#answers
>
>
>
> Daí deduzimos que, desprezando todo o tipo de atrito, enquanto *UM*  
> pacote ICMP está a caminho, uma CPU mequetrefe executará *150  
> MILHÕES* de instruções. Todavia, o que eu tenho certeza absoluta é  
> que o overhead de gerenciar processos/threads "paralelos" tenderá a  
> ocupar a CPU inteiramente :(
>
>
>
>
>
> Todavia, não há a menor necessidade de gerenciar processos/threads,  
> ao menos, nesse caso! Muitas pessoas empregam threads apenas para  
> contornar o "blocking" das operações de I/O. Outra forma é  
> simplesmente... desabilitar o "blocking".
>
>
>
>
>
>
> ABS()
>
>
>
>
> On Mon, Mar 12, 2012 at 09:54, Aureliano Guedes  
> <guedes_1000 em hotmail.com> wrote:
>
>
>
>
>
>
>
>
>
>
> Hoje em dia os moldens mais simples pode bloquear ping por defaut,  
> contudo no trecho citado vc falou de 2GHz.
>
> Testa um i7 e usando GPU com uma placa de video poderosa, levando  
> uma internet de 15MB/s (a minha é so 10MB/p).
>
>
>
>
>
>
>
> Facilitaria bastante, não?
>
> No meu caso, como sou programador por esporte, e me interesso pela  
> parte de segurança digital, quero aprender intimamente
> a parte "underground", para isso tenho uma rede configurada onde um  
> Windows 95 esta me esperando pra brincar com ele.
>
>
>
>
>
>
> From: creaktive em gmail.com
> Date: Mon, 12 Mar 2012 09:42:52 -0300
> To: rio-pm em pm.org
>
>
>
>
>
>
> Subject: Re: [Rio-pm] Multi threads
>
> Da documentação do AnyEvent::FastPing:
> "Performance: On my 2 GHz Opteron system with a pretty average  
> nvidia gigabit network card I can ping around 60k to 200k addresses  
> per second, depending on routing decisions"
>
>
>
>
>
>
>
>
> Tentar isso com threads certamente vai derrubar o host... O SEU :P
> ABS()
>
>
>
>
> On Mon, Mar 12, 2012 at 09:01, Vinícius Miasato  
> <viniciusmiasato em gmail.com> wrote:
>
>
>
>
>
>
>
>
>> Ainda dá pra derrubar servidor com ping hoje
>
>> em dia?
>
>
>
> dependendo do servidor, sim, mas creio que são raridades hoje em dia,
>
>
>
>> Tem uma coisa que a maioria ignora sobre threads, que é o fato de elas
>
>> serem utilizadas para rodar código em paralelo quando o processador
>
>> está *ocioso*.
>
>
>
> não necessariamente. não se usa threads para rodar código somente pelo
>
> processador estar ocioso. threads geralmente são utilizadas para
>
> executar tarefas distintas pois quando uma thread entrar em um estado
>
> bloqueante, as demais ainda podem entrar em execução, porém isso
>
> também não é regra.
>
>
>
>> Fique esperto também com a afinidade. Não necessariamente quatro
>
>> threads rodando em um processador com quatro núcleos vão rodar cada
>
>> uma em um núcleo. Eventualmente, você pode criar N threads que rodem
>
>> em apenas um dos núcleos, e aí você se lascou.
>
>
>
> com uma boa programação e se o SO permitir, você pode escolher em qual
>
> núcleo cada processo executa =D
>
>
>
> abs.
>
> Japa
>
>
>
> Em 12 de março de 2012 00:38, Blabos de Blebe <blabos em gmail.com> escreveu:
>
>>> Bem, agora exclareceu mais o assunto na minha cabeça, contudo me deixou com
>
>>> mais medo de usar threads... hahaha.
>
>>
>
>> Se você tem medo de usar threads, então você não está pronto pra  
>> usar threads.
>
>>
>
>>> Bem, esquecendo o assunto de redes, o que eu pretendo fazer é pingar um
>
>>> servidor, contudo inves de usar 4 bot para
>
>>> enviar 4 pings simultaneos eu quero usar uma unica maquina para  
>>> enviar esses
>
>>> 4 pings. Mas é so uma questão de estudo
>
>>> nada de underground.
>
>>
>
>> Estudo, sei...
>
>>
>
>> Bem, uma rede bem configurada vai solenemente cagar pro seus pings,
>
>> então vou supor que você está estudando como configurar redes de forma
>
>> a evitar um DoD por ping. Ainda dá pra derrubar servidor com ping hoje
>
>> em dia?
>
>>
>
>>> Exemplos que achei na internet não davam muita mobilidade de escolher o
>
>>> numero de threads e tals.
>
>>
>
>> Exemplos de threads que você (você, um sujeito genérico, ok)
>
>> normalmente são porcaria. O que você precisa é ler com atenção o livro
>
>> de SO do tio Tanenbaum http://www.pearsonhighered.com/tanenbaum.
>
>>
>
>> ...
>
>>
>
>> Tem uma coisa que a maioria ignora sobre threads, que é o fato de elas
>
>> serem utilizadas para rodar código em paralelo quando o processador
>
>> está *ocioso*.
>
>>
>
>> Lembre-se sempre que há um custo para o SO fazer a troca de contexto e
>
>> se o seu código for CPU bound, fazer o processador ficar chaveando
>
>> contexto quando ele deveria estar processando, é perda de tempo.
>
>>
>
>> Threads são melhores utilizadas para executar tarefas enquanto alguma
>
>> parte do código está esperando I/O. Por exemplo, interface gráfica,
>
>> que fica fica esperando o usuário interagir, ou ainda código que faz
>
>> I/O, como o seu caso.
>
>>
>
>> Fique esperto também com a afinidade. Não necessariamente quatro
>
>> threads rodando em um processador com quatro núcleos vão rodar cada
>
>> uma em um núcleo. Eventualmente, você pode criar N threads que rodem
>
>> em apenas um dos núcleos, e aí você se lascou.
>
>>
>
>>
>
>> []'s
>
>>
>
>>
>
>>
>
>>
>
>>
>
>> 2012/3/11 Aureliano Guedes <guedes_1000 em hotmail.com>:
>
>>> Bem, agora exclareceu mais o assunto na minha cabeça, contudo me deixou com
>
>>> mais medo de usar threads... hahaha.
>
>>>
>
>>> Bem, esquecendo o assunto de redes, o que eu pretendo fazer é pingar um
>
>>> servidor, contudo inves de usar 4 bot para
>
>>> enviar 4 pings simultaneos eu quero usar uma unica maquina para  
>>> enviar esses
>
>>> 4 pings. Mas é so uma questão de estudo
>
>>> nada de underground.
>
>>>
>
>>> Exemplos que achei na internet não davam muita mobilidade de escolher o
>
>>> numero de threads e tals.
>
>>>
>
>>> Mas valeu, monges, me ajudou muito mesmo.
>
>>>
>
>>>> Date: Sun, 11 Mar 2012 22:58:20 -0300
>
>>>> From: viniciusmiasato em gmail.com
>
>>>
>
>>>> To: rio-pm em pm.org
>
>>>> Subject: Re: [Rio-pm] Multi threads
>
>>>>
>
>>>> só para não ficar confuso demais, a variável $pool_thr[ $i ] não
>
>>>> recebe o retorno das threads. ela serve como uma forma de controle das
>
>>>> threads, para efetuar join, detach ou executar outros métodos
>
>>>> fornecidos,
>
>>>>
>
>>>> o link para a documentação mais detalhada estpa abaixo:
>
>>>> http://perldoc.perl.org/threads.html
>
>>>>
>
>>>> abs.
>
>>>> Japa
>
>>>>
>
>>>> Em 11 de março de 2012 22:53, Vinícius Miasato
>
>>>> <viniciusmiasato em gmail.com> escreveu:
>
>>>> > olá Aureliano,
>
>>>> >
>
>>>> > parece que você está confundindo um pouco o conceito de threads.
>
>>>> > quando uma thread é criada ela executa em paralelo ( assumindo que sua
>
>>>> > máquina possui vários nucleos e seu SO dá suporte à multi-threads ).
>
>>>> >
>
>>>> > o código que você citou espera a rotina terminar antes de iniciar uma
>
>>>> > nova iteração do loop, já com threads, o loop continua mesmo sem a
>
>>>> > thread retornar, caso a tarefa seja grande o suficiente,
>
>>>> >
>
>>>> > o que o Buss falou está certo, então venho tentar adicionar algo à mais,
>
>>>> >
>
>>>> > como você não menciona nada sobre controle de threads, talvez você não
>
>>>> > precise manter o controle das threads ao cria-las, então você pode
>
>>>> > efetuar um detach nelas, o que significa descartar qualquer retorno da
>
>>>> > thread em questão. após um detach, a thread não poderá mais ser
>
>>>> > controlada.
>
>>>> >
>
>>>> > caso queira esperar um thread específica retornar antes de criar as
>
>>>> > outras você  pode efetuar um join para aguardar o término da mesma,
>
>>>> >
>
>>>> > seria algo como:
>
>>>> >
>
>>>> > my $thr =  threads->create(\&sub1);
>
>>>> > $thr->detach; # não queremos saber sobre o retorno desta thread e
>
>>>> > liberamos ela
>
>>>> >
>
>>>> > ou
>
>>>> >
>
>>>> > my $thr2 =  threads->create(\&sub2);
>
>>>> > my $resposta = $thr->join; # o retorno da sub2 atribuído à variável
>
>>>> > escalar $resposta
>
>>>> >
>
>>>> > para o caso de você querer receber o resultado de cada thread criada,
>
>>>> > vale à ideía do Buss de criar um array no loop aonde as threads são
>
>>>> > criadas,
>
>>>> > ficando mais ou menos assim:
>
>>>> >
>
>>>> > my @pool_thr;
>
>>>> > for (my $i =1; $i = 5; $i++){
>
>>>> >    $pool_thr[ $i ] = threads->create(\&sub1);
>
>>>> > }
>
>>>> >
>
>>>> > sub sub1 {
>
>>>> > ....
>
>>>> > }
>
>>>> >
>
>>>> > quanto ao exemplo do servidor, mesmo com threads ou forks, enfim
>
>>>> > vários processos em paralelo, você ainda terá outro provável gargalo,
>
>>>> > que é a parte de rede,
>
>>>> >
>
>>>> > abs.
>
>>>> > Japa
>
>>>> >
>
>>>> > 2012/3/11 Aureliano Guedes <guedes_1000 em hotmail.com>:
>
>>>> >> Na verdade, eu acho que minha pergunta que foi feita de forma errada.
>
>>>> >> Eu queria, por exemplo, dar ping em um servidor ate derruba-lo, contudo
>
>>>> >> eu
>
>>>> >> queria para isso enviar digamos, 5 pacotes simultaneos,
>
>>>> >> inves de enviar 1 por vez.
>
>>>> >>
>
>>>> >> Mas eu entendi quanto a usar o laço, talvez eu realmente faça isso.
>
>>>> >> Contudo,
>
>>>> >> usar
>
>>>> >>
>
>>>> >> for (my $i =1; $i <= 5; $i++){
>
>>>> >> my $thr = threads->create(\&sub1);
>
>>>> >> }
>
>>>> >>
>
>>>> >> não é o mesmo que usar apenas
>
>>>> >>
>
>>>> >>
>
>>>> >> for (my $i =1; $i <= 5; $i++){
>
>>>> >> &sub1;
>
>>>> >> }
>
>>>> >>
>
>>>> >> se a função do meu sub1 for apenas enviar pacotes a um servidor???
>
>>>> >>
>
>>>> >> ________________________________
>
>>>> >> From: bruno.buss em gmail.com
>
>>>> >> Date: Sun, 11 Mar 2012 22:29:06 -0300
>
>>>> >>
>
>>>> >> To: rio-pm em pm.org
>
>>>> >> Subject: Re: [Rio-pm] Multi threads
>
>>>> >>
>
>>>> >> 2012/3/11 Aureliano Guedes <guedes_1000 em hotmail.com>
>
>>>> >>
>
>>>> >> Opa, Bruno, valeu a resposta, mas vamos ver se eu entendi
>
>>>> >>
>
>>>> >>  eu poderia fazer assim:
>
>>>> >>
>
>>>> >>     use threads;
>
>>>> >>
>
>>>> >>
>
>>>> >>     for (my $i =1; $i = 5; $i++){
>
>>>> >>     my $thr = threads->create(\&sub1);
>
>>>> >>
>
>>>> >>
>
>>>> >>     sub sub1 {
>
>>>> >>
>
>>>> >>     }
>
>>>> >> }
>
>>>> >>
>
>>>> >> Mas assim não ocorreria  execução simultanea, certo? Pois cada execução
>
>>>> >> iria
>
>>>> >> ocorrer uma por vez a cada contagem do contador.
>
>>>> >>
>
>>>> >>
>
>>>> >> A resposta para sua pergunta: errado.
>
>>>> >> Porém sua explicação está "correta"... a cada iteração do for, será
>
>>>> >> criada
>
>>>> >> uma nova thread, então você terá disparado diversas threads até o final
>
>>>> >> do
>
>>>> >> for.
>
>>>> >>
>
>>>> >> Agora, o ponto em ser simultâneo é um pouco mais complicado: depende de
>
>>>> >> quantos cores tem seu sistema (se tiver menos cores que threads
>
>>>> >> utilizadas,
>
>>>> >> então as threads estarão executando de forma concorrente e não
>
>>>> >> simultânea),
>
>>>> >> depende do escalonador de tarefas do seu sistema operacional, dependo
>
>>>> >> do que
>
>>>> >> a sua sub1 faz, etc.
>
>>>> >>
>
>>>> >> Mas acho que a sua dúvida é um pouco mais básica do que isso...
>
>>>> >>
>
>>>> >> Fazer:
>
>>>> >> for (my $i =1; $i <= 5; $i++){
>
>>>> >> [alguma coisa]
>
>>>> >> }
>
>>>> >>
>
>>>> >> é essencialmente igual a fazer [alguma coisa] 5 vezes (tirando o fato
>
>>>> >> que
>
>>>> >> você pode utilizar o parâmetro do for para fazer alterações):
>
>>>> >> [alguma coisa]
>
>>>> >> [alguma coisa]
>
>>>> >> [alguma coisa]
>
>>>> >> [alguma coisa]
>
>>>> >> [alguma coisa]
>
>>>> >>
>
>>>> >> No seu caso,
>
>>>> >> for (my $i =1; $i <= 5; $i++){
>
>>>> >> my $thr = threads->create(\&sub1);
>
>>>> >> }
>
>>>> >>
>
>>>> >> É igual a fazer:
>
>>>> >> my $thr = threads->create(\&sub1);
>
>>>> >> my $thr = threads->create(\&sub1);
>
>>>> >> my $thr = threads->create(\&sub1);
>
>>>> >> my $thr = threads->create(\&sub1);
>
>>>> >> my $thr = threads->create(\&sub1);
>
>>>> >>
>
>>>> >> Que é exatamente o que você queria, não? ;-)
>
>>>> >>
>
>>>> >> [ ]'s
>
>>>> >> --
>
>>>> >> Bruno C. Buss
>
>>>> >> http://brunobuss.wordpress.com/
>
>>>> >> http://www.dcc.ufrj.br/~brunobuss/
>
>>>> >>
>
>>>> >> _______________________________________________ Rio-pm mailing list
>
>>>> >> Rio-pm em pm.org http://mail.pm.org/mailman/listinfo/rio-pm
>
>>>> >>
>
>>>> >> _______________________________________________
>
>>>> >> Rio-pm mailing list
>
>>>> >> Rio-pm em pm.org
>
>>>> >> http://mail.pm.org/mailman/listinfo/rio-pm
>
>>>> _______________________________________________
>
>>>> Rio-pm mailing list
>
>>>> Rio-pm em pm.org
>
>>>> http://mail.pm.org/mailman/listinfo/rio-pm
>
>>>
>
>>> _______________________________________________
>
>>> Rio-pm mailing list
>
>>> Rio-pm em pm.org
>
>>> http://mail.pm.org/mailman/listinfo/rio-pm
>
>> _______________________________________________
>
>> Rio-pm mailing list
>
>> Rio-pm em pm.org
>
>> http://mail.pm.org/mailman/listinfo/rio-pm
>
> _______________________________________________
>
> Rio-pm mailing list
>
> Rio-pm em pm.org
>
> http://mail.pm.org/mailman/listinfo/rio-pm
>
>
>
>
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>
> _______________________________________________
>
> Rio-pm mailing list
>
> Rio-pm em pm.org
>
> http://mail.pm.org/mailman/listinfo/rio-pm
>
>
>
> _______________________________________________
>
> Rio-pm mailing list
>
> Rio-pm em pm.org
>
> http://mail.pm.org/mailman/listinfo/rio-pm
>
>
> --
>
>
> Tiago B. Peczenyj
> Linux User #405772
>
>
>
> http://pacman.blog.br
>
>
>
> _______________________________________________
>
> Rio-pm mailing list
>
> Rio-pm em pm.org
>
> http://mail.pm.org/mailman/listinfo/rio-pm
>
>
>
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm

Mais detalhes sobre a lista de discussão Rio-pm