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

اولین اصل: قبل از انتخاب CPU، Workload را مشخص کنید

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

سوال هایی مانند:

پاسخ به این سوال ها
مسیر انتخاب CPU
را بسیار دقیق تر
از نگاه کردن
به یک Score کلی
مشخص می کند.

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

در Interactive Workload
کاربر منتظر پاسخ
نرم افزار است.

برای مثال:

• باز کردن Command،
• ویرایش Model،
• حرکت در Timeline،
• اجرای Script کوتاه،
• بازسازی بخشی از Project.

در این شرایط
Latency و Performance
Threadهای اصلی
اهمیت زیادی دارند.

Interactive Workload
→
Response Time Matters

در Throughput Workload
هدف انجام
بیشترین حجم کار
در یک بازه زمانی است.

Rendering
/
Encoding
/
Compilation
/
Simulation
→
Throughput May Matter More

چه زمانی Single-Core و چه زمانی Multi-Core مهم تر است؟

اگر بخش اصلی Workload
نتواند روی تعداد زیادی
Thread تقسیم شود،
Performance هر Core
اهمیت بیشتری پیدا می کند.

Limited Parallelism
→
Strong Single-Thread Performance Matters

اگر Workload
به خوبی Parallel شود:

Good Parallel Scaling
→
More Useful Cores
Can Increase Throughput

اما تعداد Core
به تنهایی
معیار مناسبی نیست.

چرا CPU نباید جدا از کل سیستم انتخاب شود؟

CPU تنها یکی
از اجزای سیستم است.

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

• RAM ناکافی،
• Storage کند،
• GPU نامناسب،
• Cooling ضعیف،
• یا Power محدود

ممکن است انتخاب اقتصادی
مناسبی نباشد.

Balanced System
>
One Overpowered Component

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

کاربری اداری معمولاً شامل:

• Word،
• Excel،
• مرور وب،
• PDF،
• نرم افزارهای حسابداری،
• ویدئو کنفرانس،
• اتوماسیون اداری،
• و Multitasking سبک

است.

در چنین سیستمی
معمولاً نیازی به
تعداد بسیار زیاد Core
وجود ندارد.

موارد مهم تر:

• Performance مناسب هر Core،
• پاسخ دهی سریع سیستم،
• مصرف انرژی مناسب،
• RAM کافی،
• و SSD سریع.

برای کاربر اداری،
ارتقای یک سیستم
از HDD به SSD
در بسیاری از شرایط
بیشتر از خرید
CPU بسیار گران تر
در تجربه روزمره
احساس می شود.

برای Excel و صفحات گسترده سنگین چه چیزی مهم است؟

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

فایل ساده اداری
با Workbook بسیار بزرگ
شامل Formula،
Pivot،
Query
و Calculationهای سنگین
رفتار یکسانی ندارد.

در Workloadهای سنگین تر
علاوه بر CPU،
RAM Capacity
و Memory Performance
نیز اهمیت بیشتری
پیدا می کنند.

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

پاسخ به نوع Development
بستگی دارد.

برنامه نویسی سبک:

• Web Development،
• Script نویسی،
• IDEهای معمولی،
• و Projectهای کوچک

معمولاً CPU بسیار پرهسته
نیاز ندارد.

اما در Development سنگین:

• Compilation پروژه بزرگ،
• چند Container،
• Virtual Machine،
• Android Development،
• Buildهای مکرر،
• و اجرای چند Service محلی

Core Count،
RAM Capacity
و Storage Performance
اهمیت بیشتری پیدا می کنند.

برای Compilation چه ویژگی CPU مهم است؟

Build Systemهای مدرن
می توانند
بسیاری از Taskهای Compilation
را به صورت Parallel
اجرا کنند.

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

اما Scaling
نامحدود نیست.

بخش هایی از Build
ممکن است:

• Serial باشند،
• I/O Bound باشند،
• Memory Bound باشند،
• یا Dependency داشته باشند.

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

در بسیاری از عملیات
Interactive و طراحی
در AutoCAD،
Performance قوی
Thread اصلی
اهمیت زیادی دارد.

بنابراین صرفاً
انتخاب CPU
با بیشترین تعداد Core
الزاماً بهترین تصمیم نیست.

برای کاربری AutoCAD
باید میان:

• Single-Thread Performance،
• Clock Behavior،
• RAM Capacity،
• GPU مناسب،
• و Storage سریع

تعادل ایجاد شود.

AutoCAD Interactive Work
→
Strong Per-Core Performance Is Important

برای Revit چه CPUای مناسب است؟

Revit نیز
مجموعه ای از Workloadهای
متفاوت دارد.

بسیاری از عملیات
Modeling و تعامل
با Project
از Performance قوی
Threadهای اصلی
سود می برند.

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

در Projectهای بزرگ
RAM Capacity
نیز اهمیت بسیار زیادی دارد.

بنابراین برای Revit:

Strong Per-Core Performance
+
Adequate Core Count
+
Sufficient RAM
+
Fast Storage

معمولاً رویکرد مناسب تری
نسبت به تمرکز
صرف روی Core Count است.

برای SolidWorks چه CPUای مناسب است؟

SolidWorks نیز
بسته به Operation
می تواند رفتار
متفاوتی داشته باشد.

Modeling،
Rebuild
و بسیاری از عملیات
Interactive
به Performance قوی
هر Core حساس هستند.

در مقابل
Rendering
یا برخی Simulationها
ممکن است
از Coreهای بیشتری
استفاده کنند.

بنابراین:

SolidWorks Modeling
≠
SolidWorks Rendering
≠
SolidWorks Simulation

CPU باید براساس
بخش غالب Workflow
انتخاب شود.

برای Blender چه CPUای مناسب است؟

Blender
شامل Workloadهای
متنوعی است.

هنگام Modeling
و کار Interactive،
Performance هر Core
اهمیت دارد.

