486: чому вбудований FPU змінив усе (і про це ніхто не говорить)

Що насправді змінилося з FPU у 486

До 486DX плаваюча кома на ПК часто була опціональною. Ви купували 386, і якщо виконували серйозні чисельні задачі — додавали 387 копроцесор. Багато систем його не мали. Чимало програм обходилися без плаваючої коми або використовували фіксований дріб, бо потрібно було адекватно працювати на машинах без FPU.

Потім з’явився 486DX з інтегрованим x87 FPU прямо в кристалі ЦП. Не «на материнській платі». Не «можливо встановлено». Саме в кристалі. Здається, це історія лише про швидкість. Ні. Це історія про залежність.

Інтеграція була не тільки швидшою — вона стала передбачуванішою

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

486SX ускладнює картину: він постачався без робочого FPU (вимкнений або відсутній залежно від stepping/маркетингу). Це створило поділений ринок, де «486» не означав «FPU гарантовано». Але напрямок було задано: мейнстрімний roadmap ЦП став вважати плаваючу кому першокласною.

Плаваюча кома перейшла з «функції фахівця» в «інструмент за замовчуванням»

Як тільки FPU став поширеним, код змінився:

• Компілятори стали агресивніше використовувати інструкції з плаваючою комою.
• Бібліотеки переходили на реалізації з плаваючою комою замість цілих реалізацій.
• Розробники перестали тестувати шлях «без FPU», бо ніхто не хотів за нього відповідати.
• Бенчмарки та закупівлі почали використовувати набори з важким FP, а не лише цілочисельну пропускну здатність.

Результат — тихий, але стійкий зсув: очікування продуктивності, чисельна поведінка та навіть проєктні рішення почали припускати апаратну плаваючу кому. Це припущення й досі просочується у системи, навіть коли ми вдаємо, що зараз «це просто мікросервіси».

Одна цитата стала оперативним маніфестом — часто приписується Hyrum Wright з доповіді «Hyrum’s Law» — ось вона (парафраз): «За достатньої кількості користувачів всі спостережувані поведінки вашої системи будуть на них покладені.» FPU у 486 зробив поведінку плаваючої коми широко спостережуваною. Отже — понадіяною.

Жарт №1: Вбудований FPU у 486 не просто прискорив математику — він прискорив суперечки про те, чиї «дрібні похибки округлення» зламали продакшн.

Чому це має хвилювати ops і reliability-людей

Якщо ви керуєте продакшн-системами, вас турбують дві речі, які плаваюча кома любить порушувати:

1. Латентність і пропускна здатність під реальним навантаженням (особливо хвостова латентність).
2. Детермінізм (відтворюваність між хостами, збірками і часом).

Інтегрований FPU у 486 полегшив переход на FP-орієнтоване ПЗ. Це покращило середню продуктивність для відповідних навантажень. Але це також:

• Зробило «ущелини продуктивності» гострішими, коли ви падаєте з шляху «є FPU» (486SX, неправильна конфігурація емуляції, налаштування VM, трапи тощо).
• Збільшило випадки чисельних розбіжностей між платформами, бо плаваюча кома почала використовуватися ширше.
• Нормалізувало модель x87 у ПО для ПК: розширена точність всередині, «округлення при вигрузці», і купа крайових випадків, що проявляються як «heisenbug’и».

З перспективи SRE головний операційний урок: «апаратна здатність» — це не булева змінна. Це контракт поведінки, який змінює продуктивність, коректність і множину режимів відмов, що ви побачите. Коли плаваюча кома стає загальною, ви починаєте відлагоджувати числення як інфраструктуру.

Цікаві факти і контекст для аргументів

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

