דלגו לתוכן

מתודולוגיית בנצ'מרק

בדף זה

PCBenchmarkX מודד ביצוע של תרחישי CPU/GPU מוגדרים וזמן תגובה לאות תוכנה. נפח העבודה קבוע, נוסחאות ההערכה פתוחות. הרצות חוזרות מאפשרות לבדוק את יציבות התוצאה.

תיעוד זה מתייחס למנוע 0.5.2, לעומס phase4.6-dev-1, לסטטיסטיקה stats-phase4.6-v1 ולמודל score-model-1.2-candidate-1. בשם המודל משתמשים ב-Candidate. ערכי הנרמול שלו ראשוניים: אין לראות בהם ממוצעים של כל המחשבים. פרטים נוספים על אמת המידה מופיעים בחישוב הניקוד.

הכנה

Section titled “הכנה”

BoosterX מנהל הפעלה של מנוע נטיבי נפרד, מציג את התקדמות הבדיקה ושומר את התוצאה. בזמן המדידה הוא משהה את הניטור שלו עצמו של החומרה והזיכרון וממזער את חלונותיו, ואחר כך משחזר את מצבם. זה מפחית את ההשפעה של ממשק BoosterX עצמו; תוכנות חיצוניות עדיין עלולות ליצור עומס.

חזרו על הבדיקות עם אותה גרסת מנוע ואותו דרייבר, עם אותן הגדרות צריכת חשמל, המהרה וקירור. סגרו תוכנות רקע מיותרות. אם יש לכם מחשב נייד, בצעו את כל הבדיקות עם מטען מחובר. כשמשווים לפני ואחרי שינוי, רשמו בדיוק איזו הגדרה שיניתם.

רצף Candidate

Section titled “רצף Candidate”
חלק ההרצה משך מוגדר מטרה
חימום 15 שנ׳ להכין את העומס עד למדידות הנחשבות
CPU 20 שנ׳ בסך הכול שלושה בלוקים של כ-6.67 שנ׳ כל אחד
GPU 30 שנ׳ בסך הכול 10 שנ׳ לכל אחד מ-Geometry, Shader ו-Compute, כל אחד בשלושה בלוקים
Combined 30 שנ׳ בסך הכול שלושה בלוקים של 10 שנ׳
כיול 10 שנ׳ להתאים את מורכבות Loaded Latency
חימום השהיה 2 שנ׳ להכין מסלול מדידה נפרד להשהיה
Baseline Latency 5 שנ׳ למדוד השהיה בעומס בסיסי
Loaded Latency 20 שנ׳ למדוד השהיה בעומס מכויל

מעברים, הכנת משאבים, פריימים מקדימים של CPU וסיום מוסיפים זמן. לכן זמן ההרצה הכולל גדול מסכום השלבים הנמדדים: בסדרה שנבדקה המרווחים בין תחילות של הרצות סמוכות באותה הפעלה היו כ-157–172 שניות — כולל ההשהיה בין הרצות; לא ניתן לקבוע מתוך הנתונים שפורסמו את משך ההרצה המדויק של הרצה אחת.

בלוקי בדיקות הביצועים מתחלפים בשלושה סבבים. ב-CPU לפני כל בלוק נחשב יש מצב התחלתי קבוע ו-512 פריימים מקדימים. אם מהירות העבודה משתנה בהדרגה מבלוק לבלוק, הדבר בא לידי ביטוי באבחון. התוצאות המתקבלות אינן מותאמות בגלל זה.

פרופילי הרצה ומשכים

Section titled “פרופילי הרצה ומשכים”

המנוע תומך בארבעה פרופילים: candidate, quick, extended ו-custom. משכי השלבים המדויקים:

פרופיל משימה מעבר חימום CPU GPU Combined כיול חימום השהיה Baseline Loaded
Candidate קנוני 0.5 שנ׳ 15 שנ׳ 20 שנ׳ 30 שנ׳ 30 שנ׳ 10 שנ׳ 2 שנ׳ 5 שנ׳ 20 שנ׳
Quick אבחוני 0.25 שנ׳ 7.5 שנ׳ 10 שנ׳ 15 שנ׳ 15 שנ׳ 5 שנ׳ 1 שנ׳ 2.5 שנ׳ 10 שנ׳
Extended אבחוני 1 שנ׳ 30 שנ׳ 40 שנ׳ 60 שנ׳ 60 שנ׳ 20 שנ׳ 4 שנ׳ 10 שנ׳ 40 שנ׳
Custom בהתאמה אישית לפי בחירת המשתמש בגבולות המותרים

Candidate הוא פרופיל ברירת המחדל, ורק ההרצות שלו מדורגות. Quick, Extended ו-Custom נחשבים תמיד לאבחוניים: אין לערבב אותם עם Candidate באותה השוואה ואין לפרסם אותם בדירוג. ב-Custom אפשר להשאיר חלק מהבדיקות ולקבוע משכים משלכם: בלוקים נחשבים מקבלים 1–180 שנ׳, מעברים — 0.1–180 שנ׳, חימום השהיה — 0.5–180 שנ׳. כל דריסה של משך הופכת את ההרצה לאבחונית.

