راهنمای جامع پردازنده های (Intel و AMD) | تشخیص نسل CPU، معنی پسوندها، مقایسه قدرت، انتخاب بهترین پردازنده و کاربرد هر مدل

Performance Counter چیست؟

برای مثال CPU
می تواند تعداد:

• Instructionهای Retired شده،
• Clock Cycleها،
• Branchها،
• Branch Missها،
• Cache Missها،
• و انواع دیگر Event

را ثبت کند.

PMU چیست؟

PMU
مخفف:

Performance Monitoring Unit

است.

PMU
بخشی از Processor
است که قابلیت
Monitoring
رویدادهای عملکردی
را فراهم می کند.

Software
می تواند از طریق
Interfaceهای سیستم عامل
یا ابزارهای Profiling
به بخشی از این داده ها
دسترسی پیدا کند.

Hardware Event چیست؟

Event
اتفاق مشخصی
در داخل CPU
است که می توان
وقوع آن را
شمارش کرد.

برای مثال:

Instruction Retired

یا:

Branch Misprediction

می توانند Event
باشند.

آیا تمام Performance Eventها در همه CPUها یکسان هستند؟

خیر.

بعضی Eventها
عمومی تر هستند،
اما بسیاری از Counterها
به Microarchitecture
وابسته اند.

حتی نام یک Event مشابه
ممکن است در دو CPU
جزئیات پیاده سازی
متفاوتی داشته باشد.

Same Event Name
≠
Necessarily Identical Microarchitectural Meaning

Instructions Retired چیست؟

CPU مدرن
Instructionها
را به صورت
Out-of-Order
اجرا می کند.

اما نتیجه
زمانی از دید معماری
نهایی محسوب می شود
که Instruction
Retire شود.

بنابراین:

Instructions Retired

تعداد Instructionهایی را
نشان می دهد
که اجرای معماری آنها
با موفقیت
نهایی شده است.

Executed Instruction و Retired Instruction چه تفاوتی دارند؟

CPU ممکن است
بعضی عملیات
را به صورت Speculative
اجرا کند.

اگر مشخص شود
مسیر اشتباه بوده،
بخشی از این کار
کنار گذاشته می شود.

بنابراین:

Executed Work
≥
Retired Useful Architectural Work

این تفاوت
یکی از دلایلی است
که فقط نگاه کردن
به Activity
CPU کافی نیست.

CPU Cycles چیست؟

یکی از Counterهای پایه
تعداد Cycleهای
سپری شده
هنگام Measurement
را ثبت می کند.

با ترکیب Cycles
و Instructions Retired
می توان Metricهای
بسیار مهمی ساخت.

IPC چگونه از Performance Counterها محاسبه می شود؟

IPC
مخفف:

Instructions Per Cycle

است.

یک رابطه ساده:

IPC
=
Instructions Retired
/
CPU Cycles

IPC
نشان می دهد
در هر Cycle
به طور متوسط
چند Instruction
Retire شده است.

CPI چیست؟

CPI
مخفف:

Cycles Per Instruction

است.

رابطه آن با IPC:

CPI
=
CPU Cycles
/
Instructions Retired

در یک تعریف ساده:

CPI
≈
1 / IPC

البته هنگام تحلیل
باید دقیقاً بدانیم
چه نوع Cycle
و چه نوع Instruction Event
اندازه گیری شده است.

IPC بالاتر همیشه بهتر است؟

در یک Workload
و شرایط مقایسه مشابه،
IPC بالاتر
می تواند نشان دهد
CPU در هر Cycle
کار معماری بیشتری
انجام داده است.

اما IPC
نباید بین Workloadهای
کاملاً متفاوت
بدون Context
مقایسه شود.

بعضی Workloadها
ذاتاً Instruction-Level Parallelism
بیشتری دارند.

برخی دیگر
Dependency
یا Memory Stall
بیشتری ایجاد می کنند.

IPC و Frequency چگونه با هم Performance می سازند؟

به صورت مفهومی:

Instruction Throughput
≈
IPC
×
Frequency

بنابراین CPU
می تواند:

• IPC بالاتر داشته باشد،
• Frequency بالاتر داشته باشد،
• یا ترکیبی از هر دو.

این یکی از دلایلی است
که GHz
به تنهایی
برای مقایسه CPU
کافی نیست.

یک مثال مفهومی از IPC و Frequency

فرض کنید:

CPU A:
4 GHz
×
2 IPC
=
8 Relative Units

CPU B:
3 GHz
×
3 IPC
=
9 Relative Units

در این مثال بسیار ساده،
CPU B
با وجود Frequency کمتر
می تواند Throughput
بیشتری داشته باشد.

این فقط
یک مدل آموزشی
است و Performance واقعی
بسیار پیچیده تر است.

Branch Instruction Counter چیست؟

CPU
می تواند تعداد Branchهایی
را که در طول
اجرای Workload
پردازش شده اند
ثبت کند.

Branchها
در Control Flow
برنامه نقش دارند
و Prediction صحیح آنها
برای Pipeline
اهمیت زیادی دارد.

Branch Miss چیست؟

اگر Branch Predictor
جهت یا Target
یک Branch
را اشتباه پیش بینی کند،
CPU ممکن است
بخشی از مسیر اشتباه
را اجرا کرده باشد.

سپس باید
این Speculative Work
کنار گذاشته شود
و مسیر صحیح
دوباره تغذیه شود.

Branch Misprediction
→
Wrong-Path Work
→
Pipeline Recovery
→
Lost Cycles

Branch Miss Rate چگونه محاسبه می شود؟

به صورت ساده:

Branch Miss Rate
=
Branch Mispredictions
/
Branch Instructions

نرخ بیشتر
می تواند نشان دهد
Workload
برای Predictor
دشوارتر بوده است.

اما هزینه واقعی
هر Miss
به Microarchitecture
و Pipeline
نیز بستگی دارد.

Cache Counterها چه چیزی را نشان می دهند؟

Performance Counterها
می توانند Eventهایی
مرتبط با Cache
را ثبت کنند.

بسته به CPU
ممکن است اطلاعاتی درباره:

• Cache Access،
• Cache Hit،
• Cache Miss،
• Load Miss،
• و سطح های مختلف Cache

موجود باشد.

جزئیات معماری Cache
در فصل های قبلی
بررسی شده است؛
اینجا تمرکز
بر تحلیل Runtime
آن است.

Cache Miss Rate چیست؟

به صورت مفهومی:

Cache Miss Rate
=
Cache Misses
/
Cache Accesses

هر Miss
می تواند CPU
را مجبور کند
Data را از سطح
دورتر Hierarchy
دریافت کند.

در نتیجه Latency
افزایش پیدا می کند.

Stall چیست؟

Stall
زمانی رخ می دهد
که بخشی از Pipeline
نتواند با نرخ
مورد نظر
پیشروی کند.

علت می تواند:

• Data Dependency،
• Instruction Supply،
• Cache Miss،
• Execution Resource Conflict،
• Branch Recovery،
• یا Data Availability

باشد.

آیا Stall یعنی CPU بیکار است؟

نه دقیقاً.

ممکن است بخشی
از Core
منتظر یک Dependency
باشد،
در حالی که بخش دیگری
Instructionهای مستقل
را اجرا می کند.

Out-of-Order Execution
دقیقاً برای کاهش
اثر بعضی از این Stallها
طراحی شده است.

Frontend Bound یعنی چه؟

اگر Backend CPU
ظرفیت اجرای بیشتری
داشته باشد،
اما Front-End
نتواند Instruction
یا µop
کافی تحویل دهد،
Performance می تواند
Frontend Bound شود.

علت ها می توانند شامل:

• Instruction Cache Miss،
• Decode Limitation،
• Branch Misprediction Recovery،
• Instruction Fetch Problem،
• یا Front-End Bandwidth

باشند.

Backend Bound یعنی چه؟

اگر Front-End
Work کافی
فراهم کند،
اما Backend
نتواند آن را
با سرعت کافی
اجرا کند،
Workload می تواند
Backend Bound باشد.

دلایل ممکن:

• Execution Unit Pressure،
• Data Dependency،
• Cache Miss،
• Memory Latency،
• Store / Load Pressure،
• یا Resource Contention.

Bad Speculation چیست؟

CPU
برای افزایش Performance
بخشی از کار
را قبل از قطعی شدن
مسیر اجرا
به صورت Speculative
انجام می دهد.

اگر Prediction
اشتباه باشد،
این کار
به Retired Instruction
مفید تبدیل نمی شود.

به این اتلاف
در بعضی مدل های
تحلیل Performance:

Bad Speculation

گفته می شود.

Retiring در مدل تحلیل Performance یعنی چه؟

Retiring
بخشی از زمان
یا ظرفیت Pipeline
را نشان می دهد
که به انجام
Useful Work
و Retire شدن Instructionها
منجر شده است.

در یک مدل مفهومی:

CPU Pipeline Slots
→
Retiring
+
Frontend Bound
+
Backend Bound
+
Bad Speculation

این نوع دسته بندی
می تواند کمک کند
بفهمیم ظرفیت Pipeline
کجا مصرف شده است.