1. 486DX інтегрував x87 FPU в кристал, тоді як раніше 386-системи часто покладалися на опціональний 387 копроцесор.
2. 486SX постачався без працездатного FPU, створивши заплутану розбіжність сумісності, де «клас 486» не обов’язково означав «швидка плаваюча кома».
3. x87 використовує 80-бітну розширену точність всередині (в регістрах), що може змінювати результати залежно від того, коли значення зберігаються в пам’ять і округлюються.
4. Ранні ПК-програми часто уникали плаваючої коми, бо встановлена база не мала копроцесорів; інтеграція змінила економічну доцільність.
5. Бенчмарки вплинули на закупівлі: коли FP став «стандартом», показники з плаваючою комою стали важливіші й для нефахових покупців (CAD, DTP, фінанси).
6. Операційні системи мали краще зберігати стан FPU під час перемикань контексту; з ростом використання FP стратегії lazy-FPU і трапи стали видимою змінною продуктивності.
7. Чисельно-важкі додатки, як CAD та EDA, стали життєздатними на настільних ПК частково тому, що плаваюча кома більше не була предметом розкоші.
8. 486 був кроком до сучасної тенденції «все в кристалі» — спочатку FP, потім кеші, контролери пам’яті, GPU й акселератори з часом.

Це не дрібниці. Вони пояснюють, чому деякі «очевидно нешкідливі» зміни — прапори компілятора, моделі CPU у VM, оновлення бібліотек — можуть вдарити вас роками потому.

Навантаження, які тихо змінив 486 FPU

Електронні таблиці та фінанси: не просто швидше, а інакше

Таблиці — це проблема надійності у маскараді офісного ПЗ. Коли апаратна FP стала звичайною, рушії таблиць і фінансові інструменти поклалися на неї. Це покращило відгук і дозволило більші моделі, але також зробило «та сама таблиця, інша відповідь» більш імовірною між апаратами/ОС/компіляторами.

CAD/CAE і графічні конвеєри

CAD-навантаження тяжкі по FP і чутливі до пропускної здатності та чисельної стабільності. З вбудованим FP десктоп став реалістичною робочою станцією для більше команд. Прихована вартість: більше кодових шляхів, що залежать від тонких особливостей IEEE 754 і x87, і додатковий тиск на «оптимізацію» з припущеннями про точність.

Бази даних і аналітичні рушії

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

Стиснення, обробка сигналів і «хитрі» алгоритми

Як тільки FP стає швидким, розробники намагаються використовувати його скрізь: нормалізація, евристики, апроксимації, ймовірностні структури даних. Зсув епохи 486 допоміг нормалізувати такий підхід. Урок для ops — ставитися до чисельного коду як до залежності: версіонуйте, тестуйте під навантаженням і фіксуйте, коли він частина історії надійності.

Режими відмов: швидкість, детермінізм і «чисельне дрейфування»

1) Кліфф продуктивності: емуляція, трапи і «чому це в 10 разів повільніше?»

Коли інструкції FP виконуються апаратно — ви отримуєте відносно стабільну продуктивність. Коли вони не виконуються — бо ви на CPU без FPU, всередині емулятора, у певних конфігураціях VM або потрапляєте на шлях трапу — ви падаєте зі скелі.

Цей кліфф оперативно підступний, бо на перший погляд виглядає як звичайна інцидентна перевантаженість CPU. На дашбордах видно великий user time, не I/O wait. Все «працює». Просто повільно. І так буде, поки ви не знайдете конкретний інструкційний шлях, що змінився.

2) «Той самий код, інша відповідь»: розширена точність і вигрузка регістрів

x87 тримає значення в 80-бітних регістрах. Це означає, що проміжні обчислення можуть мати більшу точність, ніж 64-бітний double, який ви вивантажите в пам’ять. Якщо компілятор тримає значення в регістрі довше в одній збірці, ніж в іншій, результати можуть відрізнятися. Іноді це останній біт. Іноді це змінює гілку й шлях алгоритму.

У продакшні це проявляється як:

