AVX: інструкції, що пришвидшують навантаження — й роблять CPU гарячішими

Що насправді робить AVX (і чому це змінює поведінку CPU)

AVX (Advanced Vector Extensions) — це сімейство SIMD-інструкцій: одна інструкція оперує кількома елементами даних одночасно. Якщо ви колись думали
«чому ця матрична множина така повільна», AVX — одна з відповідей. Замість однієї операції множення-додавання на інструкцію ви виконуєте 4, 8, 16 — залежно від
ширини вектора й типу даних — плюс купа хитрих конвеєрних і злитих операцій.

AVX — це не одна річ. Це еволюція:

• AVX (256-біт): додає регістри YMM і 256-бітні вектори.
• AVX2: розширює підтримку цілих чисел, додає операцію gather і робить векторизацію цілих чисел більш корисною.
• FMA (часто у парі з AVX/AVX2): злитий множник-додавальник; велика вигода для густої лінійної алгебри та багатьох DSP-подібних навантажень.
• AVX-512 (512-біт): подвоює ширину, додає маски та великий набір інструкцій. Також додає великий операційний головний біль.

Операційна суть: AVX може змінити споживання потужності CPU настільки значно, що сучасні процесори регулюють частоту (а іноді й напругу), коли виконується AVX-код.
Ваш CPU робить компроміс: «я можу виконувати ширші вектори, але не можу тримати ті ж частоти, не порушивши обмежень по потужності/теплу».
Ось чому ви можете побачити, що навантаження «оптимізоване» AVX прискорюється в одному бенчмарку, але гальмує в системному тесті на затримки.

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

Жаргон, який почуєте на інцидентних розборах:

• AVX frequency offset: зниження максимальних турбо-ступенів, коли активні AVX (особливо AVX-512) інструкції.
• Рівні «ліцензії» AVX (деякі покоління Intel): окремі робочі точки для скалярного/SSE, AVX2, AVX-512.
• Тротлінг через тепло: падіння частот, бо CPU досягнув температурних меж, а не обов’язково через AVX-біни.
• Обмеження потужності (PL1/PL2 на багатьох Intel-системах): довготривалі і короткочасні ліміти потужності, що можуть обмежувати частоту.

Якщо ви ставитесь до AVX як до «безкоштовного прискорення», випадково зміните енергетичний профіль сервера. Це не метафора. Ваш рейк вам скаже.

Цікаві факти та контекст, який стане в пригоді на нарадах

Це не тривіальні відомості для самої цікавості. Це контекст, який завадить кімнаті приймати спрощені рішення на кшталт «включимо AVX-512 скрізь» або «відключимо AVX глобально через одну проблемну службу».

1. AVX з’явився в мейнстрім x86 близько 2011 року (ера Sandy Bridge), а AVX2 з’явився через кілька років. Це означає, що у вас може бути змішаний флот, де «нативна» підтримка різниться.
2. AVX-512 не є універсальним навіть серед сучасних Intel ліній. Він з’являвся у деяких серверних/робочих станціях, зникав у багатьох споживчих моделях і присутній селективно залежно від SKU та покоління.
3. AVX-512 може викликати більший спад частоти, ніж AVX2, на багатьох CPU. Чим ширші вектори — тим більша щільність струму й енергоспоживання.
4. «Швидше на інструкцію» все одно може програти, коли CPU знижується у частоті занадто сильно. Системна продуктивність — це пропускна здатність × частота × паралелізм × поведінка пам’яті; AVX змінює кілька цих множників.
5. AVX2 зробив векторизацію цілих чисел практичною для більшої кількості навантажень, тому ви побачите його в стисненні, хешуванні, парсингу JSON і пакетній обробці — не тільки у плаваючій арифметиці.
6. Автовекторизація компіляторів значно покращилась з часом. Ви можете використовувати AVX, не написавши жодного intrinsic, особливо з сучасними GCC/Clang і «-O3».
7. Деякі вендори постачають мультиверсійні бібліотеки (runtime dispatch), які вибирають SSE/AVX/AVX2/AVX-512 за CPUID. Це може змінити поведінку просто при переміщенні контейнера на інший тип вузла.
8. Мікрокод і оновлення BIOS можуть змінювати поведінку AVX (керування потужністю, пом’якшення, правила турбо). «Та сама модель CPU» не завжди означає «той же ефективний такт під AVX».

Вам не потрібно тримати все це в голові. Потрібно мати це в ранбуках і оцінці ризиків, коли хтось пропонує «просто вмикнути -march=native».