در CPU Rendering
تعداد Core و Thread
اهمیت بسیار بیشتری
پیدا می کند.

Blender Modeling
→
Per-Core Performance Important

CPU Rendering
→
Multi-Core Throughput Important

اگر Rendering
عمدتاً روی GPU
انجام شود،
بودجه بیشتر CPU
الزاماً بهترین محل
سرمایه گذاری نیست.

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

Rendering
از Workloadهایی است
که در بسیاری از Engineها
می تواند Parallelism
قابل توجهی داشته باشد.

بنابراین:

• Core Count،
• Thread Count،
• Sustained Clock،
• Power Budget،
• Cooling،
• و Memory Capacity

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

در Render طولانی
Peak Boost
اهمیت کمتری
از Sustained Performance
پیدا می کند.

برای تدوین ویدئو چه CPUای مناسب است؟

Video Editing
فقط یک CPU Workload
نیست.

Performance می تواند
به ترکیبی از:

• CPU،
• GPU،
• Hardware Media Engine،
• RAM،
• Storage،
• Codec،
• Resolution،
• و Software

وابسته باشد.

بنابراین انتخاب CPU
بدون دانستن Codec
و نرم افزار تدوین
می تواند گمراه کننده باشد.

چرا Codec در انتخاب CPU تدوین مهم است؟

Codecهای مختلف
مسیر پردازشی
یکسانی ندارند.

بعضی Workloadها
می توانند از
Hardware Decode/Encode
استفاده کنند.

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

Same Resolution
≠
Same Decode Cost
≠
Same CPU Requirement

برای Gaming چه CPUای مناسب است؟

در Gaming
CPU و GPU
با یکدیگر
در تولید Frame
همکاری می کنند.

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

• نوع Game،
• Frame Rate هدف،
• Resolution،
• قدرت GPU،
• Game Engine،
• Simulation Complexity،
• و Background Workload

بستگی دارد.

برای Gaming
فقط Average FPS
مهم نیست.

Frame-Time Consistency
و رفتار بخش های کندتر
نیز روی تجربه کاربر
اثر دارند.

CPU Bound و GPU Bound در Gaming چیست؟

اگر GPU
محدودیت اصلی
تولید Frame باشد:

GPU Bound

ارتقای CPU
ممکن است
افزایش FPS محدودی
ایجاد کند.

اگر CPU
نتواند Work لازم
برای GPU
را با سرعت کافی
آماده کند:

CPU Bound

CPU سریع تر
می تواند تاثیر
بیشتری داشته باشد.

چرا Resolution روی اهمیت CPU در Gaming اثر می گذارد؟

با افزایش Resolution
معمولاً بار Rendering
روی GPU بیشتر می شود.

در نتیجه
در برخی Scenarioها
GPU زودتر
به Bottleneck تبدیل می شود.

اما این یک قانون مطلق
برای تمام Gameها
و تمام تنظیمات نیست.

برای Virtual Machine و Virtualization چه CPUای مناسب است؟

اگر چند VM
به صورت همزمان
اجرا شوند،
نیاز به:

• Core بیشتر،
• Thread بیشتر،
• RAM زیاد،
• Virtualization Support،
• و Storage سریع

افزایش پیدا می کند.

در بسیاری از سیستم های
Virtualization،
RAM Capacity
حتی می تواند
زودتر از CPU
به محدودیت تبدیل شود.

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

Data Analysis
اصطلاح بسیار گسترده ای است.

Performance می تواند
به:

• اندازه Dataset،
• Library مورد استفاده،
• Parallelism،
• Vectorization،
• RAM Capacity،
• Memory Bandwidth،
• و Storage

وابسته باشد.

بنابراین قبل از خرید
باید Workload واقعی
Benchmark شود.

برای Workstation حرفه ای چه CPUای مناسب است؟

Workstation
فقط به معنی
CPU بسیار پرهسته نیست.

Workstation ممکن است
به ویژگی هایی مانند:

• Core Count بالا،
• Memory Capacity زیاد،
• ECC Support،
• PCIe Lane بیشتر،
• چند GPU،
• I/O گسترده،
• Reliability،
• و Sustained Performance

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

بنابراین Platform
به اندازه خود CPU
اهمیت پیدا می کند.

برای لپ تاپ فقط مدل CPU را بررسی کنیم؟

خیر.

در Laptop
باید CPU
را همراه با
طراحی دستگاه
ارزیابی کرد.

موارد مهم:

• Cooling،
• Power Limit،
• Chassis،
• Fan Profile،
• Battery،
• RAM Configuration،
• و Sustained Performance.

Laptop CPU Performance
=
CPU
+
Laptop Design

اگر Battery Life مهم باشد چه؟

بالاترین Performance
همیشه بهترین انتخاب
برای لپ تاپ نیست.

اگر کاربر:

• دانشجو،
• کاربر اداری سیار،
• مدیر،
• یا کاربر سفر

باشد،
Performance-per-Watt
و رفتار Idle
اهمیت بیشتری پیدا می کند.

Cache چه زمانی در انتخاب CPU مهم می شود؟

Cache بزرگ تر
می تواند در برخی Workloadها
بسیار مفید باشد،
اما نباید
Cache Capacity
را جدا از:

• Cache Latency،
• Cache Topology،
• Memory Behavior،
• Dataset،
• و Microarchitecture

بررسی کرد.

بنابراین:

More Cache
≠
Automatically Faster CPU

آیا CPU با GHz بیشتر سریع تر است؟

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

Performance واقعی
به ترکیبی از:

Frequency
×
Work Per Cycle
×
Workload Behavior

وابسته است.

بنابراین مقایسه
4 GHz یک Architecture
با 4 GHz
Architecture دیگر
نتیجه قطعی
درباره Performance نمی دهد.

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

نسل جدیدتر
می تواند مزایایی
در Architecture،
Efficiency،
Platform
و Featureها داشته باشد.