• Невідтворювані помилки тестів, що корелюють з «debug vs release» або «один хост проти іншого».
• Контрольні суми, що дрейфують у конвеєрах, які мали бути детермінованими.
• Системи консенсусу або розподілені обчислення, що не погоджуються на кордонах.

3) «Оптимізації», що руйнують стабільність

Оптимізації плаваючої коми можуть змінювати порядок операцій. Оскільки додавання й множення у фінітній точності не асоціативні, зміна порядку змінює результати. Сучасні компілятори можуть робити це під прапорами на кшталт -ffast-math. Бібліотеки можуть робити це через векторизацію або злиті операції.

Операційна позиція така: якщо коректність важлива, не дозволяйте «fast math» у проді випадково. Зробіть це свідомим, протестованим рішенням. Ставте це на рівень вимкнення fsync: можна, але ви відповідаєте за радіус ураження.

Жарт №2: Плаваюча кома — єдине місце, де 0.1 — це брехня, і всі просто кивають головами.

План швидкої діагностики

Це «вхід у war room» порядок дій, коли ви підозрюєте, що поведінка плаваючої коми (або відсутність апаратного FP) спричиняє регресію, проблему коректності або дивну недетермінованість.

По-перше: підтвердьте, що ЦП і ядро думають, що мають

• Перевірте модель CPU і прапори (шукайте підтримку FPU).
• Перевірте віртуалізацію: чи виставлені очікувані фічі CPU гостьовій ОС?
• Перевірте, чи ви в режимі сумісності CPU (поширено при старих налаштуваннях гіпервізорів).

По-друге: ідентифікуйте, чи навантаження зараз FP-важке

• Профілюйте на високому рівні (perf top, top/htop).
• Шукайте гарячі точки FP-інструкцій (libm, чисельні ядра, векторизовані цикли).
• Перевірте, чи процес не потрапляє на трапи або не проводить час у несподіваних шляхах ядра.

По-третє: підтвердьте детермінізм та припущення щодо точності

• Порівняйте виходи на різних хостах для відомого фіксованого набору вхідних даних.
• Перевірте прапори компілятора й середовище виконання (fast-math, FMA, x87 vs SSE2 codegen).
• За можливості змусьте сталість FP-поведінки (образ контейнера, узгоджені CPU flags, закріплені бібліотеки).

По-четверте: вирішіть — фікс продуктивності чи фікс коректності?

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

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

Це реальні завдання, які можна виконати на Linux-хостах, щоб діагностувати апаратну FP-можливість CPU, поведінку, тяжку на FP, і «чому це змінилося після міграції?» Кожен пункт включає: команду, що типовий вихід означає, і яке рішення з цього випливає.

Завдання 1: Підтвердити модель CPU і чи присутній FPU

cr0x@server:~$ lscpu | egrep -i 'model name|vendor|flags|hypervisor'
Vendor ID:                    GenuineIntel
Model name:                   Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
Flags:                        fpu vme de pse tsc msr pae mce cx8 apic sep mtrr ...
Hypervisor vendor:            KVM

Значення: Прапор fpu вказує, що апаратна підтримка плаваючої коми виставлена для ОС. Наявність гіпервізора підказує, що це гостьова система — можливе маскування фіч.

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

Завдання 2: Швидка перевірка можливостей x87/SSE/AVX

cr0x@server:~$ grep -m1 -oE 'fpu|sse2|avx|avx2|fma' /proc/cpuinfo | sort -u
avx
avx2
fma
fpu
sse2

Значення: Сучасний FP часто здійснюється через SSE2/AVX; спадщина x87 все ще є, але не завжди головний шлях. Відсутність SSE2 на x86_64 була б підозрілою; відсутність AVX може пояснювати різницю продуктивності для векторизованого коду.

Рішення: Якщо на переміщеному хості зникли AVX/AVX2/FMA, очікуйте сповільнення чисельних ядер і можливих змін у округленні (FMA змінює результати). Вирішіть, чи стандартизувати фічі CPU по флоту.

