Intel проти AMD в іграх: де бенчмарки вас вводять в оману

Що ігрові бенчмарки зазвичай приховують

Якщо ви хочете зрозуміти Intel vs AMD в іграх, перестаньте запитувати «хто швидший» і почніть питати
«за яких обмежень, з якими режимами відмов і які показники важливі для мого стилю гри».
Хороший бенчмарк ізолює змінну. Поганий бенчмарк ізолює фантазію.

1) Вони підлаштовуються під один движок і називають це «іграми»

Одна гра може бути тортурним тестом для планувальника; інша — святом кешу; ще одна — фактично демо-рендер GPU із мінімальним CPU. Якщо набір тестів сильно тяжіє до одного-двох движків (або однієї версії гри), ви не купуєте процесор — ви купуєте сумісність з цим тестом.

2) Вони показують середній FPS, а не вартість нестабільності

Середній FPS легко відобразити і легко з його допомогою обманювати. «1% найнижчих» краще, але все одно занадто стиснуто в одному числі.
Те, що ви відчуваєте, — це стабільність часу кадру: чи отримуєте ви рівномірний потік кадрів, або періодичні сплески 40–80 мс, які здаються підгальмовуванням?

3) Вони нормалізують витрати платформи

«CPU A перемагає на 6%» часто ховає за собою, що CPU A тестували з агресивним тюнінгом оперативки, іншою політикою буста на материнській платі
або BIOS із тихою за замовчуванням налаштуванням, яке змінює все (привіт, Multi-Core Enhancement / «enhanced turbo»).
Для реальних покупців поведінка платформи — частина продукту.

4) Вони ігнорують фонову роботу, поки вона не з’явиться у вас

Більшість бенчмарків запускають на чистій ОС без фонових процесів: без оновлень лаунчерів, без вкладок браузера, без софту RGB у треї.
Багато гравців стрімлять, записують, використовують голосовий чат і мають антивірус та оверлеї.
У такому середовищі гібридні CPU і особливості планувальника стають важливішими.

5) Вони уникають тривалих прогонів, де з’являються тепло- і енергобюджети

Короткі прогони лестять. Довгі прогони чесні. Поведінка буста при тривалому навантаженні відрізняється між чіпами, платами, кулерами й корпусами.
Процесор, що виглядає блискуче 60 секунд, може стати просто «середнім» на 10-й хвилині.

Суха правда: «CPU-бенчмарк», який не публікує ліміти потужності, налаштування пам’яті, версію BIOS, збірку Windows і графік часу кадру,
— це як звіт про інцидент із фразою «ми перезавантажили і все зникло».

Факти та контекст, що пояснюють сучасні результати

Дебати Intel vs AMD набувають релігійного забарвлення, бо люди забувають, як сильно змінюється ландшафт. Ось конкретні контекстні моменти, що
роблять сучасні бенчмарки менш загадковими й більш передбачуваними.

1. Оригінальний Athlon 64 від AMD (2003) вивів контролер пам’яті на кристал, зменшивши затримки та змусивши Intel реагувати.
   Урок «затримка має значення» повторюється й у сучасному ігровому світі.
2. Мікроархітектура Core від Intel (2006) перебудувала історію продуктивності за тактом після ери Pentium 4 із підходом «додай GHz».
   IPC і ефективність стали справжнім полем бою.
3. Hyper-Threading з’явився для споживачів у ранніх 2000-х, потім зникав у деяких SKU, потім повернувся — нагадуючи, що логічні потоки допомагають у деяких завданнях і заплутують інші.
4. Повернення Ryzen (2017) зробило «більше ядер» більш доступним, що підштовхнуло движки й програмне забезпечення вважати 6–8 ядер нормою, а не екзотикою.
5. Планування Windows для гетерогенних CPU стало масовим з появою гібридних архітектур Intel (P-ядра + E-ядра), створивши нові класи помилок продуктивності «працює на моїй машині».
6. 3D V-Cache від AMD (X3D) зсунуто лідерство в іграх у багатьох тайтлах за рахунок зменшення поїздок до пам’яті для ігрових даних. Це не магія; це затримка та локальність.
7. Рання епоха DDR5 мала реальні проблеми росту: вища пропускна здатність, іноді гірша затримка залежно від таймінгів і режимів — отже «DDR5» сам по собі мало що говорить.
8. Resizable BAR / Smart Access Memory вийшли з ніші в широкий ужиток, змінюючи профілі продуктивності деяких ігор, особливо при стрімінгу ресурсів.
9. DirectX 12 і Vulkan не «прибрали CPU-вузькі місця»; вони їх перемістили. Накладні витрати на подачу команд змінили форму проблеми, але движки все ще можуть блокуватися на роботі головного потоку.

Жарт для розрядки: вибирати процесор за одним графіком — це як обирати парашут за палітрою кольорів.
Він може бути гарний. Він також може стати вашим останнім естетичним рішенням.

Середній FPS — це примха; час кадру — це ваша плата за житло

Ви можете отримувати в середньому 200 FPS і при цьому гра виглядати погано. Це не суб’єктивно; це математика.
«Хіч» — це сплеск часу кадру: один кадр займає значно більше часу, ніж сусідні, порушуючи плавність руху й відгук на введення.

Що заміряти натомість

• Графік часу кадру (час кадру у мс на кадр): показує сплески, періодичні підвисання та довгий хвіст поведінки.
• 1% і 0.1% найнижчих значень: грубе стиснення хвостової латентності. Корисно, але недостатньо.
• Послідовність розподілу кадрів: чи чергуються 5 мс і 15 мс кадри (мікро-підгальмовування) навіть при високому середньому?
• Завантаження CPU/GPU у часі: не один знімок, а графік по часу.

Як тут спотворюється Intel vs AMD

Деякі CPU виграють у середньому FPS, бо досягають вищого пікового буста й мають відмінну одно-потокову продуктивність. Це добре виглядає в коротких прогонах.
Інші CPU виграють за стабільністю, бо кеш зменшує залежність від пам’яті, або бо тривалі частоти стабільніші при типовому охолодженні.
Що «відчувається краще», залежить від гри, вашої GPU, налаштувань і фонового навантаження.

Ви не купуєте процесор, щоб вразити діаграму. Ви купуєте його, щоб мінімізувати хвостову латентність, виконуючи інші ваші задачі:
голосовий чат, стрімінг, браузер, компіляція шейдерів, оновлення Windows, які обирають найгірший момент для свого існування.

Роздільна здатність і налаштування: проблема «косплею CPU-бенчмарка»

Якщо ви тестуєте процесори при 1080p low з флагманською відеокартою, ви можете виявити відмінності CPU. Це корисно для аналізу.
Але не прикидайтеся, що це передбачає, як люди грають на 1440p high або 4K з трасуванням променів.

Коли 1080p low корисний

Це корисно, коли ви спеціально досліджуєте масштабування CPU: обмеження движка, подача викликів рендеру, симуляція, AI, скрипти.
Також це корисно, якщо ви справді граєте в esports тайтли на високому оновленні з низькими налаштуваннями.

Коли це вводить в оману

Коли ви підвищуєте роздільну здатність і якість, ви зсуваєте вузьке місце до GPU. CPU-відмінності стискаються. Іноді вони інвертуються через:

• GPU стає лімітером, маскуючи дельти CPU.
• Різні CPU по-різному взаємодіють із накладними витратами драйвера GPU і поведінкою PCIe.
• Конфігурація пам’яті, що допомагала на 1080p, стає неактуальною на 4K, де GPU — довгий кінець.

Практична порада: якщо ви граєте на 1440p/4K з високими налаштуваннями, пріоритезуйте CPU, який дає стабільні часи кадру й достатньо ядер для багатозавдань,
а реальні гроші витрачайте на GPU і охолодження. Якщо ви граєте конкурентно на 1080p/240Hz, CPU і тюнінг пам’яті мають набагато більше значення.

Поведінка буста, ліміти потужності та планувальники: невидимі руки

Більшість драм навколо «Intel vs AMD» — це не силікон. Це політика.
Алгоритми буста — це динамічні системи. Материнські плати «ввічливо брешуть» про «стокові» налаштування. Операційні системи планують потоки з неповною інформацією.
А ліміти потужності/теплові обмеження — це бюджет, який перетворює теоретичну продуктивність на реальну.

Intel: ліміти потужності й значення за замовчуванням плати можуть переписати результати

Сучасні настільні чіпи Intel можуть споживати значно більше за номінальну базову потужність під турбо. Багато плат постачаються з лояльними налаштуваннями:
тривалі турбо-періоди, високий PL2 і параметри, що фактично знімають обмеження. Оглядачі можуть тестувати на тих налаштуваннях; у вас цього може не бути.
Або гірше: у вас може бути, але ваш кулер/корпус не витримує, і частоти починають коливатися.

AMD: буст чутливий до температур і зрілості прошивки

Поведінка буста AMD також динамічна й чутливо реагує на запас температури. Невеликі зміни в монтажі кулера, кривій вентиляторів
і потоці повітря по корпусу можуть змінити «середню ефективну частоту» під час сесії. Оновлення BIOS/AGESA історично покращували сумісність пам’яті
і іноді послідовність продуктивності.

Гібридне планування: P-ядра, E-ядра і податок «не та нитка на не тому ядрі»

На гібридних CPU ігри можуть поводитися по-різному залежно від того, чи головний потік стабільно розміщується на продуктивному ядрі,
і чи фонові завдання відсуваються на ефективні ядра. Сучасні версії Windows загалом справляються добре, але залишаються крайові випадки:
антічіт, оверлеї, софт для захоплення, старі ігри з дивними пріоритетами потоків.

Найпоширеніша помилка в бенчмаркуванні: запуск чистого, однопроцесного тесту, який ніколи не змушує планувальник приймати важкі рішення.
У реальному житті ви завжди його змушуєте.

