Metodyka benchmarku

PCBenchmarkX mierzy wykonanie zadanych scenariuszy CPU/GPU oraz opóźnienie reakcji na sygnał programowy. Objętość pracy jest stała, formuły oceny są jawne. Powtórne uruchomienia pozwalają sprawdzić stabilność wyniku.

Ta dokumentacja dotyczy silnika 0.5.2, obciążenia phase4.6-dev-1, statystyki stats-phase4.6-v1 i modelu score-model-1.2-candidate-1. W nazwie modelu użyto Candidate. Jego wartości normalizacyjne są wstępne: nie można ich uznawać za średnie wskaźniki wszystkich komputerów. Więcej o wzorcu opisano w obliczaniu punktów.

Przygotowanie

BoosterX steruje uruchomieniem osobnego natywnego silnika, pokazuje przebieg testu i zapisuje wynik. Na czas pomiaru wstrzymuje własny monitoring sprzętu i pamięci oraz minimalizuje swoje okna, a następnie przywraca ich stan. Zmniejsza to wpływ samego interfejsu BoosterX; programy zewnętrzne i tak mogą tworzyć obciążenie.

Powtarzaj testy z jedną wersją silnika i sterownika, takimi samymi ustawieniami zasilania, podkręcania i chłodzenia. Zamknij zbędne programy działające w tle. Jeśli masz laptopa, wykonuj wszystkie testy z podłączoną ładowarką. Porównując stan przed zmianą i po niej, zapisz, które dokładnie ustawienie zmieniłeś.

Sekwencja Candidate

Część uruchomienia	Zadany czas trwania	Przeznaczenie
Rozgrzewka	15 s	Przygotować obciążenie do pomiarów zaliczanych
CPU	20 s łącznie	Trzy bloki po około 6,67 s
GPU	30 s łącznie	Po 10 s na Geometry, Shader i Compute, każdy w trzech blokach
Combined	30 s łącznie	Trzy bloki po 10 s
Kalibracja	10 s	Dobrać złożoność Loaded Latency
Rozgrzewka opóźnienia	2 s	Przygotować osobną ścieżkę pomiaru opóźnienia
Baseline Latency	5 s	Zmierzyć opóźnienie przy podstawowym obciążeniu
Loaded Latency	20 s	Zmierzyć opóźnienie przy skalibrowanym obciążeniu

Przejścia, przygotowanie zasobów, wstępne klatki CPU i zakończenie dodają czas. Dlatego całkowity czas uruchomienia jest większy niż suma mierzonych etapów: w sprawdzonej serii odstępy między początkami sąsiednich uruchomień w jednym obciążeniu wynosiły około 157–172 sekundy — z uwzględnieniem pauzy między uruchomieniami; dokładnego czasu trwania jednego uruchomienia nie można ustalić na podstawie opublikowanych danych.

Bloki testów wydajności przeplatają się w trzech rundach. W CPU przed każdym zaliczanym blokiem jest stały stan początkowy i 512 klatek przygotowawczych. Jeśli szybkość działania stopniowo zmienia się z bloku na blok, znajduje to odzwierciedlenie w diagnostyce. Otrzymane wyniki nie są przy tym korygowane.

Profile uruchomienia i czasy trwania

Silnik obsługuje cztery profile: candidate, quick, extended i custom. Dokładne czasy trwania etapów:

Profil	Zadanie	Przejście	Rozgrzewka	CPU	GPU	Combined	Kalibracja	Rozgrzewka opóźnienia	Baseline	Loaded
Candidate	kanoniczny	0,5 s	15 s	20 s	30 s	30 s	10 s	2 s	5 s	20 s
Quick	diagnostyczny	0,25 s	7,5 s	10 s	15 s	15 s	5 s	1 s	2,5 s	10 s
Extended	diagnostyczny	1 s	30 s	40 s	60 s	60 s	20 s	4 s	10 s	40 s
Custom	użytkownika	do wyboru użytkownika w dopuszczalnych granicach

Candidate to profil domyślny i tylko jego uruchomienia są klasyfikowane. Quick, Extended i Custom zawsze uchodzą za diagnostyczne: nie można ich mieszać z Candidate w jednym porównaniu ani publikować w rankingu. W Custom można zostawić część testów i ustawić własne czasy trwania: bloki zaliczane przyjmują 1–180 s, przejścia — 0,1–180 s, rozgrzewka opóźnienia — 0,5–180 s. Każde nadpisanie czasu trwania czyni uruchomienie diagnostycznym.