Завдання 3: Виявити, чи ви в VM і яка модель CPU виставлена

cr0x@server:~$ systemd-detect-virt
kvm

Значення: Ви віртуалізовані. Це нормально. Але це також означає, що прапори CPU можуть бути замасковані для сумісності при live migration.

Рішення: Якщо продуктивність регресувала після переселення гіпервізора, порівняйте моделі CPU гостьової ОС і прапори; запросіть host-passthrough або менш суворий baseline CPU, де це безпечно.

Завдання 4: Порівняти прапори CPU між двома хостами (перевірка дрейфу)

cr0x@server:~$ ssh cr0x@hostA "grep -m1 '^flags' /proc/cpuinfo"
flags		: fpu ... sse2 avx avx2 fma
cr0x@server:~$ ssh cr0x@hostB "grep -m1 '^flags' /proc/cpuinfo"
flags		: fpu ... sse2 avx

Значення: HostB позбавлений avx2 і fma. Це може бути апаратна різниця або маскування віртуалізацією.

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

Завдання 5: Швидко виявити FP-гарячі точки через perf top

cr0x@server:~$ sudo perf top -p 24831
Samples: 2K of event 'cycles', 4000 Hz, Event count (approx.): 712345678
Overhead  Shared Object      Symbol
  21.33%  libm.so.6          __exp_finite
  16.10%  myservice          compute_risk_score
   9.87%  libm.so.6          __log_finite

Значення: Ваш процес витрачає серйозні цикли в математичних рутинах і власній чисельній функції.

Рішення: Якщо регресія корелює з втратою векторних фіч, зосередьтеся на прапорах CPU і опціях компілятора. Якщо ні — профілюйте глибше (perf record) і перевіряйте алгоритмічні зміни.

Завдання 6: Захопити короткий профіль для офлайн-аналізу

cr0x@server:~$ sudo perf record -F 99 -p 24831 -g -- sleep 30
[ perf record: Woken up 3 times to write data ]
[ perf record: Captured and wrote 7.112 MB perf.data (12345 samples) ]

Значення: У вас є call-graph за 30 секунд виконання, достатній, щоб побачити, куди йде час.

Рішення: Використайте perf report, щоб підтвердити, чи ви обмежені в обчисленнях у FP-рутинах, чи застрягли в іншому місці. Не здогадуйтеся.

Завдання 7: Подивитися, чи бінарник використовує x87 чи SSE для FP

cr0x@server:~$ objdump -d -M intel /usr/local/bin/myservice | egrep -m1 'fld|fstp|addsd|mulsd|vaddpd'
0000000000412b10:	fld    QWORD PTR [rbp-0x18]

Значення: fld/fstp натякає на використання x87. addsd/mulsd вказують на SSE скалярні операції; префікс v* — на AVX.

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

Завдання 8: Перевірити версії glibc/libm (числова поведінка може змінитися)

cr0x@server:~$ ldd --version | head -n1
ldd (Ubuntu GLIBC 2.35-0ubuntu3.4) 2.35

Значення: Різні версії libc/libm можуть змінювати реалізації математичних функцій і поведінку в крайових випадках.

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

Завдання 9: Підтвердити, які спільні бібліотеки процес дійсно використовує

cr0x@server:~$ cat /proc/24831/maps | egrep 'libm\.so|libgcc_s|libstdc\+\+|ld-linux' | head
7f1a2b2a0000-7f1a2b33a000 r-xp 00000000 08:01 123456 /usr/lib/x86_64-linux-gnu/libm.so.6
7f1a2b700000-7f1a2b720000 r-xp 00000000 08:01 123457 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1

Значення: Підтверджує шляхи використовуваних бібліотек; уникає плутанини «але я встановив нову lib».

Рішення: Якщо різні хости маплять різні шляхи/версії libm, вирівняйте їх. Чисельні баги люблять гетерогенність.