Один цитат, перефразована ідея, бо це суть: Вернер Фогельс (перефразовано): «Усе виходить із ладу весь час — проєктуйте й експлуатуйте так, ніби воно вийде з ладу»
Вибір CPU — частина цього проєктування.

Затримка пам’яті, кеш і чому X3D спотворює дискусію

Ігри — це хаотичні задачі з даними. Багато переходів за покажчиками, оновлень стану й стрімінгу ресурсів. Це робить їх чутливими до затримки пам’яті й поведінки кешу,
а не лише до сирої пропускної здатності. Саме тут спрощені тези «Intel має вищі такти» або «AMD має більше кешу» перетворюються на нісенітницю.

Чому кеш може домінувати

Якщо робочий набір гарячого циклу поміщається в кеш, CPU менше чекає DRAM. Це зменшує хвостову латентність і покращує 1% найнижчих значень.
X3D-версії AMD часто блищать тут, бо додатковий L3 тримає ближче більше ігрових даних.
Але це залежить від навантаження: деякі ігри виграють дуже сильно; інші — майже не змінюються.

Чому тюнінг пам’яті може перевертати графіки

Швидкість оперативки — заголовок; таймінги — ось історія. DDR5 з високою частотою та розслабленими таймінгами може програвати DDR5 з нижчою частотою, але жорсткішими таймінгами в іграх, чутливих до затримки.
Також: режими передачі, command rate і стабільність важливі. «Швидкий» профіль пам’яті, який постійно виправляє помилки або переучує канали, створить підгальмовування, яке ви не поясните середнім FPS.

Що робити покупцю

• Якщо ви хочете plug-and-play, обирайте комплекти пам’яті й плати з нудною історією сумісності, а не лише за найвищим XMP/EXPO-числом.
• Якщо ви прагнете високого оновлення для esports, будьте готові до тюнінгу пам’яті або заплатіть за перевірену конфігурацію, яку хтось інший уже валідував.
• Якщо ви граєте в великі відкриті світи, що стрімлять ресурси й запускають важку симуляцію, кеш і затримка пам’яті можуть мати більше значення, ніж додаткові 200 МГц.

Схоплювання й I/O-стуттер: бенчмарк, який не протримався довго

Ви можете мати «найкращий ігровий CPU» і все одно отримувати підгальмовування, бо система чекає на зберігання, декомпресію, компіляцію шейдерів або через конфлікт файлової системи.
Бенчмарки часто запускають канонічну сцену після того, як ресурси вже розігріті в ОЗП і шейдер-кеші побудовані. Ваші перші 30 хвилин гри не такі ввічливі.

Де схоплювання взаємодіє з вибором CPU

Стрімінг асетів і декомпресія можуть забирати CPU-час. Різні CPU по-різному справляються з фоновою декомпресією, файловим I/O і накладними витратами драйверів, особливо під одночасним навантаженням (гра + запис + браузер + патчер). Бенчмарк, що ізолює процес гри, пропускає це.

Як «швидкий SSD» стає «генератором випадкового стуттера»

NVMe-диски можуть тротлитися термічно, ділити лінії або страждати від прошивкових багів. Індексація Windows і антивірус можуть підсилити невеликі I/O- зупинки до помітних хічів.
І якщо ваша система має дефіцит пам’яті, пейджинг перетворює будь-яке порівняння CPU на фарс.

Три корпоративні міні-історії з полів бою

Міні-історія №1: Інцидент через неправильне припущення

Лабораторія продуктивності ігрової студії стандартизувала одну «референсну ПК»-збірку. Припущення було розумним: тримати ОС чистою,
зафіксувати драйвери і порівнювати процесори яблуко до яблука. Вони додали новий гібридний Intel CPU в пул і побачили періодичні сплески часу кадру в DX12-тайтлі.
На AMD-системах цього не було. У кімнаті стало голосно.

Перша реакція була класичною: звинуватити CPU. Друга — звинуватити движок. Третя — «має бути драйвер GPU».
Тим часом сплески траплялися лише на машинах, які ще й захоплювали телеметрію з високою частотою.
В образі лабораторії фоновий збирач був встановлений на «normal priority», і Windows іноді планував його на P-ядро саме тоді, коли рендер-потік гри його потребував.

Неправильне припущення було не «гібридні CPU погані». Воно полягало в тому, що «наше тестове середовище відповідає реальному середовищу».
Гравці стрімлять. Гравці мінімізують вікна. Гравці мають оверлеї. Лабораторія — ні.

Виправлення не було магічною правкою реєстру. Вони перевели збирач на нижчий пріоритет, задали явну афініті для процесу захоплення
і оновили збірки Windows по всій лабораторії. CPU не був невинним, але й не був лиходієм.
Лиходієм стало немоделюване фонове навантаження плюс планувальник, якому довелося приймати важчі рішення, ніж про це казав бенчмарк.