איסוף בלי כתיבה לדיסק בכל פריים

Section titled “איסוף בלי כתיבה לדיסק בכל פריים”

המדידות נשמרות בבלוקי זיכרון שהוקצו מראש. בעת איסוף כל פריים התוכנית אינה מפרמטת JSON, אינה מרחיבה וקטור ואינה כותבת לקובץ. גודל המאגרים מחושב מראש לפי משך הבדיקה ותדירות הכתיבה המרבית הצפויה, עם מרווח ביטחון. במימוש הזה חלה מגבלה של 768 MiB.

לאחר סיום עבודת ה-GPU הנתונים מאוחדים ומעובדים. זה מפחית את השפעת איסוף הנתונים על הבדיקה, אם כי האיסוף עצמו גם צורך משאבים. כדי למדוד את השפעתו יש להשוות בנפרד הרצות עם איסוף מדידות ובלעדיו.

התוצאה מכילה מדדים מסכמים. קובץ נפרד של מדידות מקור מאפשר לחזור על העיבוד הסטטיסטי בלי להריץ מחדש את העומס. חישוב מחדש כזה בודק את החישובים; כדי לבדוק חזרתיות על החומרה נדרשת הרצה חדשה.

איכות ההרצה ואי-כשירות התוצאה

Section titled “איכות ההרצה ואי-כשירות התוצאה”

במהלך כל בלוק המנוע מעריך את איכות ההרצה — Run Quality. המדד העיקרי הוא עומס רקע של CPU, כלומר כל מה שמעמיס על המערכת מלבד הבenchmark עצמו. הוא מחושב לכל בלוק כהפרש בין העומס של כל המערכת לעומס של תהליך הבenchmark, כפי שנמדדו באותם מוני זמן. ערכי הסף לפרופיל Candidate: מעל 20% — אזהרה, מעל 50% — ההרצה נחשבת לא כשירה.

Run Quality גם מתעד תנאים נלווים: דיבאגר מחובר, הפעלה מרחוק, צריכת חשמל מסוללה ומצב חיסכון בסוללה, נוכחות היפרוויזור, אובדן פוקוס של החלון והחלפת צג. היפרוויזור, סוללה והפעלה מרחוק מוצגים כאזהרות: הם כשלעצמם אינם פוסלים את התוצאה, אבל מסבירים למה המספרים עשויים להיות שונים מ“סטנד” נקי. החלפת צג במהלך בלוק נחשב הופכת את ההרצה ללא כשירה.

תוצאת בלוק נחשב כשירה דורשת בנוסף:

  • כיול מוצלח של Loaded Latency — אם לא הצליחו להתאים את המורכבות לזמן היעד, ההרצה אינה כשירה;
  • מעבר של בדיקת היציאה של עומסי ה-GPU — אי-התאמה של חתימת הבקרה הופכת את ההרצה ללא כשירה;
  • היעדר רשומות אבודות של האספן — כל אובדן הופך את ההרצה ללא כשירה.

סיווג האיכות נשמר בקובץ התוצאה, ולכן תנאים “גרועים” נראים בדיעבד, ולא רק בזמן ההרצה.

איך לקרוא את התוצאה

Section titled “איך לקרוא את התוצאה”
מדד משמעות
Performance מהירות יחסית של עומסים קבועים
Core Latency Score הערכה יחסית של השהיה פנימית; יותר נקודות זה טוב יותר
Consistency מידת הבולטות של הזנב האיטי בתוך ההרצה
PC Score איחוד גאומטרי של שלושה רכיבים עם משקלים 50/30/20

השהיות אמיתיות מוצגות במילישניות, ולגביהן פחות זה טוב יותר. אין לערבב Consistency עם חזרתיות של PC Score בין הרצות. הנוסחאות וקבועי הנרמול פתוחים בחישוב הניקוד.

גבולות התוצאה

Section titled “גבולות התוצאה”
  • תרחיש סינתטי עוזר לזהות שינויים במערכת, אבל אינו מחליף בדיקה של משחק מסוים.
  • פיזור נמוך בין הרצות עדיין אינו מוכיח את הדיוק של כל חתימת זמן או את היעדר הטיה שיטתית.
  • שמונה הרצות של מחשב אחד אינן קובעות את התפלגות התוצאות עבור כל ה-CPU, ה-GPU וגרסאות Windows.
  • השוו גרסאות עומס תואמות ואותם פרופילים. אין לערבב ללא סייג פרופיל מואץ, מורחב ובהתאמה אישית עם Candidate.
  • אין להשתמש בהרצה שבוטלה או חלקית במקום מדידה שהושלמה.

הלאה: עומסים, השהיות ו-PresentMon, נוסחאות, חזרתיות, השוואת הרצות, דירוג.

נבדק: 2026-09-20.