Executando verificação de segurança...
-5

Mas do outro lado da moeda existem pessoas que acreditam que usar mais threads é "mais lento" dando a explicação de que você basicamente está dividindo a mesma capacidade de CPU para duas threads.

Começou o texto afirmando isso e terminou com aquilo. Mas claro deve ser só eu que não sei interpreter texto que viajei achando que estava falando de um problema cpu bound quando apenas estava se referindo a capacidade de processamento da cpu como a execução do software no geral e não de trabalho real da cpu, my bad.

Claro se a cpu ta ociosa usar mais threads é um jeito muito eficaz de ocupar ela. Mas não foi isso que entendi do seu texto.

Enfim um abraço e bons estudos muchacho.

Carregando publicação patrocinada...
-1

Meu caro, leia de novo o que eu acabei de falar. Dei dois exemplos que você pode testar na prática para ver se usar mais threads beneficia ou não: make e ffmpeg.

Compilação de código e processamento de vídeo são exemplos de problemas CPU bound ou de tempo ocioso? Você sabe que são exemplos de problemas de CPU e não de ociosidade. E você também sabe que os dois exemplos mencionados ganham performance ao usar múltiplas threads. É por isso que eles têm opção para isso. Se prejudicasse a performance não teria motivos para os desenvolvedores deixarem essas opções aí.

Agora se você tem interesse em entender a diferença entre o que o make e o ffmpeg faz (que é sobre o que eu estou falando neste post) contra o que você estava falando sobre dividir o problema em mais threads — que realmente não implica em melhoria de performance, eu deixo como dever de casa. É bem simples de entender, na verdade.

Sobre a afirmação inicial, também está claro no texto sobre o que eu estava falando e de onde surgiu esta percepção errada. Está tudo muito bem explicado, basta ler.