c0re dumped wrote: > Obrigado pelo bom material Patrick ! > > Só uma pergunta: o benchamrk qual você se referem em > http://www.2cpu.com/articles/42_1.html não foi feito somente em > windows, como ele se refere no final do artigo ?
Sem duvida, e cumpre o objetivo muito bem especialmente por testar processamento de conversao de video. A base do benchmark eh a comparacao no mesmo ambiente, mesmas aplicacoes. > O que sempre vejo em forums, como o bsdforums, é que recomenda-se o > não uso de HTT. Inclusive em sites como slashdot há notícias > interessantes em relação ao assunto, em sua maioria, informando a > queda de performance em sistemas (inclusive Windows) com HTT > habilitado: > > http://hardware.slashdot.org/article.pl?sid=05/11/19/1358218&from=rss Pois eh ai que cabe uma analise critica, veja que os comentarios dessa noticia, tem mais gente mencionando beneficios do que maleficios de usar HTT. Em varios ambientes a degradacao pode acontecer, mas nesses casos tem que ser muito bem observado, porque a causa em potencial pode nao ser o HTT, mas sim a aplicacao ou o perfil do servidor. A questao a ser levantada e': em casos onde a performance degrada, degrada apenas HTT? Nao teria o mesmo impacto usando duas CPU fisicas? No caso citado do PostgreSQL 7 por exemplo, teria. O melhor comentario dessa thread na Slashdot eh o que compara o gap de performance entre 2 CPU, dois nucleos e HTT: tudo depende, do que roda no servidor. Os gargalos do HTT sao cache e registradores, que sao os mesmos rodando como uma CPU ou duas. Se usando duas CPU logicas o gargalo de ter esses recursos compartilhados de forma logica chega a ser mais expressivo do que com apenas uma, (veja bem, o recurso eh o mesmo) provavelmente eh fato relacionado a como o sistema esta consumindo esses recursos, e ai a aplicacao tem que ser analisada. Por outro lado existe a possibilidade de ter de fato threads paralelas, e nao concorrentes, consumindo o poder total de processamento da maquina, e paralelismo VS concorrencia, nao tem como, de forma geral, concorrencia ser melhor, nao faz sentido neh? Ai que mora a vantagem do SMT. O SMT eh a forma mais barata, financeiramente, e mais pobre, tecnologicamente de conseguir o paralelismo, se compararmos com SMP fisico ou nucleos duplos. Mas consegue atingir o objetivo e torna o sistema nao exclusivamente dependente de multiplexacao, o que se nao resutar em ganho de performance eh porque o ambiente/aplicacao nao consegue tirar proveito suficiente (nao ser multithread) ou algo de incomum acontece que deve ser considerado com mais atencao, do que simplesmente desligar o SMT. > Há também uma entrevista muito interessante com o Frederico Biancuzzi > na qual ele diz que o SMPng melhora muitíssimo pouco a performance em > CPUS HTT (e sobre a necessidade de um HTT ware scheduler) > > http://www.onlamp.com/pub/a/bsd/2005/01/20/smpng.html Sem duvida, como menciona o Scott Long um escalonador especifico melhoraria a performance, mas como nao existe escalonador especifico pra HTT, temos que nos ater simplesmente ao fato que o poder de processamento total eh uma constante, e os recursos paralelos a ele, especialmente cache e frequencia de troca de registradores - mais importante pra multiplexacao no caso - sao igualmente constantes e limitados, com ou sem HTT. Entao a diferenca eh a possibilidade de haver paralelismo ou de tudo se resumir a multiplexacao. Isso ja eh possibilitado por escalonamento generico, sem nada especial para HTT. -- Patrick Tracanelli FreeBSD Brasil LTDA. (31) 3281-9633 / 3281-3547 [EMAIL PROTECTED] http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd