Seu post tem boas intenções e acerta em cheio ao dizer que "as coisas são mais complicadas na vida real", mas a maior parte das explicações está simplesmente equivocada ou simplificada demais.

Por exemplo a ideia que de dividir um problema CPU bound em mais thread o deixaria mais rápido por que o processo teria mais vruntime, um benchmark simples mostrou que não para de pé.

Silva97há 11 dias

Obrigado por tentar contribuir com a qualidade do conteúdo, mas a correção apresentada não está corrigindo algo que realmente está escrito no texto do post.

O que realmente está escrito é uma demonstração bem simples (porém suficiente para compreensão da informação) do porque a percepção de que adicionar mais uma threads divide a capacidade da CPU em partes iguais para as duas threads não está correta. O que eu demonstro mencionando o fato de que na vida real a CPU não está 100% dedicada há um único software mas sim a centenas ou até milhares deles.

E para demonstrar como realmente mais uma thread não "divide pela metade" (N/2) eu fiz aquela explicação de que não é N/1 -> N/2 mas sim 1/N -> 2/(N+1) quando você muda de uma thread para duas.

De forma alguma está escrito no texto que isso necessariamente se converte em um software mais rápido. Está claro no texto que isso não é verdade em todo caso e, inclusive, explica em qual caso usar threads prejudica a performance.

Também está claro no texto que existem outros fatores que precisam ser levados em consideração, como o fato do kernel diminuir a prioridade de threads que estejam usando muita CPU.

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