Чому AVX робить CPU гарячішими (і чому падають частоти)

Теплова історія проста: ширші вектори означають більше перемикань у виконавчих блоках і шляхах даних, а це більше потужності.
Потужність стає теплом. Тепло наближає ліміти. Ліміти змушують знижувати частоту.

Нюанс у тому, що AVX не просто «використовує більше CPU». Він може змінити де CPU витрачає енергію. Щільні векторні обчислення можуть інтенсивно завантажувати
певні функціональні блоки, викликаючи локальні гарячі точки. У CPU складна система управління потужністю, але фізика бере своє.

Зазвичай є три різні механізми, які можуть знижувати частоту під час «AVX-інцидентів», і їх треба розрізняти:

• AVX turbo offset / AVX bins: CPU навмисно знижує максимальну частоту, коли виявляє тривале використання AVX-інструкцій.
  Це може трапитися навіть коли температура «виглядає нормально», бо це рішення щодо цілісності живлення.
• Тротлінг через обмеження потужності: CPU досягає PL1/PL2 або еквівалентних пакетних лімітів потужності. Частота падає, оскільки платформа каже «більше ватів — ні».
• Тротлінг через тепло: температура досягає порога; частота падає, щоб не перевищити безпечні робочі межі.

Вони виглядають схоже в дашборді. Але виправлення для них різні.

У термінах SRE: це одна з тих проблем, де «завантаження CPU високе» — нічого не говорить. Потрібно знати:

• Чи CPU зайнятий скалярною роботою чи векторною?
• Чи обмежені ми частотою ядра, пропускною здатністю пам’яті чи потужністю?
• Чи це одинична поведінка по всіх вузлах, чи тільки на підмножині з різним мікрокодом/BIOS?

Ще одна операційна реальність: AVX downclock може впливати на інші потоки на тому ж ядрі, і залежно від CPU, може впливати на сусідні ядра
(спільні бюджети потужності/тепла). Це означає, що один «галасливий» AVX-важкий сервіс може потягнути вниз чутливі до затримки скалярні сервіси на тому ж хості.

Жарт №1 (коротко й заслужено): AVX — як еспресо: робить вас продуктивним, а потім ви дивуєтесь, чому тремтять руки й в кімнаті раптом надто тепло.

Хто виграє від AVX — і хто «обпікається»

Навантаження, що зазвичай виграють

• Густа лінійна алгебра: BLAS, GEMM, FFT, багато ML-інференсних ядер. Часто великі виграші, бо інтенсивність арифметики висока.
• Відео/обробка зображень: згортки, перетворення, конвертація кольору, фільтрація.
• Стиснення/розпакування: певні кодеки і швидкі шляхи (залежить від бібліотеки й даних) можуть отримати значний приріст.
• Криптографія та хешування: не завжди AVX (AES-NI окремо), але векторизовані реалізації допомагають при масових операціях.
• Пакетна та лог-обробка: парсинг і сканування можуть виграти, особливо з AVX2 для цілочисельних операцій.

Навантаження, що можуть програти (або поводитися дивно)

• Послуги, чутливі до затримки, які ділять вузли: AVX-важкі сусіди можуть знизити ефективну частоту для всіх.
• Навантаження, залежні від пам’яті: якщо ви вже обмежені пропускною здатністю пам’яті або кеш-промахами, AVX може не дати виграшу (ви швидше дістанете дані, а потім гальмуватимете).
• Змішані скалярні/векторні сплески: «хвіст» падіння частоти після векторного коду може покарати скалярну фазу.
• Будь-що скомпільоване з надто агресивною ціллю: «-march=native» на збірочній машині з AVX-512 може створити бінар, що поводитиметься інакше (або взагалі не запуститься) на інших вузлах.

Правило прийняття рішення, яке реально можна застосувати

Використовуйте AVX, коли це дає вам реальні системні виграші: пропускну здатність при тій же SLO або покращення затримки без порушення потужності й сумісності.
Уникайте AVX, коли він створює перехресне втручання між сервісами й ви не можете ізолювати його (виділені вузли, прив’язка CPU або окремі пулі).

Якщо навантаження — «одна велика пакетна задача на виділеному металі», AVX часто — подарунок.
Якщо це «десять мікросервісів і база даних на одному хості», AVX — соціальна проблема.

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

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

Перше: підтвердьте поведінку частоти і чи це специфічно для вузла