Міні-історія №2: Оптимізація, яка дала зворотний ефект

Корпоративний кіберспортивний зал ввів «підгонку продуктивності» на десятках ПК. Хтось прочитав форум і вирішив,
що найкраще — відключити E-ядра скрізь, щоб «зменшити латентність». Також вони нав’язали агресивний профіль пам’яті, бо комплект «так міг».
На швидкому тесті все виглядало нормально.

Під час першого турніру машини почали показувати періодичні підгальмовування і зрідка тріск у голосовому зв’язку.
Персонал бачив високий FPS і припустив, що це мережа. Вони замінили свичі. Поміняли гарнітури. Перезавантажували ПК між матчами.
Проблема лишалася, бо система не падала гучно — вона давала збої в хвості.

Постмортем виявив дві причини. По-перше, відключення E-ядер штовхнуло фонові задачі (оновлення антічіту, служби лаунчера, голосовий софт)
на ті ж P-ядра, які використовувала гра, збільшуючи конкуренцію під час пікових моментів. По-друге, профіль пам’яті був маргінальним: він переучувався на деяких холодних завантаженнях
і логував скориговані помилки. Нічого не «впало», але джиттери латентності проявилися як джиттер часу кадру.

Повернення до розумних значень відразу покращило консистентність. Справжній урок: оптимізація — це експеримент, а не віра.
Якщо ви не можете виміряти це (час кадру + лічильники ОС + логи стабільності), ви не оптимізували; ви просто щось змінили.

Міні-історія №3: Скучна, але правильна практика, яка врятувала день

ІТ-команда, що підтримувала віддалених розробників і тестувальників, отримувала скаргу: «збірка гри на AMD працює добре, на Intel — підгальмовує».
Спокуса була почати CPU-святу війну. Натомість вони зробили непопулярне: склали чекліст і застосували його.

Кожна машина мала надсилати однукову базову телеметрію: версію BIOS, конфігурацію пам’яті, збірку Windows, план живлення, версію драйвера GPU
і 10-хвилинний запис часу кадру в стандартизованому сценарії. Якщо проблема не відтворювалася з цим набором, її не брали в роботу.
Інженери бурчали. Сапорт святкував.

Візерунок стуттера корелював із певною версією драйвера сховища і фоновим скануванням шифрування, що запускалося за розкладом, який перетинався з часом тестів.
Це не було Intel vs AMD. Це було I/O-конкуренція плюс регресія драйвера. Різниця CPU лише визначала, наскільки видимою була проблема.

Виправлення було нудним: відкат драйвера, корекція розкладу і політика, що тестування продуктивності виконується з паузою сканування.
Чекліст не змусив нікого відчути себе розумнішим — саме тому він і працював.

Швидкий план діагностики

Коли хтось каже «CPU A краще за CPU B в моїй грі», ваше завдання — швидко знайти вузьке місце.
Ось прагматичний порядок дій, що дозволяє уникнути днів забобонів.

Спочатку: класифікуйте вузьке місце (CPU vs GPU vs I/O) за 5 хвилин

• Перевірте завантаження GPU під час проблеми. Якщо GPU під 95–100% і часи кадру стабільні — здебільшого ви GPU-заблоковані.
• Перегляньте поведінку по ядрах CPU. Якщо одне-дві ядра завантажені під 100%, а інші празі — ймовірно обмеження головного потоку або драйвера.
• Перевірте активність диска й hard faults. Якщо піки читання диска співпадають зі сплесками часу кадру і ви бачите пейджинг — це I/O або пам’ять.

Друге: перевірте частоти, потужність і терміни (фізика непереможна)

• Підтвердіть стійкі частоти під 10–15 хвилинним навантаженням, а не 60-секундним спринтом.
• Шукайте термальне троттлінг і коливання лімітів потужності.
• Переконайтеся, що CPU працює з очікуваною політикою живлення (balanced/high performance) і що плата не «допомагає» потай.

Третє: усуньте планувальник і фоновий шум

• Тимчасово відключіть оверлеї й захоплення, щоб перевірити, чи зникає стуттер.
• Перевірте, чи не потрапляють ігрові потоки на невірний клас ядер (гібридні CPU).
• Переконайтеся, що збірки Windows і драйвери чипсету достатньо актуальні для вашої платформи.

Четверте: перевірте пам’ять і сигнали стабільності

• Підтвердіть, що швидкість/таймінги RAM відповідають очікуванням.
• Перевірте наявність скоригованих помилок пам’яті (тихі вбивці продуктивності).
• Не довіряйте оверклоку, що «лягає раз на тиждень». Це не стабільність; це терпіння.

Практичні завдання з командами (і що робити з результатом)

Це команди для Linux, бо вони спостережні й скриптовані. Логіка переноситься на будь-яку ОС:
виміряйте, скорелюйте, вирішіть. Запускайте їх під час відтворення стуттера або низького FPS.

Завдання 1: Визначити модель CPU, топологію й типи ядер

cr0x@server:~$ lscpu
Architecture:             x86_64
CPU(s):                   24
Thread(s) per core:       2
Core(s) per socket:       12
Socket(s):                1
Vendor ID:                GenuineIntel
Model name:               13th Gen Intel(R) Core(TM) i7-13700K
CPU MHz:                  800.000
CPU max MHz:              5400.0000
L3 cache:                 30720K
Flags:                    ...

Що це означає: Підтверджує вендора, кількість ядер, SMT, розмір кешу й макс-частоту.
Рішення: Якщо ви очікували 8 ядер, а бачите 6 — ви в неправильному ящику або BIOS обмежує. Якщо гібридна архітектура, плануйте перевірку планування й афініті.

Завдання 2: Слідкувати за завантаженням по ядрах, щоб виявити обмеження головного потоку

cr0x@server:~$ mpstat -P ALL 1
Linux 6.5.0 (server)  01/10/2026  _x86_64_ (24 CPU)

12:01:02 AM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
12:01:03 AM  all   35.2  0.0   4.1   0.3     0.0  0.8    0.0   59.6
12:01:03 AM    2   98.5  0.0   0.5   0.0     0.0  0.0    0.0    1.0
12:01:03 AM    7   12.1  0.0   1.0   0.0     0.0  0.2    0.0   86.7

Що це означає: CPU2 завантажений, інші ні: класична поведінка «гарячий потік».
Рішення: Ви CPU-обмежені головним потоком або потоком драйвера; покращення GPU навряд допоможе. Розгляньте CPU із кращою одно-потоковою продуктивністю й кешем, та налаштуйте фонове навантаження.

Завдання 3: Підтвердити поведінку частот під навантаженням

cr0x@server:~$ sudo turbostat --Summary --interval 2
turbostat version 2023.11.07 - Len Brown 
Summary:		Avg_MHz	Busy%	Bzy_MHz	TSC_MHz	PkgTmp	PkgWatt
2.00 sec	 4120	 62.5	 5120	 3300	  92	 175.3
2.00 sec	 3980	 61.8	 4980	 3300	  97	 188.9

Що це означає: Температура пакета висока і потужність близька до лімітів; частоти можуть почати падати, якщо охолодження не витримає.
Рішення: Якщо сплески часу кадру збігаються з коливаннями температури/потужності — виправте охолодження, потік повітря корпусу або ліміти потужності, перш ніж звинувачувати «Intel vs AMD».

Завдання 4: Швидко виявити термальне троттлінг

cr0x@server:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +98.0°C  (high = +100.0°C, crit = +105.0°C)
Core 0:        +96.0°C
Core 1:        +97.0°C

Що це означає: Ви на межі термального потолка.
Рішення: Очікуйте нестабільні частоти і непослідовні часи кадру. Вирішіть питання охолодження або зменшіть стійкий турбо-режим. Швидший процесор на папері не допоможе, якщо він живе біля TjMax.

Завдання 5: Побачити, який процес створює тиск на CPU

cr0x@server:~$ pidstat -u -p ALL 1
12:05:11 AM   UID       PID    %usr %system  %CPU  Command
12:05:12 AM  1000     18422   160.0    12.0 172.0  game.bin
12:05:12 AM  1000     10233    18.0     3.0  21.0  obs
12:05:12 AM     0      1321     6.0     9.0  15.0  nvidia-powerd

Що це означає: Гра важка, але OBS теж непо-дрібному навантажує.
Рішення: Якщо OBS переводить вас від «добре» до «підгальмовування», потрібен запас ядер або кращий шлях кодування (апаратний енкодер), а не перемога в середньому FPS на 3%.

Завдання 6: Перевірити планування CPU і афініті для конкретного процесу

cr0x@server:~$ taskset -cp 18422
pid 18422's current affinity list: 0-23

Що це означає: Процес може запускатися на будь-якому CPU.
Рішення: На гібридних системах (або «шумних» системах) розгляньте прикріплення фонових процесів подалі від пріоритетних ядер, щоб захистити стабільність часу кадру.

Завдання 7: Проінспектувати I/O wait і тиск диска під час стуттеру

cr0x@server:~$ iostat -xz 1
avg-cpu:  %user %system %iowait  %idle
          28.4    4.2     9.8    57.6

Device            r/s     rkB/s   await  %util
nvme0n1          85.0   18432.0   22.5   96.8

Що це означає: Високий %iowait, велике await і %util близько до насичення: сховище зараз вузьке місце.
Рішення: Не купуйте новий CPU, щоб виправити перевантажений NVMe або фонове сканування. Виправте I/O-конкуренцію, перемістіть гру або усуньте тротлінг.

Завдання 8: Підтвердити, чи система пейджить (тиск на пам’ять)

cr0x@server:~$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 2  0  262144  81200  1024  110000   0   64  1200   300 2100 4800 32  5 54  9

Що це означає: Ненульове so (swap out) вказує на активність пейджингу.
Рішення: Додайте RAM, зменшіть кількість фонових додатків або виправте витік. Пейджинг робить порівняння CPU безглуздим, бо ви тестуєте латентність сховища.

Завдання 9: Перевірити вільне місце файлової системи й ризик фрагментації (проксі)

cr0x@server:~$ df -h /games
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p3  931G  890G   41G  96% /games

Що це означає: Диск майже заповнений; багато SSD уповільнюються при малій кількості вільного місця через зниження overprovisioning і доступного простору для garbage collection.
Рішення: Звільніть простір (ціль — 15–20%), перемістіть великі захоплення з ігрового диска і перезапустіть тест. Не плутайте «задушений SSD» з «втратами CPU».

Завдання 10: Перевірити стан NVMe і термальні попередження

cr0x@server:~$ sudo smartctl -a /dev/nvme0
SMART/Health Information (NVMe Log 0x02)
Temperature:                        78 Celsius
Available Spare:                    100%
Percentage Used:                    2%
Data Units Read:                    12,345,678
Warning  Comp. Temperature Time:    4

Що це означає: Температура висока і були інтервали термальних попереджень.
Рішення: Додайте радіатор/покращіть потік повітря для диска або перемістіть його. Тротлінг NVMe може виглядати як «випадкове» підгальмовування в сценах із активним стрімінгом ресурсів.

Завдання 11: Виявити симптоми накладних витрат драйвера GPU на CPU (опосередковано)

cr0x@server:~$ perf top -g --call-graph fp
Samples: 2K of event 'cycles', 4000 Hz, Event count (approx.): 123456789
  18.2%  game.bin                [.] RenderSubmit
  12.5%  libnvidia-glcore.so     [.] __GLDispatchDispatchStub
   9.1%  game.bin                [.] PhysicsStep
   6.8%  libc.so.6               [.] memcpy

Що це означає: Значна частина циклів CPU йде в шлях розгортання драйвера графіки.
Рішення: Якщо ви обмежені головним потоком і накладні витрати драйвера помітні, архітектура CPU і частоти можуть мати більше значення. Також розгляньте вибір API (DX12/Vulkan), версії драйвера і налаштування в грі, що зменшують кількість draw call.

Завдання 12: Перевірити версії ядра і драйверів для зрілості платформи

cr0x@server:~$ uname -a
Linux server 6.5.0-21-generic #21-Ubuntu SMP PREEMPT_DYNAMIC x86_64 GNU/Linux

Що це означає: Підтверджує версію ядра. Новіші CPU і планувальники часто виграють від новіших ядер і підтримки прошивок.
Рішення: Якщо ви на старому ядрі/збірці ОС з новим гібридним CPU — оновіть перед тим, як робити висновки про «яка марка плавніша».

Завдання 13: Перевірити governor/power policy CPU (латентність vs економія)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
schedutil

Що це означає: Governor впливає на те, як швидко піднімаються частоти. Деякі політики віддають перевагу ефективності; інші — відгуку.
Рішення: Якщо ви бачите повільний підйом і сплески латентності — протестуйте тимчасово governor performance як експеримент (потім вирішіть на основі енергоспоживання/терм та виміряного часу кадру).

Завдання 14: Скорелюйте стуттер з системними логами (помилки WHEA-подібні і нестабільність)

cr0x@server:~$ sudo journalctl -k -p warning --since "1 hour ago" | tail -n 12
Jan 10 00:41:02 server kernel: mce: [Hardware Error]: CPU 3: Machine Check: 0 Bank 12: b200000000070005
Jan 10 00:41:02 server kernel: mce: [Hardware Error]: TSC 0 ADDR fef1a140 MISC d012000100000000
Jan 10 00:41:02 server kernel: EDAC MC0: 1 CE memory read error on DIMM_A1

Що це означає: Скориговані помилки (CE) і шум machine check можуть вказувати на маргінальну стабільність — часто налаштування пам’яті/IMC, іноді undervolt/overclock.
Рішення: Послабте профіль RAM або undervolt, оновіть BIOS і перезапустіть тест. Проблеми зі стабільністю проявляються як «стуттер» задовго до краху.

Другий і останній жарт: Оверклокинг пам’яті — це як сперечатися з дитиною — іноді ви «переможете», але заплатите пізніше, і це не буде готівкою.

Типові помилки: симптом → корінь проблеми → виправлення

1) Симптом: Високий середній FPS, але «випадкові» підгальмовування кожні 10–30 секунд

Корінь: Фонові I/O (індексація, антивірусні сканування), компіляція шейдерів або термальний тротлінг NVMe.

Виправлення: Моніторте %util диска і температуру NVMe під час гри; перемістіть гру на «холодніший» диск; виключіть папки гри з реального часу сканування; переконайтеся, що кеш шейдерів зберігається.

2) Симптом: Завантаження GPU сильно коливається (60–99%), а CPU виглядає «не надто зайнятим»