Top-Down Performance Analysis چیست؟

Top-Down Analysis
روشی برای طبقه بندی
رفتار Pipeline
در سطح های مختلف است.

به جای بررسی
صدها Event
بدون ساختار،
ابتدا Performance
به دسته های اصلی
تقسیم می شود.

Retiring
/
Bad Speculation
/
Frontend Bound
/
Backend Bound

سپس اگر یکی
از دسته ها
سهم زیادی داشته باشد،
تحلیل در همان شاخه
عمیق تر می شود.

Memory-Bound Behavior در Counterها چگونه دیده می شود؟

اگر CPU
بخش زیادی از زمان
منتظر Data
باشد،
ممکن است نشانه هایی
مانند:

• Cache Miss بیشتر،
• Backend Stall،
• Load Stall،
• Lower IPC،
• و Latency Sensitivity

مشاهده شوند.

اما تشخیص دقیق
نیازمند Eventهای
مخصوص همان Microarchitecture
است.

جزئیات DRAM
و Memory Timing
را به دانشنامه RAM
منتقل می کنیم.

چگونه بفهمیم محدودیت از Execution Unitهاست؟

در بعضی Workloadها
داده به موقع
در دسترس است،
اما نوع عملیات
فشار زیادی
روی Execution Port
یا Unit مشخصی
وارد می کند.

برای مثال
ممکن است Workload
تعداد زیادی عملیات
مشابه ایجاد کند
که همه به
Resource محدود
یکسانی نیاز دارند.

Enough Instructions
+
Enough Data
+
Limited Execution Resource
→
Execution Bottleneck

Execution Port Pressure چیست؟

در بعضی Microarchitectureها
µopها
باید از Portهای مشخصی
وارد Execution Unitها
شوند.

اگر Workload
بیش از ظرفیت
Port مشخصی
عملیات نیاز داشته باشد،
همان مسیر
می تواند Throughput
را محدود کند.

ابزارهای تخصصی Profiling
می توانند برای
تحلیل چنین رفتارهایی
استفاده شوند.

Instruction Mix چیست؟

همه برنامه ها
ترکیب Instruction
یکسانی ندارند.

یک برنامه
ممکن است بیشتر:

• Integer،
• Floating-Point،
• Vector،
• Branch،
• Load،
• Store،
• یا Cryptographic Operation

داشته باشد.

این ترکیب
تعیین می کند
کدام بخش CPU
بیشتر درگیر شود.

رابطه Instruction Count، CPI و Execution Time چیست؟

یک مدل کلاسیک
برای زمان اجرا:

CPU Time
=
Instruction Count
×
CPI
×
Clock Cycle Time

یا به شکل دیگر:

CPU Time
=
Instruction Count
×
CPI
/
Clock Frequency

این رابطه
سه عامل مهم
Performance را
کنار هم قرار می دهد:

• چه تعداد Instruction لازم است؟
• هر Instruction به طور متوسط چند Cycle هزینه دارد؟
• هر Cycle چقدر طول می کشد؟

چرا Software می تواند بدون تغییر CPU سریع تر شود؟

اگر Algorithm
یا Compiler
تعداد Instructionهای لازم
را کاهش دهد،
زمان اجرا
می تواند کمتر شود
حتی اگر CPU
همان CPU قبلی باشد.

Lower Instruction Count
→
Less Work
→
Potentially Lower Execution Time

بنابراین Performance
فقط حاصل
قدرت Hardware نیست.

چرا Counterهای خام باید Normalize شوند؟

فرض کنید برنامه A
یک میلیارد Cache Miss
و برنامه B
صد میلیون Cache Miss
داشته باشد.

اگر برنامه A
صد برابر
Data بیشتری
پردازش کرده باشد،
عدد خام Miss
به تنهایی
مقایسه مناسبی نیست.

بنابراین Eventها
اغلب نسبت به:

• Instruction Count،
• Cycle Count،
• Access Count،
• Time،
• یا Unit of Work

Normalize می شوند.

Branch Miss Rate
=
Branch Misses
/
Branches

Cache Miss Rate
=
Cache Misses
/
Cache Accesses

Instructions per Second
=
Instructions Retired
/
Time

Counter Multiplexing چیست؟

تعداد Hardware Counterهای
فیزیکی
محدود است.

اما ممکن است
Software بخواهد
Eventهای زیادی
را همزمان
اندازه گیری کند.

در این شرایط
سیستم می تواند
Eventها را
در بازه های مختلف
میان Counterهای موجود
جابه جا کند.

این روش:

Counter Multiplexing

نامیده می شود.

چرا Multiplexing می تواند Accuracy را کاهش دهد؟

چون هر Event
تمام زمان
مستقیماً اندازه گیری
نمی شود.

Software
ممکن است مقدار
نهایی را
از Sampleهای
محدودتر
Scale کند.

برای تحلیل بسیار دقیق
گاهی بهتر است
Eventهای کمتری
به صورت همزمان
اندازه گیری شوند.

Counting و Sampling چه تفاوتی دارند؟

Counterها را
می توان فقط
برای شمارش Eventها
استفاده کرد.

اما در Profiling
می توان از Event
برای Sampling
محل وقوع رفتار نیز
استفاده کرد.

Counting
→
How Many Events?

Sampling
→
Where Did Events Occur?

این تفاوت
برای پیدا کردن
Hotspotهای Code
بسیار مهم است.

Hotspot در Profiling چیست؟

Hotspot
بخشی از Program
است که سهم زیادی
از:

• Execution Time،
• CPU Cycles،
• Cache Miss،
• Branch Miss،
• یا Event مهم دیگر

را مصرف می کند.

Optimization
معمولاً زمانی
ارزش بیشتری دارد
که روی Hotspot واقعی
انجام شود.

چرا باید اول Hotspotها را پیدا کرد؟

اگر Functionی
فقط 0.1 درصد
زمان برنامه
را مصرف کند،
حتی دو برابر
سریع تر کردن آن
تاثیر کمی
روی زمان کل دارد.

در مقابل
بهبود بخشی
که 50 درصد
زمان اجرا را
تشکیل می دهد
می تواند
تاثیر بسیار بیشتری
ایجاد کند.

Optimize What Matters Most

آیا Performance Counter فقط برای مهندسان CPU است؟

خیر.

تحلیل عمیق Eventها
بیشتر در:

• Software Optimization،
• Compiler Engineering،
• Performance Engineering،
• Server Tuning،
• HPC،
• و Architecture Analysis

استفاده می شود.

اما مفاهیم پایه
آن برای کاربران حرفه ای
نیز بسیار مفید است،
چون نشان می دهد
چرا CPU Usage
به تنهایی
کافی نیست.

CPU Usage بالا و IPC پایین چه معنایی می تواند داشته باشد؟

چنین حالتی
می تواند دلایل زیادی
داشته باشد.

برای مثال:

• Dependency زیاد،
• Cache Miss زیاد،
• Branch Misprediction،
• Frontend Starvation،
• Backend Stall،
• یا Workload ذاتاً Serial.

بنابراین:

High CPU Usage
+
Low IPC
→
CPU Busy but Not Necessarily Efficiently Retiring Work

CPU Usage پایین و IPC بالا چه معنایی دارد؟

ممکن است فقط
یک یا چند Core
Workload
را بسیار کارآمد
اجرا کنند.

اگر Software
Parallelism بیشتری
نداشته باشد،
Coreهای دیگر
بیکار خواهند بود.

بنابراین IPC بالا
به تنهایی
نمی گوید کل CPU
به طور کامل
استفاده شده است.

اگر Frequency بالا باشد ولی Performance پایین بماند چه؟

Frequency بالا
فقط تعداد Cycle
را افزایش می دهد.

اگر CPU
در هر Cycle
Work مفید کمی
Retire کند،
Performance
ممکن است همچنان
پایین باشد.

High Frequency
+
Low IPC
→
Potentially Limited Performance

این یکی از مهم ترین
کاربردهای IPC
در تحلیل Performance است.

Performance Counter جای Benchmark را می گیرد؟

خیر.

Benchmark
می گوید
Workload
چقدر سریع
تمام شده است.

Counterها کمک می کنند
بفهمیم چرا
این Performance
به دست آمده است.

Benchmark
→
What Performance Did We Get?

Performance Counters
→
Why Did We Get It?

روش اصولی تحلیل Performance Counter

چند الگوی مفهومی در تفسیر Counterها

Profiling چیست؟

Profiling
فرایند اندازه گیری
رفتار Runtime
یک Software
هنگام اجرای Workload
واقعی یا کنترل شده است.

هدف این است که
بفهمیم منابع سیستم
کجا و چگونه
مصرف می شوند.

در CPU Profiling
معمولاً می خواهیم بدانیم:

• کدام Functionها بیشترین CPU Time را مصرف می کنند؟
• کدام Code Pathها بیشتر اجرا می شوند؟
• کدام Threadها فعال تر هستند؟
• کدام بخش ها Hotspot هستند؟
• کجا Stall یا Bottleneck ایجاد می شود؟
• کدام بخش واقعاً ارزش Optimization دارد؟