• Перевіряйте частоту по ядру, а не лише CPU%. Якщо під навантаженням частота обмежена знизу, ви в зоні потужності/тепла.
• Порівняйте «погані» вузли з «хорошими» в тому ж пулі. Якщо постраждали лише деякі, підозрюйте BIOS/мікрокод, охолодження або різні SKU CPU.

Друге: розрізніть AVX offset, обмеження потужності та термальне тротлінг

• Подивіться на температуру й пакетну потужність. Якщо температура в нормі, але частота низька — підозрюйте AVX-біни або обмеження потужності.
• Перевірте явні індикатори тротлінгу (де доступно) і скорелюйте падіння частоти з AVX-важкими процесами.

Третє: ідентифікуйте споживача AVX

• Використайте perf для семплінгу гарячих точок і міксу інструкцій.
• Перевірте останні деплої та оновлення бібліотек; runtime dispatch може «увімкнути» AVX на новому обладнанні без змін у коді.
• Якщо в контейнерах — зіставте використання CPU контейнера з PID-ами хоста; AVX-важкі гарячі цикли покажуться передбачуваними стеками.

Четверте: вирішіть ізоляцію перед оптимізацією

• Якщо ви порушуєте SLO по затримці через спільне проживання, ізолюйте: виділений пул вузлів, прив’язка CPU або обмеження cgroup.
• Якщо це пакетна задача і вона швидша загалом — прийміть тепло, але слідкуйте за потужністю й обмеженнями стійкості стійок.
• Якщо це справді регресія — вимкніть AVX-шлях (параметри бібліотеки, маскування можливостей CPU) і відновіть сервіс спочатку.

Практичні завдання: команди, виводи та рішення

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

Завдання 1: Підтвердіть, які AVX-фічі CPU видає

cr0x@server:~$ lscpu | egrep 'Model name|Flags|Vendor ID'
Vendor ID:             GenuineIntel
Model name:            Intel(R) Xeon(R) Gold 6230 CPU @ 2.10GHz
Flags:                 fpu vme de pse tsc ... sse4_2 avx avx2 fma ... avx512f avx512dq avx512cd avx512bw avx512vl

Значення: Рядок Flags показує, які набори інструкцій доступні. Наявність avx/avx2/avx512* вказує на потенційні шляхи виконання.

Рішення: Якщо флот змішаний, потрібен runtime dispatch або окремі збірки. Якщо AVX-512 присутній лише на частині флоту — очікуйте різниць у поведінці.

Завдання 2: Перевірте повідомлення ядра на підказки про тротлінг CPU

cr0x@server:~$ dmesg -T | egrep -i 'throttl|thermal|powercap|pstate' | tail -n 8
[Mon Jan  8 10:31:12 2026] intel_pstate: Intel P-state driver initializing
[Mon Jan  8 11:02:44 2026] CPU0: Core temperature above threshold, cpu clock throttled
[Mon Jan  8 11:02:45 2026] CPU0: Core temperature/speed normal

Значення: Є ознаки термального тротлінгу (не лише AVX-біни). Це проблема охолодження й потужності.

Рішення: Припиніть шукати прапорці компіляції насамперед. Перевірте потік повітря, радіатори, криву вентиляторів, температуру навколишнього середовища та розміщення навантаження.

Завдання 3: Спостерігайте в реальному часі частоту по ядру під навантаженням

cr0x@server:~$ sudo turbostat --Summary --interval 2
     Summary:     PkgTmp  PkgWatt  Avg_MHz  Busy%  Bzy_MHz
     2.000 sec     86      185      2195    92.1    2382
     2.000 sec     90      198      2010    94.3    2132

Значення: Температура пакета й ватаж високі; середнє MHz падає, поки Busy% залишається високим — це вказує на обмеження потужності/тепла.

Рішення: Якщо це корелює з вікном підозрілої служби, розглядайте це як питання операційної ємності, а не лише «завантаження CPU».

Завдання 4: Підтвердіть поточний governor та драйвер CPU

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
intel_pstate

Значення: Ви на драйвері Intel P-state, який взаємодіє з турбо, лімітами потужності й політиками платформи.

Рішення: Якщо ви налагоджуєте неконсистентну частоту, зафіксуйте конфігурацію P-state і налаштування BIOS; не приймайте «performance governor вирішить це» як аксіому.

Завдання 5: Подивіться, що ядро вважає доступною частотою (min/max)

cr0x@server:~$ sudo cpupower frequency-info | sed -n '1,12p'
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  hardware limits: 800 MHz - 3900 MHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 800 MHz and 3900 MHz.
                  The governor "powersave" may decide which speed to use
  current CPU frequency: 2200 MHz