اما تصمیم خرید
باید قیمت
و Performance واقعی
را نیز در نظر بگیرد.

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

آیا Core i7 همیشه از Core i5 بهتر است؟

خیر.

نام خانواده
بدون دانستن:

• Generation،
• Exact Model،
• Core Count،
• Architecture،
• Power Class،
• و Platform

برای مقایسه کافی نیست.

Product Tier
Alone
≠
Performance Ranking

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

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

یعنی:

Required Performance
/
Total System Cost

گاهی یک سیستم
نسل قدیمی تر
با RAM بیشتر،
SSD مناسب
و Cooling بهتر
برای کاربر
انتخاب کاربردی تری
از دستگاهی با CPU جدیدتر
اما سایر اجزای ضعیف تر است.

چک لیست انتخاب CPU برای سیستم استوک

ماتریس کلی انتخاب CPU براساس کاربری

مسیر تصمیم گیری سریع برای انتخاب CPU

اشتباه اول: «Core i7 همیشه از Core i5 سریع تر است»

Core i5 و Core i7
نام Tier محصول هستند،
نه یک رتبه بندی جهانی
میان تمام نسل ها.

برای مقایسه صحیح
باید حداقل:

• نسل،
• مدل دقیق،
• Architecture،
• Core Configuration،
• Power Class،
• و نوع دستگاه

مشخص باشد.

Core i7
Alone
Does Not Define Performance

یک Core i5
از نسل جدیدتر
ممکن است در برخی Workloadها
از Core i7
نسل قدیمی تر
سریع تر باشد.

اشتباه دوم: «Ryzen 7 همیشه از Ryzen 5 سریع تر است»

همین منطق
درباره خانواده های دیگر
نیز صدق می کند.

Ryzen 5،
Ryzen 7
یا Ryzen 9
باید در Context
نسل،
Architecture،
مدل،
Power Class
و Workload
بررسی شوند.

Product Family
≠
Universal Performance Ranking

اشتباه سوم: «نسل جدیدتر همیشه سریع تر است»

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

• Architecture،
• Efficiency،
• Featureها،
• Memory Support،
• I/O،
• و Platform

داشته باشد.

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

Newer Generation
≠
Automatically Faster Than Every Older CPU

اشتباه چهارم: «GHz بیشتر یعنی CPU سریع تر»

Frequency
تعداد Cycle
در واحد زمان
را توصیف می کند.

اما مقدار کاری
که CPU
در هر Cycle
انجام می دهد
بین Architectureها
متفاوت است.

Performance
≠
Frequency Alone

عواملی مانند:

• IPC،
• Execution Width،
• Branch Prediction،
• Cache،
• Memory Latency،
• Instruction Set Implementation،
• و Workload

روی Performance نهایی
اثر دارند.

اشتباه پنجم: «CPU همیشه با Maximum Boost Clock کار می کند»

Maximum Boost Clock
معمولاً یک Frequency
تضمین شده برای
تمام Coreها
و تمام مدت Load
نیست.

Frequency واقعی
می تواند تحت تاثیر:

• تعداد Coreهای فعال،
• Temperature،
• Power Limit،
• Current Limit،
• نوع Workload،
• Firmware،
• و Cooling

تغییر کند.

Advertised Max Boost
≠
Sustained All-Core Frequency

اشتباه ششم: «هرچه Core بیشتر، CPU بهتر»

Core بیشتر
زمانی مفید است
که Workload
بتواند از آنها
استفاده کند.

اگر بخش اصلی برنامه
Serial باشد،
اضافه شدن Coreها
الزاماً Performance
آن بخش را افزایش نمی دهد.

More Cores
+
Poor Parallel Scaling
=
Limited Benefit

بنابراین Core Count
باید در کنار
Per-Core Performance
بررسی شود.

اشتباه هفتم: «Thread بیشتر یعنی همان مقدار Core بیشتر»

Logical Thread
با Physical Core
یکسان نیست.

SMT یا فناوری های مشابه
به یک Core اجازه می دهند
چند Thread
را مدیریت کند،
اما منابع داخلی Core
کاملاً دو برابر نمی شوند.

8 Cores / 16 Threads
≠
16 Physical Cores

اشتباه هشتم: «Cache بیشتر همیشه CPU را سریع تر می کند»

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

اما Performance Cache
فقط به Capacity
وابسته نیست.

موارد مهم دیگر:

• Latency،
• Bandwidth،
• Topology،
• Sharing Policy،
• Hit Rate،
• و Working Set.

Larger Cache
≠
Universal Performance Gain

اشتباه نهم: «TDP همان مصرف برق CPU است»

TDP
نباید بدون توجه
به تعریف سازنده
معادل مستقیم
مصرف لحظه ای CPU
در تمام شرایط
در نظر گرفته شود.

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

• Workload،
• Boost،
• Power Policy،
• Motherboard،
• Firmware،
• و محدودیت های Platform

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

TDP
≠
Universal Real-Time Power Consumption

اشتباه دهم: نادیده گرفتن پسوند CPU

پسوند مدل
می تواند اطلاعات مهمی
درباره کلاس
یا ویژگی پردازنده
ارائه دهد.

برای مثال
بسته به خانواده و نسل،
پسوند ممکن است
به تفاوت هایی در:

• Power Class،
• Unlocked Multiplier،
• Integrated Graphics،
• Mobile Segment،
• Performance Class،
• یا Feature Set

اشاره کند.

معنی پسوندها
باید براساس
همان Manufacturer
و همان Generation
بررسی شود.

اشتباه یازدهم: مقایسه CPU لپ تاپ و دسکتاپ فقط براساس نام

حتی اگر نام تجاری
دو CPU شبیه باشد،
نسخه Mobile
و Desktop
می توانند:

• Power Budget متفاوت،
• Core Configuration متفاوت،
• Clock Behavior متفاوت،
• Cooling متفاوت،
• و Performance متفاوت