Завдання 10: Виявити проблеми з denormals/subnormals через лічильники perf (коротка порада)

cr0x@server:~$ sudo perf stat -p 24831 -e cycles,instructions,fp_arith_inst_retired.scalar_double sleep 10
 Performance counter stats for process id '24831':

     24,112,334,981      cycles
     30,445,112,019      instructions
        412,334,112      fp_arith_inst_retired.scalar_double

      10.001234567 seconds time elapsed

Значення: Високі лічильники FP-інструкцій свідчать, що навантаження тяжке по FP. Якщо cycles per instruction різко зростає в певних фазах, ви можете потрапляти на повільні шляхи (включаючи denormals, хоча це потребує більш глибоких інструментів для підтвердження).

Рішення: Якщо фаза корелює з величезним CPI і FP-лічильниками, дослідіть чисельні діапазони і розгляньте обережне очищення denormals або зміну алгоритмів, щоб уникнути субнормальних режимів.

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

cr0x@server:~$ readelf -p .GCC.command.line /usr/local/bin/myservice 2>/dev/null | head
String dump of section '.GCC.command.line':
  [     0]  -O3 -ffast-math -march=native

Значення: -ffast-math і -march=native можуть породжувати різну чисельну поведінку і різні набори інструкцій між машинними збірками.

Рішення: Для продакшн-збірок уникайте -march=native, якщо машина збірки не відповідає вашому рантайм-флоту. Ставте -ffast-math як продуктовий вибір з тестами, а не як «безкоштовний» прапор швидкості.

Завдання 12: Перевірити, чи ядро використовує lazy FPU switching (рідко зараз, але важливо в деяких контекстах)