Значення: Аппаратні ліміти можуть показувати 3.9 GHz, але AVX-біни все ще можуть зменшувати ефективний турбо під векторним навантаженням.

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

Завдання 6: Швидке сканування температур і сенсорів (виявити аутлайєр охолодження)

cr0x@server:~$ sudo sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +92.0°C  (high = +95.0°C, crit = +105.0°C)
Core 0:        +90.0°C  (high = +95.0°C, crit = +105.0°C)
Core 1:        +89.0°C  (high = +95.0°C, crit = +105.0°C)

Значення: Ви на підході до верхнього порога. Навіть якщо AVX-біни існують, ви в зоні ризику, де може спрацювати термальне тротлінгу.

Рішення: Якщо лише деякі вузли показують це — виведіть їх з пула і перевірте апарат. Якщо всі вузли — це питання ємності/розміщення і навколишніх умов.

Завдання 7: Ідентифікуйте топ-споживачів CPU і чи це один процес

cr0x@server:~$ ps -eo pid,comm,pcpu,psr --sort=-pcpu | head
  PID COMMAND         %CPU PSR
23144 inference-svc   780.3  12
23161 inference-svc   772.9  13
 1187 node-exporter     2.1   0

Значення: Одна служба насичує багато ядер (зверніть увагу на %CPU > 100). Колонка PSR показує, на якому ядрі знаходиться потік.

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

Завдання 8: Зіставте контейнерне навантаження з процесами хоста (systemd + cgroups)

cr0x@server:~$ systemd-cgls --no-pager | sed -n '1,18p'
Control group /:
-.slice
├─kubepods.slice
│ ├─kubepods-besteffort.slice
│ │ └─kubepods-besteffort-pod7d1b...slice
│ │   └─cri-containerd-2a0c...scope
│ │     └─23144 inference-svc
└─system.slice
  └─node-exporter.service

Значення: Гарячий PID належить конкретному поду/контейнеру. Тепер можна пов’язати поведінку вузла з певним деплоєм.

Рішення: Якщо один под викликає AVX downclock на спільних вузлах — прив’яжіть його до виділеного пулу або встановіть cpuset.

Завдання 9: Використайте perf, щоб побачити, куди йде CPU-час (гарячі функції)

cr0x@server:~$ sudo perf top -p 23144 -n 5
Samples:  2K of event 'cycles', 4000 Hz, Event count (approx.): 512345678
Overhead  Shared Object        Symbol
  38.12%  libmkl_rt.so         mkl_blas_avx512_sgemm_kernel
  21.44%  libc.so.6            __memmove_avx_unaligned_erms
  10.03%  inference-svc        compute_layer

Значення: Ви в AVX-512 BLAS-ядрі і AVX-оптимізованому memmove. Це не «таємний CPU» — це векторизований код, що робить те, для чого його збудували.

Рішення: Якщо це очікувано (ML-інференс), переконайтесь, що розмір пулу вузлів і охолодження під це розраховані. Якщо неочікувано — дослідіть, чому MKL вибрав AVX-512 і чи потрібно його обмежити.

Завдання 10: Порахуйте векторні інструкції проти інших за допомогою perf stat (високий сигнал, малий церемоніал)

cr0x@server:~$ sudo perf stat -p 23144 -e cycles,instructions,fp_arith_inst_retired.256b_packed_single,fp_arith_inst_retired.512b_packed_single -- sleep 5
 Performance counter stats for process id '23144':

     12,345,678,901      cycles
      6,789,012,345      instructions
         234,567,890      fp_arith_inst_retired.256b_packed_single
         345,678,901      fp_arith_inst_retired.512b_packed_single

       5.001234567 seconds time elapsed

Значення: У вас є значний об’єм 256b і 512b FP-векторної арифметики. Це сильна ознака, що у гарячому шляху справді виконується AVX/AVX-512.

Рішення: Якщо служба не повинна потребувати AVX-512, розгляньте відключення цього шляху (налаштування бібліотеки, змінні середовища) або перекомпіляцію з іншою ціллю.

Завдання 11: Проскануйте бінарник на наявність AVX/AVX2/AVX-512 інструкцій

cr0x@server:~$ objdump -d /usr/local/bin/inference-svc | egrep -m 8 '\b(vaddps|vmulps|vfmadd|zmm|ymm)\b'
  000000000042f190: vfmadd231ps %zmm2,%zmm1,%zmm0
  000000000042f196: vaddps      %zmm4,%zmm0,%zmm0
  000000000042f19c: vmulps      %zmm3,%zmm0,%zmm1

