Quanto mais CPU uma thread consome, menos ela é priorizada pelo kernel. Logo dividir o trabalho em dois (ou mais) pode evitar que o processo tenha a performance prejudicada pelo escalonador de tarefas.

Dividir em mais threads um problema cpu bound não melhora a perfomance. Eu testei. E sugiro que teste também, vc escreve implicitamente que pode melhorar a perfomance sim, em qual caso? Tem algum exemplo concreto que mostra isso?

Silva97há 11 dias

«Dividir em mais threads um problema cpu bound[...]»

Esse que é o problema, eu não disse isso em lugar nenhum. Nem disse que melhora nem que piora a performance. Quando eu falo de "dividir o trabalho" eu me refiro a execução do software no geral, não de um algoritmo.

Troca de contexto nem sempre é ruim, é importante dar espaço para outros processos senão o escalonador vai prejudicar a performance do seu software. É por isso que softwares que consomem CPU em excesso começam a travar — é o kernel fazendo isso.

Além disso, você também não quer prejudicar a execução de outros processos a menos que o software execute em um contexto em que isso faça sentido.

Sobre exemplos: O simples fato do GNU make ter a opção -j já serve muito bem para exemplificar o que eu estou dizendo. E também provar na prática que o uso de threads assim realmente acarreta em ganho de performance. Faça o teste: Compile um projeto com e sem -j e veja em qual dos dois casos termina mais rápido.

Você pode ver outros softwares com opções semelhantes, como o -threads do ffmpeg.

E antes que diga o que eu estou prevendo que dirá, repito: «Dividir em mais threads um problema cpu bound[...]» não foi o que eu disse. Então não responda dizendo que nem o make nem o ffmpeg fazem isso. Realmente não fazem.

clacerdahá 11 dias
> 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*.
Silva97há 11 dias
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.