Benchmarkmetode

PCBenchmarkX måler udførelsen af definerede CPU/GPU-scenarier og reaktionstiden på et softwaresignal. Arbejdsmængden er fast, og vurderingsformlerne er åbne. Gentagne kørsler gør det muligt at kontrollere resultatets stabilitet.

Denne dokumentation vedrører motoren 0.5.2, belastningen phase4.6-dev-1, statistikken stats-phase4.6-v1 og modellen score-model-1.2-candidate-1. I modelnavnet bruges Candidate. Dens normaliseringsværdier er foreløbige: de kan ikke betragtes som gennemsnit for alle computere. Mere om referenceværdien findes i beregning af point.

Forberedelse

BoosterX styrer starten af en separat native motor, viser testens forløb og gemmer resultatet. Under målingen sætter den sin egen overvågning af hardware og hukommelse på pause og minimerer sine vinduer, hvorefter den gendanner deres tilstand. Dette reducerer selve BoosterX-grænsefladens indflydelse; eksterne programmer kan stadig skabe belastning.

Gentag testene med én version af motoren og driveren, samme indstillinger for strøm, overclocking og køling. Luk unødvendige baggrundsprogrammer. Hvis du har en bærbar computer, skal du udføre alle tests med strømadapteren tilsluttet. Når du sammenligner før og efter en ændring, skal du notere, hvilken indstilling du præcist har ændret.

Candidate-sekvens

Del af kørslen	Angivet varighed	Formål
Opvarmning	15 s	Forberede belastningen til de tællende målinger
CPU	20 s i alt	Tre blokke på cirka 6,67 s
GPU	30 s i alt	10 s hver til Geometry, Shader og Compute, hver i tre blokke
Combined	30 s i alt	Tre blokke på 10 s
Kalibrering	10 s	Tilpasse sværhedsgraden for Loaded Latency
Opvarmning af latens	2 s	Forberede en separat målevej for latens
Baseline Latency	5 s	Måle latens ved grundbelastning
Loaded Latency	20 s	Måle latens ved kalibreret belastning

Overgange, forberedelse af ressourcer, foreløbige CPU-billeder og afslutning tilføjer tid. Derfor er den samlede kørselstid større end summen af de målte etaper: i den verificerede serie var intervallerne mellem starten af nabokørsler i samme indlæsning cirka 157–172 sekunder — inklusive pausen mellem kørslerne; den nøjagtige varighed af en enkelt kørsel kan ikke bestemmes ud fra de offentliggjorte data.

Blokkene med ydelsestests skifter i tre runder. For CPU er der en fast starttilstand og 512 forberedende billeder før hver tællende blok. Hvis hastigheden gradvist ændrer sig fra blok til blok, afspejles det i diagnostikken. De opnåede resultater korrigeres dog ikke.

Kørselsprofiler og varigheder

Motoren understøtter fire profiler: candidate, quick, extended og custom. De nøjagtige varigheder af etaperne:

Profil	Opgave	Overgang	Opvarmning	CPU	GPU	Combined	Kalibrering	Opvarmning af latens	Baseline	Loaded
Candidate	kanonisk	0,5 s	15 s	20 s	30 s	30 s	10 s	2 s	5 s	20 s
Quick	diagnostisk	0,25 s	7,5 s	10 s	15 s	15 s	5 s	1 s	2,5 s	10 s
Extended	diagnostisk	1 s	30 s	40 s	60 s	60 s	20 s	4 s	10 s	40 s
Custom	brugerdefineret	efter brugerens valg inden for tilladte grænser

Candidate er standardprofilen, og kun dens kørsler rangeres. Quick, Extended og Custom betragtes altid som diagnostiske: de kan ikke blandes med Candidate i samme sammenligning og kan ikke offentliggøres i ranglisten. I Custom kan man beholde en del af testene og angive sine egne varigheder: tællende blokke accepterer 1–180 s, overgange — 0,1–180 s, opvarmning af latens — 0,5–180 s. Enhver tilsidesættelse af varigheden gør kørslen diagnostisk.