Значення: Побачити регістри zmm означає AVX-512. Побачити ymm — AVX/AVX2. Це не доводить, що шлях гарячий, але доводить, що бінар містить такі шляхи.

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

Завдання 12: Перевірте, яку ціль насправді вказав компілятор (метадані збірки)

cr0x@server:~$ readelf -p .comment /usr/local/bin/inference-svc | head
String dump of section '.comment':
  [     0]  GCC: (Ubuntu 13.2.0-4ubuntu3) 13.2.0
  [    2d]  -O3 -march=native -mtune=native

Значення: -march=native прив’язує збірку до того, що підтримує машина збірки. Якщо ваш CI runner має AVX-512, ви могли тихо створити бінар з AVX-512 як пріоритетом.

Рішення: Припиніть робити так у загальних флотах. Використовуйте консервативну базову ціль з runtime dispatch або збірку окремих артефактів для кожного класу вузлів.

Завдання 13: Підтвердіть ідентичність мікрокоду/BIOS між вузлами

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'microcode|bios' | tail -n 6
Jan 08 09:12:02 server kernel: microcode: updated early from revision 0x5002c2a to 0x5002c36, date = 2023-10-12
Jan 08 09:12:02 server kernel: DMI: VendorX ModelY/BoardZ, BIOS 2.7.1 08/14/2024

Значення: Ревізія мікрокоду і версія BIOS — частина профілю продуктивності. Якщо лише деякі вузли мають іншу ревізію, поведінка AVX може відрізнятись.

Рішення: Нормалізуйте прошивку в межах пулу перед тим, як оголосити «регресію у софті». Інакше ви налагоджуєте дві рухомі цілі одночасно.

Завдання 14: Перевірте поточні ліміти потужності (Intel RAPL)

cr0x@server:~$ sudo powercap-info -p intel-rapl
Zone: package-0
  enabled: 1
  power limit 1: 165.00 W (enabled, clamp disabled)
  power limit 2: 215.00 W (enabled, clamp disabled)
  energy counter: 123456.789 Joules

Значення: Пакетні ліміти потужності можуть змусити частоту впасти навіть без термального тротлінгу. AVX-важкий код може швидко упертись у ці ліміти.

Рішення: Якщо ви не можете підняти ліміти потужності (зазвичай не можна, з вагомих причин), доведеться керувати розміщенням AVX-навантжень і очікуваннями.

Завдання 15: Виявлення апаратних лічильників, що вказують на тротлінг (деталь turbostat)

cr0x@server:~$ sudo turbostat --interval 2 --quiet --show PkgTmp,PkgWatt,Busy%,Bzy_MHz,IRQ,POLL,CoreTmp
  PkgTmp PkgWatt Busy% Bzy_MHz  IRQ  POLL CoreTmp
     88     195  95.2    2105  820   112     90
     91     201  96.0    1998  845   118     93

Значення: MHz ковзає вниз при стабільному Busy% і температурі поблизу порогів — це узгоджується з тротлінгом. (Точні прапори тротлінгу залежать від CPU; це швидка евристика.)

Рішення: Вважайте це «обмеженням платформи», поки не доведено протилежне. Оптимізуйте код пізніше; спочатку стабілізуйте платформу (охолодження, потужність, ізоляція).

Завдання 16: Порівняйте запуск без AVX і з AVX на тому ж хості (A/B перевірка)

cr0x@server:~$ taskset -c 4 /usr/local/bin/microbench --mode scalar --seconds 5
mode=scalar seconds=5 ops=1200000000 avg_ns=4.1 p99_ns=6.3

cr0x@server:~$ taskset -c 4 /usr/local/bin/microbench --mode avx2 --seconds 5
mode=avx2 seconds=5 ops=1850000000 avg_ns=2.7 p99_ns=4.9

Значення: AVX2-шлях швидший в ізоляції. Це хороша новина, але не вирок для проду.

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

Три корпоративні історії з AVX-окопів

1) Інцидент через хибне припущення: «CPU% — це CPU%»

Середня компанія запускала API платежів і окрему службу оцінки шахрайства в тому самому пулі вузлів. Команда оцінки шахрайства випустила оновлення моделі.
Це був «лише підвищення бібліотеки» в рантаймі інференсу. Зміна виглядала безпечною: ті самі CPU-запити, та сама пам’ять, ті самі кінцеві точки.

