O que você realmente precisa saber sobre performance de CPU
A primeira coisa que a maioria das pessoas faz ao comprar um processador é olhar para o número de núcleos e torcer. Isso funciona até você tentar rodar compiladores paralelos ou VMs simultâneas e perceber que dois processadores com o mesmo core count podem ter diferença de 40% em throughput real. A medição da capacidade de um processador não é uma coisa só. É um conjunto de métricas que se contradizem frequentemente, e entender isso evita gastar dinheiro à toa. Como é medida a capacidade do processador envolve três camadas principais: frequência, arquitetura e eficiência por ciclo. A frequência (GHz) é a métrica mais visível, mas também a mais enganosa. Um chip de 3.0 GHz baseado em Zen 4 pode superar um de 4.5 GHz baseado em Skylake em tarefas multi-thread porque tem mais instrucciones por clock, melhor branch prediction e um IPC significativamente maior. IPC é o número de instruções executadas por ciclo de relógio, e esse é o dado que os fabricantes não colocam em caixa nas prateleiras.
No meu dia a dia, trabalho com benchmarks de stress e análise comparativa entre gerações. Certa vez precisei comparar um Intel Core i7-12700K com um Ryzen 7 5800X3D num cenário específico de renderização de vídeo com codecs AV1 que dependiam fortemente de single-thread performance. O 5800X3D tinha clock base menor, mas o cache L3 enorme mudava completamente o cenário. O i7 ganhava em multitarefa pura, mas no workload específico, o Ryzen empatava em alguns trechos porque o cache reduzia acessos à memória RAM. A solução foi rodar o trabalho em ciclos separados, medir com hwmon e Linux perf, e usar cset para pinar threads aos núcleos corretos e evitar migração entre big.LITTLE que distorcia os resultados. Levei cerca de três horas para chegar a um dado confiável, enquanto uma benchmark genérica daria uma resposta errada em cinco minutos.
Métricas que realmente importam na prática
O IPC não é divulgado oficialmente pela maioria dos fabricantes. Você precisa derivar de benchmarks como SPECint ou Geomean do PassMark, cruzando com a frequência nominal. Um jeito mais direto é usar ferramentas como perf do Linux, rdmsr para ler MSRs de contadores de hardware, ou o próprio Ryzen Master para chips AMD. Para Intel, o Intel Processor Identifier e o Turbo Boost Max 3.0 Scheduler ajudam a mapear qual núcleo é o melhor para tarefas sensíveis a latency. Core count é útil, mas só quando o software escala. Programas tradicionais ainda rodam fortemente em single-thread, então núcleos extras só ajudam se você tiver workloads multi-threaded nativos. Thread count (hyperthreading/SMT) dobra os threads lógicos, mas isso não significa dobro de performance. Na prática, SMT costuma dar ganho de 15 a 30% em cargas paralelas, e em alguns casos chega a 5% ou menos porque os dois threads competem pelos mesmos recursos executáveis.
👉 Clique no botão abaixo para saber mais sobre o assunto!
TDP e power draw são outra armadilha comum. Um processador de 65W TDP pode entregar performance superior a um de 125W se o cooler permitir manter boost frequencies por mais tempo. O problema é que muitos vendors medem TDP em condições específicas de laboratório que não refletem o uso contínuo. A watt efficiency (performance por watt) é a métrica que eu confio mais para desktops e notebooks, porque relaciona throughput real com consumo energético sustentado.
Como fazer medição caseira sem precisar de laboratório
Você pode instalar o sysbench e rodar testes de CPU pura com múltiplas threads. O comando sysbench cpu --threads=8 run mostra quantos eventos por segundo cada configuração produz. Para testes mais realistas, use o Prime95 com configurações small FFTs para stress de all-core, ou o Cinebench R23 para benchmark multi-thread e single-thread isolado. Anote os scores e compare com dados públicos do mesmo modelo para ter uma baseline. Se você tem Linux, o comando perf stat -a sleep 30 coleta contadores de hardware durante 30 segundos de uso normal ou carregado. Isso revela miss rate de cache, cycles per instruction, e stalls, dados que benchmarks prontos nunca mostram. Com esse nível de detalhe, é possível identificar gargalos que parecem invisíveis em benchmarks convencionais. Por exemplo, um sistema pode ter bom IPC mas suffering de memory wall se o banco L3 não for suficiente e o controller de memória estiver limitando a banda disponível.
A parte chata é que resultados de benchmark sempre dependem do contexto térmico, da configuração de BIOS, da versão de firmware e até da tensão aplicada. Eu já vi máquinas que perdiam 12% de performance só porque a BIOS estava em modo eco para poupar energia. Desativar c-states e colocar o plano de energia em performance resolve, mas aumenta o consumo em repouso. Não existe configuração universal, então a medição precisa ser feita no mesmo setup onde o processador vai trabalhar de fato.
Onde as métricas falham completamente
Benchmarks de produtividade não traduzem bem para jogos, e benchmarks de jogos não traduzem para compiladores. Um chip pode ser rei em Blender e medíocre em Valorant porque a latência de cache e a frequência de boost importam de formas diferentes. A diferença entre DDR5-5600 e DDR5-6000 pode ser 5% em alguns workloads e 25% em outros, dependendo se o processador é sensível a latency de memória. A principal limitação é que nenhuma métrica única captura tudo. Frequência alta sem IPC bom é desperdício de energia. Muitos núcleos sem software que os use são custo sem retorno. O conselho prático é sempre cruzar pelo menos três métricas: IPC estimado, frequências de boost sustentadas sob load all-core, e performance por watt no seu workload real. Se você tiver como rodar o próprio software que vai usar, faça isso antes de decidir. Benchmarks de terceiros são bons para referência, mas raramente replicam exatamente o que acontece na sua máquina com seus arquivos e configurações.
