Metodologia del benchmark

PCBenchmarkX misura l’esecuzione di scenari CPU/GPU definiti e la latenza di reazione a un segnale software. Il volume di lavoro è fisso, le formule di valutazione sono aperte. Le esecuzioni ripetute permettono di verificare la stabilità del risultato.

Questa documentazione si riferisce al motore 0.5.2, al carico phase4.6-dev-1, alla statistica stats-phase4.6-v1 e al modello score-model-1.2-candidate-1. Nel nome del modello è usato Candidate. I suoi valori di normalizzazione sono preliminari: non possono essere considerati medie di tutti i computer. Maggiori dettagli sul riferimento sono descritti nel calcolo dei punteggi.

Preparazione

BoosterX gestisce l’avvio di un motore nativo separato, mostra l’avanzamento del test e salva il risultato. Durante la misurazione sospende il proprio monitoraggio dell’hardware e della memoria e riduce a icona le proprie finestre, poi ne ripristina lo stato. Questo riduce l’influenza dell’interfaccia di BoosterX stessa; i programmi esterni possono comunque creare carico.

Ripeti i test con la stessa versione del motore e del driver, con le stesse impostazioni di alimentazione, overclock e raffreddamento. Chiudi i programmi in background superflui. Se hai un portatile, esegui tutti i test con l’alimentatore collegato. Quando confronti prima e dopo una modifica, annota quale impostazione hai cambiato esattamente.

Sequenza Candidate

Parte dell’esecuzione	Durata definita	Scopo
Riscaldamento	15 s	Preparare il carico alle misurazioni valide
CPU	20 s in totale	Tre blocchi di circa 6,67 s
GPU	30 s in totale	10 s ciascuno su Geometry, Shader e Compute, in tre blocchi
Combined	30 s in totale	Tre blocchi da 10 s
Calibrazione	10 s	Selezionare la complessità di Loaded Latency
Riscaldamento latenza	2 s	Preparare il percorso separato di misurazione della latenza
Baseline Latency	5 s	Misurare la latenza con carico di base
Loaded Latency	20 s	Misurare la latenza con carico calibrato

Le transizioni, la preparazione delle risorse, i frame CPU preliminari e la conclusione aggiungono tempo. Perciò il tempo totale di esecuzione è maggiore della somma delle fasi misurate: nella serie verificata gli intervalli tra gli inizi di esecuzioni adiacenti in una stessa sessione erano di circa 157–172 secondi — tenendo conto della pausa tra le esecuzioni; la durata esatta di una singola esecuzione non può essere determinata dai dati pubblicati.

I blocchi dei test di prestazioni si alternano in tre round. Per la CPU, prima di ogni blocco valido c’è uno stato iniziale fisso e 512 frame preparatori. Se la velocità di lavoro cambia gradualmente da un blocco all’altro, questo si riflette nella diagnostica. I risultati ottenuti non vengono tuttavia corretti.

Profili di esecuzione e durate

Il motore supporta quattro profili: candidate, quick, extended e custom. Durate esatte delle fasi:

Profilo	Attività	Transizione	Riscaldamento	CPU	GPU	Combined	Calibrazione	Riscaldamento latenza	Baseline	Loaded
Candidate	canonico	0,5 s	15 s	20 s	30 s	30 s	10 s	2 s	5 s	20 s
Quick	diagnostico	0,25 s	7,5 s	10 s	15 s	15 s	5 s	1 s	2,5 s	10 s
Extended	diagnostico	1 s	30 s	40 s	60 s	60 s	20 s	4 s	10 s	40 s
Custom	personalizzato	a scelta dell’utente entro i limiti consentiti

Candidate è il profilo predefinito, e solo le sue esecuzioni vengono classificate. Quick, Extended e Custom sono sempre considerati diagnostici: non possono essere mescolati con Candidate in un unico confronto e non possono essere pubblicati nella classifica. In Custom si può lasciare una parte dei test e impostare durate proprie: i blocchi validi accettano 1–180 s, le transizioni — 0,1–180 s, il riscaldamento della latenza — 0,5–180 s. Qualsiasi ridefinizione della durata rende l’esecuzione diagnostica.