Zbieranie bez zapisu na dysk w każdej klatce

Pomiary są zapisywane w z góry przydzielonych blokach pamięci. Przy zbieraniu każdej klatki program nie formatuje JSON, nie powiększa wektora i nie zapisuje do pliku. Rozmiar buforów jest obliczany z góry na podstawie czasu trwania testu i oczekiwanej maksymalnej częstotliwości zapisów, z zapasem. W tej implementacji obowiązuje limit 768 MiB.

Po zakończeniu pracy GPU dane są łączone i przetwarzane. Zmniejsza to wpływ zbierania danych na test, choć samo zbieranie również zużywa zasoby. Aby zmierzyć jego wpływ, trzeba osobno porównać uruchomienia ze zbieraniem pomiarów i bez niego.

Wynik zawiera metryki zbiorcze. Osobny plik surowych pomiarów pozwala powtórzyć przetwarzanie statystyczne bez ponownego wykonywania obciążenia. Takie przeliczenie sprawdza obliczenia; do sprawdzenia powtarzalności na sprzęcie potrzebne jest nowe uruchomienie.

Jakość uruchomienia i nieprzydatność wyniku

Podczas każdego bloku silnik ocenia jakość uruchomienia — Run Quality. Głównym wskaźnikiem jest obciążenie CPU w tle, czyli wszystko, co obciąża system poza samym benchmarkiem. Jest ono obliczane dla bloku jako różnica między obciążeniem całego systemu a obciążeniem procesu benchmarku, zmierzonymi za pomocą tych samych liczników czasu. Wartości progowe dla profilu Candidate: powyżej 20% — ostrzeżenie, powyżej 50% — uruchomienie uznaje się za nieprzydatne.

Run Quality rejestruje także warunki towarzyszące: podłączony debugger, sesję zdalną, zasilanie z baterii i tryb oszczędzania energii, obecność hiperwizora, utratę fokusu okna i zmianę ekranu. Hiperwizor, bateria i sesja zdalna są ujawniane jako ostrzeżenia: same w sobie nie odrzucają wyniku, ale wyjaśniają, dlaczego liczby mogą różnić się od „czystego” stanowiska. Zmiana ekranu podczas zaliczanego bloku czyni uruchomienie nieprzydatnym.

Przydatny wynik zaliczany dodatkowo wymaga:

• udanej kalibracji Loaded Latency — jeśli nie udało się dobrać złożoności do docelowego czasu, uruchomienie jest nieprzydatne;
• zaliczonej kontroli wyjścia obciążeń GPU — niezgodność sygnatury kontrolnej czyni uruchomienie nieprzydatnym;
• braku utraconych zapisów kolektora — każda utrata czyni uruchomienie nieprzydatnym.

Klasyfikacja jakości jest zapisywana w pliku wyniku, więc „złe” warunki są widoczne po fakcie, a nie tylko podczas uruchomienia.

Jak czytać wynik

Wskaźnik	Znaczenie
Performance	Względna szybkość stałych obciążeń
Core Latency Score	Względna ocena wewnętrznego opóźnienia; więcej punktów jest lepiej
Consistency	Wyraźność wolnego ogona wewnątrz uruchomienia
PC Score	Geometryczne połączenie trzech składników z wagami 50/30/20

Rzeczywiste opóźnienia są pokazywane w milisekundach i dla nich mniej jest lepiej. Consistency nie można mieszać z powtarzalnością PC Score między uruchomieniami. Formuły i stałe normalizacyjne są jawne w obliczaniu punktów.

Granice wyniku

• Scenariusz syntetyczny pomaga wykrywać zmiany systemu, ale nie zastępuje testu konkretnej gry.
• Niski rozrzut między uruchomieniami jeszcze nie dowodzi dokładności każdego znacznika czasu ani braku błędu systematycznego.
• Osiem uruchomień jednego komputera nie ustala rozkładu wyników dla wszystkich CPU, GPU i wersji Windows.
• Porównuj zgodne wersje obciążeń i takie same profile. Profilu przyspieszonego, rozszerzonego i użytkownika nie można bezwarunkowo mieszać z Candidate.
• Anulowanego lub niepełnego uruchomienia nie używaj zamiast ukończonego pomiaru.

Dalej: obciążenia, opóźnienia i PresentMon, formuły, powtarzalność, porównanie uruchomień, ranking.

Sprawdzone: 2026-09-20.