Metodologi benchmark
Di halaman ini
PCBenchmarkX mengukur eksekusi skenario CPU/GPU yang telah ditentukan dan latensi respons terhadap sinyal perangkat lunak. Volume kerja bersifat tetap, rumus penilaian terbuka. Pengulangan eksekusi memungkinkan pemeriksaan kestabilan hasil.
Dokumentasi ini merujuk pada mesin 0.5.2, beban phase4.6-dev-1, statistik stats-phase4.6-v1, dan model score-model-1.2-candidate-1. Nama model menggunakan Candidate. Nilai normalisasinya bersifat sementara: nilai tersebut tidak dapat dianggap sebagai rata-rata semua komputer. Penjelasan lebih lanjut tentang acuan diuraikan dalam perhitungan skor.
Persiapan
Section titled “Persiapan”BoosterX mengendalikan eksekusi mesin native terpisah, menampilkan kemajuan pengujian, dan menyimpan hasil. Selama pengukuran, BoosterX menghentikan sementara pemantauan perangkat keras dan memori miliknya sendiri serta meminimalkan jendelanya, lalu memulihkan keadaannya. Hal ini mengurangi pengaruh antarmuka BoosterX itu sendiri; program eksternal tetap dapat menciptakan beban.
Ulangi pengujian dengan versi mesin dan driver yang sama, pengaturan daya, overclocking, dan pendinginan yang identik. Tutup program latar belakang yang tidak perlu. Jika Anda menggunakan laptop, lakukan semua pengujian dengan adaptor daya terhubung. Saat membandingkan sebelum dan sesudah perubahan, catat pengaturan mana yang Anda ubah.
Urutan Candidate
Section titled “Urutan Candidate”| Bagian eksekusi | Durasi yang ditentukan | Tujuan |
|---|---|---|
| Pemanasan | 15 s | Mempersiapkan beban hingga pengukuran yang dihitung |
| CPU | 20 s total | Tiga blok masing-masing sekitar 6,67 s |
| GPU | 30 s total | Masing-masing 10 s untuk Geometry, Shader, dan Compute, setiap bagian dalam tiga blok |
| Combined | 30 s total | Tiga blok masing-masing 10 s |
| Kalibrasi | 10 s | Menyesuaikan kompleksitas Loaded Latency |
| Pemanasan latensi | 2 s | Mempersiapkan jalur pengukuran latensi terpisah |
| Baseline Latency | 5 s | Mengukur latensi pada beban dasar |
| Loaded Latency | 20 s | Mengukur latensi pada beban terkalibrasi |
Transisi, persiapan sumber daya, frame CPU pendahuluan, dan penyelesaian menambah waktu. Oleh karena itu, total waktu eksekusi lebih besar daripada jumlah tahap yang diukur: dalam seri terverifikasi, interval antara awal eksekusi yang berdekatan dalam satu beban adalah sekitar 157–172 detik — dengan memperhitungkan jeda antar eksekusi; durasi tepat satu eksekusi tidak dapat ditentukan dari data yang dipublikasikan.
Blok pengujian performa bergantian dalam tiga ronde. Pada CPU, sebelum setiap blok yang dihitung terdapat keadaan awal yang tetap dan 512 frame persiapan. Jika kecepatan kerja berubah secara bertahap dari blok ke blok, hal ini tercermin dalam diagnostik. Hasil yang diperoleh tidak dikoreksi.
Profil eksekusi dan durasi
Section titled “Profil eksekusi dan durasi”Mesin mendukung empat profil: candidate, quick, extended, dan custom. Durasi tahap yang tepat:
| Profil | Tugas | Transisi | Pemanasan | CPU | GPU | Combined | Kalibrasi | Pemanasan latensi | Baseline | Loaded |
|---|---|---|---|---|---|---|---|---|---|---|
| Candidate | kanonis | 0,5 s | 15 s | 20 s | 30 s | 30 s | 10 s | 2 s | 5 s | 20 s |
| Quick | diagnostik | 0,25 s | 7,5 s | 10 s | 15 s | 15 s | 5 s | 1 s | 2,5 s | 10 s |
| Extended | diagnostik | 1 s | 30 s | 40 s | 60 s | 60 s | 20 s | 4 s | 10 s | 40 s |
| Custom | pengguna | sesuai pilihan pengguna dalam batas yang diizinkan |
Candidate adalah profil default, dan hanya eksekusinya yang diperingkat. Quick, Extended, dan Custom selalu dianggap diagnostik: eksekusi tersebut tidak dapat dicampur dengan Candidate dalam satu perbandingan dan tidak dapat dipublikasikan ke peringkat. Dalam Custom, Anda dapat menyisakan sebagian pengujian dan menentukan durasi sendiri: blok yang dihitung menerima 1–180 s, transisi — 0,1–180 s, pemanasan latensi — 0,5–180 s. Setiap penimpaan durasi membuat eksekusi menjadi diagnostik.
Pengumpulan tanpa penulisan ke disk pada setiap frame
Section titled “Pengumpulan tanpa penulisan ke disk pada setiap frame”Pengukuran disimpan dalam blok memori yang telah dialokasikan sebelumnya. Saat mengumpulkan setiap frame, program tidak memformat JSON, tidak memperluas vektor, dan tidak menulis ke file. Ukuran buffer dihitung sebelumnya berdasarkan durasi pengujian dan frekuensi pencatatan maksimum yang diharapkan, dengan cadangan. Dalam implementasi ini berlaku batas 768 MiB.
Setelah pekerjaan GPU selesai, data digabungkan dan diproses. Hal ini mengurangi pengaruh pengumpulan data terhadap pengujian, meskipun pengumpulan itu sendiri juga mengonsumsi sumber daya. Untuk mengukur pengaruhnya, perlu membandingkan secara terpisah eksekusi dengan pengumpulan pengukuran dan tanpa pengumpulan.
Hasil berisi metrik ringkasan. File pengukuran mentah terpisah memungkinkan pengulangan pemrosesan statistik tanpa menjalankan ulang beban. Perhitungan ulang semacam itu memverifikasi komputasi; untuk memverifikasi keterulangan pada perangkat keras diperlukan eksekusi baru.
Kualitas eksekusi dan ketidaklayakan hasil
Section titled “Kualitas eksekusi dan ketidaklayakan hasil”Selama setiap blok, mesin menilai kualitas eksekusi — Run Quality. Indikator utamanya adalah beban CPU latar belakang, yaitu segala hal yang membebani sistem selain benchmark itu sendiri. Nilai ini dihitung per blok sebagai selisih antara beban seluruh sistem dan beban proses benchmark, yang diukur dengan penghitung waktu yang sama. Nilai ambang untuk profil Candidate: di atas 20% — peringatan, di atas 50% — eksekusi dinyatakan tidak layak.
Run Quality juga mencatat kondisi terkait: debugger yang terhubung, sesi jarak jauh, daya dari baterai dan mode hemat daya, keberadaan hypervisor, kehilangan fokus jendela, dan pergantian layar. Hypervisor, baterai, dan sesi jarak jauh diungkapkan sebagai peringatan: hal-hal tersebut sendiri tidak menolak hasil, tetapi menjelaskan mengapa angka dapat berbeda dari standar “bersih”. Pergantian layar selama blok yang dihitung membuat eksekusi tidak layak.
Hasil yang dihitung dan layak juga memerlukan:
- kalibrasi Loaded Latency yang berhasil — jika kompleksitas tidak dapat disesuaikan dengan waktu target, eksekusi tidak layak;
- pemeriksaan keluaran beban GPU yang lulus — ketidakcocokan tanda tangan kontrol membuat eksekusi tidak layak;
- tidak adanya catatan kolektor yang hilang — setiap kehilangan membuat eksekusi tidak layak.
Klasifikasi kualitas disimpan dalam file hasil, sehingga kondisi “buruk” terlihat setelah fakta, bukan hanya selama eksekusi.
Cara membaca hasil
Section titled “Cara membaca hasil”| Indikator | Arti |
|---|---|
| Performance | Kecepatan relatif beban tetap |
| Core Latency Score | Penilaian relatif latensi internal; semakin banyak poin semakin baik |
| Consistency | Seberapa menonjol ekor lambat di dalam eksekusi |
| PC Score | Penggabungan geometris tiga komponen dengan bobot 50/30/20 |
Latensi nyata ditampilkan dalam milidetik, dan untuk itu semakin kecil semakin baik. Consistency tidak dapat dicampur dengan keterulangan PC Score antar eksekusi. Rumus dan konstanta normalisasi terbuka dalam perhitungan skor.
Batasan hasil
Section titled “Batasan hasil”- Skenario sintetis membantu mendeteksi perubahan sistem, tetapi tidak menggantikan pengujian game tertentu.
- Sebaran antar eksekusi yang rendah belum membuktikan ketepatan setiap tanda waktu atau tidak adanya kesalahan sistematis.
- Delapan eksekusi pada satu PC tidak menetapkan distribusi hasil untuk semua CPU, GPU, dan versi Windows.
- Bandingkan versi beban yang kompatibel dan profil yang sama. Profil dipercepat, diperluas, dan pengguna tidak dapat begitu saja dicampur dengan Candidate.
- Jangan gunakan eksekusi yang dibatalkan atau tidak lengkap sebagai pengganti pengukuran yang telah selesai.
Selanjutnya: beban, latensi dan PresentMon, rumus, keterulangan, perbandingan eksekusi, peringkat.
Terverifikasi: 2026-09-20.
