Como a afinidade do processador do Windows funciona com CPUs com hyperthread?

Question

Como a afinidade do processador do Windows funciona com CPUs com hyperthread? Vamos usar um exemplo (foto) de um sistema com quatro núcleos, cada um com um núcleo virtual hyper-threaded.

1. Quais núcleos correspondem a cada "CPU" abaixo?
2. A (digamos) CPU 6 e CPU 7 abaixo representam um núcleo; o HT e o núcleo real?
3. Se, por exemplo, a CPU 6 representa um núcleo real e a CPU 7 um núcleo HT, será que um encadeamento designado apenas para CPU7 obterá apenas os recursos que sobraram de um núcleo real? (assumindo que o núcleo está executando outras tarefas)
4. O hyperthreading é gerenciado inteiramente dentro do processador, de modo que os threads são manipulados internamente? Se sim, isso é no escopo da CPU ou no escopo do núcleo? Exemplo: Se as CPUs 6 e 7 representam um núcleo, não importa qual processo está atribuído porque a CPU atribuirá recursos conforme apropriado para um encadeamento em execução?
5. Percebo que processos de thread único de execução longa são devolvidos em torno de núcleos um pouco, pelo menos de acordo com o gerenciador de tarefas. Isso significa que atribuir um processo a um único núcleo melhorará o desempenho um pouco (evitando comutadores de contexto e invalidações de cache, etc.)? Em caso afirmativo, posso saber que não estou atribuindo a "apenas um núcleo virtual"?

Isso tudo é muito vago e confuso para mim. O HT é ótimo, mas com certeza parece reduzir a transparência da alocação de recursos.

    

Answer 1

Which cores correspond to each "CPU" below?

Supondo que temos o Core 1, 2, 3 e 4, o CPU4 e o CPU5 representam o núcleo 3.

Does (say) CPU 6 and CPU 7 below represent one core; the HT and the real core?

Não há distinção entre os dois - ambos têm interfaces físicas de hardware para a CPU, a interface lógica é implementada em hardware (veja o Folha de dados do processador Intel Core, Volume 1 para mais detalhes). Basicamente, cada núcleo tem duas unidades de execução separadas, mas compartilha alguns recursos comuns entre elas. É por isso que, em certos casos, o hyperthreading pode reduzir o desempenho.

If, for example, CPU 6 represents a real core and CPU 7 an HT core, will a thread assigned just to just CPU7 get only the left over resources of a real core? (assuming the core is running other tasks)

Veja acima. Um encadeamento designado para SOMENTE CPU6 ou SOMENTE CPU7 será executado na mesma velocidade exata (supondo que o encadeamento faça o mesmo trabalho e os outros núcleos no processador fiquem inativos). O Windows sabe sobre processadores habilitados para HT, e o agendador de processos leva isso em consideração.

Is the hyperthreaded managed entirely within the processor such that threads are juggled internally? If so, is that at the CPU scope or the core scope? Example: If CPU 6 and 7 represent one core, does it not matter which a process is assigned to because the CPU will assign resources as appropriate to a running thread?

Ambos. O hardware em si não não agenda em quais núcleos executar programas, esse é o trabalho do sistema operacional. A própria CPU, no entanto, é responsável pelo compartilhamento de recursos entre as unidades de execução reais, e a Intel determina como você pode escrever código para tornar isso o mais eficiente possível.

I notice that long-running single-threaded processes are bounced around cores quite a bit, at least according to task manager. Does this mean that assigning a process to a single core will improve performance by a little bit (by avoiding context switches and cache invalidations, etc.)? If so, can I know I am not assigning to "just a virtual core"?

Esse é um comportamento normal e não, atribuí-lo a um único núcleo não melhora o desempenho. Dito isto, se por algum motivo você quiser garantir que um único processo seja executado apenas em um único núcleo físico, atribua-o a um único processador lógico.

