Benchmark-Methodik

PCBenchmarkX misst die Ausführung vorgegebener CPU/GPU-Szenarien und die Reaktionslatenz auf ein Softwaresignal. Der Arbeitsumfang ist fest, die Bewertungsformeln sind offen. Wiederholte Läufe erlauben es, die Stabilität des Ergebnisses zu prüfen.

Diese Dokumentation bezieht sich auf die Engine 0.5.2, die Last phase4.6-dev-1, die Statistik stats-phase4.6-v1 und das Modell score-model-1.2-candidate-1. Im Namen des Modells wird Candidate verwendet. Seine Normierungswerte sind vorläufig: Sie dürfen nicht als Durchschnittswerte aller Computer betrachtet werden. Mehr zur Referenz steht in der Berechnung der Punkte.

Vorbereitung

BoosterX steuert den Start einer separaten nativen Engine, zeigt den Fortschritt des Tests an und speichert das Ergebnis. Während der Messung pausiert es seine eigene Überwachung von Hardware und Speicher und minimiert seine Fenster, danach stellt es deren Zustand wieder her. Das verringert den Einfluss der BoosterX-Oberfläche selbst; externe Programme können trotzdem Last erzeugen.

Wiederholen Sie die Tests mit einer Version der Engine und des Treibers, mit denselben Einstellungen für Energie, Übertaktung und Kühlung. Schließen Sie überflüssige Hintergrundprogramme. Wenn Sie ein Notebook verwenden, führen Sie alle Tests mit angeschlossenem Netzteil durch. Notieren Sie beim Vergleich vor und nach einer Änderung, welche Einstellung Sie genau geändert haben.

Ablauf von Candidate

Teil des Laufs	Vorgegebene Dauer	Zweck
Aufwärmen	15 s	Die Last auf die gewerteten Messungen vorbereiten
CPU	20 s insgesamt	Drei Blöcke von etwa 6,67 s
GPU	30 s insgesamt	Je 10 s für Geometry, Shader und Compute, jeweils in drei Blöcken
Combined	30 s insgesamt	Drei Blöcke von je 10 s
Kalibrierung	10 s	Die Komplexität von Loaded Latency einstellen
Aufwärmen der Latenz	2 s	Den separaten Pfad zur Latenzmessung vorbereiten
Baseline Latency	5 s	Die Latenz bei Grundlast messen
Loaded Latency	20 s	Die Latenz bei kalibrierter Last messen

Übergänge, Vorbereitung der Ressourcen, vorläufige CPU-Frames und der Abschluss kosten zusätzliche Zeit. Deshalb ist die Gesamtzeit eines Laufs größer als die Summe der gemessenen Etappen: in der geprüften Serie betrugen die Intervalle zwischen den Starts benachbarter Läufe innerhalb eines Bootvorgangs etwa 157–172 Sekunden — einschließlich der Pause zwischen den Läufen; die genaue Dauer eines einzelnen Laufs lässt sich aus den veröffentlichten Daten nicht bestimmen.

Die Blöcke der Leistungstests wechseln sich in drei Runden ab. Bei der CPU gibt es vor jedem gewerteten Block einen festen Anfangszustand und 512 vorbereitende Frames. Wenn sich die Arbeitsgeschwindigkeit von Block zu Block allmählich ändert, zeigt sich das in der Diagnose. Die erhaltenen Ergebnisse werden dabei nicht korrigiert.

Startprofile und Dauern

Die Engine unterstützt vier Profile: candidate, quick, extended und custom. Die genauen Dauern der Etappen:

Profil	Aufgabe	Übergang	Aufwärmen	CPU	GPU	Combined	Kalibrierung	Aufwärmen der Latenz	Baseline	Loaded
Candidate	kanonisch	0,5 s	15 s	20 s	30 s	30 s	10 s	2 s	5 s	20 s
Quick	diagnostisch	0,25 s	7,5 s	10 s	15 s	15 s	5 s	1 s	2,5 s	10 s
Extended	diagnostisch	1 s	30 s	40 s	60 s	60 s	20 s	4 s	10 s	40 s
Custom	benutzerdefiniert	nach Wahl des Benutzers innerhalb zulässiger Grenzen

Candidate ist das Standardprofil, und nur seine Läufe werden eingestuft. Quick, Extended und Custom gelten immer als diagnostisch: Sie dürfen nicht mit Candidate in einem Vergleich vermischt und nicht in die Rangliste aufgenommen werden. In Custom kann man einen Teil der Tests behalten und eigene Dauern festlegen: Die gewerteten Blöcke akzeptieren 1–180 s, Übergänge 0,1–180 s, das Aufwärmen der Latenz 0,5–180 s. Jede Überschreibung einer Dauer macht den Lauf diagnostisch.

Erfassung ohne Schreiben auf die Festplatte in jedem Frame