Indsamling uden skrivning til disken i hvert billede

Målingerne gemmes i forudallokerede hukommelsesblokke. Ved indsamling af hvert billede formaterer programmet ikke JSON, udvider ikke vektoren og skriver ikke til en fil. Bufferstørrelserne beregnes på forhånd ud fra testens varighed og den forventede maksimale skrivefrekvens, med margin. I denne implementering gælder en grænse på 768 MiB.

Efter afslutningen af GPU-arbejdet kombineres og behandles dataene. Dette reducerer indsamlingens indflydelse på testen, selvom selve indsamlingen også bruger ressourcer. For at måle dens indflydelse skal man separat sammenligne kørsler med og uden indsamling af målinger.

Resultatet indeholder opsummerede målinger. En separat fil med rå målinger gør det muligt at gentage den statistiske behandling uden en ny udførelse af belastningen. En sådan genberegning kontrollerer beregningerne; for at kontrollere reproducerbarheden på hardware kræves en ny kørsel.

Kørselskvalitet og uanvendeligt resultat

Under hver blok vurderer motoren kørselskvaliteten — Run Quality. Det primære mål er CPU’ens baggrundsbelastning, det vil sige alt, der belaster systemet ud over selve benchmarken. Den beregnes pr. blok som forskellen mellem belastningen af hele systemet og belastningen af benchmarkprocessen, målt med de samme tidsmålinger. Grænseværdierne for profilen Candidate: over 20% — advarsel, over 50% — kørslen anses for uanvendelig.

Run Quality registrerer også ledsagende forhold: tilsluttet debugger, fjernsession, strøm fra batteri og strømsparetilstand, tilstedeværelse af hypervisor, tab af vinduesfokus og skift af skærm. Hypervisor, batteri og fjernsession vises som advarsler: de afviser ikke i sig selv resultatet, men forklarer, hvorfor tallene kan afvige fra en «ren» stand. Skift af skærm under en tællende blok gør kørslen uanvendelig.

Et anvendeligt tællende resultat kræver desuden:

• vellykket kalibrering af Loaded Latency — hvis det ikke lykkedes at tilpasse sværhedsgraden til målvarigheden, er kørslen uanvendelig;
• bestået kontrol af GPU-belastningernes afslutning — manglende overensstemmelse med kontrolsignaturen gør kørslen uanvendelig;
• ingen tabte poster i opsamleren — ethvert tab gør kørslen uanvendelig.

Kvalitetsklassificeringen gemmes i resultatfilen, så «dårlige» forhold er synlige bagefter og ikke kun under kørslen.

Sådan læses resultatet

Mål	Betydning
Performance	Relativ hastighed af faste belastninger
Core Latency Score	Relativ vurdering af intern latens; flere point er bedre
Consistency	Udtrykket for den langsomme hale inden for en kørsel
PC Score	Geometrisk sammenslutning af tre komponenter med vægte 50/30/20

Faktiske latenstider vises i millisekunder, og for dem er mindre bedre. Consistency må ikke forveksles med reproducerbarheden af PC Score mellem kørsler. Formler og normaliseringskonstanter er åbne i beregning af point.

Resultatets grænser

• Et syntetisk scenarie hjælper med at opdage ændringer i systemet, men erstatter ikke en test af et konkret spil.
• Lav spredning mellem kørsler beviser endnu ikke nøjagtigheden af hvert tidsstempel eller fraværet af en systematisk fejl.
• Otte kørsler på én PC fastlægger ikke fordelingen af resultater for alle CPU’er, GPU’er og Windows-versioner.
• Sammenlign kompatible versioner af belastninger og identiske profiler. Profilerne Quick, Extended og Custom kan ikke uden videre blandes med Candidate.
• Brug ikke en afbrudt eller ufuldstændig kørsel i stedet for en afsluttet måling.

Videre: belastninger, latens og PresentMon, formler, reproducerbarhed, sammenligning af kørsler, rangliste.

Verificeret: 2026-09-20.