Корінь: Однопотокове CPU-вузьке місце (головний потік/потік драйвера), приховане середнім по ядрах.

Виправлення: Перевірте завантаження по ядрах; зменшіть налаштування, що навантажують CPU (відстань видимості, щільність натовпу); розгляньте CPU з кращою одно-потоковою продуктивністю і/або більшим кешем; тримайте фонові задачі подалі від критичних ядер.

3) Симптом: Бенчмарк каже, що Intel перемагає, але ваша Intel-збірка підвисає більше, ніж AMD

Корінь: Поведінка лімітів потужності/тепла відрізняється від тестового стенду; «покращення» материнської плати спричиняють коливання частот; планувальник конфліктує з фоновими додатками.

Виправлення: Нормалізуйте ліміти потужності й охолодження; оновіть BIOS; підтвердіть стійкі частоти; тестуйте з відключеними оверлеями/захопленням; потім додавайте їх по одному.

4) Симптом: 1% найнижчих значень погіршилися лише після оновлення драйвера

Корінь: Регресія драйвера, що змінює накладні витрати CPU або поведінку кешу шейдерів.

Виправлення: Відкат до відомого робочого драйвера; очистити/перебудувати кеш шейдерів; повторити тест в ідентичній сцені гри.

5) Симптом: Підгальмовування з’явилося після увімкнення EXPO/XMP, але інші програми «ніби в нормі»

Корінь: Маргінальна стабільність пам’яті, що викликає скориговані помилки, переучування або джиттер затримки.

Виправлення: Зменшіть частоту пам’яті, встановлюйте таймінги лише після валідації стабільності, оновіть BIOS/AGESA і розглядайте скориговані помилки як провал тесту — навіть якщо нічого не падає.

6) Симптом: Конкурентний шутер здається «плавним», незважаючи на високий FPS

Корінь: Варіація в розподілі кадрів, латентність введення або втручання планувальника від софту для захоплення/овералей.

Виправлення: Обмежте FPS для стабілізації часу кадру, відключіть/оптимізуйте оверлеї, забезпечте послідовний high-refresh шлях і ізолюйте фонові задачі на некритичні ядра.

7) Симптом: Оновлення GPU не покращило FPS у конкретній грі

Корінь: Обмеження CPU (симуляція, draw calls) або вузьке місце API/движка.

Виправлення: Підтвердіть по завантаженню по ядрах і графіках часу кадру; налаштуйте параметри, які навантажують CPU; розгляньте апгрейд CPU або вигоду від X3D-подібного кешу, якщо тайтл чутливий до кешу.

8) Симптом: Продуктивність відмінна перші 2 хвилини, потім падає й стає непослідовною

Корінь: Теплове насичення CPU або VRM, або примусове застосування лімітів потужності після короткого вікна турбо.

Виправлення: Покращіть охолодження/потік повітря для VRM, встановіть розумні ліміти потужності і підтвердіть стійку поведінку 10–15-хвилинними прогонами.

Контрольні списки / крок за кроком

Контрольний список A: Рішення про покупку (не дозволяйте бенчмаркам запхати вас у каяття)

1. Запишіть свій реальний режим гри: роздільна здатність, частота оновлення, налаштування та чи стрімите/записуєте/користуєтесь Discord.
2. Обирайте 5–8 ігор, в які ви справді граєте на різних движках (одна кібертитул, один відкритий світ, один на UE, одна стратегія/симулятор тощо).
3. Пріоритезуйте докази стабільності часу кадру (графіки, довгі прогони) над середніми FPS-дельтами менше ніж 10%.
4. Залучіть бюджет під платформу: якісна материнська плата, комплект RAM і кулер. CPU не існує сам по собі; це система.
5. Визначте свою толерантність до ризику: якщо ви не будете тюнінгувати, уникайте конфігів, що вимагають героїчних заходів (агресивна RAM, граничне охолодження).
6. Для high-refresh 1080p/1440p esports: віддавайте перевагу сильній одно-потоковій продуктивності і стабільному бусту; тюнінг пам’яті може мати значення.
7. Для 1440p/4K з високими налаштуваннями: не переплачуйте за CPU заради крихітних середніх; витрачайте на GPU і стабільність.
8. Для ігор чутливих до стуттеру в відкритих світах: кеш і затримка пам’яті можуть вартовати реальних грошей.

Контрольний список B: Бенчмаркування вашої системи (щоб ваші дані не були вигадкою)

1. Зафіксуйте сцену тесту і тривалість (не менш ніж 10 хвилин, а не 60 секунд).
2. Записуйте час кадру, а не тільки FPS.
3. Публікуйте конфігурацію: версія BIOS, профіль RAM, ліміти потужності, версія Windows/драйверів.
4. Запустіть три проходи і порівняйте варіативність. Якщо варіативність велика — ви вимірюєте шум.
5. Розігрівайте кеші послідовно (або окремо тестуйте холодний старт).
6. Тестуйте з реальними фоновими додатками і без них.

