Eu estava interessado em como a conscientização sobre Hyper-Threading impacta o agendamento de threads em núcleos lógicos e físicos, por exemplo, ele colocaliza threads do mesmo processo para se beneficiar do compartilhamento de cache, ele separa threads que, de alguma forma, sabe que disputarão muito os recursos do núcleo, ele combina threads computacionalmente intensos com threads com E/S intensas, etc.
Pesquisei no Google como-o-agendador-trata-o-núcleo-lógico. Não pedi uma resposta de IA, mas os resultados do Google levaram à resposta de IA de que um agendador que não reconhece Hyper-Threading trata os núcleos lógicos da mesma forma que os núcleos físicos. Em uma CPU multi-core, se houver hipoteticamente apenas dois threads para executar, a falta de reconhecimento de Hyper-Threading pode causar o agendamento de ambos os threads no mesmo núcleo físico. Isso torna um núcleo muito ocupado e atrasa a conclusão das tarefas de thread.
No entanto, isso é apenas a IA do Google. Se for para ter alguma credibilidade, então precisa de corroboração. A resposta da IA parece implicar que um agendador com conhecimento de Hyper-Threading preferiria espalhar threads em diferentes processadores físicos e apenas duplicá-los quando não houvesse mais processadores físicos. Isso é realmente verdade? Onde posso encontrar essas informações?
Há uma razão pela qual me pergunto sobre a veracidade dessa preferência do Hyper-Threading para espalhar threads em diferentes núcleos físicos. Em um computador típico, há milhares de threads esperando para serem executados . Isso é maior do que o número de processadores lógicos e físicos por muitas vezes, se não ordens de magnitude. Esta não é apenas uma resposta de IA, então parece que fora de aplicações de computação científica muito específicas, é bastante plausível que não haja vantagem em evitar duplicar threads em núcleos físicos. Isso está correto ou estou esquecendo de algo?
No final das contas, estou tentando ter uma ideia de como a conscientização do Hyper-Threading melhora o agendamento. Com base no que consegui descobrir até agora, é bem possível que não. No entanto, não sou um cientista da computação -- eu apenas tive que aprender sobre multithreading para tornar meu componente de software thread-safe, já que o aplicativo host usa hyperthreading.
PS: Estou lendo páginas sobre Hyper-Threading online há dias, então não estou perguntando sobre os conceitos básicos de multithreading, SMT, o que é Hyper-Threading, superscalar ou esse tipo de informação.
O Hyperthreading compartilha um núcleo de CPU entre dois threads. Isso significa que ambos os threads precisam compartilhar caches, recursos de núcleo e unidades de execução. Quando você está usando apenas um dos núcleos hyperthreaded, isso significa que o cache e o recurso podem ser melhor alocados para o thread que está em execução.
Simplificando, se você tem 4 coisas para fazer e 4 núcleos hyperthreaded e, como resultado, precisa apenas de 4 núcleos, o melhor desempenho será alcançado usando os núcleos "completos" e evitando o segundo (hyper) thread em cada núcleo.
Como esclarecimento, hyperthreading não é igual a um aumento de 100% no desempenho por núcleo. Um exemplo antigo era que hyperthreading poderia permitir um aumento extra de 30% no desempenho dependendo da tarefa. Duas tarefas em execução em um único núcleo hyperthreaded seriam equivalentes a apenas 1,3 processadores.
Como alternativa, executar duas tarefas em dois processadores "cheios", assumindo nenhuma memória ou outras restrições, alcançaria o desempenho total de ambos os núcleos. Duas coisas estariam realmente sendo executadas simultaneamente em vez de compartilhar recursos de execução.
Então para esclarecer:
Então você certamente preferiria ter tarefas individuais sendo executadas em núcleos "completos" sempre que possível.
É aí que entra o agendador com reconhecimento de hyperthreading.
Ele preferencialmente agendaria tarefas em cada núcleo e, então, somente utilizaria o recurso restante do núcleo por meio de hyperthreading quando necessário.
Ignore "I/O" e outros recursos, entre processos cada núcleo é basicamente idêntico e tem a mesma velocidade para memória e discos rígidos. Não há benefício em "co-localizar" processos, pois no momento em que eles fazem uma solicitação de memória ou outro hardware, eles verão o mesmo limite, independentemente do núcleo em que estão.