Profiler چیست؟

Profiler
ابزاری است
که اطلاعات مربوط
به اجرای Software
را جمع آوری
و سازمان دهی می کند.

بسته به نوع ابزار،
Profiler می تواند:

• Execution Time را اندازه گیری کند،
• Call Stackها را Sample کند،
• Function Callها را ثبت کند،
• Thread Activity را بررسی کند،
• Hardware Counterها را بخواند،
• و Timeline اجرای برنامه را نمایش دهد.

Profiling و Monitoring چه تفاوتی دارند؟

Monitoring
معمولاً وضعیت کلی
سیستم را نشان می دهد.

برای مثال:

CPU Usage = 80%

اما Profiling
تلاش می کند
مشخص کند
این 80 درصد
در کدام بخش Software
مصرف شده است.

Monitoring
→
What Is Happening?

Profiling
→
Where Is It Happening?

Hotspot چیست؟

Hotspot
بخشی از Software
است که سهم قابل توجهی
از یک Resource
یا Execution Time
را مصرف می کند.

Hotspot می تواند:

• یک Function،
• یک Loop،
• یک Thread،
• یک Code Path،
• یک Library Call،
• یا حتی یک Instruction Pattern

باشد.

پیدا کردن Hotspot
معمولاً اولین قدم
Optimization جدی است.

CPU Time چیست؟

CPU Time
مقدار زمانی است
که Processor
برای اجرای Work
مربوط به Process
یا Thread
صرف کرده است.

این مقدار
با مدت زمانی
که کاربر منتظر
پایان برنامه می ماند
الزاماً یکسان نیست.

Wall-Clock Time چیست؟

Wall-Clock Time
زمان واقعی سپری شده
از شروع
تا پایان یک Operation
است.

برای مثال:

Start = 10:00:00

Finish = 10:00:05

Wall Time = 5 Seconds

اما در این پنج ثانیه
برنامه ممکن است
بخشی از زمان
منتظر:

• Disk،
• Network،
• GPU،
• Lock،
• Input،
• یا Thread دیگر

بوده باشد.

Call Stack چیست؟

هنگام اجرای Program،
Functionها
می توانند Functionهای دیگری
را فراخوانی کنند.

Call Stack
مسیر تو در توی
این فراخوانی ها
را در یک لحظه
نشان می دهد.

برای مثال:

main()
→
processImage()
→
applyFilter()
→
calculatePixel()

اگر Profiler
در این لحظه
Sample بگیرد،
می تواند این مسیر
را ثبت کند.

Call Tree چیست؟

وقتی تعداد زیادی
Call Stack
جمع آوری شود،
می توان آنها را
به شکل ساختاری
سازمان دهی کرد.

Call Tree
نشان می دهد
Functionها
چگونه یکدیگر
را فراخوانی کرده اند
و چه مقدار زمان
در شاخه های مختلف
مصرف شده است.

Inclusive Time چیست؟

Inclusive Time
زمان Function
به همراه زمانی است
که Functionهای
فراخوانی شده توسط آن
مصرف کرده اند.

فرض کنید:

Function A
→
Function B
→
Function C

زمان Inclusive
برای Function A
می تواند زمان
B و C
را نیز شامل شود.

Exclusive Time یا Self Time چیست؟

Exclusive Time
فقط زمانی است
که مستقیماً
داخل خود Function
مصرف شده است.

زمان Functionهای
فرزند
از آن حذف می شود.

Inclusive Time
=
Self Time
+
Child Function Time

مثال Inclusive Time و Exclusive Time

فرض کنید Function A
در مجموع
100 میلی ثانیه
طول کشیده است.

اما 80 میلی ثانیه
از این زمان
داخل Function B
مصرف شده است.

A Inclusive Time = 100 ms

A Exclusive Time = 20 ms

اگر فقط Inclusive Time
را ببینیم،
ممکن است اشتباهاً
Function A
را مقصر اصلی
بدانیم.

Sampling Profiler چگونه کار می کند؟

Sampling Profiler
در بازه های زمانی
مشخص
وضعیت اجرای Program
را Sample می کند.

در هر Sample
ممکن است:

• Instruction Pointer،
• Thread،
• Call Stack،
• و Event مرتبط

ثبت شود.

پس از جمع شدن
Sampleهای زیاد،
بخش هایی که
بیشتر دیده شده اند
احتمالاً سهم بیشتری
از Execution Time
داشته اند.

Sample 1 → Function A

Sample 2 → Function A

Sample 3 → Function B

Sample 4 → Function A

Sample 5 → Function C

در این مثال ساده،
Function A
در Sampleهای بیشتری
دیده شده است.

مزیت Sampling Profiling چیست؟

Sampling
معمولاً نسبت به
ثبت کامل
تمام Function Callها
Overhead کمتری دارد.

به همین دلیل
برای Workloadهای
بزرگ یا طولانی
بسیار کاربردی است.

البته نتیجه
Statistical
است و به:

• Sampling Frequency،
• مدت Test،
• رفتار Workload،
• و تعداد Sampleها

وابسته است.

Instrumentation Profiling چیست؟

در Instrumentation
نقاط مشخصی
از Program
برای ثبت Event
یا Timing
مجهز می شوند.

برای مثال
می توان هنگام:

• ورود به Function،
• خروج از Function،
• شروع Operation،
• پایان Operation،
• یا وقوع Event مشخص

اطلاعات ثبت کرد.

مزیت و عیب Instrumentation چیست؟

Instrumentation
می تواند اطلاعات
بسیار دقیق و ساختاری
درباره Eventهای مشخص
ارائه دهد.

اما خود این ثبت اطلاعات
می تواند:

• Execution Time را افزایش دهد،
• Cache Behavior را تغییر دهد،
• Thread Timing را تغییر دهد،
• و حتی رفتار برنامه را کمی متفاوت کند.

به این اثر:

Profiling Overhead

گفته می شود.

Tracing چیست؟

Tracing
مجموعه ای از Eventها
را در طول زمان
ثبت می کند
تا Timeline
اجرای سیستم
بازسازی شود.

برای مثال می توان دید:

• Thread چه زمانی اجرا شده،
• چه زمانی Sleep شده،
• چه زمانی منتظر Lock بوده،
• چه زمانی I/O شروع شده،
• چه زمانی Context Switch رخ داده،
• و کدام Event باعث Wake-Up شده است.

Profiling و Tracing چه تفاوتی دارند؟

Profiling
معمولاً برای پیدا کردن
بخش هایی استفاده می شود
که سهم زیادی
از Resource
مصرف می کنند.

Tracing
بیشتر روی:

What Happened
+
When
+
In What Order

تمرکز دارد.

این دو روش
مکمل یکدیگرند.

Flame Graph چیست؟

Flame Graph
یک روش Visualization
برای نمایش
Call Stackهای جمع آوری شده
در Profiling است.

در این نمودار
معمولاً عرض یک Block
نشان دهنده سهم نسبی
آن Code Path
در Sampleهاست.

بنابراین:

Wider Block
→
More Samples
→
Larger Share of Profile

ارتفاع نمودار
بیشتر نشان دهنده
عمق Call Stack است
و به خودی خود
به معنی کندتر بودن
نیست.

چرا Profiling باید Threadها را جدا بررسی کند؟

یک Process
می تواند
تعداد زیادی Thread
داشته باشد.

ممکن است:

• یک Thread کاملاً CPU-Bound باشد،
• چند Thread منتظر I/O باشند،
• یک Thread منتظر Lock باشد،
• و Thread دیگری Background Work انجام دهد.

Total CPU Usage
این تفاوت ها
را پنهان می کند.

CPU-Bound Workload در Profiling چه شکلی دارد؟

در یک Workload
واقعاً CPU-Bound،
Threadهای مهم
بخش بزرگی از زمان
را در حالت
Running
سپری می کنند.

سپس باید بررسی شود
زمان CPU
در کدام Function
و کدام Code Path
مصرف می شود.

اگر برنامه کند باشد ولی CPU Time پایین باشد چه؟

این یکی از
مهم ترین نشانه هاست.

اگر:

Wall Time High
+
CPU Time Low

باشد،
احتمال دارد
برنامه بیشتر
منتظر چیزی باشد
تا اینکه CPU
مشغول محاسبه باشد.

برای مثال:

• Storage I/O،
• Network Response،
• Database،
• Lock،
• Synchronization،
• GPU،
• یا External Service.

Amdahl’s Law چه ارتباطی با Optimization دارد؟

Amdahl’s Law
نشان می دهد
Speedup کل سیستم
توسط بخشی محدود می شود
که بهبود پیدا نکرده است.

اگر فقط بخش کوچکی
از زمان اجرای برنامه
را Optimize کنیم،
تاثیر آن روی
کل Performance
محدود خواهد بود.

رابطه کلاسیک:

Overall Speedup
=
1
/
((1 – P) + (P / S))

که در آن:

P = Fraction Improved

S = Speedup of Improved Fraction

مثال ساده Amdahl’s Law

فرض کنید
یک Function
فقط 10 درصد
زمان اجرای برنامه
را مصرف می کند.

