Quantas CPUs devem ser utilizadas com o Hyperthreading?

Question

Digamos que eu tenha uma cpu de servidor com 18 núcleos, com hyperthreading ativado, o que significa que posso ver 36 cpus no htop.

Para utilizar totalmente a CPU e não impactar o desempenho de thread único, eu deveria estar mirando todos os 36 "núcleos" para rodar a 100%, e os núcleos HT só farão menos trabalho e ainda reportarão 100%, ou teriam isso significa que os núcleos "completos" já estão sendo interrompidos pela tarefa em seu "núcleo HT" e, portanto, realizando menos tarefas de encadeamento único?

Estou ciente de que há muitas variáveis que afetam o desempenho do HT, apenas quero saber o que o medidor de CPU significa ao lidar com o HT.

    

Answer 1

Se for permitido que o segundo núcleo virtual contribua quando o primeiro estiver preso, é melhor que não , para que você obtenha (pelo menos) um pouco mais de trabalho.

A questão é: quando dois tópicos diferentes fazem com que um seja pior? A predição da ramificação e as dependências entre as instruções não serão alteradas. Esperando o acesso à memória agora ... os dois threads competem pelo acesso à memória, tanto na utilização do cache quanto na largura de banda.

Se você tem algumas CPUs rodando com HT e outras não, isso também significa que você irá designar threads específicas para um tipo ou outro? Acho que não: seus programas executarão seus threads em núcleos virtuais aleatórios. Então, como dividir a ajuda de configuração? Como cada CPU tem seu próprio cache, o único efeito é devido à largura de banda da memória e à carga da coerência do cache.

Em geral, você chega a um ponto em que ter algo mais que você poderia fazer é mais caro do que deixar algumas unidades de execução da CPU ficarem ociosas. Isso não depende do número de encadeamentos diretamente, mas de o que os encadeamentos estão fazendo e da arquitetura detalhada da memória e das nuances de desempenho dos vários componentes.

Não há uma resposta simples. Mesmo com um programa específico em mente, a máquina pode diferir daquelas de pessoas que relatam suas próprias experiências.

Você tem que experimentar você mesmo e medir o que é mais rápido, com esse trabalho específico nessa máquina exata. E mesmo assim, isso pode mudar com atualizações de software e mudança de uso ao longo do tempo.

Dê uma olhada no volume 3 do magnum opus de Anger. Se você examinar cuidadosamente algum processador específico, poderá encontrar recursos de limitação entre o pipeline profundo de muitas etapas necessárias para executar o código. Você precisa encontrar um caso em que o excesso de cometer faz com que seja executado mais lentamente, em vez de não levar mais trabalho. Em geral, isso significaria algum tipo de armazenamento em cache; e onde o recurso é compartilhado entre threads.

O que significa o medidor da CPU: ele informa todo o tempo que não é gasto na execução do thread inativo. Os dois segmentos lógicos atribuídos a um núcleo não ficarão inativos, embora o trabalho real feito em um deles possa ser pequeno. Tempo gasto com o pipeline preso por alguns ciclos até que os resultados estejam prontos, a memória seja buscada, as operações atômicas sejam protegidas, etc. da mesma forma, não faça com que o fio seja arquivado como "não pronto" para que não fique ocioso, e o tempo ainda mostra como em uso. Esperando na RAM não mostrará como ocioso. Apenas algo como I / O fará com que o segmento bloqueie e pare de carregar o tempo em direção a ele. Um mutex do sistema operacional em geral o fará, mas com o surgimento de sistemas multicore que não é mais uma certeza, já que um "spinlock" não fará o thread ir de volta na prateleira.

Portanto, um medidor de 100% da CPU não significa que tudo está funcionando bem, se a CPU estiver freqüentemente esperando pela memória. Um número menor de núcleos lógicos mostrando 90% poderia muito bem estar fazendo mais trabalho, já que termina o processamento de números e agora está aguardando no disco.

Portanto, não se preocupe com o medidor da CPU. Veja o progresso real realizado, somente .

    

Answer 2