Контрольний список C: Кроки усунення, коли починаються «CPU brand» суперечки

1. Доведіть клас вузького місця (CPU vs GPU vs I/O) за допомогою завантаження і кореляції з часом кадру.
2. Нормалізуйте потужність і терміни; перестаньте порівнювати дроселений бокc з холодним.
3. Стабілізуйте пам’ять; рахуйте скориговані помилки як червоний прапорець.
4. Оновіть BIOS/чипсет; зрілість платформи має значення.
5. Лише потім порівнюйте CPU — і робіть це на наборі завдань, що відповідає реальності.

Часті питання

1) Хто зараз «кращий для ігор» — Intel чи AMD?

Ніхто універсально. Деякі AMD X3D-чіпи перемагають у багатьох ігрових сценаріях завдяки кеш-орієнтованій консистентності; деякі Intel-чіпи виграють у високочастотних, слабо багатопотокових випадках.
Ваш рівень GPU, роздільна здатність і фонове навантаження вирішують, які відмінності проявляться.

2) Навіщо оглядачі тестують на 1080p low, якщо більшість грає на вищих налаштуваннях?

Щоб виставити CPU-відмінності, зменшивши GPU-обмеження. Це корисно для аналізу, але вводить в оману при покупці, якщо ви граєте у GPU-заблокованих налаштуваннях.
Завжди зіставляйте тест із вашим реальним вузьким місцем.

3) Що важливіше: середній FPS чи 1% найнижчих?

1% найнижчих ближче до того, що ви відчуваєте, але графіки часу кадру ще кращі. Одне число може приховати періодичні сплески або мікро-джиттер.

4) Чи шкодять E-ядра іграм?

Не обов’язково. Вони можуть допомогти, поглинаючи фонові задачі. Проблеми виникають, коли планування або пріоритети змушують критичні ігрові потоки конкурувати за невірні ядра.
При налагодженні спочатку тестуйте без фонових додатків, перш ніж міняти конфігурацію ядер.

5) Чи завжди швидша пам’ять покращує ігри?

Ні. Затримка й стабільність важать так само, іноді більше за пропускну здатність. Нестабільний «швидкий» профіль може погіршити час кадру і спричиняти скориговані помилки без очевидних крашів.

6) Чому у мого друга «той самий CPU», але у нього плавніше?

За замовчуванням материнська плата, версія BIOS, ефективність кулера, профіль RAM, фонове ПЗ і навіть терміни SSD можуть змінити поведінку часу кадру.
«Той самий CPU» не означає «та сама система».

7) Чи варто обмежувати FPS для плавнішої гри?

Часто так. Розумне обмеження може стабілізувати час кадру і зменшити коливання потужності/термальної поведінки. Особливо корисно, коли GPU близький до насичення або буст CPU стрибкоподібний.

8) Чи потрібно хвилюватися про сховище для ігрової продуктивності?

Так, щодо стуттера. Стрімінг ресурсів, читання/запис кешу шейдерів і фонові сканування можуть створити I/O-зупинки. Багато бенчмарків не протримаються довго, щоб це показати.

9) Яке найобманливіше твердження «Intel vs AMD»?

«Цей CPU на X% швидший в іграх». Без вказання роздільної здатності, рівня GPU, конфігурації пам’яті, лімітів потужності і розподілу часу кадру — це маркетинг, а не інженерія.

10) Якщо я стрімлю чи записую, що пріоритезувати?

Запас ядер, передбачуване планування і стабільність часу кадру. Апаратне кодування може зменшити навантаження на CPU, але система все одно має справлятися з фоновими задачами, не відбираючи час у гарячих потоків гри.

Висновок: наступні кроки, які дійсно працюють

Intel vs AMD в іграх — це не боксерський поєдинок. Це системна проблема. Бенчмарки вводять в оману, коли прикидаються, що ваше навантаження — це 60-секундний скрипт на стерильній ОС із магічним охолодженням і без фонового шуму. Ваше реальне навантаження — це хаотичне, довготривале, перериване цирк-шоу — і воно хоче консистентності.

Практичні наступні кроки:

1. Визначте, що ви оптимізуєте: відчуття латентності в high-refresh конкуренті або візуальна пропускна здатність у високих налаштуваннях, або стабільність при стримінгу.
2. Заміряйте час кадру на власній системі протягом 10–15 хвилин з вашими реальними фоновими додатками.
3. Нормалізуйте базові речі: BIOS актуальний, розумні ліміти потужності, стабільна пам’ять, достатнє охолодження і вільний простір на SSD.
4. Виправте те вузьке місце, яке у вас є — насичення GPU, обмеження головного потоку або I/O-стуттер — перш ніж купувати «переможця».
5. Лише потім порівнюйте CPU, і вважаєте малі дельти середнього FPS неважливими, якщо вони не супроводжуються кращою хвостовою латентністю.

Якщо вам потрібне правило, що виведе з біди: купуйте під те вузьке місце, яке ви можете довести, а не за скріншот бенчмарка.