cr0x@server:~$ dmesg | egrep -i 'fpu|xsave|fxsave' | head
[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[    0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format.

Значення: Показує можливості керування станом FPU. Сучасні ядра добре з цим справляються, але в обмежених середовищах розмір контексту й стратегія збереження/відновлення можуть мати значення.

Рішення: Якщо ви підозрюєте накладні витрати контекстних переключень через активне SIMD-користування (багато потоків роблять FP), профілюйте накладні витрати планувальника і кількість потоків; виправляйте архітектуру (батчування, менше потоків), а не ядро у вигляді фольклору.

Завдання 13: Помітити троттлінг CPU, що маскується під «регресію FPU»

cr0x@server:~$ sudo turbostat --quiet --Summary --show Busy%,Bzy_MHz,TSC_MHz,PkgTmp --interval 5 --num_iterations 2
Busy%   Bzy_MHz  TSC_MHz  PkgTmp
72.31   1895     2394     86
74.02   1810     2394     89

Значення: Висока температура пакета й знижена busy MHz можуть вказувати на теплове тротлінгування. FP-важкі навантаження можуть сильніше навантажувати потужність/тепло, ніж цілочисельні.

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

Завдання 14: Підтвердити детермінованість виходу на двох хостах (швидкий diff-тест)

cr0x@server:~$ ./myservice --fixed-input ./fixtures/case1.json --emit-score > /tmp/score.hostA
cr0x@server:~$ ssh cr0x@hostB "./myservice --fixed-input ./fixtures/case1.json --emit-score" > /tmp/score.hostB
cr0x@server:~$ diff -u /tmp/score.hostA /tmp/score.hostB
--- /tmp/score.hostA	2026-01-09 10:11:11.000000000 +0000
+++ /tmp/score.hostB	2026-01-09 10:11:12.000000000 +0000
@@ -1 +1 @@
-score=0.7134920012
+score=0.7134920013

Значення: Різниця мала, але реальна. Чи має вона значення — залежить від порогів, сортування, бакетування й аудиту у наступних етапах.

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

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

Міні-історія №1: Інцидент, спричинений хибним припущенням

Середньої величини fintech мав сервіс ціноутворення, що обчислював «ризиковий скор» на транзакцію. Це був не ML — просто детермінована модель з купою експонент, логарифмів і кількома умовами. Вони запускали її на кластері VM. Сервіс мав жорстке SLO, бо працював inline у платежах.

Вони перемістили VM до нового пулу гіпервізорів. Роллаут виглядав як по книжці: канарки, бюджет помилок, план відкату. Латентність була в нормі першу годину. Потім почав рости хвіст. Не відразу, не катастрофічно — просто настільки, щоб перевести алерт зі зеленого у «ваш вікенд — це зустріч».

Хибне припущення: «CPU — це CPU». Новий пул виставив більш консервативну модель віртуального CPU для сумісності. AVX2 і FMA були замасковані. Бінарник зібрали з -march=native кілька місяців раніше на хості збірки, де AVX2/FMA були доступні. На старому пулі гості експонували ці фічі, тож швидкий шлях працював. На новому пулі бінарник все ще працював, але гарячі цикли впали до скалярних рутин у libm і в їхньому коді. Нічого не впало — просто стало повільніше.

Вони витратили півдня на марні пошуки: налаштування GC, пули потоків, параметри ядра, мережеві джиттери. Всі червоні осі. Докази були на виду: прапори CPU різнилися, perf top показував гарячі точки в libm, регресія збігалася з міграцією.

Виправлення було нудним і ефективним: перебудувати без -march=native, цілитися у відомий baseline і забезпечити паритет фіч CPU (або розклад по можливостях). Латентність нормалізувалася. Потім додали self-check при старті, який логував доступні набори інструкцій і відмовлявся запускатися, якщо артефакт очікував більше, ніж хост експонує.

Міні-історія №2: Оптимізація, що обернулась проти

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

Профіль показав: домінували FP-обчислення. Інженер перебудував ключовий компонент з агресивними прапорами компілятора. Джоб став швидшим у staging. Керівництво аплодувало. Випустили в прод.

Через два тижні бізнес помітив тонку проблему: рекомендації «стрибали». Не радикально — просто достатньо, щоб вплинути на граничні SKU. Пайплайн не був явно неправильним; він став нестабільним. Запуски з однаковими вхідними даними давали трохи різні виходи залежно від хоста. Іноді це міняло порядок близьких кандидатів. Це змінювало downstream-рішення і ускладнило аудити.

Причина фейлу: -ffast-math і векторизація змінили порядок операцій і внесли малі чисельні відхилення. У поєднанні з tie-breaker’ами, що припускали стабільне сортування, «дрібні» різниці стали великими змінами поведінки. Пайплайн набув швидкості, але втратив довіру.

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

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

Логістична фірма мала сервіс симуляцій для планувальників. Класичне «запустити багато сценаріїв і вибрати найкращий» навантаження. Сервіс не був критичним по латентності на запит, але був бізнес-критичним за добу, бо планувальники потребували результати до дедлайну.

Команда мала непопулярне правило: продакшн-образ був зафіксований. Такий самий дистро, та сама libc, той самий рантайм компілятора, ті ж версії математичних бібліотек. Команди скаржилися, бо патчинг вимагав координації. Безпеку патчили, але через контрольовані перебудови образів і staged rollouts. Нудно. Повільно. Набридливо.

Одного дня прийшов апаратний refresh. Нові CPU, новий мікрокод і оновлення гіпервізора. Інша організація, що вела «схожі» системи, зіткнулася з дрейфом виходів і різницею продуктивності. Ця команда — ні. Поведінка їхнього сервісу залишилась достатньо стабільною, щоб планувальники цього навіть не помітили.

Чому? Вони серйозно ставилися до гетерогенності. Мали conformity-тести, що запускали фіксовані сценарії і порівнювали виходи з базою. Мали логи при старті, що фіксували CPU flags, версії lib і метадані збірки. Коли на нових хостах з’явилися додаткові фічі, вони не почали автоматично їх експлуатувати; чекали, поки не приведуть флот до консистентності.

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

Поширені помилки (симптом → корінь → виправлення)

1) Симптом: уповільнення 5–20× після міграції, без очевидних помилок

Корінь: маскування фіч CPU (AVX/AVX2/FMA не виставлені) або fallback до не-векторних FP-шляхів; іноді випадкова емуляція в обмежених середовищах.

Виправлення: порівняйте прапори /proc/cpuinfo між старим і новим; відкоригуйте модель VM CPU; перебудуйте з стабільним baseline (-march=x86-64-v2 чи подібна політика) і уникайте -march=native для артефактів флоту.

2) Симптом: той самий вхід дає трохи різні чисельні результати на різних хостах