За годину p99 латентності платежів підскочив. Завантаження CPU не виглядало тривожно — трималося у звичному діапазоні. Інцидентний керівник
підозрював мережу, бо графіки «не показували тиску на CPU».

SRE подивився частоту по ядру і пакетну температуру. Хости знижували частоту під навантаженням. Служба шахрайства тепер використовувала AVX-512 ядра
через зміну runtime dispatch, що збільшило споживання потужності. Графіки CPU% залишались оманливо стабільними, бо ядра залишалися «зайнятими», хоча робили менше роботи в секунду.

Виправлення не було героїчним: вони перемістили оцінку шахрайства в виділений пул з більшим тепловим запасом і встановили явні налаштування бібліотеки, щоб уникнути AVX-512
на спільних вузлах. Латентність платежів повернулася до норми, і всі зрозуміли, що CPU% без частоти — це як спідометр, що показує лише натиск на педаль.

2) Оптимізація, що зіграла злий жарт: «-march=native — безкоштовна продуктивність»

Команда платформи даних володіла сервісом стиснення логів з високою пропускною здатністю. Вони економили і мали культуру вичавлювати CPU-цикли.
Розробник зробив логічну річ у лабораторії: перекомпілював сервіс з -O3 -march=native і побачив значний приріст пропускної здатності.

CI-раннери випадково були новішими машинами з AVX-512. Отриманий бінар працював на деяких прод-вузлах (також нових) й падав на старіших з «illegal instruction». Цю проблему спіймали швидко.

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

Вони в кінці кінців випустили два артефакти: консервативну збірку для загальних вузлів і AVX2-оптимізовану збірку для виділеного пулу стиснення.
AVX-512 залишили поза столом для цього сервісу, бо він не окупився після урахування частоти й обмежень потужності.

3) Нудна, але правильна практика, що врятувала день: «класи апаратури — це контракти»

Інша компанія запускала змішані навантаження на Kubernetes. У них була звичка, що здавалася бюрократичною: кожен пул вузлів мав задекларований «клас апаратури»
з зафіксованою версією BIOS, базовим мікрокодом і невеликим документом про профіль продуктивності. Інженери скаржилися, поки не настав день, коли це стало в пригоді.

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

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

Джоб вийшов вчасно, ніхто не вигадував героїчних рішень вночі, і єдиною жертвою стало трохи его. Ось чому нудні практики заслуговують на повагу:
вони не дають заплутаним проблемам перетворитись на містичні.

Типові помилки (симптом → корінна причина → виправлення)

1) Симптом: CPU% стабільний, але пропускна здатність впала після «оптимізованого» релізу

Корінна причина: AVX запускає зниження частоти; ядра залишаються зайнятими, але виконують менше циклів за секунду.

Виправлення: Додайте до дашбордів частоту по вузлу і пакетну потужність; підтвердіть AVX vs non-AVX під змішаним навантаженням; ізолюйте AVX-важкі сервіси.

2) Симптом: Лише деякі вузли показують сплески латентності після оновлення бібліотеки

Корінна причина: Runtime dispatch вибирає AVX2/AVX-512 на вузлах, що це підтримують; змішана поведінка флоту.

Виправлення: Стандартизуйте пули вузлів; фіксуйте поведінку інструкційних наборів бібліотек де можливо; збирайте мультиверсійні бінарі з контрольованим диспачем.

3) Симптом: «Illegal instruction» аварії після деплою

Корінна причина: Зібрано для новішого ISA (AVX2/AVX-512), ніж деякі продакшен-CPU підтримують, часто через -march=native.

Виправлення: Збирайте проти консервативної цілі (наприклад, x86-64-v2/v3 де доречно) і використовуйте runtime dispatch; впровадьте правила прийому по міткам вузлів.

4) Симптом: Вентилятори розкручуються і температури досягають високих порогів під час пакетної задачі

Корінна причина: Тривале AVX-важке виконання підвищує пакетну потужність; охолодження маргінальне або потік повітря обмежений.

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

5) Симптом: Скалярні сервіси сповільнюються, коли запускається один «обчислювальний» контейнер

Корінна причина: AVX downclock і спільні бюджети потужності/тепла знижують частоту для інших ядер/потоків.

Виправлення: Жорстка ізоляція: виділений пул вузлів, CPU sets (cpuset.cpus) або окремі хости. М’яка ізоляція через квоти часто недостатня.

6) Симптом: Бенчмарк показує великий прогрес, продакшен — ні

