Em 20/3/2011 19:14, Cleyton Agapito escreveu: > Em 20 de março de 2011 13:57, Paulo Henrique BSD Brasil > <[email protected]> escreveu: >> Em 20/3/2011 10:59, Cleyton Agapito escreveu: >>> Em 20 de março de 2011 04:31, Paulo Henrique BSD Brasil >>> <[email protected]> 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... ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