A razão pela qual o processo "gira em torno" é devido ao agendador de processos. Esse é um comportamento normal, e você provavelmente experimentará um desempenho reduzido limitando em que núcleos o processo pode ser executado (independentemente de quantos segmentos ele tenha), já que o agendador de processos agora precisa trabalhar mais para que tudo funcione com as restrições impostas. Sim, essa penalidade pode ser insignificante na maioria dos casos, mas o resultado final é a menos que você tenha uma razão para fazer isso, não !

    

Answer 2

O layout da CPU deve ser organizado de modo que um sistema operacional que não possa reconhecer todas as CPUs obtenha o máximo desempenho possível. Isso significa que um núcleo virtual de cada núcleo físico será listado antes de um segundo núcleo virtual de qualquer núcleo físico ser listado.

Por exemplo, digamos que você tenha quatro núcleos com hyper-threaded, chamados A, B, C e D. Se você assumir que A e B compartilham um cache L2 e C e D compartilharem um cache L2, o pedido deve ser algo como :
0 = A1 1 = C1 2 = B1 3 = D1 4 = A2 5 = C2 6 = B2 7 = D2

Dessa forma, um sistema operacional que apenas pega duas CPUs consegue usar todo o cache L2. Além disso, um sistema operacional que apenas agarra quatro CPUs consegue usar todas as unidades de execução.

Mais uma vez, é assim que deve ser.

Claro, se você estiver usando um sistema operacional que entenda sua topologia de CPU, não importa. O BIOS preenche uma tabela que explica quais núcleos compartilham unidades de execução, quais compartilham caches e assim por diante. Todo sistema operacional moderno que você provavelmente usará e que ofereça suporte total ao seu processador compreende a topologia completa da CPU.

    

Answer 3

1. Como eles correspondem, depende de como sua CPU & placa-mãe enumerar e identificar os núcleos. O que é suposto acontecer é que os soquetes físicos são enumerados primeiro, os núcleos lógicos são os próximos e os núcleos virtuais são os últimos. No seu caso, os núcleos 0-3 devem ser núcleos físicos e 4-7 os núcleos virtuais HT. A principal razão para isso é que no caso de você executar um sistema operacional que não seja capaz de lidar com todas as unidades de execução disponíveis, é mais provável que ele obtenha as unidades mais independentes antes das compartilhadas. Não seria bom se um hipotético SO de 2 CPUs encontrasse um par HT em seu sistema em vez de 2 núcleos distintos. (Esse foi um problema real para alguns sistemas HT iniciais, antes que os programadores do kernel pudessem ser atualizados para as novas CPUs.)
2. Não. Veja 1.
3. Não. HT é mais complexo que isso. Lembre-se de que os 2 núcleos virtuais geralmente compartilham alguns recursos enquanto outros bits são separados, mas que apenas um ou outro pode estar em execução por vez.
4. Mais ou menos. Seu exemplo (dadas as suposições) é geralmente correto. No entanto, se o aplicativo puder saber que tipo de carga de trabalho está executando, ele poderá ajudar os encadeamentos de planejamento do SO adequadamente.
5. Há uma boa razão para o core hopping: espalhar a carga de trabalho térmica. Dado que em muitos casos caches de nível superior (L2, L3) são compartilhados em todos os núcleos de qualquer maneira, o hopping de núcleo não terá um impacto significativo no desempenho, mas o impacto térmico será significativo porque você não terá um "hot spot" o núcleo que está constantemente correndo enquanto os outros ficam ociosos. Agora, o cruzamento de soquetes em um sistema multi-soquete (particularmente um sistema NUMA) pode ter um impacto significativo no desempenho. A maioria dos agendadores está ciente disso e leva isso em consideração.

Em suma, o que isso significa é que muitas vezes você (como usuário final) pode fazer pouco com a afinidade de thread para impactar significativamente o desempenho, além de garantir que esteja executando um sistema operacional atualizado que conheça o desempenho vários bits no seu sistema.

Se você encontrar alguma carga de trabalho onde a atribuição manual de afinidade tenha um impacto significativo, relate-a como um erro para o desenvolvedor do aplicativo, para que o programa possa ser corrigido.