Корінь: різні набори інструкцій (FMA vs non-FMA), відмінності розширеної точності x87, різні версії libm або перестановки компілятора.

Виправлення: зафіксуйте рантайм-бібліотеки; стандартизуйте фічі CPU; компілюйте з узгодженою FP-моделлю; введіть явне округлення на межах; додайте детерміновані tie-breaker’и в сортуваннях і порогах.

3) Симптом: релізна збірка відрізняється від debug-збірки у виході

Корінь: оптимізації змінюють розподіл регістрів і вигрузку, впливаючи на поведінку розширеної точності x87 і точки округлення.

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

4) Симптом: хвостова латентність стрибає лише при високій конкуренції

Корінь: інтенсивне використання SIMD/FPU у поєднанні з великою кількістю потоків; зростання накладних витрат на контекстні переключення; іноді термальне тротлінгування при тривалому FP-навантаженні.

Виправлення: зменшіть кількість потоків, батчуйте роботу, використовуйте work-stealing пули; перевірте turbostat; розподіліть «гарячі» навантаження; не «вирішуйте» це магічними sysctl-хитрощами.

5) Симптом: один вузол видає аномальні результати, що ламають консенсус або кеш

Корінь: змішані фічі CPU у флоті; один хост позбавлений фічі або має інший мікрокод/версію lib, що спричиняє чисельний дрейф.

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

6) Симптом: «Ми оптимізували математику і тепер скаржаться клієнти»

Корінь: -ffast-math або подібні прапори порушили очікування IEEE (NaN, знак нуля, асоціативність), змінивши контрольний потік і поведінку в крайових випадках.

Виправлення: відкатіть fast-math; поетапно повертайте таргетовані оптимізації з хронологією тестів; документуйте FP-контракт як частину API.

Чеклісти / покроковий план

Чекліст A: Перед міграцією сервісу з чисельними навантаженнями

1. Зробіть інвентар фіч CPU на поточному флоті (lscpu, /proc/cpuinfo) і запишіть їх, ніби це частина API.
2. Зробіть інвентар рантайм-бібліотек (версії glibc/libm, хеші образів контейнерів).
3. Збирайте артефакти з фіксованою ціллю (уникайте -march=native, якщо build і runtime не співпадають за політикою).
4. Запустіть тест-пак на детермінованість: фіксовані входи, порівняйте виходи хоча б на двох хостах у цільовому середовищі.
5. Профілюйте репрезентативне навантаження, щоб зрозуміти, чи ви FP-bound чи memory-bound; не покладайтеся на синтетичні бенчмарки.

Чекліст B: Якщо підозрюєте регресію, пов’язану з FPU

1. Підтвердіть прапори CPU і модель віртуалізації.
2. Запустіть perf top, щоб побачити, чи домінують libm або чисельні ядра.
3. Переконайтеся, що немає термального тротлінгу (особливо на щільних нодах).
4. Порівняйте прапори збірки бінарника і версії бібліотек між середовищами.
5. Тільки тоді змінюйте прапори компілятора або алгоритмічні вибори.

Чекліст C: Якщо підозрюєте дрейф коректності

