Número ideal de threads enquanto multitarefa

Question

Eu sei que perguntas semelhantes foram feitas, mas acho que meu caso é um pouco diferente.

Digamos que eu tenha um computador com 8 núcleos e memória infinita com um sistema operacional Linux.

Eu tenho um software de cálculo chamado Gaussian que pode aproveitar o multithreading. Então eu configurei sua contagem de threads para 8 para um único cálculo para a velocidade máxima. No entanto, eu realmente não consigo decidir o que fazer quando preciso executar, por exemplo, 8 cálculos simultaneamente. Nesse caso, devo definir a contagem de threads como 1 (total de 8 threads gerados em 8 processos) ou mantê-lo 8 (total de 64 threads gerados em 8 processos) para cada trabalho? Isso realmente importa muito? Uma questão relacionada é que o sistema operacional faz automaticamente o core-parking para diferentes núcleos para cada thread?

EDIT: Eu sei que o benchmarking é a melhor maneira de saber. A coisa é, os computadores pertencem à minha universidade, então eles estão ocupados o tempo todo. Em outras palavras, sua carga de trabalho varia de maneira incontrolável para mim, porque outras pessoas também estão usando esses computadores para seus cálculos, impossibilitando a experimentação. Além disso, o software é muito caro (1500 $ ou algo assim) e licenciado para cada computador, portanto, não posso simplesmente executar uma referência no meu computador pessoal ...

    

Answer 1

Idealmente, a contagem total de encadeamentos para todos os trabalhos deve ser o número de núcleos do sistema, exceto em sistemas que suportam o hyper-threading, no qual deve ser o dobro do número de núcleos. Portanto, se o sistema não tiver hyper-threading, existem 8 cálculos em execução, cada um deve ser executado em um thread.

Muitos processadores Intel vêm com hyper-threading, então cada núcleo pode suportar dois threads. Por exemplo, um sistema de 8 núcleos que suporte hyper-threading deve ter 16 threads para utilizar o sistema completamente.

    

Answer 2

A resposta depende do que o processo faz e como o multi-threading foi programado, significando que você precisará experimentar.

Se o processo usa semáforos e outros mecanismos de exclusão para contenção entre os encadeamentos em recursos comuns (como memória), então, menos é o número de encadeamentos no processo, menos é o número de conflitos que causam esperas.

Durante uma espera, o encadeamento não faz nada, portanto, as esperas terão um efeito negativo na taxa de transferência. Nesse caso, mais processos e menos encadeamentos por processo melhorarão a taxa de transferência, então 8x8 terá um desempenho melhor que 1x64.

Por outro lado, se cada thread estiver totalmente isolado e não houver compartilhamento comum recursos, então o sistema operacional irá agendar os threads sem qualquer distinção entre os dois casos de 8x8 ou 1x64. Neste caso, apenas o número total de threads é importante para o throughput total, então ambos os casos são de igual desempenho.

    

Answer 3

O número correto depende de quanto tempo os processos passam bloqueados no IO.

O livro "Programação de Concorrência na JVM" tem algumas boas informações sobre isso:

"Determining the Number of Threads". For a large problem, we'd want to have at least as many threads as the number of available cores. This will ensure that as many cores as available to the process are put to work to solve our problem...

So the minimum number of threads is equal to the number of available cores. If all tasks are computation intensive, then this is all we need. Having more threads will actually hurt in this case because cores would be context switching between threads when there is still work to do. If tasks are IO intensive, then we should have more threads.

When a task performs an IO operation, its thread gets blocked. The processor immediately context switches to run other eligable threads. If we had only as many threads as the number of available cores, even though we have tasks to perform, they can't run because we haven't scheduled them on threads for the processors to pick up.

If tasks spend 50 percent of the time being blocked, then the nubmer of threads should be twice the number of available cores. If they spend less time being blocked--that is, they're computation intensive--then we should have fewer threads but no less than the number of cores. If they spend more time being blocked--that is, they're IO intensive--then we should have more threads, specifically, several multiples of the number of cores.

So we can compute the total number of threads we'd need as follows:

Number of threads = Number of Available Cores / (1 - Blocking Coefficient)

Se você precisar executar vários cálculos simultaneamente, talvez veja se é possível executá-los em um processo com um conjunto de encadeamentos dimensionado adequadamente.

Caso contrário, se você tiver o número ideal de encadeamentos para um cálculo, mas depois executar 8 de cada vez, você pode ter muitos.

A melhor solução é compará-lo experimentalmente.

Não sei exatamente o que você quer dizer com estacionamento central, mas a CPU tende a continuar executando o mesmo thread em um determinado núcleo por motivos de cache, embora também o mova algumas vezes por diferentes razões de calor / energia. Você pode investigar isso usando uma ferramenta como htop.

    

Answer 4

Você respondeu a pergunta. "os computadores pertencem à minha universidade, então eles estão ocupados o tempo todo"

Na verdade, você só recebe uma fatia dos processadores. Para fazer o trabalho da maneira mais eficiente, a sobrecarga de tarefas de comutação e multiplex, e os recursos em espera devem ser minimizados. Assim, você deve sempre considerar fazer um thread único.

O multiencadeamento sempre é menos eficiente quando calculado com base no "poder de processamento" devido à sobrecarga da alternância de contexto. Apenas acelera os problemas para utilizar todos os recursos desocupados "livres". ideia: use 8 computadores para executar um problema provavelmente 7,9 vezes mais rápido, o que nunca pode ser superior a 8.

Se tudo isso for dedicado a você, faça isso em paralelo para acelerar, se não, mantenha-o em uma única thread e deixe que outros usem o núcleo restante para outro trabalho.

a propósito, de uma maneira egoísta, há uma ferramenta que chama de grade que pode dividir seu trabalho para todo o Linux no campus. (> 200). Ele vai correr tão rápido, só não seja pego, pois vai desacelerar todo mundo. ou use as ferramentas antigas, mathlab parallel.