Raccolta senza scrittura su disco in ogni frame

Le misurazioni vengono salvate in blocchi di memoria preallocati. Durante la raccolta di ogni frame il programma non formatta JSON, non espande il vettore e non scrive su file. La dimensione dei buffer è calcolata in anticipo in base alla durata del test e alla frequenza massima di scrittura prevista, con margine. In questa implementazione vale un limite di 768 MiB.

Al termine del lavoro GPU i dati vengono uniti ed elaborati. Questo riduce l’influenza della raccolta dati sul test, sebbene la raccolta stessa consumi anch’essa risorse. Per misurarne l’influenza, occorre confrontare separatamente esecuzioni con e senza la raccolta delle misurazioni.

Il risultato contiene metriche riassuntive. Un file separato delle misurazioni grezze permette di ripetere l’elaborazione statistica senza una nuova esecuzione del carico. Tale ricalcolo verifica i calcoli; per verificare la ripetibilità sull’hardware serve una nuova esecuzione.

Qualità dell’esecuzione e inidoneità del risultato

Durante ogni blocco il motore valuta la qualità dell’esecuzione — Run Quality. L’indicatore principale è il carico CPU in background, cioè tutto ciò che carica il sistema oltre al benchmark stesso. Esso viene calcolato per blocco come differenza tra il carico dell’intero sistema e il carico del processo del benchmark, misurati sugli stessi contatori di tempo. I valori di soglia per il profilo Candidate: oltre 20% — avviso, oltre 50% — l’esecuzione è riconosciuta inidonea.

Run Quality registra anche le condizioni accessorie: debugger collegato, sessione remota, alimentazione a batteria e modalità di risparmio energetico, presenza di un hypervisor, perdita del focus della finestra e cambio di display. Hypervisor, batteria e sessione remota vengono segnalati come avvisi: di per sé non scartano il risultato, ma spiegano perché i numeri possono differire da un banco di prova “pulito”. Il cambio di display durante un blocco valido rende l’esecuzione inidonea.

Un risultato valido idoneo richiede inoltre:

• una calibrazione riuscita di Loaded Latency — se non è stato possibile selezionare la complessità in base al tempo target, l’esecuzione è inidonea;
• una verifica superata dell’uscita dei carichi GPU — una mancata corrispondenza della firma di controllo rende l’esecuzione inidonea;
• l’assenza di record persi del collector — qualsiasi perdita rende l’esecuzione inidonea.

La classificazione della qualità viene salvata nel file del risultato, quindi le condizioni “cattive” sono visibili a posteriori, non solo durante l’esecuzione.

Come leggere il risultato

Indicatore	Significato
Performance	Velocità relativa dei carichi fissi
Core Latency Score	Valutazione relativa della latenza interna; più punti è meglio
Consistency	Pronunciatezza della coda lenta all’interno dell’esecuzione
PC Score	Unione geometrica di tre componenti con pesi 50/30/20

Le latenze reali sono mostrate in millisecondi, e per esse meno è meglio. Consistency non può essere confuso con la ripetibilità di PC Score tra esecuzioni. Le formule e le costanti di normalizzazione sono aperte nel calcolo dei punteggi.

Limiti del risultato

• Lo scenario sintetico aiuta a individuare cambiamenti del sistema, ma non sostituisce il test di un gioco specifico.
• Una bassa dispersione tra esecuzioni non dimostra ancora l’accuratezza di ogni marca temporale o l’assenza di errore sistematico.
• Otto esecuzioni di un solo PC non stabiliscono la distribuzione dei risultati per tutti i CPU, GPU e versioni di Windows.
• Confronta versioni compatibili dei carichi e profili identici. I profili accelerato, esteso e personalizzato non possono essere mescolati incondizionatamente con Candidate.
• Un’esecuzione annullata o incompleta non va usata al posto di una misurazione completata.

Successivamente: carichi, latenze e PresentMon, formule, ripetibilità, confronto delle esecuzioni, classifica.

Verificato: 2026-09-20.