داشته باشند.

Desktop Product Name
≠
Mobile Product Performance

اشتباه دوازدهم: «CPU یکسان در دو لپ تاپ دقیقاً یک Performance دارد»

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

دو لپ تاپ
با CPU یکسان
ممکن است:

• Cooling متفاوت،
• Power Limit متفاوت،
• Fan Curve متفاوت،
• RAM متفاوت،
• Firmware متفاوت،
• و Chassis متفاوت

داشته باشند.

Same Mobile CPU
≠
Guaranteed Same Sustained Performance

اشتباه سیزدهم: تصمیم خرید براساس یک Benchmark

یک Benchmark
فقط رفتار CPU
در Workload مشخص
و شرایط مشخص
را نشان می دهد.

CPU ممکن است
در یک Test
برتری داشته باشد
و در Test دیگری
نتیجه متفاوتی
ارائه دهد.

One Benchmark
≠
Complete CPU Evaluation

Benchmarkهای انتخاب شده
باید با نرم افزار
و Workflow واقعی کاربر
ارتباط داشته باشند.

اشتباه چهاردهم: اعتماد کامل به یک امتیاز کلی

برخی سایت ها
چند Test مختلف
را در یک Score
ترکیب می کنند.

این Score
می تواند برای
مقایسه سریع مفید باشد،
اما باید بدانیم:

• چه Testهایی در Score وجود دارند،
• وزن هر Test چقدر است،
• داده ها چگونه جمع آوری شده اند،
• و Score با Workload کاربر چه ارتباطی دارد.

امتیاز کلی
نباید جایگزین
Benchmark مرتبط
با کاربرد واقعی شود.

اشتباه پانزدهم: اعتماد مطلق به Bottleneck Calculator

Bottleneck
یک درصد ثابت
متعلق به دو قطعه نیست.

Bottleneck
به Workload
وابسته است.

در Gaming
حتی برای
یک CPU و GPU ثابت،
Bottleneck می تواند
با تغییر:

• Game،
• Resolution،
• Graphics Settings،
• Frame Rate Target،
• Scene،
• Game Engine،
• RAM،
• و Background Load

تغییر کند.

Bottleneck
=
Workload-Dependent Limitation

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

17% CPU Bottleneck

نباید بدون دانستن
Methodology
به عنوان حقیقت ثابت
پذیرفته شود.

اشتباه شانزدهم: تلاش برای ساخت سیستم با «صفر درصد Bottleneck»

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

هدف طراحی سیستم
حذف کامل Bottleneck
نیست.

هدف این است
که Bottleneck
با نیاز کاربر،
بودجه
و Performance هدف
منطقی باشد.

No Bottleneck
Is Not A Practical Design Goal

اشتباه هفدهم: صرف بودجه بیش از حد برای CPU

اگر Workload
عمدتاً GPU Bound باشد،
خرید CPU بسیار گران
و GPU ضعیف تر
می تواند Performance
کل سیستم را کاهش دهد.

این مسئله
در Gaming،
GPU Rendering،
AI
و برخی Workloadهای
Visual Computing
اهمیت دارد.

Budget Allocation
Should Follow
Workload Bottlenecks

اشتباه هجدهم: خرید CPU قوی با RAM ناکافی

اگر Working Set
برنامه در RAM
جا نشود،
سیستم ممکن است
مجبور به استفاده
بیشتر از Storage
شود.

در چنین شرایطی
CPU سریع
نمی تواند
کمبود Memory Capacity
را جبران کند.

Fast CPU
+
Insufficient RAM
=
Potentially Slow System

اشتباه نوزدهم: تمرکز روی CPU و نادیده گرفتن Storage

بسیاری از عملیات
روزمره سیستم
تحت تاثیر Storage هستند.

برای مثال:

• Boot،
• باز شدن Application،
• Load Project،
• File Search،
• Cache،
• و برخی Buildها.

بنابراین سیستم
با CPU متوسط
و SSD مناسب
می تواند در استفاده روزمره
Responsiveتر از سیستمی
با CPU قوی تر
و Storage بسیار کند باشد.

اشتباه بیستم: نادیده گرفتن Cooling

Cooling
فقط برای جلوگیری
از خرابی نیست.

در CPUهای مدرن
Thermal Headroom
می تواند روی:

• Boost Frequency،
• Sustained Clock،
• Noise،
• Power Behavior،
• و Performance طولانی مدت

اثر بگذارد.

Cooling
Is Part Of
Performance

اشتباه بیست و یکم: رد کردن سیستم استوک فقط به دلیل نسل قدیمی تر

Generation
عامل مهمی است،
اما تنها عامل
ارزش خرید نیست.

باید بررسی شود:

• Performance واقعی CPU،
• تعداد Core مناسب،
• RAM،
• SSD،
• GPU،
• کیفیت ساخت،
• قابلیت ارتقا،
• و قیمت کل دستگاه.

یک Workstation
یا لپ تاپ تجاری
نسل قدیمی تر
ممکن است برای
Workload مشخص
همچنان انتخاب مناسبی باشد.

اشتباه بیست و دوم: خرید سیستم استوک فقط به خاطر برچسب i7

عبارت:

Core i7 Laptop

برای تصمیم خرید
اطلاعات کافی
ارائه نمی دهد.

باید مدل دقیق
مانند:

CPU Family
+
Generation
+
Model Number
+
Suffix

مشخص باشد.

علاوه بر آن،
خود مدل Laptop
نیز باید بررسی شود.

اشتباه بیست و سوم: نسبت دادن هر افت Performance به خود CPU

اگر یک سیستم استوک
Benchmark ضعیفی
ثبت کند،
علت الزاماً
CPU معیوب نیست.

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

• Thermal Throttling،
• Cooling System،
• Fan،
• Power Mode،
• Firmware،
• RAM Configuration،
• Background Process،
• و Power Adapter

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

