[Rio-pm] Multi threads

Segunda Março 12 14:52:28 PDT 2012

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