[Rio-pm] Multi threads

Segunda Março 12 13:58:41 PDT 2012

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
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20120312/65d25132/attachment-0001.html>