اشتباه بیست و چهارم: نادیده گرفتن آداپتور لپ تاپ هنگام تست

در برخی Laptopها
استفاده از Adapter
نامناسب،
کم توان
یا شناسایی نشده
می تواند روی
Power Policy
سیستم اثر بگذارد.

بنابراین هنگام Benchmark
لپ تاپ استوک،
وضعیت Adapter
نیز باید بررسی شود.

اشتباه بیست و پنجم: مقایسه Benchmark روی Battery و برق مستقیم

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

بنابراین:

AC Performance
≠
Battery Performance

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

اشتباه بیست و ششم: مقایسه Performance بدون توجه به قیمت

CPU سریع تر
الزاماً Value
بهتری ندارد.

ممکن است
برای 10 درصد
Performance بیشتر،
هزینه بسیار بیشتری
پرداخت شود.

تصمیم اقتصادی
باید بررسی کند:

Additional Performance
vs
Additional Cost

و مهم تر از آن:

Does The User Actually Need
That Extra Performance?

اشتباه بیست و هفتم: خرید بیش از حد با عنوان Future-Proof

داشتن Headroom
منطقی مفید است،
اما خرید Hardware
بسیار فراتر
از نیاز واقعی
همیشه اقتصادی نیست.

Technology،
Software،
Platform
و نیاز کاربر
در طول زمان
تغییر می کنند.

بنابراین Future-Proofing
باید براساس
سناریوی واقعی
و مدت استفاده
تعریف شود.

اشتباه بیست و هشتم: انتخاب CPU فقط براساس برند

Intel،
AMD
یا سایر Vendorها
در نسل ها
و Segmentهای مختلف
محصولات متفاوتی دارند.

انتخاب مهندسی
باید براساس:

• Workload،
• Performance،
• Efficiency،
• Platform،
• Featureها،
• قیمت،
• و Availability

انجام شود.

اشتباه بیست و نهم: برابر دانستن Benchmark Score با تجربه کاربری

دو سیستم
ممکن است اختلاف
Benchmark CPU داشته باشند،
اما کاربر در Workflow واقعی
تفاوت بسیار کمتری
احساس کند.

برعکس،
در یک Workload خاص
اختلاف کوچک
در Score کلی
می تواند تفاوت بزرگ تری
در Task مورد نظر
ایجاد کند.

Benchmark Difference
≠
Automatically Same Difference
In User Experience

اشتباه سی ام: استفاده اشتباه از درصد Performance

اگر CPU A
یک Task را
در 100 ثانیه
و CPU B
در 80 ثانیه
انجام دهد،
زمان اجرا
20 درصد کاهش یافته است.

اما Speedup:

100 / 80
=
1.25×

است.

بنابراین عبارت های:

20% Less Time

و:

20% Faster

الزاماً یک مفهوم
ریاضی ندارند.

قبل از خرید CPU این سوال ها را بپرسید

روش اشتباه و روش درست مقایسه CPU

تصویر بزرگ: CPU دقیقاً در کجای سیستم قرار دارد؟

کاربر مستقیماً
با CPU کار نمی کند.

کاربر با Application
کار می کند.

Application
از طریق Software Stack
به Hardware می رسد.

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

مرحله اول: نرم افزار چگونه به دستور CPU تبدیل می شود؟

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

بسته به زبان
و Runtime،
این تبدیل می تواند
از طریق:

• Compilation،
• Interpretation،
• Just-In-Time Compilation،
• یا ترکیبی از این روش ها

انجام شود.

در پایین این زنجیره
ISA قرار دارد.

Source Code
→
Machine Instructions
→
ISA

ISA چه نقشی در این مدل دارد؟

Instruction Set Architecture
قرارداد میان Software
و Processor است.

ISA مشخص می کند
Software چه عملیات هایی
می تواند از CPU درخواست کند.

اما ISA الزاماً مشخص نمی کند
CPU در داخل
چگونه آن دستور را اجرا کند.

ISA
=
Architectural Contract

Microarchitecture
=
Internal Implementation

Microarchitecture؛ جایی که طراحی واقعی CPU آغاز می شود

دو پردازنده
می توانند ISA
یکسانی داشته باشند،
اما Performance،
Power
و رفتار کاملاً متفاوتی
ارائه دهند.

دلیل آن
تفاوت Microarchitecture است.

Microarchitecture
شامل تصمیم هایی درباره:

• Front-End Width،
• Decoderها،
• Branch Predictor،
• Register Renaming،
• Scheduler،
• Execution Units،
• ROB،
• Load/Store System،
• Cache Hierarchy،
• و بسیاری از ساختارهای داخلی دیگر

است.

Front-End؛ رساندن Instruction به موتور اجرا

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

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

Instruction Fetch
↓
Branch Prediction
↓
Decode
↓
Internal Operations
↓
Rename / Dispatch

اگر Front-End
نتواند با سرعت کافی
عملیات مورد نیاز
Back-End را تامین کند،
Execution Units
ممکن است منتظر بمانند.

Front-End Bottleneck
→
Execution Resources Underutilized

Branch Prediction؛ حدس زدن آینده برای جلوگیری از توقف

Pipelineهای مدرن
برای Performance بالا
نیاز دارند
قبل از مشخص شدن
نتیجه بعضی Branchها
مسیر احتمالی اجرا
را پیش بینی کنند.

Good Prediction
→
Useful Work Continues

Misprediction
→
Wrong-Path Work Discarded
→
Pipeline Recovery

بنابراین کیفیت
Branch Predictor
مستقیماً می تواند
روی IPC
اثر بگذارد.

Decode؛ تبدیل Instruction به عملیات قابل مدیریت داخلی

Instructionهای معماری
باید توسط Front-End
Decode شوند.

بسته به Architecture،
یک Instruction
ممکن است به یک
یا چند عملیات داخلی
تبدیل شود.

