Hyper-Threading e htop / system-monitor

Question

Estou executando um grande conjunto de simulações em um Xenon E5520 de quatro núcleos com o Hyper-Threading ativado. Meu software detecta automaticamente oito núcleos (virtuais) e lança oito simulações para serem executadas em paralelo. No entanto, o htop e o monitor do sistema mostram apenas cada um dos 8 núcleos carregados para ~ 50%.

Esse comportamento é pretendido? De certo modo, faz sentido já que a carga total seria de 400% ou 100% para cada núcleo físico, mas eu não deveria conseguir um pouco mais do que isso? Quero dizer, esse é o propósito do HT, certo? Use o SMT para usar as unidades de execução de outra forma não utilizadas para executar outro thread. Então, o rendimento deve ser maior, certo?

Devo mencionar que a carga é muito consistente, 50% em cada núcleo, o tempo todo. As simulações são executadas por Java, em uma única JVM, o GC não é o problema, estou muito abaixo do limite de heap da JVM. As simulações não são limitadas pela memória, há muito para dar a volta e sem troca. As simulações estão gravando muitos dados no disco, mas existem grandes buffers no lugar (128MB de buffer de gravação para cada thread) e a atividade do disco mostrada pelo gkrellm é freqüente em ~ 90MB / s, mas não é uma carga consistente e eu posso acredito que isso poderia ser um gargalo.

Poderia alguém lançar alguma luz sobre isso?

    

Answer 1

However htop and system-monitor only show each of the 8 cores as loaded to ~50%.

Ok, isso significa simplesmente que você não está executando simulações suficientes ao mesmo tempo. Existem muitos elementos que podem resultar em uma simulação que não usa um núcleo de 100%. Ou você conserta isso ou simplesmente adiciona mais simulações.

but shouldn't I get a bit more than that?

Você deve conseguir 100% em cada núcleo.

Agora, se você ler metade do conhecimento de Khaledds ... aqui está a verdade:

• O Hyper-Threading significa que ambos os núcleos não têm tudo, isso é verdade, então ambos os núcleos podem, por exemplo, não realizar certas operações ao mesmo tempo.
• Infelizmente para ele, porém, isso não é visível para o sistema operacional. Fatores de "carga" da CPU "baseiam-se em" que% do tempo foi o principal ocupado por agendador de SO ". Portanto, se uma CPU tiver uma tarefa ativa de 400ms de segundo, ela estará 40% ocupada.

Falta de recursos do Hyper-Threading (ou seja, um núcleo virtual tem que esperar por um recurso) Significará simples que o núcleo virtual demora mais para executar uma operação - mas isso não é visível para o planejador do sistema operacional.Se o núcleo gastar 100ms esperando internamente , a tarefa levará 500 ms em vez de 400 ms. É bastante complexo tentar descobrir quando você se depara com a fome de recursos, e isso não é algo que o SO possa fazer (ou seja, é algo em que você executa um código especial e compara os tempos de execução para ver que demora mais do que deveria) = Hyper-threading "ruim" Se a CPU afinasse as estatísticas de uso interno, você poderia se despedir de qualquer performance para começar - isso é muito mais dados.

O resultado é que o segundo núcleo simplesmente não adicionará 100% de desempenho - portanto, se algo levar 100ms em um núcleo, com hyper-threading e 2 núcleos, ele pode levar 75, não 50. Depende muito do código. / p>

No seu caso, eu começaria com um único segmento e descobriria se você pode obter um núcleo para 100%. Se não, então a simulação simplesmente está esperando por algo - o que é um problema de stackoverflow (programa em todos os casos) (o programa deve ser alterado). Se é como é (IO, escrever / ler do disco), então pode ser uma necessidade simples executar mais de 1 simulação por núcleo.