1. Відтворіть на мінімальному фіксованому вході і зробіть diff виходу.
2. Підтвердіть, що версії бібліотек і фічі CPU збігаються між хостами.
3. Визначте прийнятну толерантність (ULPs) і місця, де потрібна точна відтворюваність.
4. Стабілізуйте: закріпіть оточення і поведінку набору інструкцій.
5. Укріпіть: додайте явне округлення і детерміновані tie-breaker’и там, де бізнес залежить від порогів.

FAQ

1) Яке найпростіше пояснення, чому вбудований FPU у 486 мав значення?

Він зробив апаратну плаваючу кому достатньо поширеною, щоб програмне забезпечення могло її припускати, змінивши екосистеми від уникнення фіксованого дробу до FP-first дизайну — і змінивши очікування щодо продуктивності та коректності.

2) Чи був 486 першим x86 з плаваючою комою?

Ні. У x86 плаваюча кома існувала через копроцесори (як 287/387) і через більш ранні інтегровані підходи в інших архітектурах. 486DX зробив її мейнстрімом на популярній лінії PC CPU.

3) Чому ops має хвилюватися про фічу CPU 1990-х сьогодні?

Бо операційні патерни збереглися: маскування фіч у VM, гетерогенний флот, прапори компілятора, різниці libm і проблеми детермінізму. 486 — це точка, де «FP за замовчуванням» стала культурно нормальною на x86 ПК.

4) Яка практична різниця між x87 і SSE2 плаваючою комою?

x87 використовує 80-бітні розширені регістри і стекову модель; SSE2 використовує 64-бітні double регістри з більш послідовною поведінкою округлення. x87 може давати тонкі відмінності залежно від вигрузки регістрів.

5) Чому я отримую різні результати на різних CPU, якщо існує IEEE 754?

IEEE 754 визначає багато речей, але не все про проміжну точність, злиття операцій (як FMA), реалізації трансцендентних функцій та перестановки компілятора. Ці відмінності можуть мати значення в крайових випадках.

6) Чи варто використовувати -ffast-math в продакшні?

Тільки якщо ви явно протестували, що змінені правила математики не ламають бізнес-коректність, аудити чи детермінованість. Ставте це як feature-flag, що впливає на надійність, а не як нешкідливу оптимізацію.

7) Як запобігти «той самий запит, інша відповідь» між вузлами?

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

8) Хіба сучасне апаратне FP настільки швидке, що це не має значення?

Швидкість — не єдина проблема. Детермінізм, експозиція фіч у VM, теплове тротлінгування під сталі векторні навантаження і тонкі відмінності у злитих операціях досі спричиняють інциденти в проді.

9) Чи інтегрований FPU завжди покращує надійність?

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

Висновок: практичні кроки далі

Вбудований FPU у 486 був не лише апгрейдом швидкості. Це була зміна контракту: апаратна плаваюча кома стала «нормою», і екосистеми програмного забезпечення перебудувалися навколо цього припущення. Сьогодні ми успадкували плюси (швидкий чисельний код скрізь) та мінуси (тонкий дрейф, фіч-кліффи і сеанси відлагодження, де винен один біт у наборі інструкцій).

Кроки, які ви можете зробити цього тижня, навіть якщо ніколи не плануєте торкатися 486:

1. Зробіть інвентар фіч CPU по вашому продакшн-флоту і перестаньте вдавати, що всі вони однакові.
2. Забороніть -march=native для артефактів флоту, якщо у вас немає суворої політики «build equals run».
3. Додайте тест-пак детермінованості для чисельно-важких сервісів: фіксовані входи, порівняння між хостами, алерт на дрейф.
4. Зафіксуйте рантайм для сервісів, де числа мають юридичне, фінансове чи аудиторське значення.
5. Зробіть прапори продуктивності продуктовим рішенням: документуйте, тестуйте і вводьте як будь-яку іншу ризиковану зміну.

Ось така неславетна правда: історія «апаратної математики» — це історія ops. 486 просто зробив так, щоб ми жили з цим десятиліттями.