Architectural Instruction
↓
Decode
↓
Internal Operations

از این نقطه به بعد
CPU تلاش می کند
Dependencyها
و منابع مورد نیاز
عملیات را مدیریت کند.

Register Renaming؛ حذف Dependencyهای کاذب

نام Registerهای معماری
همیشه نشان دهنده
Dependency واقعی داده نیست.

Register Renaming
به CPU اجازه می دهد
برخی Dependencyهای کاذب
را حذف کند.

Architectural Registers
↓
Rename
↓
Physical Register Resources

نتیجه:
آزادی بیشتر
برای اجرای همزمان
عملیات مستقل.

Out-of-Order Execution؛ پیدا کردن کار مفید هنگام انتظار

برنامه Instructionها
را با ترتیب منطقی
مشخصی ارائه می دهد.

اما CPU مدرن
مجبور نیست
تمام عملیات را
دقیقاً به همان ترتیب
اجرا کند.

اگر یک عملیات
منتظر داده باشد
و عملیات دیگری
مستقل و آماده باشد،
CPU می تواند
عملیات آماده را
زودتر اجرا کند.

Waiting Instruction
+
Independent Ready Instruction
↓
Out-of-Order Scheduling
↓
Useful Execution Continues

هدف اصلی:

Hide Latency
+
Increase Resource Utilization
+
Increase IPC

Execution Units؛ جایی که عملیات واقعاً انجام می شوند

عملیات آماده
به واحدهای مناسب
ارسال می شوند.

بسته به طراحی CPU
این واحدها می توانند شامل:

• Integer Units،
• Floating-Point Units،
• Vector Units،
• Load Units،
• Store Units،
• Branch Units،
• و واحدهای تخصصی دیگر

باشند.

تعداد زیاد Execution Unit
به تنهایی کافی نیست.

Front-End،
Scheduler
و Workload
باید بتوانند
آنها را تغذیه کنند.

Retirement؛ چگونه اجرای Out-of-Order نتیجه صحیح تولید می کند؟

CPU ممکن است
عملیات را Out-of-Order
اجرا کند،
اما وضعیت معماری
باید طوری به روز شود
که از دید Software
رفتار صحیح حفظ شود.

ساختارهایی مانند
Reorder Buffer
در این فرایند
نقش مهمی دارند.

Out-of-Order Execution
↓
Ordered Retirement
↓
Precise Architectural State

مسیر داده؛ چرا CPU بدون Memory System سریع نمی ماند؟

Execution Unit
فقط زمانی
می تواند عملیات را انجام دهد
که Operandهای لازم
در دسترس باشند.

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

Register
↓
L1 Cache
↓
L2 Cache
↓
Last-Level Cache
↓
Main Memory
↓
Storage

قرار داشته باشد.

هرچه داده
از Core دورتر شود،
معمولاً دسترسی
هزینه بیشتری دارد.

Cache؛ تلاش برای نزدیک نگه داشتن داده به CPU

اختلاف سرعت
میان CPU Core
و DRAM
یکی از مسائل بنیادی
طراحی سیستم است.

Cache Hierarchy
برای کاهش اثر
این فاصله ایجاد شده است.

Small + Fast
→
L1
→
L2
→
LLC
→
Larger + Slower

Cache Hit
می تواند داده را
سریع تر در اختیار Core
قرار دهد.

Cache Miss
ممکن است CPU را
مجبور به مراجعه
به سطح پایین تر
Memory Hierarchy کند.

TLB؛ چرا ترجمه آدرس نیز بخشی از Performance است؟

Applicationها معمولاً
با Virtual Address
کار می کنند.

Hardware و Operating System
باید این آدرس ها
را به Physical Address
مرتبط کنند.

TLB
اطلاعات Translation
پرکاربرد را Cache می کند.

Virtual Address
↓
TLB
↓
Physical Address

TLB Miss
می تواند هزینه
بیشتری به مسیر
Memory Access
اضافه کند.

CPU چگونه بخشی از Memory Latency را پنهان می کند؟

CPU مدرن
فقط منتظر یک Memory Request
نمی ماند.

در صورت امکان
چند Access مستقل
می توانند همزمان
در جریان باشند.

Memory-Level Parallelism
→
Multiple Outstanding Requests
→
Better Latency Hiding

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

از یک Core به چند Core؛ Parallelism در سطح سیستم

افزایش تعداد Core
امکان اجرای
Threadهای بیشتری
را به صورت همزمان
فراهم می کند.

اما Software
باید بتواند Workload
را به Taskهای
قابل اجرا به صورت موازی
تقسیم کند.

More Cores
+
Parallel Software
→
Potentially Higher Throughput

اگر Workload
Serial باشد،
Coreهای اضافی
ممکن است کمک محدودی
ایجاد کنند.

SMT؛ استفاده بهتر از منابع یک Core

یک Thread
همیشه نمی تواند
تمام منابع Core
را در تمام Cycleها
استفاده کند.

SMT
اجازه می دهد
بیش از یک Thread
منابع Core
را به اشتراک بگذارند.

Idle Execution Capacity
+
Another Thread
→
Potentially Higher Utilization

اما Logical Thread
معادل یک Core فیزیکی
مستقل نیست.

چند Core چگونه روی داده مشترک توافق می کنند؟

در سیستم Multi-Core
چند Cache
می توانند نسخه هایی
از داده مشترک
داشته باشند.

Cache Coherence
کمک می کند
Coreها دید سازگاری
از Memory
داشته باشند.

اما Sharing
و Synchronization
رایگان نیستند.

More Parallelism
Can Also Mean
More Communication
+
More Synchronization

Clock و IPC؛ دو بخش مهم Performance

Frequency
به ما می گوید
CPU در هر ثانیه
چند Cycle دارد.

IPC
نشان می دهد
در یک Workload مشخص
به طور متوسط
چه مقدار Instruction
در هر Cycle
تکمیل می شود.