Корінна причина: Бенчмарк обчислювально-обмежений; продакшен — обмежений пам’яттю або конкуренцією. AVX прискорює обчислення, але не вирішує затримки пам’яті.

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

7) Симптом: Продуктивність змінилася після оновлення BIOS/мікрокоду

Корінна причина: Оновлення змінило управління потужністю, політику турбо, пом’якшення або поведінку на рівні мікрокоду під AVX-навантаженням.

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

Контрольні списки / поетапний план

Покроково: безпечне впровадження AVX у продакшен-сервіс

1. Класифікуйте навантаження: обмежене обчисленнями vs обмежене пам’яттю; чутливе до затримки vs пакетне; очікування щодо співіснування.
2. Проведіть інвентаризацію ISA флоту: точно знайте, де є AVX2 і AVX-512; маркуйте пули вузлів відповідно.
3. Виберіть базову ціль збірки: уникайте -march=native у CI; використовуйте консервативну ціль і явний мультиверсійний підхід за потреби.
4. Додайте операційні метрики: частота по ядру, пакетна температура, пакетна потужність; корелюйте їх із затримкою запитів.
5. Канарте з змішаним навантаженням: не покладайтесь лише на мікробенчмарки. Запускайте канари на вузлах з типовими сусідами.
6. Визначте політику ізоляції: виділений пул для AVX-важких сервісів або сувора прив’язка CPU і правила розміщення.
7. Встановіть явні налаштування бібліотек: якщо бібліотека може обрати AVX-512 у рантаймі, робіть цей вибір явним для кожного середовища.
8. Плануйте ємність за ватами, а не за відчуттями: перевірте тривалу пакетну потужність під піком; забезпечте, щоб бюджет стійки і охолодження це витримали.
9. Проводьте вправи аварійних режимів: симулюйте тротлінг (стрес-інструменти або контрольоване навантаження) і перевірте оповіщення та авто-скейлінг.
10. Документуйте клас апаратури: мікрокод, BIOS, ліміти потужності та «очікувана» поведінка AVX у ранбуку пулу.

Контрольний список: перед тим як звинувачувати AVX у регресії

• Чи стало навантаження більш обмеженим пам’яттю (збільшилися кеш-промахи, зросла пропускна здатність)?
• Чи змінився пул вузлів (інший CPU SKU, налаштування BIOS, мікрокод)?
• Чи падає частота, і чи це корелює з підозрілим процесом?
• Чи регресія тільки в p99 (втручання через співіснування) або також в p50 (чисте обчислення)?
• Чи змінився шлях диспачу бібліотеки (BLAS, memcpy/memmove, кодеки)?

Жарт №2: Якщо ви не можете пояснити свій графік частоти CPU, вітаємо — ви відкрили нову релігію. Будь ласка, не деплойте її.

Операційні поради: контроль AVX без перетворення флоту на науковий проєкт

Віддавайте перевагу runtime dispatch з явною політикою

Мультиверсійний код — стандартна практика: постачати SSE/AVX2/AVX-512 варіанти і вибирати їх у рантаймі за CPUID. Це хороша інженерія.
Погана інженерія — дозволяти вибір бути випадковим.

Якщо AVX-512 — виграш лише на виділених вузлах, забезпечте це:

• Використовуйте мітки вузлів і обмеження планувальника, щоб лише певні робочі навантаження потрапляли на AVX-512-підтримувані хости.
• Налаштуйте бібліотеки так, щоб обмежити набори інструкцій на спільних вузлах (багато математичних бібліотек надають змінні середовища або прапорці конфігурації).
• Тримайте окремі пули вузлів для «гарячих обчислень» і «змішаних з латентністю». Так, це більше пулів. Ні, ваш p99 не переймається естетикою ваших переваг.

Міряйте з урахуванням потужності і частоти

Ядро може бути 100% зайняте на 2.0 GHz або 100% зайняте на 3.5 GHz. Це різні всесвіти. Якщо ваш моніторинг зводить їх до однієї лінії з назвою «CPU»,
ви неправильно діагностуєте проблеми і випускаєте невірні виправлення.

Тримайте AVX-навантження поза спільними хостами, коли p99 важливий

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

Цитата, яку варто приклеїти на монітор

переказана ідея: «Надія — це не стратегія.» — часто приписується лідерам з надійності/операцій в інженерній культурі.

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

FAQ

1) Чи AVX завжди швидший за SSE або скалярний код?

Ні. AVX може бути швидшим для обчислювально-обмежених циклів з доброю локальністю даних. Але зниження частоти, пам’ятні затримки і конкуренція можуть знищити виграш або викликати регресії.
Завжди вимірюйте на рівні системи.

