[FUG-BR] Impacto de software single-thread nos atuais Sistemas multi-threads.

[Paulo Henrique BSD Brasil]

Em 20/3/2011 19:14, Cleyton Agapito escreveu:
> Em 20 de março de 2011 13:57, Paulo Henrique BSD Brasil
> <paulo.rddck em bsd.com.br>  escreveu:
>> Em 20/3/2011 10:59, Cleyton Agapito escreveu:
>>> Em 20 de março de 2011 04:31, Paulo Henrique BSD Brasil
>>> <paulo.rddck em bsd.com.br>    escreveu:
>>>> Saudações a todos da lista,
>>>> Recentemente passei a avaliar o real impacto na performance de um
>>>> sistema multi-thread quando apenas parte dos software executados no
>>>> mesmo são single-thread.
>>>> Contudo nas pesquisas que executei a documentação quanto a software
>>>> multi-thread em si é grande porem o software single-thread sobre
>>>> plataformas de OS multi-thread é quase inexistente.
>>>> Por acaso algum companheiro dispõem de informações, referencias quanto a
>>>> esse problema, se é que pode ser considerado um problema ?
>>>>
>>> Se servir um palpite, o "problema" fica apenas restrito ao programa
>>> que só pode fazer uma coisa de cada vez, tipo abre uma janela e o
>>> resto "congela". No SO não tem impacto já que ele troca o carinha de
>>> contexto e vai fazer outra coisa. Não sei se as threads recebem
>>> prioridade diferentes, mas caso recebam o problema continuarestrito ao
>>> software que vai acabar rodando mais devagar por receber menos atenção
>>> do SO.
>>>
>>> Agora, se o software estiver em área de núcleo "kernel", em sistemas
>>> monolíticos (na prática quase todos) aí sim tem impacto, enquanto o SO
>>> está nesta tarefa ele não faz mais nada (lags e congelamentos
>>> temporários).
>>>
>>> Se falei alguma bobagem por favor me corrijam, espero ter ajudado.
>>>
>>> []'s
>>> -------------------------
>>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>> Mais ainda assim tem um impacto de performance se o software
>> single-thread for parte de um dos software da solução onde todos os
>> demais softwares são multi-thread mais depende de tarefas dos software
>> single-thread, ou estou enganado, não haveria no caso um gargalo
>> originado nas tarefas de responsabilidade do software single-thread ?
>> Bibliotecas single-thread não atrapalha o desempenho dos software
>> multi-threads, ou são criado instâncias de execução distintas entre cada
>> thread do software multi-thread para lidar com as funções single-thread
>> da biblioteca ?
>>
> Até onde eu sei (e não é muito, diga-se de passagem) thread cria
> filhotes (forks) da -mesma tarefa- que vc está executando, em algum
> momento alguém vai ter que pegar as peças e juntar novamente, não tem
> milagre e não é trivial, na maior parte das vezes o conjunto deve
> aguardar a finalização de todos os pedaços (sincronização) para
> concluir a execução.
>
> Entre um processo e outro depende de como são tratadas as entradas e
> saídas, pode ser que um single vá gerando saída a medida que vai
> executando e um multi fique aguardando o sincronismo e não gere saída
> nenhuma, neste caso teríamos a sensação de que o primeiro roda mais
> depressa. Vai depender de cada caso.
>
> Na prática quem tira proveito das threads são sistemas com mais de um
> processador e clusters porque vc consegue dividir melhor as tarefas
> menores entre eles, sistemas monoprocessados (como o meu) tem um
> desempenho menor devido ao overhead que esse tratamento causa, não
> adianta dividir em tarefas menores se é sempre o mesmo processador que
> vai executar todas elas...
>
> Abração.
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
É Cleyton realmente quando se coloca sistemas monoprocessados a 
tendência de fato é igualar a perder desempenho, como acontece com os 
Pentium 4 HT, que acabam em muitas tarefas sendo mais lento ( compilação 
de kernel é uma delas ), mais em se tratando dos atuais sistemas que 
quase todos são multi-processados a tendência de melhora da performace 
tende a ser notável, por exemplo não sei muito quanto a BGP, mais o 
mesmo só vei a ganhar espaço entre maquinas x86 apos o processamento 
multi-thread, infelizmente não li como é escrito os principais daemon de 
roteamento BGP/OSPF, porem creio que o uso de multi-thread deles 
principalmente para pesquisas nas tabelas de rotas são inegavelmente 
necessárias para garantir uma velocidade constante em comutação de pacotes.
Outro fator que garante uma melhora consideravel de velocidade é 
soluções de virtualização, onde creio que a atual mudança de mercado 
para processamento paralelo se deu mais por essa necessidade de 
virtualização.
São alguns pontos de vistas que adquiri ao longo dos tempos e no caso 
estou empenhado em questiona-los para ter dados mais tecnicos para 
basear tais discussões...

Abraços e um ótima semana...