Instructions / Second
≈
IPC
×
Frequency

این رابطه
برای ساخت مدل ذهنی
مفید است،
اما IPC
مقدار ثابتی
برای یک CPU نیست.

IPC با Workload،
Memory Behavior،
Branches
و سایر عوامل
تغییر می کند.

چه چیزهایی IPC را پایین می آورند؟

بنابراین IPC
حاصل تعامل
Workload
با Microarchitecture است.

چرا Performance به Power وابسته است؟

افزایش فعالیت،
Frequency
و Voltage
می تواند مصرف توان
و تولید Heat
را افزایش دهد.

به صورت ساده شده:

Dynamic Power
∝
C × V² × f

این رابطه نشان می دهد
افزایش Voltage
می تواند هزینه توان
قابل توجهی داشته باشد.

بنابراین Frequency
را نمی توان
بدون توجه به Power
افزایش داد.

Heat؛ حلقه بازخوردی که Performance را محدود می کند

Power مصرف شده
در نهایت
به Heat تبدیل می شود.

Cooling System
باید این Heat
را از Processor
خارج کند.

Workload
↓
CPU Activity
↓
Power
↓
Heat
↓
Cooling
↓
Temperature

اگر Temperature
یا Power
به محدودیت برسد،
CPU می تواند
Operating Point
خود را تغییر دهد.

Boost؛ Performance ثابت نیست

CPU مدرن
الزاماً با یک Frequency
ثابت کار نمی کند.

سیستم مدیریت توان
دائماً شرایطی مانند:

• Workload،
• Active Cores،
• Temperature،
• Power،
• Current،
• و Platform Limits

را بررسی می کند.

Available Headroom
→
Higher Operating Frequency

Reduced Headroom
→
Lower Sustainable Operating Point

Peak Performance و Sustained Performance

CPU ممکن است
برای مدت کوتاهی
Performance بالایی
ارائه دهد.

اما Workload طولانی
شرایط متفاوتی ایجاد می کند.

Short Burst
→
High Boost

Long Load
→
Thermal Equilibrium
+
Power Constraints
→
Sustained Performance

این موضوع
مخصوصاً در Laptopها
اهمیت زیادی دارد.

حالا می توانیم مدل کامل تری از Performance بسازیم

Performance واقعی
نتیجه یک متغیر
واحد نیست.

علامت جمع در این مدل
یک فرمول ریاضی دقیق نیست؛
بلکه نشان دهنده
تعامل چند عامل
در Performance نهایی است.

مفهوم کلیدی تمام دانشنامه: Bottleneck جابه جا می شود

اگر Front-End
محدود باشد:

More Execution Units
May Not Help

اگر Memory
محدود باشد:

Higher Clock
May Provide Limited Gain

اگر Software
Serial باشد:

More Cores
May Provide Limited Gain

اگر Cooling
محدود باشد:

Higher Theoretical Boost
May Not Be Sustainable

بنابراین:

Optimization
=
Find The Current Bottleneck
→
Reduce It
→
Find The Next Bottleneck

چرا Workload همیشه مرکز تحلیل است؟

یک CPU
ممکن است در Workload A
بسیار خوب
و در Workload B
متوسط باشد.

دلیل آن
تفاوت نیازهای Workload است.

چرا مشخصات روی کاغذ Performance را کامل توضیح نمی دهند؟

اکنون می توانیم
پاسخ این سوال را
دقیق تر بدهیم.

مشخصاتی مانند:

8 Cores
/
16 Threads
/
4.5 GHz
/
16 MB Cache

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

• IPC واقعی Workload،
• Branch Prediction،
• Memory Behavior،
• Execution Width،
• Latencyها،
• Power Limit،
• Cooling،
• و Software Optimization

اطلاعات کاملی نمی دهند.

به همین دلیل
Specification
باید همراه Benchmark
و Workload Analysis
تفسیر شود.

یک مثال کامل: وقتی کاربر دکمه Render را می زند چه اتفاقی می افتد؟

این زنجیره نشان می دهد
چرا یک Benchmark نهایی
حاصل عملکرد
ده ها Mechanism
به صورت همزمان است.

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

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

باید بپرسیم:

یعنی دانش معماری CPU
مستقیماً به تصمیم خرید
قابل تبدیل می شود.

مدل ذهنی نهایی CPU

ده اصل مهندسی که از دانشنامه CPU باید باقی بمانند

نقشه اصلی مفاهیم CPU

لایه اول: Software و Workload

همه چیز از Workload شروع می شود.

Software مشخص می کند:

• چه تعداد Instruction اجرا شود،
• چه نوع Instructionهایی استفاده شوند،
• چه مقدار Data پردازش شود،
• چه میزان Parallelism وجود داشته باشد،
• چه مقدار Branch وجود داشته باشد،
• و چه الگوی Memory Access ایجاد شود.

Workload Characteristics
→
CPU Behavior

Algorithm چگونه روی CPU اثر می گذارد؟

دو برنامه
ممکن است یک مسئله
را حل کنند،
اما Algorithmهای متفاوت
داشته باشند.

Algorithm می تواند
روی:

• Instruction Count،
• Branch Frequency،
• Memory Access Pattern،
• Cache Locality،
• Parallelism،
• و Synchronization

اثر بگذارد.

Better Algorithm
Can Matter More Than
Faster Hardware

Compiler در این نقشه کجا قرار می گیرد؟

Compiler
میان Source Code
و ISA
قرار دارد.

Compiler می تواند
تصمیم هایی درباره:

• Instruction Selection،
• Instruction Scheduling،
• Vectorization،
• Inlining،
• Loop Optimization،
• و Register Usage

بگیرد.

Algorithm
+
Compiler
→
Instruction Stream

ISA؛ مرز بین Software و Hardware

ISA
مجموعه قواعدی است
که Software
براساس آن
با Processor
ارتباط برقرار می کند.

