[Rio-pm] Multi threads

Stanislaw Pusep creaktive em gmail.com
Segunda Março 12 06:13:22 PDT 2012


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


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