Os medidores de CPU são muito ruins para dizer a você quanto mais desempenho você pode extrair de suas CPUs com hyperthread. Para isso, você deve executar seus próprios benchmarks em várias taxas de assinatura excessiva de núcleo físico. Existem algumas cargas de trabalho que funcionam melhor com o HT completamente desativado, portanto inclua esse caso em seus testes também. Poderia ser 1: 2 (36 trabalhadores paralelos), ou 1: 1.5, ou mesmo 1: 2.5! Depende da sua carga de trabalho.

Mais detalhadamente, o HT é implementado no silício de maneiras que reduzem o tempo que o processador fica ocioso quando um contexto precisa ser alternado ou uma previsão de ramificação falha. Isso torna mais fácil alcançar 100% de uso da unidade de execução do que com truques puros do sistema operacional. HT evoluiu desde a sua introdução, e há mais paralelismo em chips modernos do que os que estávamos usando há 10 anos.

Existem dois perfis de execução que afetarão o local ideal para o excesso de assinatura:

• Duração da execução longa . Se seus funcionários forem executados por minutos ou horas antes da reciclagem, como grandes trabalhos de renderização ou modelagem de ambiente, você obterá um desempenho de núcleo único mais eficiente por trabalhador. Isso diminuirá sua proporção.
• Duração de execução curta . Se seus funcionários percorrerem em segundos ou em pequenos minutos, como encadeamentos de aplicativos da web, a sobrecarga envolvida na ativação de um novo processo significa que sua proporção será maior.

Answer 3

Você deve ver todos os 36 núcleos rodando a 100% - assumindo que o software pode fazer isso (o que não é trivial - o agendamento pode ser complicado com muitos núcleos, então mergulhos abaixo de 100% são aceitáveis).

Obviamente, quando você "divide" um minério com hyperthreading, o significado desses 200% não é "2x100% - no trabalho feito. Mas isso é invisível para qualquer medida tomada (que vem da utilização da CPU e não tem noção de trabalho Quanto trabalho isso é feito depende do que o trabalho é - em algum lugar acima de 1,5x o trabalho sem hyper threading é esperado na maioria das vezes.

    

Answer 4

A maneira como o hyperthreading é implementado varia com o uarch específico da CPU. De Nehalem a Skylake, a Intel reduziu significativamente as partes compartilhadas do rácio fixo (ie: 50/50), indo para estruturas compartilhadas dinamicamente.

De qualquer forma, em termos gerais, a habilitação de HT levou à execução slidtly slow thread-single, mas devido ao funcionamento do agendador Linux, isso só acontece quando o número ou thread em execução é maior que o número de núcleos físicos. Como em tais situações (quando threads > core) você valoriza tipicamente o throughput total de máxima importância, o hyperthreading continua sendo uma vitória líquida.

Como isso é possível? O ponto-chave a ser entendido é que a CPU não apresenta os núcleos físicos e os virtuais como núcleos iguais, mas expõe os últimos de uma maneira que o planejador Linux pode evitar o agendamento sobre eles se qualquer outro núcleo físico estiver disponível. Em outras palavras, primeiro usa todos os núcleos físicos, então começa a usar o virtual.

Isso significa que, geralmente, o HyperThreading é um recurso muito valioso (outros processadores, como o Power8, usam técnicas SMT ainda mais profundas) e que para maximizar a taxa você deve habilitá-lo, carregando a CPU com pelo menos um thread por virtual ou físico testemunho. Para um exemplo prático, para extrair o desempenho total de uma CPU de 18 núcleos, você deve usar pelo menos 36 threads.

Existem duas exceções:

1. se tudo o que você quer é minimizar a latência de um conjunto limitado de segmentos (onde os threads < os núcleos físicos), você pode desativar o HT
2. CPU muito antiga (Pentium4 e, de forma muito menor, Nehalem) tem regras de particionamento inflexíveis que forçam o processador a dividir muitos recursos-chave na proporção 50/50, independentemente do status / carga do segundo thread. Nesse caso, você precisava avaliar seu caso de uso para ter certeza de que a taxa de transferência adicionada valeria o desempenho de thread único significativamente menor.