Entendendo paralelismo na prática
Paralelismo é quando várias tarefas são executadas simultaneamente, em vez de uma depois da outra. Em computação, isso se traduz basicamente em dividir um problema grande em partes menores e processá-las ao mesmo tempo em diferentes núcleos de processamento, threads ou até máquinas diferentes. É simples de explicar e fácil de errar na hora de implementar.
O que significa paralelismo
A pergunta que muitas pessoas fazem é sobre a diferença entre paralelismo e concorrência, e essa confusão existe por um motivo. Concorrência é sobre lidar com várias coisas ao mesmo tempo, fazendo alternâncias rápidas. Paralelismo é sobre executar coisas realmente ao mesmo tempo, de fato. Um servidor Node.js que atende múltiplas requisições usando async/await é.concurrent, não paralelo. Já um processo que usa três threads rodando em três núcleos diferentes da CPU, processando partes diferentes de um dataset, esse sim é paralelo. Na minha experiência, a definição teórica nunca atrapalha tanto quanto a implementação. Já vi desenvolvedores escreverem código paralelo e perceberem que a performance piorava em vez de melhorar. Isso acontece porque o overhead de comunicação e sincronização entre threads pode consumir mais tempo do que o ganho real do processamento concurrente. Em um projeto meu de processamento de logs, onde eu precisava analisar arquivos de dezenas de gigabytes, eu simplesmente lancei dez threads para processar fatias diferentes do arquivo. O resultado foi uma queda de 40% na performance comparado ao processamento sequencial. O gargalo não estava na CPU, estava na disputa pelo acesso ao disco. Quando migrei para um modelo onde cada thread trabalhava em arquivos diferentes em discos diferentes, o tempo caiu de 1 hora e meia para cerca de 8 minutos.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outro ponto que os tutoriais geralmente deixam de fora é a questão da (granularidade). Dividir demais o trabalho gera mais threads do que processadores, e cada thread adicional custa memória e tempo de contexto. Dividir de menos e você deixa núcleos ociosos. A regra geral que eu uso como referência é tentar manter o número de tarefas ativas próximo ao número de núcleos físicos da máquina, e não o número de núcleos lógicos. Em processadores com hyperthreading ou SMT, os núcleos lógicos compartilham recursos internos, então o paralelismo real é menor do que o número de threads que o sistema operacional reporta. Tem ainda o problema dos dados compartilhados. Se duas threads precisam escrever no mesmo buffer ou ler a mesma variável de estado sem sincronização adequada, você vai enfrentar condições de corrida que são praticamente impossíveis de debugar. Um caso que me marcou foi quando eu estava construindo um agregador de métricas em Python usando multiprocessing. Duas workers escreviam em uma lista compartilhada e, de tempos em tempos, o resultado final estava com valores duplicados ou faltando. A solução foi trocar a lista por uma Queue do módulo multiprocessing, que garante serialização segura, e deixar que um processo consumidor único lê as mensagens na ordem correta. Antes disso, eu já tinha gastado dois dias tentando encontrar o bug com prints e logs, sem sucesso, porque o problema só aparecia sob carga.
O paralelismo também tem limites que não adianta ignorar. A Lei de Amdahl diz que o ganho máximo é limitado pela parte do programa que não pode ser paralelizada. Se 10% do seu código é sequencial por necessidade inerente do algoritmo, mesmo com infinitos processadores o melhor speedup possível é 10x. Isso significa que adicionar mais núcleos a partir de certo ponto traz retornos decrescentes e, em muitos casos, insignificantes. Na prática, eu recomendo medir o tempo gasto nas seções críticas antes de qualquer esforço de paralelização. Se 80% do tempo total está em uma única função que depende do resultado da anterior, parallelizar o restante do código vai dar um ganho marginal. Para quem está começando, uma alternativa mais segura do que thread management manual é usar bibliotecas de alto nível. No Python, o módulo concurrent.futures com ThreadPoolExecutor ou ProcessPoolExecutor abstrai a maioria da complexidade. No Go, goroutines com channels resolvem parte grande dos problemas de sincronização de forma idiomática. Em linguagens como Rust, o sistema de ownership impede muitos erros de race condition em tempo de compilação, o que elimina uma classe inteira de bugs que leva horas para investigar.
O importante é entender que paralelismo não é uma solução mágica para problemas de performance. É uma ferramenta específica para problemas que têm uma estrutura divisível e onde o custo de coordenação é menor do que o benefício do processamento simultâneo. Antes de paralelizar qualquer coisa, pergunte se o seu problema cabe em uma dessas categorias. Se não cabe, o tempo que você gastaria tentando fazê-lo caber provavelmente seria melhor investido otimizando o algoritmo original ou reduzindo a escala do problema.