مفاهیم مهم مرتبط:

SOFTWARE
↔
ISA
↔
MICROARCHITECTURE

Microarchitecture؛ پیاده سازی واقعی ISA

Microarchitecture
تصمیم می گیرد
چگونه Instructionهای ISA
در Hardware
اجرا شوند.

مفاهیم اصلی:

• Pipeline،
• Superscalar Execution،
• Out-of-Order Execution،
• Speculation،
• Register Renaming،
• ROB،
• Scheduler،
• Execution Portها،
• Cache Hierarchy،
• و Prefetcher.

نقشه Front-End

Front-End
باید با نرخ کافی
Operation
به Back-End
تحویل دهد.

نقشه Branch Prediction

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

• Speculative Execution،
• Pipeline Depth،
• Bad Speculation،
• IPC،
• و Security Side Channel

متصل است.

نقشه Back-End و Execution

Dependencyها چگونه به Performance متصل می شوند؟

سه مفهوم اصلی:

• True Dependency،
• False Dependency،
• Memory Dependency.

Register Renaming
می تواند بعضی
False Dependencyها
را حذف کند.

اما True Dependency
قابل حذف نیست.

Long Dependency Chain
→
Low Instruction-Level Parallelism
→
Lower Potential IPC

نقشه جامع Memory Hierarchy

حرکت به سمت پایین
معمولاً با:

Capacity ↑

Latency ↑

Cost Per Bit ↓

همراه است.

مفاهیم Cache چگونه به هم متصل می شوند؟

Locality
شامل:

• Temporal Locality،
• Spatial Locality.

Prefetching
نیز تلاش می کند
این رفتار
را پیش بینی کند.

Cache Coherence در سیستم Multi-Core کجا قرار می گیرد؟

وقتی چند Core
روی Data مشترک
کار می کنند،
باید نسخه های Cache
هماهنگ باشند.

این موضوع
به:

• False Sharing،
• Synchronization،
• Memory Ordering،
• Interconnect،
• و Multi-Core Scaling

مرتبط است.

Virtual Memory چگونه به CPU متصل می شود؟

این مسیر
به:

• Page Table،
• TLB،
• Page Size،
• Memory Protection،
• Virtualization،
• و Security

متصل است.

نقشه Multi-Core

Multi-Core Performance
به:

• Parallelism،
• Load Balance،
• Synchronization،
• Communication،
• Memory Bandwidth،
• Cache Coherence،
• و Power Budget

وابسته است.

SMT در نقشه Multi-Core چه جایگاهی دارد؟

SMT
تعداد Core فیزیکی
را افزایش نمی دهد.

بلکه تلاش می کند
Resourceهای Core
را بهتر استفاده کند.

SIMD و Vector Processing کجا قرار می گیرند؟

بعضی Workloadها
عملیات مشابهی
را روی حجم زیادی
از Data
انجام می دهند.

SIMD
امکان پردازش
چند Data Element
با یک Instruction
را فراهم می کند.

One Instruction
→
Multiple Data Elements
→
Higher Data-Level Parallelism

این موضوع
به:

• Compiler Vectorization،
• AVX / SSE یا Extensionهای مشابه،
• Execution Width،
• Memory Bandwidth،
• و Power Consumption

متصل است.

نقشه Performance

هیچ کدام
از این عوامل
به تنهایی
Performance
را تعیین نمی کنند.

IPC به چه چیزهایی وابسته است؟

بنابراین IPC
مشخصه ثابت
یک CPU
نیست.

نقشه Power و Frequency

این حلقه
دائماً در CPU مدرن
در حال تغییر است.

رابطه ساده Dynamic Power

Pdynamic
≈
α × C × V² × f

بنابراین:

• Switching Activity بیشتر → Power بیشتر
• Capacitance بیشتر → Power بیشتر
• Voltage بیشتر → افزایش شدیدتر Power
• Frequency بیشتر → Power بیشتر

این رابطه
توضیح می دهد
چرا آخرین بخش Performance
معمولاً از نظر Power
گران تر است.

نقشه Thermal

هر بخش
می تواند Thermal Resistance
ایجاد کند.

Cooling بهتر
می تواند Headroom
بیشتری برای
Sustained Performance
فراهم کند.

نقشه CPU در Laptop

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

نقشه CPU در Server

NUMA چگونه در نقشه Server قرار می گیرد؟

در سیستم های بزرگ،
فاصله CPU
تا Memory
می تواند متفاوت باشد.

CPU / NUMA Node
→
Local Memory
=
Lower Access Cost

CPU / NUMA Node
→
Remote Memory
=
Higher Access Cost

بنابراین Thread Placement
و Memory Placement
روی Performance
اثر دارند.

نقشه امنیت CPU

در کنار این لایه ها،
Microarchitectural Side Channelها
نشان می دهند
Performance Optimization
می تواند با Security
تعامل پیچیده داشته باشد.

نقشه Virtualization

Memory Virtualization:

Guest Virtual Address
→
Guest Physical Address
→
Host Physical Address

با کمک:

EPT / NPT / SLAT

نقشه Reliability

نقشه Aging

این مسیر
با:

• Electromigration،
• BTI،
• Hot Carrier Effects،
• TDDB،
• و Thermal Cycling

مرتبط است.

نقشه تولید و Binning

این بخش
به تفاوت میان:

• Silicon Variation،
• Product Segmentation،
• Harvesting،
• و Silicon Lottery

متصل است.

نقشه Performance Monitoring

نقشه Benchmark

اگر Question
مشخص نباشد،
Benchmark
می تواند عدد تولید کند
اما پاسخ مفیدی
تولید نکند.

نقشه انتخاب CPU

نقشه Bottleneck

نقشه Trade-offهای اصلی CPU

مهم ترین روابط علت و معلولی در CPU

نقشه نهایی؛ CPU از چهار زاویه