Die Messungen werden in vorab reservierte Speicherblöcke gespeichert. Bei der Erfassung jedes Frames formatiert das Programm kein JSON, erweitert keinen Vektor und schreibt nicht in eine Datei. Die Größe der Puffer wird vorab anhand der Testdauer und der erwarteten maximalen Aufzeichnungsrate mit Reserve berechnet. In dieser Implementierung gilt eine Begrenzung von 768 MiB.

Nach Abschluss der GPU-Arbeit werden die Daten zusammengeführt und verarbeitet. Das verringert den Einfluss der Datenerfassung auf den Test, obwohl die Erfassung selbst ebenfalls Ressourcen verbraucht. Um ihren Einfluss zu messen, muss man Läufe mit Erfassung der Messungen und ohne sie separat vergleichen.

Das Ergebnis enthält zusammenfassende Metriken. Eine separate Datei mit den Rohmessungen erlaubt es, die statistische Verarbeitung ohne erneute Ausführung der Last zu wiederholen. Eine solche Neuberechnung prüft die Berechnungen; zur Prüfung der Wiederholbarkeit auf der Hardware ist ein neuer Lauf nötig.

Qualität des Laufs und Unbrauchbarkeit des Ergebnisses

Während jedes Blocks bewertet die Engine die Qualität des Laufs — Run Quality. Der Hauptindikator ist die Hintergrundlast der CPU, also alles, was das System neben dem Benchmark selbst belastet. Sie wird pro Block als Differenz zwischen der Last des gesamten Systems und der Last des Benchmark-Prozesses berechnet, gemessen mit denselben Zeitzählern. Die Schwellenwerte für das Profil Candidate: über 20% — Warnung, über 50% — der Lauf wird als unbrauchbar anerkannt.

Run Quality erfasst außerdem begleitende Bedingungen: einen angeschlossenen Debugger, eine Remotesitzung, Batteriebetrieb und Energiesparmodus, das Vorhandensein eines Hypervisors, den Verlust des Fensterfokus und einen Displaywechsel. Hypervisor, Batterie und Remotesitzung werden als Warnungen ausgewiesen: Sie allein lehnen das Ergebnis nicht ab, erklären aber, warum die Zahlen von einem „sauberen“ Prüfstand abweichen können. Ein Displaywechsel während eines gewerteten Blocks macht den Lauf unbrauchbar.

Ein brauchbares gewertetes Ergebnis erfordert zusätzlich:

• eine erfolgreiche Kalibrierung von Loaded Latency — wenn es nicht gelungen ist, die Komplexität auf die Zielzeit einzustellen, ist der Lauf unbrauchbar;
• eine bestandene Prüfung des Ausgangs der GPU-Lasten — eine Nichtübereinstimmung der Kontrollsignatur macht den Lauf unbrauchbar;
• das Fehlen verlorener Einträge des Kollektors — jeder Verlust macht den Lauf unbrauchbar.

Die Klassifizierung der Qualität wird in der Ergebnisdatei gespeichert, deshalb sind „schlechte“ Bedingungen im Nachhinein sichtbar und nicht nur während des Laufs.

Wie man das Ergebnis liest

Kennzahl	Bedeutung
Performance	Relative Geschwindigkeit der festen Lasten
Core Latency Score	Relative Bewertung der internen Latenz; mehr Punkte sind besser
Consistency	Ausprägung des langsamen Ausläufers innerhalb eines Laufs
PC Score	Geometrische Zusammenführung dreier Komponenten mit Gewichten 50/30/20

Reale Latenzen werden in Millisekunden angezeigt, und für sie ist weniger besser. Consistency darf nicht mit der Wiederholbarkeit des PC Score zwischen Läufen vermischt werden. Die Formeln und Normierungskonstanten sind offen in der Berechnung der Punkte.

Grenzen des Ergebnisses

• Ein synthetisches Szenario hilft, Änderungen des Systems zu erkennen, ersetzt aber nicht den Test eines konkreten Spiels.
• Eine geringe Streuung zwischen Läufen beweist noch nicht die Genauigkeit jeder Zeitmarke oder das Fehlen eines systematischen Fehlers.
• Acht Läufe eines PCs legen nicht die Verteilung der Ergebnisse für alle CPUs, GPUs und Windows-Versionen fest.
• Vergleichen Sie kompatible Versionen der Lasten und gleiche Profile. Die beschleunigten, erweiterten und benutzerdefinierten Profile dürfen nicht bedingungslos mit Candidate vermischt werden.
• Verwenden Sie einen abgebrochenen oder unvollständigen Lauf nicht anstelle einer abgeschlossenen Messung.

Weiter: Lasten, Latenzen und PresentMon, Formeln, Wiederholbarkeit, Vergleich von Läufen, Rangliste.

Geprüft: 2026-09-20.