حتی اگر
اجرای آن Function
را تقریباً
بی نهایت سریع کنیم،
90 درصد باقی مانده
همچنان وجود دارد.

بنابراین Maximum Speedup
کل برنامه
حدود:

1 / 0.9
≈
1.11×

خواهد بود.

یعنی Optimization فوق العاده
یک بخش کوچک،
فقط حدود 11 درصد
Speedup کلی ایجاد می کند.

کدام Hotspot را باید اول Optimize کرد؟

صرفاً بزرگ ترین Function
یا پیچیده ترین Code
بهترین هدف نیست.

هدف مناسب معمولاً بخشی است
که:

• سهم قابل توجهی از زمان دارد،
• در Workload واقعی زیاد اجرا می شود،
• امکان بهبود واقعی دارد،
• بهبود آن روی Metric نهایی اثر می گذارد،
• و هزینه یا ریسک تغییر آن قابل قبول است.

ROI در Performance Optimization چیست؟

Optimization
نیز هزینه دارد.

ممکن است نیازمند:

• زمان توسعه،
• Code پیچیده تر،
• Memory بیشتر،
• Maintenance دشوارتر،
• Platform-Specific Code،
• یا کاهش Readability

باشد.

بنابراین باید پرسید:

Performance Gain
vs
Engineering Cost

Baseline چیست؟

قبل از Optimization
باید Performance فعلی
ثبت شود.

این مقدار:

Performance Baseline

نامیده می شود.

بدون Baseline
نمی توان با اطمینان
گفت تغییر انجام شده
واقعاً Performance
را بهتر کرده است.

چرا تست باید قابل تکرار باشد؟

Performance
می تواند تحت تاثیر:

• Background Process،
• Temperature،
• CPU Boost،
• Power Mode،
• Cache State،
• Scheduler،
• Storage State،
• و Input Data

تغییر کند.

بنابراین Test
باید تا حد امکان
در شرایط مشابه
تکرار شود.

چرا Profiling نسخه Debug می تواند گمراه کننده باشد؟

Debug Build
ممکن است:

• Compiler Optimization کمتری داشته باشد،
• Instrumentation بیشتری داشته باشد،
• Code Generation متفاوتی تولید کند،
• و Runtime Behavior متفاوتی ایجاد کند.

بنابراین برای
Performance Analysis واقعی،
معمولاً باید Build
نزدیک به شرایط
Production
بررسی شود.

Compiler چه نقشی در Performance Optimization دارد؟

Compiler
می تواند Transformهای
مختلفی روی Code
انجام دهد.

برای مثال:

• Inlining،
• Loop Optimization،
• Dead Code Elimination،
• Vectorization،
• Constant Propagation،
• Instruction Scheduling،
• و Register Allocation.

بنابراین Code
که CPU واقعاً اجرا می کند
الزاماً ساختار
Source Code
را به صورت مستقیم
دنبال نمی کند.

Inlining چگونه Profiling را پیچیده می کند؟

Compiler
ممکن است Body
یک Function کوچک
را مستقیماً
داخل Caller
قرار دهد.

در این صورت
Function Call
واقعی ممکن است
دیگر در Machine Code
وجود نداشته باشد.

Profilerهای پیشرفته
تلاش می کنند
این Mapping
میان Source Code
و Optimized Code
را بازسازی کنند.

Symbolها چرا در Profiling مهم هستند؟

بدون Symbol Information
Profiler ممکن است
فقط Address
یا اطلاعات سطح پایین
نمایش دهد.

Symbolها کمک می کنند
Addressهای Machine Code
به:

• Function Name،
• Module،
• Source File،
• و گاهی Source Line

مرتبط شوند.

Lock Contention چگونه Performance را کاهش می دهد؟

در Multi-Threaded Software
چند Thread
ممکن است برای دسترسی
به Resource مشترک
نیازمند Lock باشند.

اگر Threadهای زیادی
منتظر همان Lock
بمانند،
Parallelism واقعی
کاهش پیدا می کند.

More Threads
+
Heavy Lock Contention
≠
More Performance

Context Switch چه تاثیری دارد؟

Context Switch
زمانی رخ می دهد
که CPU
اجرای یک Thread
را متوقف کند
و Thread دیگری
را اجرا کند.

Context Switch
بخشی طبیعی
از Multitasking است.

اما تعداد بسیار زیاد
Switch
می تواند Overhead
ایجاد کند
و Locality
را کاهش دهد.

Scheduler چگونه نتیجه Profiling را تغییر می دهد؟

Operating System Scheduler
تصمیم می گیرد
Threadها
چه زمانی
و روی کدام Logical Processor
اجرا شوند.

در CPUهای Hybrid
این موضوع
اهمیت بیشتری پیدا می کند،
زیرا نوع Core
نیز می تواند متفاوت باشد.

بنابراین Performance
فقط نتیجه Code نیست؛
Placement و Scheduling
نیز می توانند
روی Runtime Behavior
اثر بگذارند.

چرا باید Phaseهای مختلف Workload را جدا تحلیل کنیم؟

یک Application
ممکن است در مراحل مختلف
رفتار کاملاً متفاوتی
داشته باشد.

برای مثال:

Load Data
→
Parse
→
Compute
→
Compress
→
Write Output

اگر Profile
کل برنامه
بدون تفکیک Phase
بررسی شود،
رفتارهای متفاوت
با یکدیگر
مخلوط می شوند.

Representative Workload چیست؟

Workload مورد استفاده
برای Profiling
باید تا حد امکان
رفتار واقعی
کاربران یا سیستم
را نمایندگی کند.

اگر Input
بسیار کوچک،
غیرواقعی
یا مصنوعی باشد،
Hotspotهای مشاهده شده
ممکن است با شرایط واقعی
متفاوت باشند.

Microbenchmark چیست؟

Microbenchmark
تست کوچکی است
که بخش محدود
و مشخصی
از سیستم یا Code
را اندازه گیری می کند.

این روش
برای بررسی
یک Operation خاص
بسیار مفید است.

اما نتیجه Microbenchmark
الزاماً Performance
Application کامل
را نشان نمی دهد.

چه نوع Optimizationهایی ممکن است انجام شوند؟

پس از پیدا کردن
Bottleneck واقعی،
نوع Optimization
به علت محدودیت
بستگی دارد.

چرا Algorithm معمولاً مهم تر از Micro-Optimization است؟

اگر Algorithm
Work بسیار زیادی
تولید کند،
تغییر چند Instruction
ممکن است تاثیر محدودی
داشته باشد.

در مقابل
Algorithm بهتر
می تواند تعداد Operationهای
مورد نیاز
را به شکل بنیادی
کاهش دهد.

Less Necessary Work
Often Beats
Faster Unnecessary Work

چرا حذف Work از سریع تر کردن Work بهتر است؟

سریع ترین Instruction
Instructionی است
که اصلاً لازم نیست
اجرا شود.

اگر بتوان:

• محاسبه تکراری را حذف کرد،
• نتیجه را Cache کرد،
• Operation غیرضروری را حذف کرد،
• Data کمتری پردازش کرد،
• یا Algorithm بهتری انتخاب کرد،

ممکن است Improvement
بسیار بزرگ تری
ایجاد شود.

آیا Optimization همیشه بدون هزینه است؟

خیر.

ممکن است
برای Speed بیشتر:

• Memory بیشتری مصرف شود،
• Code پیچیده تر شود،
• Binary Size افزایش یابد،
• Latency بهتر ولی Throughput بدتر شود،
• Power Consumption افزایش یابد،
• یا Portability کاهش پیدا کند.

بنابراین Performance
فقط یک Dimension
از طراحی سیستم است.

Performance Regression چیست؟

اگر نسخه جدید
Software
نسبت به نسخه قبلی
در یک Workload
کندتر شود،
Performance Regression
رخ داده است.

Regression
ممکن است
ناشی از:

• Code جدید،
• Algorithm جدید،
• Compiler Change،
• Dependency Update،
• Configuration Change،
• یا Platform Change

باشد.

چرا Performance Test باید بخشی از توسعه باشد؟

اگر فقط Functional Correctness
تست شود،
Software ممکن است
همچنان درست کار کند
ولی هر نسخه
کمی کندتر شود.

Benchmarkهای تکرارشونده
می توانند
Regressionهای Performance
را زودتر
آشکار کنند.

Profile-Guided Optimization چیست؟

در بعضی Toolchainها
اطلاعات اجرای واقعی
Program
می تواند به Compiler
داده شود.

Compiler
از این Profile
برای تصمیم گیری بهتر
درباره Optimization
استفاده می کند.

این روش:

Profile-Guided Optimization
(PGO)

نامیده می شود.

Build Instrumented Version
→
Run Representative Workload
→
Collect Profile
→
Rebuild Using Profile
→
Optimized Binary

کیفیت Workload
مورد استفاده
برای Profile
اهمیت زیادی دارد.

Profiling قبل از ارتقای CPU چه کمکی می کند؟

اگر سیستم کند باشد،
اولین واکنش
ممکن است خرید
CPU سریع تر باشد.

