Metodologia do benchmark

PCBenchmarkX mede a execução de cenários de CPU/GPU definidos e a latência de reação a um sinal de software. O volume de trabalho é fixo, as fórmulas de avaliação são abertas. Execuções repetidas permitem verificar a estabilidade do resultado.

Esta documentação refere-se ao motor 0.5.2, à carga phase4.6-dev-1, às estatísticas stats-phase4.6-v1 e ao modelo score-model-1.2-candidate-1. O nome do modelo usa Candidate. Os seus valores de normalização são preliminares: não podem ser considerados médias de todos os computadores. Mais detalhes sobre o padrão de referência estão em cálculo de pontuação.

Preparação

O BoosterX controla a execução de um motor nativo separado, mostra o progresso do teste e guarda o resultado. Durante a medição, suspende a sua própria monitorização de hardware e memória e minimiza as suas janelas, restaurando depois o seu estado. Isto reduz a influência da própria interface do BoosterX; ainda assim, programas externos podem criar carga.

Repita os testes com a mesma versão do motor e do driver, com as mesmas definições de energia, overclocking e arrefecimento. Feche programas em segundo plano desnecessários. Se tiver um portátil, execute todos os testes com o carregador ligado. Ao comparar antes e depois de uma alteração, registe exatamente que definição alterou.

Sequência Candidate

Parte da execução	Duração definida	Finalidade
Aquecimento	15 s	Preparar a carga antes das medições válidas
CPU	20 s no total	Três blocos de aproximadamente 6,67 s
GPU	30 s no total	10 s para Geometry, Shader e Compute, cada um em três blocos
Combined	30 s no total	Três blocos de 10 s
Calibração	10 s	Ajustar a complexidade de Loaded Latency
Aquecimento da latência	2 s	Preparar o percurso separado de medição da latência
Baseline Latency	5 s	Medir a latência com carga base
Loaded Latency	20 s	Medir a latência com carga calibrada

As transições, a preparação de recursos, os fotogramas preliminares de CPU e a conclusão acrescentam tempo. Por isso, o tempo total de execução é maior do que a soma das etapas medidas: na série verificada, os intervalos entre os inícios de execuções consecutivas numa mesma carga eram de aproximadamente 157–172 segundos — contando com a pausa entre execuções; a duração exata de uma execução não pode ser determinada a partir dos dados publicados.

Os blocos de testes de desempenho alternam em três rondas. Na CPU, antes de cada bloco válido há um estado inicial fixo e 512 fotogramas preparatórios. Se a velocidade de trabalho mudar gradualmente de bloco para bloco, isso reflete-se no diagnóstico. Os resultados obtidos não são corrigidos por isso.

Perfis de execução e durações

O motor suporta quatro perfis: candidate, quick, extended e custom. Durações exatas das etapas:

Perfil	Tarefa	Transição	Aquecimento	CPU	GPU	Combined	Calibração	Aquecimento da latência	Baseline	Loaded
Candidate	canónico	0,5 s	15 s	20 s	30 s	30 s	10 s	2 s	5 s	20 s
Quick	diagnóstico	0,25 s	7,5 s	10 s	15 s	15 s	5 s	1 s	2,5 s	10 s
Extended	diagnóstico	1 s	30 s	40 s	60 s	60 s	20 s	4 s	10 s	40 s
Custom	do utilizador	à escolha do utilizador dentro dos limites permitidos

Candidate é o perfil predefinido, e só as suas execuções são classificadas. Quick, Extended e Custom são sempre considerados diagnósticos: não podem ser misturados com Candidate numa mesma comparação nem publicados na classificação. Em Custom é possível manter parte dos testes e definir durações próprias: os blocos válidos aceitam 1–180 s, as transições — 0,1–180 s, o aquecimento da latência — 0,5–180 s. Qualquer substituição da duração torna a execução diagnóstica.

Recolha sem escrita em disco em cada fotograma

As medições são guardadas em blocos de memória previamente alocados. Ao recolher cada fotograma, o programa não formata JSON, não expande o vetor e não escreve no ficheiro. O tamanho dos buffers é calculado antecipadamente com base na duração do teste e na frequência máxima esperada de registos, com margem. Nesta implementação aplica-se um limite de 768 MiB.

Após a conclusão do trabalho da GPU, os dados são combinados e processados. Isto reduz a influência da recolha de dados no teste, embora a própria recolha também consuma recursos. Para medir a sua influência, é necessário comparar separadamente execuções com e sem recolha de medições.

O resultado contém métricas resumidas. Um ficheiro separado de medições originais permite repetir o tratamento estatístico sem uma nova execução da carga. Esse recálculo verifica os cálculos; para verificar a repetibilidade no hardware é necessária uma nova execução.

Qualidade da execução e inadequação do resultado

Durante cada bloco, o motor avalia a qualidade da execução — Run Quality. O indicador principal é a carga de CPU em segundo plano, ou seja, tudo o que sobrecarrega o sistema além do próprio benchmark. É calculada por bloco como a diferença entre a carga de todo o sistema e a carga do processo do benchmark, medidas pelos mesmos contadores de tempo. Os valores-limite para o perfil Candidate: acima de 20% — aviso, acima de 50% — a execução é considerada inadequada.

O Run Quality também registra condições associadas: depurador ligado, sessão remota, alimentação por bateria e modo de poupança de energia, presença de hipervisor, perda de foco da janela e mudança de monitor. O hipervisor, a bateria e a sessão remota são apresentados como avisos: por si só não rejeitam o resultado, mas explicam porque os números podem diferir de um banco de testes «limpo». A mudança de monitor durante o bloco válido torna a execução inadequada.

Um resultado válido exige ainda:

• calibração bem-sucedida de Loaded Latency — se não foi possível ajustar a complexidade ao tempo-alvo, a execução é inadequada;
• verificação aprovada da saída das cargas de GPU — uma divergência da assinatura de controlo torna a execução inadequada;
• ausência de registos perdidos do coletor — qualquer perda torna a execução inadequada.

A classificação da qualidade é guardada no ficheiro de resultado, por isso as condições «más» ficam visíveis a posteriori, e não apenas durante a execução.

Como ler o resultado

Indicador	Significado
Performance	Velocidade relativa das cargas fixas
Core Latency Score	Avaliação relativa da latência interna; mais pontos é melhor
Consistency	Expressão da cauda lenta dentro da execução
PC Score	Combinação geométrica de três componentes com pesos 50/30/20

As latências reais são apresentadas em milissegundos, e para elas menos é melhor. A Consistency não pode ser confundida com a repetibilidade do PC Score entre execuções. As fórmulas e as constantes de normalização são abertas em cálculo de pontuação.

Limites do resultado

• O cenário sintético ajuda a detetar alterações no sistema, mas não substitui o teste de um jogo específico.
• Uma baixa dispersão entre execuções ainda não prova a exatidão de cada marca temporal nem a ausência de erro sistemático.
• Oito execuções de um mesmo PC não estabelecem a distribuição de resultados para todos os CPU, GPU e versões do Windows.
• Compare versões de cargas compatíveis e perfis iguais. Os perfis acelerado, expandido e do utilizador não podem ser misturados incondicionalmente com Candidate.
• Não use uma execução cancelada ou incompleta em vez de uma medição concluída.

A seguir: cargas, latências e PresentMon, fórmulas, repetibilidade, comparação de execuções, classificação.

Verificado: 2026-09-20.