Quanta aceleração um hiper thread fornece? (em teoria)
Respostas:
Como outros já disseram, isso depende inteiramente da tarefa.
Para ilustrar isso, vejamos uma referência real:
Isso foi retirado da minha tese de mestrado (atualmente não disponível online).
Isso mostra a aceleração relativa 1 dos algoritmos de correspondência de string (cada cor é um algoritmo diferente). Os algoritmos foram executados em dois processadores quad-core Intel Xeon X5550 com hyperthreading. Em outras palavras: havia um total de 8 núcleos, cada um dos quais pode executar dois threads de hardware (= "hyperthreads"). Portanto, o benchmark testa a aceleração com até 16 threads (que é o número máximo de threads simultâneos que essa configuração pode executar).
Dois dos quatro algoritmos (azul e cinza) escalam mais ou menos linearmente em toda a faixa. Ou seja, ele se beneficia do hyperthreading.
Dois outros algoritmos (em vermelho e verde; escolha infeliz para daltônicos) são dimensionados linearmente para até 8 threads. Depois disso, eles estagnam. Isso indica claramente que esses algoritmos não se beneficiam do hyperthreading.
O motivo? Nesse caso em particular, é carga de memória; os dois primeiros algoritmos precisam de mais memória para o cálculo e são limitados pelo desempenho do barramento de memória principal. Isso significa que enquanto um segmento de hardware está aguardando memória, o outro pode continuar a execução; um caso de uso principal para encadeamentos de hardware.
Os outros algoritmos requerem menos memória e não precisam esperar o barramento. Eles são quase inteiramente vinculados à computação e usam apenas aritmética inteira (operações de bit, de fato). Portanto, não há potencial para execução paralela nem benefícios de pipelines de instruções paralelas.
1 Ou seja, um fator-speed-se de 4 significa que o algoritmo é executado quatro vezes mais rápido como se fosse executado com apenas um thread. Por definição, então, todo algoritmo executado em um encadeamento possui um fator de aceleração relativo de 1.
O problema é que depende da tarefa.
A noção por trás do hyperthreading é basicamente que todas as CPUs modernas têm mais de um problema de execução. Geralmente mais perto de uma dúzia ou mais agora. Dividido entre Inteiro, ponto flutuante, SSE / MMX / Streaming (como é chamado hoje).
Além disso, cada unidade possui velocidades diferentes. Ou seja, pode levar uma unidade matemática inteira de 3 ciclos para processar alguma coisa, mas uma divisão de ponto flutuante de 64 bits pode levar 7 ciclos. (Estes são números míticos que não se baseiam em nada).
A execução fora de ordem ajuda muito a manter as várias unidades o mais cheias possível.
No entanto, uma única tarefa não utilizará todas as unidades de execução a cada momento. Nem mesmo a divisão de threads pode ajudar totalmente.
Assim, a teoria torna-se fingindo que existe uma segunda CPU, outro thread pode ser executado nela, usando as unidades de execução disponíveis que não são usadas, por exemplo, sua transcodificação de áudio, que é 98% SSE / MMX, e as unidades int e float são totalmente ocioso, exceto por algumas coisas.
Para mim, isso faz mais sentido em um único mundo de CPU; criar uma segunda CPU permite que os threads cruzem esse limite com mais facilidade com pouca (se houver) codificação extra para lidar com essa segunda CPU falsa.
No mundo principal de 3/4/6/8, com CPU de 6/8/12/16, isso ajuda? Não sei. Tanto quanto? Depende das tarefas em mãos.
Portanto, para responder às suas perguntas, isso dependeria das tarefas em seu processo, quais unidades de execução estão sendo usadas e, em sua CPU, quais unidades de execução estão ociosas / subutilizadas e disponíveis para a segunda CPU falsa.
Diz-se que algumas 'classes' de material computacional se beneficiam (vagamente genericamente). Mas não existe uma regra rígida e rápida e, para algumas classes, torna as coisas mais lentas.
Eu tenho algumas evidências anedóticas a serem adicionadas à resposta de geoffc, na verdade, eu tenho uma CPU Core i7 (4 núcleos) com hyperthreading e joguei um pouco com a transcodificação de vídeo, que é uma tarefa que requer muita comunicação e sincronização, mas tem bastante paralelismo em que você pode efetivamente carregar totalmente um sistema.
Minha experiência em jogar com quantas CPUs são atribuídas à tarefa geralmente usando os 4 núcleos "extras" hiperencadeados equivale a um equivalente a aproximadamente 1 CPU extra no valor de poder de processamento. Os 4 núcleos "hyperthread" extras adicionaram aproximadamente a mesma quantidade de poder de processamento utilizável da passagem de 3 para 4 núcleos "reais".
Concedido que este não é estritamente um teste justo, pois todos os threads de codificação provavelmente competirão pelos mesmos recursos nas CPUs, mas para mim isso mostrou pelo menos um pequeno aumento no poder geral de processamento.
A única maneira real de mostrar se realmente ajuda ou não seria executar alguns testes diferentes do tipo Número inteiro / Ponto flutuante / SSE ao mesmo tempo em um sistema com o hyperthreading ativado e desativado e ver quanto poder de processamento está disponível em um ambiente controlado. meio Ambiente.
Depende muito da CPU e da carga de trabalho, como já foi dito.
O desempenho medido no processador Intel® Xeon® MP com tecnologia Hyper-Threading mostra ganhos de desempenho de até 30% nos benchmarks de aplicativos de servidor comuns para esta tecnologia
(Isso me parece um pouco conservador.)
E há outro artigo mais longo (que ainda não li tudo) com mais números aqui . Uma conclusão interessante desse artigo é que o hyperthreading pode tornar o thras mais lento para algumas tarefas.
A arquitetura Bulldozer da AMD pode ser interessante . Eles descrevem cada núcleo como efetivamente 1,5 núcleos. É um tipo de hyperthreading extremo ou multinúcleo sub-padrão, dependendo da confiança que você tem em seu desempenho provável. Os números dessa peça sugerem uma aceleração de comentário entre 0,5x e 1,5x.
Finalmente, o desempenho também depende do sistema operacional. Esperamos que o sistema operacional envie processos para CPUs reais , de preferência para os hyperthreads que estão apenas disfarçados de CPUs. Caso contrário, em um sistema de núcleo duplo, você pode ter uma CPU ociosa e um núcleo muito ocupado com dois threads debitados. Eu me lembro que isso aconteceu com o Windows 2000, embora, é claro, todos os sistemas operacionais modernos sejam capazes.