اما Profiling
می تواند مشخص کند
آیا CPU واقعاً
Bottleneck است یا خیر.

اگر Application
بیشتر منتظر:

• Storage،
• Network،
• Memory،
• GPU،
• Database،
• یا Synchronization

باشد،
CPU سریع تر
ممکن است تاثیر کمی
ایجاد کند.

این مفاهیم در انتخاب کامپیوتر چه کاربردی دارند؟

شناخت Profiling
کمک می کند
بدانیم عبارت:

“This Software Needs a Fast CPU”

بیش از حد کلی است.

باید مشخص شود
Software به چه چیزی
حساس است:

• Single-Core Performance؟
• Multi-Core Throughput؟
• Cache؟
• Memory Latency؟
• Memory Bandwidth؟
• GPU؟
• Storage؟
• یا ترکیبی از آنها؟

این موضوع
برای انتخاب:

• لپ تاپ،
• کامپیوتر رومیزی،
• Workstation،
• All-in-One،
• Mini PC،
• و Server

کاربرد دارد.

Workflow اصولی Profiling و Optimization

الگوهای مهم برای تشخیص Performance Problem

Benchmark چیست؟

Benchmark می تواند:

• زمان انجام یک Task را اندازه بگیرد،
• تعداد Operation در ثانیه را ثبت کند،
• Throughput را اندازه بگیرد،
• Latency را ثبت کند،
• یا یک Score ترکیبی تولید کند.

Score بنچمارک چه معنایی دارد؟

Score
فقط در چارچوب
همان Benchmark
معنی پیدا می کند.

برای مثال:

Score = 15000

به خودی خود
هیچ واحد فیزیکی
مشخصی ندارد،
مگر اینکه Benchmark
تعریف کرده باشد
این عدد دقیقاً
چه چیزی را نشان می دهد.

بنابراین Scoreهای
دو Benchmark متفاوت
را نباید
مستقیماً با هم
مقایسه کرد.

Benchmark Methodology چیست؟

Methodology
مجموعه قوانین
و شرایطی است
که مشخص می کند
Test چگونه
انجام شده است.

یک Methodology مناسب
باید مواردی مانند:

• Hardware Configuration،
• Software Version،
• Operating System،
• Power Mode،
• Cooling Condition،
• Ambient Temperature،
• تعداد Runها،
• Warm-Up Procedure،
• روش محاسبه نتیجه نهایی،
• و شرایط رد کردن Run نامعتبر

را مشخص کند.

چرا یک بار اجرای Benchmark کافی نیست؟

سیستم کامپیوتری
کاملاً Deterministic
از دید Measurement
روزمره نیست.

در دو Run متوالی
ممکن است تفاوت هایی
در:

• Scheduler Behavior،
• Background Activity،
• CPU Temperature،
• Boost Frequency،
• Cache State،
• و Power Behavior

وجود داشته باشد.

بنابراین نتیجه یک Run
ممکن است نماینده خوبی
از Performance معمول
سیستم نباشد.

Repeatability چیست؟

Repeatability
یعنی اگر Test
تحت شرایط مشابه
چند بار اجرا شود،
نتایج تا حد معقول
به یکدیگر نزدیک باشند.

Run 1 = 100

Run 2 = 101

Run 3 = 99

چنین نتایجی
نسبتاً پایدارند.

اما اگر:

100
/
82
/
108
/
91

مشاهده شود،
باید علت Variability
بررسی شود.

Reproducibility چیست؟

Reproducibility
یعنی فرد یا آزمایشگاه دیگری
بتواند با استفاده
از Methodology مشابه
به نتیجه ای
نزدیک برسد.

اگر Test Method
مخفی یا ناقص باشد،
بررسی مستقل نتیجه
دشوار می شود.

Warm-Up چیست؟

بعضی Workloadها
در اولین اجرا
رفتار متفاوتی
نسبت به اجراهای بعدی
دارند.

علت می تواند:

• Cold Cache،
• File Cache،
• JIT Compilation،
• Library Initialization،
• Memory Allocation،
• یا Power-State Transition

باشد.

Warm-Up Run
می تواند سیستم
را به حالت
پایدارتر Measurement
نزدیک کند.

Cold Run و Warm Run چه تفاوتی دارند؟

Cold Run
معمولاً اجرای Test
در حالتی است
که بعضی Cacheها
یا Resourceها
هنوز Warm نشده اند.

Warm Run
پس از یک یا چند
اجرای قبلی
انجام می شود.

هیچ کدام
ذاتاً درست یا غلط نیستند.

مهم این است
که Test
با هدف واقعی
هماهنگ باشد.

اگر تجربه
اولین اجرای Application
مهم است،
Cold Performance
اهمیت دارد.

اگر Workload
ساعت ها پیوسته
اجرا می شود،
Steady-State Performance
مهم تر است.

Steady State چیست؟

Steady State
وضعیتی است
که رفتار سیستم
پس از گذشت
Transientهای اولیه
نسبتاً پایدار شده است.

در CPU Benchmark
ممکن است بخواهیم
Temperature،
Frequency
و Power
به وضعیت نسبتاً پایدار
رسیده باشند.

چرا Benchmark کوتاه و طولانی می توانند نتیجه متفاوتی بدهند؟

یک CPU
ممکن است برای مدت کوتاه
Frequency و Power
بالاتری حفظ کند.

اما در Workload طولانی،
محدودیت:

• Temperature،
• Cooling،
• Power،
• Current،
• یا Firmware Policy

می تواند رفتار
را تغییر دهد.

Short Burst Performance
≠
Sustained Performance

Temperature چگونه Benchmark را تغییر می دهد؟

CPU مدرن
Frequency و Voltage
را به صورت Dynamic
مدیریت می کند.

اگر Temperature
افزایش پیدا کند،
Headroom حرارتی
ممکن است کمتر شود.

در نتیجه
Frequency پایدار
می تواند کاهش پیدا کند.

بنابراین مقایسه:

Cold CPU
vs
Heat-Soaked CPU

می تواند نتیجه
متفاوتی ایجاد کند.

دمای محیط چرا مهم است؟

Cooling System
گرمای CPU
را در نهایت
به محیط منتقل می کند.

اگر Ambient Temperature
بالاتر باشد،
اختلاف دمای موجود
برای دفع Heat
کاهش پیدا می کند.

بنابراین برای Testهای
دقیق،
دمای محیط
باید ثبت
یا تا حد امکان
کنترل شود.

چرا Cooling در Benchmark لپ تاپ اهمیت بیشتری دارد؟

لپ تاپ ها
فضای محدودتری
برای Cooling
و Power Delivery
دارند.

حتی دو دستگاه
با CPU یکسان
می توانند:

• Heatpipe متفاوت،
• Fan متفاوت،
• Power Limit متفاوت،
• Firmware متفاوت،
• و Chassis متفاوت

داشته باشند.

بنابراین نام CPU
به تنهایی
Performance نهایی لپ تاپ
را تعیین نمی کند.

Power Limit چگونه نتیجه Benchmark را تغییر می دهد؟

CPU ممکن است
براساس محدودیت توان
اجازه داشته باشد
Frequency بیشتری
یا کمتری
حفظ کند.

بنابراین دو سیستم
با Processor مشابه
ولی Power Budget متفاوت
می توانند Performance
متفاوتی داشته باشند.

هنگام مقایسه
باید مشخص باشد
Test در چه
Power Mode
انجام شده است.

Benchmark لپ تاپ روی برق و باتری یکسان است؟

نه لزوماً.

بسیاری از لپ تاپ ها
هنگام کار با Battery
Power Policy
متفاوتی اعمال می کنند.

ممکن است:

• CPU Power محدود شود،
• Boost Behavior تغییر کند،
• GPU Power محدود شود،
• و Fan Policy تغییر کند.

بنابراین وضعیت
اتصال به برق
باید در Methodology
مشخص شود.

چرا RAM روی Benchmark پردازنده اثر می گذارد؟

CPU
به صورت جدا
از Memory Subsystem
کار نمی کند.

بعضی Workloadها
به:

• Memory Bandwidth،
• Memory Latency،
• Channel Configuration،
• Memory Frequency،
• و Capacity

حساس هستند.

بنابراین مقایسه CPUها
با Memory Configuration
کاملاً متفاوت
می تواند نتیجه
را منحرف کند.

جزئیات فنی RAM
در دانشنامه RAM
بررسی می شود.

Background Processها چه مشکلی ایجاد می کنند؟

Operating System
حتی زمانی که کاربر
برنامه خاصی
اجرا نمی کند،
می تواند Processهای
پس زمینه داشته باشد.

برای مثال:

• Update Service،
• Antivirus Scan،
• Indexing،
• Cloud Sync،
• Telemetry،
• Browser Tab،
• و Background Application.

این فعالیت ها
می توانند CPU Time
و سایر Resourceها
را مصرف کنند.

چرا نسخه Software باید ثبت شود؟

نسخه جدید
یک Benchmark
یا Application
ممکن است:

• Algorithm متفاوتی داشته باشد،
• Compiler متفاوتی استفاده کند،
• Instruction Set جدیدی فعال کند،
• Bug را رفع کرده باشد،
• یا Workload را تغییر داده باشد.

بنابراین Score
نسخه های متفاوت
الزاماً مستقیماً
قابل مقایسه نیست.

Operating System چگونه نتیجه را تغییر می دهد؟

OS
روی:

• Scheduling،
• Power Management،
• Thread Placement،
• Security Mitigation،
• Driver Stack،
• و Background Activity

تاثیر دارد.

بنابراین OS
و Build آن
باید در Test
ثبت شوند.

Benchmark پردازنده های Hybrid چه پیچیدگی خاصی دارد؟

در CPUهایی
با Coreهای متفاوت،
Scheduler
و Thread Placement
می توانند
تاثیر بیشتری
روی نتیجه داشته باشند.

اگر Thread مهم
روی نوع Core
متفاوتی اجرا شود،
Performance
می تواند تغییر کند.

بنابراین نسخه OS
و Scheduler Behavior
در چنین سیستم هایی
اهمیت بیشتری دارد.

Single-Core Benchmark چه چیزی را اندازه می گیرد؟

Single-Core Test
تلاش می کند
Performance
یک Thread
یا تعداد بسیار محدودی
از Threadها
را بررسی کند.

این نوع Test
برای Workloadهایی
که بخش مهمی
از آنها Serial است
مفیدتر است.

Multi-Core Benchmark چه چیزی را اندازه می گیرد؟

Multi-Core Benchmark
تلاش می کند
تعداد بیشتری
از Coreها و Threadها
را درگیر کند.

نتیجه آن
علاوه بر Performance
هر Core
به:

• Core Count،
• Thread Count،
• Scaling Workload،
• Power Budget،
• Cooling،
• و Shared Resources

وابسته است.

چرا دو برابر شدن Coreها الزاماً Score را دو برابر نمی کند؟

Workload
ممکن است کاملاً
Parallel نباشد.

همچنین Coreها
Resourceهای مشترکی
دارند.

محدودیت:

• Memory Bandwidth،
• Cache،
• Synchronization،
• Power،
• Cooling،
• و Serial Code

می تواند Scaling
را محدود کند.

Synthetic Benchmark چیست؟

Synthetic Benchmark
Workloadی طراحی شده
برای اندازه گیری
یک یا چند ویژگی
مشخص سیستم است.

مزیت آن:

• تکرارپذیری مناسب،
• اجرای نسبتاً ساده،
• مقایسه تعداد زیادی سیستم،
• و کنترل بهتر Workload

است.

اما ممکن است
رفتار Application واقعی
را به طور کامل
نمایندگی نکند.

Real-World Benchmark چیست؟

Real-World Benchmark
از Application
یا Workflow
نزدیک به استفاده واقعی
استفاده می کند.

برای مثال:

• Compile یک پروژه واقعی،
• Render یک Scene واقعی،
• Export یک Project،
• Compress یک Dataset،
• پردازش یک مجموعه تصویر،
• یا اجرای Simulation.

این Testها
برای تصمیم خرید
معمولاً Context
بیشتری فراهم می کنند.

Mean یا میانگین در Benchmark چیست؟

اگر چند Run
داشته باشیم،
می توان مجموع نتایج
را بر تعداد آنها
تقسیم کرد.

Mean
=
Sum of Results
/
Number of Runs

Mean
یک خلاصه مفید
از مجموعه نتایج است،
اما به Outlierها
حساس است.

Median چیست؟

Median
مقدار وسط
پس از مرتب کردن
نتایج است.

برای مثال:

98
/
99
/
100
/
101
/
130

Median برابر:

100

است.

در این مثال
عدد 130
Mean را بیشتر
تحت تاثیر قرار می دهد،
اما Median
نسبت به آن
مقاوم تر است.

Variance در Benchmark چه مفهومی دارد؟

فقط دانستن
مقدار مرکزی
کافی نیست.

باید بدانیم
نتایج چقدر
از یکدیگر
پراکنده اند.

اگر نتایج
بسیار نزدیک باشند،
Measurement
Stableتر است.

اگر پراکندگی زیاد باشد،
باید علت آن
بررسی شود.

Standard Deviation چه کاربردی دارد؟

Standard Deviation
یکی از معیارهای
پراکندگی داده ها
حول Mean است.

مقدار پایین تر
معمولاً نشان می دهد
Runها به یکدیگر
نزدیک تر بوده اند.

اما تفسیر آن
باید نسبت به
Scale داده
انجام شود.

Coefficient of Variation چیست؟

برای مقایسه
پراکندگی نسبی
می توان از:

CV
=
Standard Deviation
/
Mean

استفاده کرد.

معمولاً CV
به صورت درصد
نیز بیان می شود.

CV%
=
(Standard Deviation / Mean)
×
100

Outlier چیست؟

Outlier
نتیجه ای است
که نسبت به
سایر Runها
به شکل غیرعادی
متفاوت است.

برای مثال:

100
/
101
/
99
/
100
/
72

عدد 72
نیاز به بررسی دارد.

شاید هنگام همان Run:

• Background Task اجرا شده،
• Thermal Throttling رخ داده،
• Update شروع شده،
• یا Measurement Error وجود داشته است.

آیا باید بهترین Score را گزارش کنیم؟

اگر هدف
نشان دادن Maximum Potential
باشد،
Best Run
می تواند اطلاعاتی
ارائه کند.

اما اگر هدف
Performance معمول
دستگاه باشد،
فقط انتخاب
بهترین Run
می تواند گمراه کننده باشد.

بهتر است
مشخص شود
گزارش بر اساس:

• Best،
• Mean،
• Median،
• یا مجموعه کامل Runها

تهیه شده است.

Benchmark Cherry-Picking چیست؟

Cherry-Picking
یعنی فقط Testهایی
انتخاب شوند
که نتیجه مطلوب
برای یک محصول
نشان می دهند
و Testهای نامطلوب
حذف شوند.

برای مثال
یک CPU ممکن است
در Rendering
بسیار قوی
ولی در Workload دیگری
متوسط باشد.

اگر فقط Rendering
نمایش داده شود،
مخاطب ممکن است
تصور کند
همان برتری
در همه کاربردها
وجود دارد.

اختلاف درصدی Benchmark چگونه محاسبه می شود؟

اگر Score بالاتر
بهتر باشد:

Percentage Difference
=
((New – Baseline) / Baseline)
×
100

برای مثال:

CPU A = 100

CPU B = 120

Difference
=
((120 – 100) / 100)
×
100
=
20%

اگر عدد کمتر بهتر باشد چه؟

در Benchmarkهای
مبتنی بر زمان،
عدد کمتر
معمولاً بهتر است.

برای مثال:

CPU A = 60 seconds

CPU B = 45 seconds

در چنین حالتی
CPU B
Task را سریع تر
تمام کرده است.

نباید صرفاً
به بزرگ تر بودن
یا کوچک تر بودن عدد
نگاه کرد.

باید Metric
را شناخت.

Speedup و کاهش زمان یک چیز نیستند

فرض کنید Task
از 100 ثانیه
به 50 ثانیه
کاهش پیدا کند.

زمان اجرا:

50% Lower

شده است.

اما Throughput
یا Speed
می تواند:

2× Faster

باشد.

این دو بیان
نباید با هم
اشتباه گرفته شوند.

آیا اختلاف 1 یا 2 درصدی Benchmark مهم است؟

نه همیشه.

اگر Run-to-Run Variation
خود Test
نزدیک همان مقدار باشد،
اختلاف کوچک
ممکن است از Noise
قابل تفکیک نباشد.

برای مثال اگر:

Typical Variation ≈ ±2%

باشد،
اختلاف 1 درصدی
نیازمند احتیاط
در تفسیر است.

چرا نمودار Benchmark بهتر است پراکندگی را هم نشان دهد؟

یک Bar Chart
که فقط Mean
را نشان دهد،
اطلاعات Stability
را پنهان می کند.

نمایش:

• Minimum،
• Maximum،
• Standard Deviation،
• Confidence Interval،
• یا تمام Runها

می تواند تصویر
کامل تری
ارائه دهد.

ترتیب اجرای Benchmarkها چرا مهم است؟

اگر همیشه
CPU A
در حالت سرد
و CPU B
بعد از Workload سنگین
تست شود،
مقایسه عادلانه نیست.

Test Order
می تواند روی:

• Temperature،
• Cache State،
• Battery State،
• Background Activity،
• و Thermal Saturation

اثر بگذارد.

Sustained Benchmark برای چه کسانی مهم است؟

Workloadهای طولانی
مانند:

• Rendering،
• Video Encoding،
• Compilation،
• Scientific Computing،
• Simulation،
• و بعضی Server Workloadها

می توانند CPU
را برای مدت طولانی
تحت Load
نگه دارند.

در این کاربردها
Sustained Performance
ممکن است از
Peak Benchmark Score
مهم تر باشد.

Burst Performance برای چه کاربردهایی مهم است؟

بسیاری از کارهای روزمره
کوتاه هستند.

برای مثال:

• باز کردن Application،
• Load کردن صفحه،
• اجرای Command کوتاه،
• پردازش لحظه ای،
• و بعضی عملیات رابط کاربری.

در این موارد
Burst Performance
می تواند تاثیر زیادی
روی Responsiveness
داشته باشد.

برای خرید سیستم به کدام Benchmark نگاه کنیم؟

Benchmark مناسب
به نوع استفاده
بستگی دارد.

برای انتخاب:

• لپ تاپ،
• کامپیوتر رومیزی،
• آل این وان،
• Workstation،
• Mini PC،
• یا Server

باید ابتدا
Workload اصلی
مشخص شود.

سپس Benchmarkهایی
انتخاب شوند
که به همان
Workload نزدیک ترند.

چه نوع Benchmarkی برای چه سؤالی مناسب تر است؟

چک لیست تشخیص Benchmark قابل اعتماد

چرا یک Score واحد نمی تواند قدرت واقعی CPU را تعریف کند؟

Processor
یک ماشین محاسباتی
چندبعدی است.

Performance آن
می تواند تحت تاثیر:

• IPC،
• Frequency،
• Core Count،
• Thread Count،
• Cache،
• Memory Subsystem،
• Instruction Set،
• Branch Prediction،
• Execution Resources،
• Power Budget،
• و Cooling

قرار بگیرد.

Workloadهای مختلف
وزن متفاوتی
به این عوامل
می دهند.

اولین سؤال هنگام انتخاب CPU چیست؟

نباید ابتدا پرسید:

Which CPU Is Faster?

سؤال بهتر این است:

Faster at What?

ابتدا باید
Workload اصلی
مشخص شود.

سپس Benchmark
مرتبط با همان Workload
بررسی شود.

Single-Thread Performance چه زمانی مهم است؟

بعضی بخش های Software
کاملاً یا تا حد زیادی
Serial هستند.

یعنی نمی توان
تمام Work
را به تعداد زیادی Thread
تقسیم کرد.

در چنین شرایطی
Performance یک Thread قوی
اهمیت زیادی پیدا می کند.

Single-Thread Performance
می تواند تحت تاثیر:

• IPC،
• Boost Frequency،
• Cache Latency،
• Memory Latency،
• Branch Prediction،
• و Architecture

باشد.

Multi-Core Performance چه زمانی مهم است؟

اگر Workload
بتواند کار را
بین تعداد زیادی Thread
تقسیم کند،
Coreهای بیشتر
می توانند Throughput
را افزایش دهند.

نمونه های رایج:

• CPU Rendering،
• Video Encoding،
• بعضی Compilationها،
• Compression،
• Scientific Computing،
• Virtualization،
• و بعضی Server Workloadها.

Latency و Throughput چه تفاوتی دارند؟

Latency
مدت زمانی است
که انجام یک Operation
طول می کشد.

Throughput
مقدار Work
انجام شده
در واحد زمان است.

Latency
=
Time per Task

Throughput
=
Tasks per Unit Time

یک سیستم
می تواند Throughput بالا
داشته باشد،
اما Latency
یک Task منفرد
همچنان زیاد باشد.

Responsiveness چیست؟

Responsiveness
به سرعت واکنش سیستم
به Interaction کاربر
مربوط می شود.

برای مثال:

• باز شدن Menu،
• اجرای Command،
• باز شدن Application،
• اعمال یک Filter،
• یا تغییر View.

این تجربه
فقط به CPU
وابسته نیست.

Storage،
RAM،
Software
و Background Activity
نیز نقش دارند.

برای کاربری روزمره کدام Benchmark مهم تر است؟

در استفاده هایی مانند:

• وب گردی،
• تماشای ویدئو،
• پیام رسانی،
• کار با فایل ها،
• Office سبک،
• و اجرای چند برنامه معمولی

معمولاً نیازی
به بالاترین
Multi-Core Score
بازار نیست.

Performance مناسب
هر Core،
SSD مناسب،
RAM کافی
و سیستم متعادل
اغلب اهمیت بیشتری دارند.

برای کار اداری چه معیارهایی مهم هستند؟

Workload اداری
می تواند شامل:

• Word Processing،
• Spreadsheet،
• Browser،
• PDF،
• Accounting Software،
• Video Conference،
• و Multitasking

باشد.

برای این نوع استفاده
معمولاً:

• Single-Thread Performance مناسب،
• تعداد Core کافی،
• RAM کافی،
• SSD سریع،
• و مصرف انرژی مناسب

مهم تر از
Extreme Multi-Core Performance
هستند.

آیا Spreadsheet همیشه Workload سبک است؟

خیر.

Spreadsheet کوچک
ممکن است بسیار سبک باشد.

اما Workbookهای بزرگ
با:

• Formulaهای زیاد،
• Dataهای حجیم،
• Macro،
• Pivot Table،
• و محاسبات پیچیده

می توانند CPU-intensive
شوند.

بنابراین حتی
یک عنوان کلی مانند
«کار اداری»
باید دقیق تر
تعریف شود.

برای برنامه نویسی چه Benchmarkی مهم است؟

«برنامه نویسی»
یک Workload واحد نیست.

توسعه دهنده ممکن است:

• Code بنویسد،
• Project را Compile کند،
• Test اجرا کند،
• Container اجرا کند،
• Virtual Machine داشته باشد،
• Database محلی اجرا کند،
• یا چند IDE و Service را همزمان باز نگه دارد.

بنابراین انتخاب CPU
باید براساس
Workflow واقعی توسعه دهنده
انجام شود.

Compilation چگونه از CPU استفاده می کند؟

بسیاری از Build Systemها
می توانند چندین File
یا Task
را به صورت Parallel
پردازش کنند.

بنابراین Coreهای بیشتر
می توانند Build Time
را کاهش دهند.

اما تمام مراحل Build
الزاماً کاملاً Parallel
نیستند.

در نتیجه
هم Single-Thread Performance
و هم Multi-Core Throughput
می توانند مهم باشند.

برای Virtualization چه چیزهایی مهم هستند؟

اگر چند Virtual Machine
یا Container
به طور همزمان
اجرا شوند،
تعداد Core
و Thread
اهمیت بیشتری پیدا می کند.

اما فقط CPU
کافی نیست.

Capacity و Performance
حافظه نیز
می توانند محدودیت
مهمی ایجاد کنند.

جزئیات Memory
در دانشنامه RAM
بررسی می شود.

برای CAD کدام Benchmark CPU مهم تر است؟

CAD
یک عنوان بسیار کلی است.

Workflow می تواند شامل:

• Drawing،
• Modeling،
• Regeneration،
• Parametric Update،
• Simulation،
• Rendering،
• و Export

باشد.

هر یک از این مراحل
می توانند
Scaling متفاوتی
با Core Count
داشته باشند.

برای AutoCAD چه نوع CPU Performance مهم است؟

بسیاری از عملیات
Interactive و Drawing
در نرم افزارهای CAD
نمی توانند
به صورت نامحدود
روی تعداد زیادی Core
Scale شوند.

بنابراین Performance قوی
در Threadهای اصلی
می تواند
برای Responsiveness
اهمیت زیادی داشته باشد.

اما عملیات دیگر
مانند Rendering
یا بعضی پردازش های جانبی
ممکن است
رفتار متفاوتی داشته باشند.

بنابراین Benchmark
باید دقیقاً
همان Operation مورد نظر
را اندازه بگیرد.

برای Revit چه چیزی مهم است؟

در Workflowهای BIM
بخش هایی مانند:

• Model Interaction،
• Regeneration،
• View Update،
• Family Processing،
• Export،
• و Rendering

می توانند رفتار
متفاوتی داشته باشند.

بنابراین یک
Multi-Core Score بزرگ
به تنهایی
نمی تواند Performance
کل Workflow
را پیش بینی کند.

برای SolidWorks چه نوع Benchmarkی مناسب تر است؟

Modeling و بسیاری
از عملیات Interactive
می توانند بیشتر
به Performance
تعداد محدودی Thread
حساس باشند.

اما:

• Rendering،
• Simulation،
• و بعضی Solverها

ممکن است
از Parallelism بیشتری
استفاده کنند.

بنابراین CPU مناسب
برای Modeling
الزاماً بهترین CPU
برای Simulation
نیست.

برای CPU Rendering چه چیزی مهم است؟

بسیاری از Rendererهای CPU
می توانند Work
را بین تعداد زیادی Core
تقسیم کنند.

بنابراین:

• Core Count،
• Performance هر Core،
• Sustained Power،
• Cooling،
• و Scaling Engine

اهمیت پیدا می کنند.

در این کاربرد
Sustained Multi-Core Performance
معمولاً از Peak Score کوتاه
مهم تر است.

در Rendering بهتر است Score را ببینیم یا زمان Render را؟

اگر Benchmark
یک Scene واقعی
را Render کند،
زمان تکمیل Task
Metric بسیار قابل فهمی است.

CPU A = 120 seconds

CPU B = 90 seconds

در این حالت
CPU B
Work را
در زمان کمتری
تمام کرده است.

این Metric
مستقیماً به Productivity
نزدیک است.

