Por que 16 threads são mais eficientes que 8 em um i7 com 4 núcleos hyperthreaded? (Robocopy)

Question

No Windows 8.1, estou usando o Robocopy para salvar dados de 2 servidores no espaço de armazenamento de um PC dedicado. O volume de dados é de 147.314 arquivos em 4.110 pastas (66.841.845.760 bytes).

Todos os 3 PCs envolvidos possuem um CPU i7 com 4 núcleos e estão em uma rede de 1 Gb. O Espaço de Armazenamento do alvo (espelhado e distribuído em D :) é realizado usando um caso JBOD de 4 x 4 TB.

Devido aos 4 núcleos e hyperthreading das CPUs eu estava esperando, que o switch Robocopy / MT: 8 funcionaria melhor, e que mais de 8 threads seriam um exagero devido ao não gerenciamento de thread beneficiário.

Eu testei isso. Eu listo os dados da quarta série de testes aqui (duração em mm: ss):

 1 thread:  59:19
 2 threads: 39:12
 4 threads: 29:13
 8 threads: 24:36
16 threads: 24:19
32 threads: 24:27

Concedidos, os poucos segundos usando 16 threads são insignificantes, mas eles são consistentes em todas as séries de testes, ou seja, não devido a mais trabalho de carga no teste de menos de 16 threads (a menos que isso fosse o caso todas as 4 séries de testes). Observe também que 32 threads são quase sempre um pouco mais rápidos que 8 threads.

Pergunta: qual razão técnica é responsável por usar 16 threads sendo mais eficiente do que 8 threads em um i7 com 4 núcleos hyperthreaded?

    

Answer 1

TL; versão dr: se você estava fazendo algo altamente intensivo de CPU, como transcodificação de vídeo usando o Handbrake, então você não iria querer usar mais núcleos do que CPUs, pois não haveria lugar para o trabalho ser feito. Nesse caso, onde a maioria das threads gastará 90% do seu tempo dormindo aguardando leituras ou gravações com mais threads funcionando para você em vez de contra.

Copiar arquivos não é uma tarefa particularmente ligada à CPU. Embora ter mais núcleos possa ajudar a impedir que outras tarefas bloqueiem sua ferramenta de cópia, é improvável que cada thread esteja sendo executado em qualquer local próximo a 100% em cada núcleo.

Cada encadeamento de cópia enviará uma solicitação de leitura para o disco rígido e, em seguida, entrará em suspensão enquanto espera que a solicitação de leitura seja atendida. Seu disco de ferrugem girando geralmente tem um tempo de busca de 9 milissegundos, praticamente uma eternidade em termos de CPU, e a tarefa de cópia não iria simplesmente girar em torno dizendo "está pronto ainda?" e desperdiçando ciclos de CPU. Se o fizer, bloqueará esse encadeamento em 100% da CPU e desperdiçará recursos. Não, o que acontece é que o encadeamento emite uma leitura e o encadeamento é colocado em suspensão até que a leitura seja concluída e os dados estejam prontos para a próxima etapa.

Nesse meio tempo, outro segmento faz o mesmo, fica bloqueado em uma leitura e é colocado em suspensão. Isso acontece para todos os 16 dos seus tópicos. (Na realidade, suas leituras e gravações estarão acontecendo em momentos aleatórios, pois ficam fora de sincronia, mas você tem a ideia)

Depois que um dos threads tiver dados prontos para ele, o Windows o reprogramará e começará a processá-lo para ser gravado. No que diz respeito ao segmento, o processo é o mesmo. Ele diz "gravar esses dados no arquivo x no local y" e o Windows obtém os dados e desordena o encadeamento. O Windows faz o trabalho em segundo plano para descobrir onde o arquivo está, move os dados (potencialmente através da rede adicionando mais milissegundos ao atraso) e, em seguida, retorna o controle para o thread uma vez que a gravação tenha sido bem-sucedida.

Nenhum encadeamento estará sendo gravado o tempo todo em um núcleo da CPU e, portanto, mais encadeamentos do que CPUs não são um problema. Nenhum tópico ficará acordado por tempo suficiente para que seja um problema.

Se você tivesse apenas uma única CPU com muitos outros threads em execução, você poderia estar fazendo gargalos na CPU, mas em um sistema multicore com esse tipo de carga eu ficaria surpreso se a CPU fosse o problema.

É mais provável que você tenha um gargalo no desempenho do disco rígido e esteja atingindo a profundidade da fila para os buffers de leitura ou gravação nas unidades. Usando mais threads, você está empurrando alguma coisa para seus limites, seja disco ou rede, e a única maneira de descobrir qual é o melhor número de threads é fazer o que você fez e experimentá-lo. .

Em um sistema com cópia SSD para SSD, eu suspeitava que um número menor de threads poderia ser melhor, já que haveria menos latência do que copiar arquivos de HDDs enferrujados, empurrando toda a rede e escrevendo para ferrugem, mas eu tenho nenhuma evidência para apoiar essa suposição.