2) Чому AVX знижує частоту на деяких CPU?

Тому що інтенсивне AVX-виконання значно підвищує потужність і щільність струму. CPU забезпечують обмеження потужності/тепла, знижуючи максимальні турбо-ступені
(AVX offset) і/або через досягнення платформи лімітів потужності.

3) Чи AVX-512 «поганий»?

Він не поганий; він специфічний. AVX-512 може бути відмінним для певних ядер і жахливим для спільного проживання. Ставтесь до нього як до спеціального інструмента:
виділяйте вузли або явно контролюйте, коли його використовувати.

4) Як дізнатися, чи мій сервіс використовує AVX у продакшені?

Використайте perf top для знаходження гарячих точок (символи часто містять «avx2»/«avx512»), і perf stat лічильники там, де доступні, щоб порахувати векторні інструкції.
Також можна дизасемблювати гарячі бінарі і шукати ymm/zmm інструкції, але це слабший доказ, якщо не корелювати з профілями.

5) Чому лише деякі вузли нагрілись після того самого деплою?

Змішана апаратна підтримка і runtime dispatch — часті причини. Інша — прошивка: різні налаштування BIOS або ревізії мікрокоду змінюють ліміти потужності і поведінку турбо.
Не приймайте однорідність, доки її не забезпечите.

6) Чи можна просто відключити AVX у BIOS або ОС?

Іноді можна замаскувати фічі або відключити певні набори інструкцій залежно від платформи. Це грубий інструмент і може зламати навантаження, які розраховують на AVX.
Віддавайте перевагу контролю на рівні сервісів (налаштування бібліотек, окремі збірки, правила розміщення), якщо немає сильної причини заборонити AVX на всьому флоті.

7) Чи AVX важливий для систем зберігання?

Опосередковано — так. Стиснення, контрольні суми, шифрування і обробка пакетів можуть використовувати векторизовані шляхи. Якщо ці шляхи викликають downclock,
ви можете побачити такі ефекти як нижча пропускна здатність на ядро або втручання в інші сервіси на спільних вузлах.

8) Чому мій p99 погіршився, хоча p50 покращився?

Класична проблема співіснування і конкуренції. AVX-важкі сплески можуть знизити частоти і вплинути на сусідів, посилюючи хвостову латентність для не пов’язаних потоків.
Ізолюйте AVX-навантження або запускайте його на виділеному обладнанні.

9) Чи варто стандартизуватися на AVX2 і уникати AVX-512?

Часто це прагматичний вибір. AVX2 дає сильні виграші з менш серйозними штрафами частоти. AVX-512 може бути виправданий для виділених пулів обчислень,
але ви повинні заслужити його вимірюваннями під реалістичним навантаженням.

10) Яка безпечніша стандартна стратегія збірки для змішаних флотів?

Компіліть під консервативну базову ціль, сумісну зі всіма цільовими вузлами, і використовуйте runtime dispatch (або окремі артефакти) для AVX2/AVX-512.
Уникайте -march=native у загальному CI, якщо апарат CI не точно відповідає продакшен-пулу, на який ви орієнтуєтесь.

Висновок: що робити далі у вашому середовищі

AVX — це не просто «швидша математика». Це поведінка потужності. Воно змінює частоти, теплові показники і іноді долю інших сервісів на тому ж хості.
Якщо ви оперуєте продакшен-системами, ставтесь до цього як до будь-якої іншої можливості, що впливає на продуктивність: спостережуваної, контрольованої і протестованої у реалістичних умовах.

Практичні кроки, які можна виконати цього тижня:

1. Додайте по-вузлові метрики частоти та пакетної температури/потужності до стандартних дашбордів для обчислювальних пулів.
2. Промаркуйте пули вузлів за ISA-можливостями (AVX2, AVX-512) і зафіксуйте бази прошивок для кожного пулу.
3. Аудитуйте збірки на предмет -march=native і приберіть його з загальних артефактів; замініть явними цілями і контрольованим диспачем.
4. Виберіть один «відомо AVX-важкий» сервіс і проведіть канар з співіснуванням: виміряйте його вплив на затримко-чутливого сусіда.
5. Напишіть короткий ранбук: «Як підтвердити AVX downclock vs термальний тротлінг», включно з точними командами, які ви виконуватимете.

Вам не потрібно боятися AVX. Потрібно припинити дивуватись ним. У продакшені здивування — найдорожчий рядок у бюджеті.