برای Video Encoding چه چیزی را باید بررسی کرد؟

Encoding
می تواند از:

• CPU Software Encoder،
• Integrated Hardware Encoder،
• Discrete GPU Encoder،
• یا ترکیبی از آنها

استفاده کند.

بنابراین باید مشخص شود
Benchmark دقیقاً
از کدام مسیر
استفاده کرده است.

اگر هدف
مقایسه CPU Compute
باشد،
استفاده از Hardware Encoder
می تواند سؤال دیگری
را اندازه بگیرد.

برای Simulation چه Benchmarkی مناسب است؟

Simulation
می تواند بسیار متفاوت باشد.

بعضی Solverها:

• Compute-Bound هستند،
• بعضی Memory-Bound هستند،
• بعضی به Latency حساس اند،
• بعضی خوب Parallel می شوند،
• و بعضی Scaling محدودی دارند.

بنابراین Generic CPU Score
برای پیش بینی
تمام Simulationها
مناسب نیست.

در Scientific Computing چه چیزهایی اهمیت دارند؟

بسته به Algorithm
ممکن است:

• Floating-Point Throughput،
• Vector Instruction Support،
• Core Count،
• Cache،
• Memory Bandwidth،
• Memory Latency،
• و Library Optimization

اهمیت داشته باشند.

بنابراین Benchmark
باید تا حد امکان
به Algorithm واقعی
نزدیک باشد.

برای Data Analysis چه معیارهایی مهم هستند؟

Data Analysis
می تواند شامل:

• Parsing،
• Filtering،
• Aggregation،
• Compression،
• Statistical Computing،
• Database Operations،
• و Visualization Preparation

باشد.

بعضی مراحل
CPU-Bound
و بعضی
Memory یا Storage-Bound
هستند.

به همین دلیل
CPU Benchmark
باید همراه با
شناخت Bottleneck
تفسیر شود.

Benchmark CPU در بازی چگونه باید تفسیر شود؟

Gaming Performance
نتیجه تعامل
چند بخش سیستم است.

از جمله:

• CPU،
• GPU،
• RAM،
• Game Engine،
• Resolution،
• Graphics Settings،
• و Frame Rate Target.

بنابراین Benchmark بازی
فقط Benchmark CPU
نیست.

CPU-Limited در Gaming یعنی چه؟

اگر GPU
بتواند Frame بیشتری
تولید کند،
اما CPU
نتواند Work لازم
برای Frameهای بیشتر
را به موقع
آماده کند،
سیستم می تواند
CPU-Limited شود.

این وضعیت
بیشتر در:

• Frame Rateهای بالا،
• Resolution پایین تر،
• Graphics Settings سبک تر،
• و بازی های CPU-heavy

دیده می شود.

چرا اختلاف CPU در Resolution بالا ممکن است کمتر شود؟

اگر GPU
عامل محدود کننده
Frame Rate باشد،
CPU سریع تر
ممکن است نتواند
FPS را به مقدار زیادی
افزایش دهد.

Faster CPU
+
GPU Bottleneck
=
Small FPS Gain

بنابراین CPU Gaming Benchmark
باید شرایط Test
را نیز نشان دهد.

چرا Average FPS به تنهایی کافی نیست؟

Average FPS
فقط میانگین
تعداد Frameها
را نشان می دهد.

اما تجربه روان بودن
می تواند تحت تاثیر
Frame Time Variation
نیز باشد.

معیارهایی مانند:

1% Low

می توانند
اطلاعات بیشتری
درباره افت های Performance
ارائه دهند.

تحلیل کامل Gaming
البته به GPU
نیز وابسته است
و نباید فقط
به CPU نسبت داده شود.

برای Server چه Benchmarkی مهم است؟

Server
یک Workload واحد نیست.

ممکن است سیستم
برای:

• Web Server،
• Database،
• Virtualization،
• File Serving،
• Compilation،
• Scientific Computing،
• یا Application Server

استفاده شود.

در Server
معمولاً علاوه بر
Raw Performance
باید:

• Throughput،
• Tail Latency،
• Efficiency،
• Scalability،
• Reliability،
• و Performance per Watt

نیز بررسی شوند.

Tail Latency چیست؟

Average Latency
ممکن است
رفتار کندترین Requestها
را پنهان کند.

در Serviceها
معیارهایی مانند:

P95
/
P99
/
P99.9

می توانند
نشان دهند
درصد کوچکی
از Requestها
چقدر کندتر
از حالت معمول
پاسخ داده می شوند.

برای Workstation چگونه CPU انتخاب کنیم؟

Workstation
معمولاً برای
Workflow حرفه ای
انتخاب می شود.

ممکن است کاربر
همزمان به:

• Single-Thread Performance بالا،
• Multi-Core Throughput بالا،
• RAM زیاد،
• GPU حرفه ای،
• Storage سریع،
• و Reliability

نیاز داشته باشد.

بنابراین Workstation
باید به صورت
یک سیستم کامل
ارزیابی شود،
نه فقط براساس CPU Score.

Multitasking چگونه انتخاب CPU را تغییر می دهد؟

Benchmark تک Application
ممکن است
شرایط واقعی کاربر
را نشان ندهد.

ممکن است کاربر
همزمان:

• IDE،
• Browser،
• Database،
• Virtual Machine،
• Communication App،
• و Background Build

اجرا کند.

در چنین شرایطی
Core Count،
RAM Capacity
و Scheduler Behavior
اهمیت بیشتری پیدا می کنند.

Performance per Watt چیست؟

Raw Performance
تنها معیار
ارزش یک Processor
نیست.

می توان بررسی کرد
CPU به ازای
توان مصرفی مشخص
چه مقدار Performance
تولید می کند.

Performance per Watt
=
Performance
/
Power

این معیار
در:

• لپ تاپ،
• Mini PC،
• Server،
• سیستم های همیشه روشن،
• و محیط های محدود از نظر Cooling

اهمیت زیادی دارد.

آیا سریع ترین CPU بهترین CPU لپ تاپ است؟

نه لزوماً.

در لپ تاپ
علاوه بر Performance
باید:

• Battery Life،
• Heat،
• Noise،
• Weight،
• Sustained Performance،
• و Performance on Battery

نیز بررسی شوند.

Processor سریع تر
ممکن است برای کاربری خاص
ارزش کاهش Battery Life
یا افزایش Noise
را نداشته باشد.

Performance per Price چیست؟

هنگام خرید
فقط Performance مطلق
مهم نیست.

باید دید
برای افزایش Performance
چه مقدار هزینه
پرداخت می شود.

Value
≈
Useful Performance
/
Total Cost

نکته مهم این است
که Performance
باید برای Workload
مورد نظر
«مفید» باشد.

پرداخت هزینه
برای Multi-Core Performance
بسیار بالا
برای کاربری که
هیچ وقت از آن
استفاده نمی کند،
Value بالایی ایجاد نمی کند.

آیا CPU جدیدتر همیشه انتخاب بهتری است؟

نسل جدیدتر
معمولاً می تواند
مزایایی در:

• Architecture،
• Efficiency،
• Instruction Support،
• Platform Features،
• و Performance

داشته باشد.

اما برای تصمیم خرید
باید:

• Performance واقعی،
• قیمت،
• وضعیت دستگاه،
• قابلیت ارتقا،
• مصرف انرژی،
• و نیاز کاربر

نیز بررسی شوند.

Benchmark در خرید سیستم استوک چه کاربردی دارد؟

در سیستم استوک
نباید فقط
نام Processor
را بررسی کرد.

باید Performance
در Context
کل دستگاه
دیده شود.

برای مثال:

• Cooling سالم است؟
• CPU زیر بار طولانی Performance را حفظ می کند؟
• RAM کافی و مناسب وجود دارد؟
• Storage مناسب نصب شده است؟
• Power Adapter مناسب است؟
• Firmware محدودیت غیرعادی ایجاد نمی کند؟

این موضوع
در لپ تاپ،
Workstation،
All-in-One
و کامپیوتر استوک
اهمیت دارد.

چرا Benchmark CPU باید همراه با Bottleneck Analysis باشد؟

اگر Application
توسط GPU
محدود شده باشد،
CPU سریع تر
ممکن است
Improvement کمی
ایجاد کند.

اگر Workload
Memory-Bound باشد،
افزایش Raw Compute
الزاماً به همان نسبت
Performance را بالا نمی برد.

اگر Storage
عامل محدود کننده باشد،
CPU قوی تر
ممکن است بیشتر
منتظر Data بماند.

Performance Gain
Depends on
the Actual Bottleneck

برای هر کاربری به چه نوع Performance بیشتر توجه کنیم؟

مدل اصولی انتخاب CPU براساس Benchmark

مثال: دو CPU با رفتار متفاوت

فرض کنید:

برای کاربری
Interactive و سبک،
CPU A
ممکن است انتخاب
بسیار مناسبی باشد.

برای Rendering طولانی،
CPU B
ممکن است
Work را سریع تر
تمام کند.

بنابراین سؤال:

Which CPU Is Better?

بدون مشخص کردن
Workload
ناقص است.