Як ми в Curiosio тестували і оцінювали процесор Ampere Altra

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Я — Василь Милько, співзасновник і керівник Curiosio, раніше — директор R&D SoftServe. Займався штучним інтелектом та машинною емпатією.

Ця стаття — про те, як ми тестували процесор Ampere^Ⓡ Altra^Ⓡ: щойно Ampere Computing оголосила про програму технічної оцінки, ми подали заявку і зазначили, що нас цікавлять багатоядерні завантажувальні (bootable) чіпи, як-от Intel Xeon Phi 72xx. І так, нам його дали. Що вийшло — читайте далі.

Стаття може бути цікавою серверним програмістам та автомандрівникам.

Про проєкт

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

Curiosio — поєднання пошукової системи, обчислювальної системи та автовідповідача для мандрівників. Говорячи мовою науки, Curiosio будує практичний маршрут, роблячи багатокритеріальну оптимізацію і виконуючи наявні обмеження. Говорячи математичною мовою, Curiosio знаходить розв’язок для NP-повної задачі в передбачуваному режимі реального часу.

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

Curiosio працює на базі Ingeenee — нашій машині штучного інтелекту, що знаходить унікальний розв’язок з-поміж нескінченних варіантів. Ingeenee — це еволюційний штучний інтелект. Еволюційний штучний інтелект працює на основі високопродуктивних обчислень (HPC). Для високопродуктивних обчислень потрібна електроенергія. Електроенергія дорога. Arm-процесори — енергоефективні. Отож ми провели оцінку цілком нового серверного Arm-процесора Ampere Altra від компанії Ampere Computing.

Допитливий мандрівник озброєний арметом

Процесор Ampere Altra

Ampere Altra — це серверний процесор на базі архітектури Arm. Це багатоядерний процесор, представлений 80 ядрами Arm Neoverse N1. Ampere Altra — перша модель серверних Arm-процесорів з родоводом (дивіться історію їхніх інвестиційних раундів).

Процесор Ampere Altra

Ampere Computing розробила дві версії процесора — Ampere Altra та Altra Max (дивіться докладну інформацію про Ampere Altra в короткому описі та технічних характеристиках). Ampere Altra має 80 ядер, Ampere^Ⓡ Altra Max — 128. Найважливіша для нашого робочого навантаження характеристика — тактова частота. Коли ми подавали заявку, то думали, що 80-ядерна версія працює на частоті 3,3 ГГц, тому обрали Ampere Altra, а не Ampere Altra Max. Тепер ми знаємо, що і Ampere Altra, і Ampere Altra Max мають постійну максимальну частоту 3,0 ГГц.

Для роботи Curiosio потрібні високопродуктивні багатоядерні серверні процесори, щільно упаковані в енергоефективні багатопроцесорні вузли, оптимізовані для HPC. Щойно Ampere Computing оголосила про програму технічної оцінки, ми подали заявку. Ми прямо зазначили, що нас цікавлять багатоядерні завантажувальні (bootable) чіпи, як-от Intel Xeon Phi 72xx. Тож покладаємо великі надії, схрещуємо пальці, стукаємо по дереву, що нам дадуть добро на тестування їхнього заліза.

Мета програми оцінювання — тестування систем Ampere — цілісних серверних систем, розроблених для задоволення виняткових потреб кожного окремого учасника і надання технічного звіту компанії Ampere Computing. Є кілька обчислювальних систем Ampere Altra, розроблених спільно з виробниками серверів. У нас двосокетна система Ampere Altra [160 ядер з тактовою частотою 3,0 ГГц], яка називається Mt. Jade. В рамках нашої програми було виділено кілька таких вузлів.

Програма оцінки

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

Під час початкового дослідження системи ми стисло порівняли продуктивність тільки для 20–30 завантажених ядер (з доступних 160), але не формалізували цього вимірювання, оскільки нам потрібно вдесятеро більше ядер. Під час цього швидкого тестування Ampere Altra показав удвічі менше енергоспоживання, як порівняти з нашими процесорами Intel.

Основний порівняльний аналіз для Ampere Altra ми провели на 80 та 150 ядрах. Ми тестували Ampere Altra у порівнянні з нашими трьома системами процесорів Intel Xeon — E5—26xx v2, v3, v4. Не найновіші, як ви бачите, але продуктивні для нас. Своє є дешевшим за хмари (AWS). Ми вимірювали продуктивність Ampere Altra з огляду на такі п’ять характеристик: продуктивність сервера, продуктивність на Вт (Watt), однопотокова продуктивність, багатопотокова продуктивність, час відгуку. Здебільшого продуктивність — це кількість запитів за одиницю часу. Що більше запитів за раз, то ліпше. На діаграмах [нижче] показано співвідношення між Ampere Altra та Intel Xeon в однакових вимірюваннях.

Продуктивність сервера. Розміщення більшої кількості ядер в одному серверному корпусі забезпечує більшу продуктивність під час використання того ж заліза. Два чіпи Ampere Altra на одному сервері дають 160 ядер для операційної системи й програм. Цей показник корелюється з продуктивністю на об’єм. У дата-центрі провайдера ви платите за розміщення обладнання, тобто за простір, тож щільно упаковані стійки-кабінети — раціональний підхід.

Порівняльний графік для серверної продуктивності

Наші процесори Intel теж двосокетні. Розуміючи, що в майбутньому ймовірне ще щільніше запаковування— 4 двосокетні HPC-вузли на сервері 2U навіть з повітряним охолодженням, слід зазначити, що це сильна сторона Ampere Altra. Це ж 640–1024 потужних ядра на одному шасі!

Продуктивність на Вт (Performance per Watt). Хоч що запаковано в сервер, на ньому [зазвичай] буде два блоки живлення. Усередині сервера електроенергію здебільшого споживають процесорні мікросхеми й мікросхеми пам’яті DIMM. Як порівняти з нашими процесорами Intel Xeon, Ampere Altra енергоощадніший.

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

Порівняльний графік для продуктивності на Вт (performance per Watt)

Однопотокова продуктивність. Цей показник описує обсяг роботи, виконаної одним потоком. У нашому випадку це кількість запитів, виконаних одним потоком за секунду. Хоча ми порівнювали продуктивність для RISC і CISC, тест показав майже ідентичну продуктивність як для архітектур зі скороченим набором команд, так і з комплексними командами.

Порівняльний графік для однопотокової продуктивності

Багатопотокова продуктивність. Цей показник описує обсяг роботи, виконаної кількома потоками. Ми вимірювали кількість запитів за секунду на потік для 2, 4, 8, ..., 160 потоків. Діаграма показує схожу продуктивність Ampere Altra та Intel Xeon CPUs. Видно, як падає продуктивність зі збільшенням кількості потоків, і це, мабуть, пов’язано зі спільною пам’яттю. (Попередній аналіз вказує на затримки під час виконання Go, де доступ надається до спільних даних тільки для читання з кількох горутин).

Порівняльний графік для багатопотокової продуктивності (спільна пам’ять)

Щоб перевірити причини, пов’язані з пам’яттю, ми повторили тести без використання спільних даних (тобто спільної пам’яті під час виконання Go). Цього разу для такої модифікації навантаження було використано всі 160 ядер. І тут усе стало дуже цікаво: Ampere Altra стабільно працював з будь-якою кількістю потоків аж до 160. Температура процесора була досить високою — ~65—70 °C (тоді як Intel Xeon E5—2620 v4 показав температуру ~37—41 °C).

Порівняльний графік для багатопотокової продуктивності (локальна пам’ять)

Час відгуку. Цей показник користувачі відчувають найбільше, бо це час реагування системи, це зручність використання. Весь наш запит занадто складний, щоб його можна було переробити для Ampere, тож ми ізолювали його найважчу частину й дали на опрацювання Ampere Altra, щоб порівняти з нашими процесорами Xeon.

Порівняльний графік для часу відгуку

Хоча ми показуємо лише співвідношення продуктивності між Ampere Altra та Intel Xeon для нашого власного робочого навантаження, видно, що серверні процесори на базі Arm не дуже відстають. Чи перейдемо ми на Arm-процесори завтра? Читайте далі, варто врахувати багато деталей.

Деталі оцінки і NUMA

Ми проводили той самий тест на різних апаратних системах, щоб порівняти продуктивність процесорів Ampere та Intel. Усі тести ми робили на великій кількості потоків (90–95% від загального числа доступних ядер), щоб виміряти продуктивність завантаженої системи. Вимірювання було вбудовано в наш код (як телеметрія). Під час навантаження ми контролювали систему за допомогою стандартних утиліт: htop, glances, sensors (приклад команди sensors нижче) тощо.

# sensors
apm_xgene-isa-0000
Adapter: ISA adapter
SoC Temperature:  +65.0°C 
CPU power:       145.00 W 
IO power:         29.83 W 
apm_xgene-isa-0000
Adapter: ISA adapter
SoC Temperature:  +70.0°C 
CPU power:       159.00 W 
IO power:         34.96 W

Деталі вимірювання. Показник «Продуктивність сервера» вимірює кількість запитів, які виконують усі ядра вузла за інтервал часу. По суті, це продуктивність ядра, помножена на кількість запущених потоків. Ось де справді помітна кількість ядер.

Показник «Продуктивність на ват» — кількість виконаних запитів, унормована відповідно до споживання електроенергії. Загальне споживання процесора Ampere Altra було приблизно пораховане за формулою: процесор + ввід-вивід. Для наших процесорів Intel датчики показують те саме загальне число, як зазначено в BMC, тобто з урахуванням споживання вентиляторів та інших модулів. Тоді як для процесора Arm не було враховано споживання дисків, мережі, вентиляторів.

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

Для показника «Час відгуку» ми виміряли загальний час виконання, витрачений на опрацювання запиту в трьох різних конфігураціях реального часу (позначених як X, Y, Z). Вони відрізнялися завантаженням процесора, розподілом ймовірностей тощо. Увесь ланцюжок команд відгуку занадто довгий і складний, тож не потрапив до однотижневого тесту. Також ми не використовували мережу в тестах.

Аномалія. Під час першого тесту сталася цікава аномалія— ми не змогли навантажити всі 160 ядер нашим тестом. Навантаження становило ~50%, коли ми налаштовували 80, 100, 150, 160 (дивіться скриншот htop нижче). Найімовірніше, це наше недопрацювання. Реально цікавий випадок, у якому варто розібратися.

Недовантажені 160 ядер (~50% навантаження)

Особливості Golang. Ми виявили потенційну проблему продуктивності в одному з наших модулів, написаних мовою Go. Проблема не була помітна на чіпах Intel з кількістю ядер менше ніж 40. Ми провели спеціальні тести для цього модуля й виявили лінійну залежність між часом відгуку і кількістю запущених процесів. Це було несподіване відкриття.

Графік Go аномалії, додавання горутин вбиває продуктивність

У нас є кілька гіпотез щодо того, чому так сталося, і ми поділимося нашими висновками, щойно закінчимо дослідження, і якщо воно пов’язане з Go. Це можуть бути сумнозвісні асоціативні масиви Go (проблеми з пам’яттю, проблеми з паралелізмом). Це може бути міжпроцесна взаємодія Go. В усякому разі, дякуємо 160-ядерному Ampere Altra за те, що допоміг це виявити.

Ми це обговорювали з фахівцем із продуктивності компанії Ampere Computing. Найімовірніше, це наша проблема або це пов’язане з середовищем виконання Go. Цієї аномалії не було на Xeon Phi 72xx з більш ніж 250 апаратними потоками, може, тому що це був один сокет? Можливо, це пов’язано з NUMA — чи підтримує планувальник Go архітектуру NUMA? Що ж, нам доведеться зробити низькорівневе профілювання і, можливо, переробити дизайн. Було б цікаво провести порівняльний аналіз обох реалізацій на 128-ядерних процесорах Ampere Altra Max, щоб побачити різницю.

Особливості OSRM. Щоб перевірити, чи проблема в наших модулях, ми провели ізольований тест OSRM — перетворення даних OSM в OSRM. Ми виконували його, запускаючи різну кількість потоків (в конфігурації OSRM). Ми побачили відхилення стосовно налаштованої кількості потоків і продуктивності ядер. Ізольований OSRM-тест показав, що, імовірно, є обмеження на кількість ядер, які працюють на максимальній частоті (перегрів?). Магічне число становить приблизно 32 ядра, від яких ми починаємо бачити зниження продуктивності OSRM, попри те, що залучено більше ядер. І десь між 70 і 100 ядрами настає негативний фазовий перехід. 128 запущених потоків уповільнюють весь процес удесятеро, як порівняти із 16 запущеними потоками.

Графік OSRM аномалії, додавання потоків вбиває продуктивність

На діаграмі видно залежність між часом і кількістю запущених потоків для перетворення дампа OSM в OSRM за допомогою osrm-contract (ієрархічного стиснення). Видно, як зі збільшенням кількості налаштованих потоків збільшується загальний час опрацювання. Це не схоже на проблему синхронізації, оскільки htop показує відповідну кількість завантажених ядер під час цього тесту.

Особливості NUMA. Ми обговорили результати OSRM із фахівцями компанії Ampere Computing, що працюють над продуктивністю й усуненням несправностей. Процесор Ampere Altra не робить дроселювання тактової частоти. Найімовірніше, це пов’язано з більш ніж 80 потоками OSRM, накладеними на апаратні потоки Ampere Altra. Оскільки один процесор має лише 80 ядер-потоків, усі інші потоки перекладаються на другий процесор. Доступ до іншого сокета відбувається із затримкою. Несиметричний доступ до пам’яті з різних сокетів викликає помітну затримку (це також актуально для процесорів Intel, хоча затримка трохи менша).

Збільшення кількості ядер і відмінності між «близькою пам’яттю» і «далекою пам’яттю» зростають у міру того, як ми переходимо до швидших технологій оперативної пам’яті на кшталт DDR5. Бути NUMA-свідомим було корисно і раніше. На сучасних платформах це стає необхідністю.

У кодовій базі OSRM немає ні #include <humaif.h>, ні "«numaif.h». Це означає, що OSRM не використовує libnuma. Найімовірніше, проблема з OSRM пов’язана з програмним забезпеченням. Схоже, що за останні кілька років мало що змінилося щодо NUMA і Go, і ми нічого особливого не робили щоб використати NUMA. Хоча вже є сучасний термін — NUMA-свідоме програмування.

Під час другого тесту ми налаштували наше програмне забезпечення, щоб не використовувати віддаленої пам’яті, і завантажили всі ядра Ampere Altra. Це мало такий прекрасний вигляд у htop.

Ampere Altra повністю навантажено (в htop)

Ampere Altra повністю навантажено (в glances)

Несправності. У нас були збої в системі. Про це ми відзвітували в Ampere Computing, не вдаючись у подробиці. Ми спробували те саме робоче навантаження без Docker, але проблеми залишилися. Можливо, це найкорисніша інформація для Ampere розробників від нас. На жаль, ми не змогли отримати дані в режимі реального часу про потенційний перегрів або помилки в обладнанні, оскільки в нас не було доступу до BMC (через політику віддаленого доступу).

Це ми обговорили з фахівцями компанії Ampere Computing. Нестабільність системи була пов’язана із застарілою прошивкою. Попередньо домовилися повторити оцінювання оновленої системи за за кілька місяців або пізніше. Було б цікаво спробувати ще один 128-ядерний процесор Ampere Altra Max, у двосокетному вузлі якого було б 256 соковитих ядер. Що ж, поживемо — побачимо, стежте за новими статтями.

Особливості програмного забезпечення

Споконвіку ми працюємо із системами Linux/Unix. Ми використовуємо Linux для всього на наших серверах і робочих станціях, навіть на настільних комп’ютерах у нас Linux; для особливих завдань ми використовуємо FreeBSD Unix. Тож ми подали запит на вузли з ОС Ubuntu. З того часу як ми автоматизували масштабованість, ми працюємо на платформі Docker. Це оцінювання ми провели на Ubuntu 20.04 LTS (GNU/Linux 5.4.0—40-generic aarch64) і Docker 20.10.9.

Як робоче навантаження ми використали наші скомпільовані модулі, написані на Go. Мову Go задумували для написання серверних програм, які було б легко підтримувати з плином часу. Ми програмуємо в Go, тому що в нас є потреба в паралельному програмуванні, великій масштабованості, низькорівневих компонентах і високій продуктивності. Наша кодова база Go компілюється для 64-розрядних процесорів Intel/AMD, Arm, Power. Поки що ми використовуємо go1.15.5.

Деякі бібліотеки Go залежать від бібліотек мови C, потрібна спеціальна конфігурація. Ось що ми зробили, щоб скомпілювати під Arm:

# destination OS
export GOOS=linux
# destination architecture
export GOARCH=arm64
# configure compilers
export CGO_ENABLED=1
export CC=aarch64-linux-gnu-gcc
export CC_FOR_TARGET=gcc-aarch64-linux-gnu
# then just build
go build -o /output/path

Тут залучено кілька сторонніх модулів, один з яких — OSRM. Ми використовували OSRM-серверну версію 5.26, що працює на Docker.

Особливості обладнання

Сервер. Mt. Jade — це рейковий сервер з двома сокетами виробництва компанії Wiwynn. На сьогодні це платформа з найвищою щільністю Arm ядер у галузі. Ми переконані, що запакувати ядра можна ще щільніше, оскільки ми не бачили ніяких проблем з охолодженням під час навантаження.

Двосокетний Ampere/Arm сервер Mt. Jade

Процесор. У нього максимальна тактова частота 3,0 ГГц. Чи є кеш L3? Так, у процесора Ampere Altra є кеш 3-го рівня. Він називається кеш системного рівня (SLC). В Ampere Altra це 32 Мбайт. У деяких операційних систем виникають проблеми з його викликом (наприклад, Ubuntu, див. нижче).

$ lscpu
Architecture:                    aarch64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
CPU(s):                          160
On-line CPU(s) list:             0-159
Thread(s) per core:              1
Core(s) per socket:              80
Socket(s):                       2
NUMA node(s):                    2
Vendor ID:                       ARM
Model:                           1
Model name:                      Neoverse-N1
...
CPU max MHz:                     3000.0000
CPU min MHz:                     1000.0000
BogoMIPS:                        50.00
L1d cache:                       10 MiB
L1i cache:                       10 MiB
L2 cache:                        160 MiB
NUMA node0 CPU(s):               0-79
NUMA node1 CPU(s):               80-159
...

Інший погляд на процесор. Це дамп докладної інформації тільки для процесора 1. Дамп для процесора 2 ідентичний, за винятком номера позначення сокета, ідентифікаторів, дескрипторів, теґів. Дескриптор кешу L3 показано з ненульовими значеннями для обох процесорів.

$ dmidecode -t 4
Processor Information
       Socket Designation: CPU 1
       Type: Central Processor
       Family: ARMv8
       Manufacturer: Ampere(TM)
       ...
       Version: Ampere(TM) Altra(TM) Processor
       Voltage: 0.9 V
       External Clock: 1600 MHz
       Max Speed: 2800 MHz
       Current Speed: 2800 MHz
       Status: Populated, Enabled
       ...
       L1 Cache Handle: ...
       L2 Cache Handle: ...
       L3 Cache Handle: ...
       Serial Number:
       ...
       Core Count: 80
       Core Enabled: 80
       Thread Count: 80
       Characteristics:
               64-bit capable

Утиліта dmidecode заявляє, що максимальна частота 2,8 ГГЦ — статичне число, це не миттєве число. Можливо, наші процесори працювали на максимальній частоті 2,8 ГГц, тому що на нашій техніці була трохи застаріла прошивка. Якщо це так, то продуктивність Ampere Altra може бути ще вищою, якщо він працюватиме на постійній частоті 3,0 ГГц.

Процесор справді працює на максимальній частоті 3,0 ГГц, але не завжди видно, як змінюються цифри під час скидання частоти процесора кілька разів поспіль.

$ cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
3000000
2250000
3000000
2010000
3000000

Пам’ять. У системі встановлено 16 DIMM-модулів оперативної пам’яті DDR4 по 16 Гбайт виробництва компанії Samsung. Це доволі стандартний набір сучасних серверів.

$ dmidecode -t memory
...      
Physical Memory Array                                           
       Location: System Board Or Motherboard              
       Use: System Memory                                      
       Error Correction Type: Multi-bit ECC                                                                                                                                                                                                                        
       Maximum Capacity: 4 TB
       Error Information Handle: Not Provided
       Number Of Devices: 16
...
Memory Device
       ...
       Total Width: 72 bits
       Data Width: 64 bits
       Size: 16384 MB
       Form Factor: DIMM
       Set: None
       Locator: DIMM 1
       Bank Locator: Bank 1
       Type: DDR4
       Type Detail: Registered (Buffered)
       Speed: 3200 MT/s
       Manufacturer: Samsung
       ...    
       Rank: 2
       Configured Memory Speed: 3200 MT/s
       Minimum Voltage: 1.14 V
       Maximum Voltage: 1.26 V
       Configured Voltage: 1.2 V
       Memory Technology: DRAM
       ...

Потужність. Блоки резервного живлення 2000 Вт. Ми не мали доступу до консолі IPMI, щоб отримувати показники енергоспоживання безпосередньо з обладнання.

Інші особливості

Від самого початку нас цікавили серверні процесори для високопродуктивних обчислень на базі Arm. Свого часу ми оцінювали Cavium ThunderX (див. статтю «Стек програмування», розділ «Інфраструктура»). Не вдалося оцінити вдосконалений ThunderX2, тому що в системі були проблеми з прошивкою. Тоді генеральний директор Packet — що за людина! — розмовляв з кожним клієнтом. Невдовзі їх купувала Equinix, і все це зупинилося й вичерпалося...

Висновки

Енергоефективні центральні процесори на базі Arm не просто стукають у двері дата-центрів. Вони вже там, усередині. Якщо недавно сервери на базі Arm використовували для сховищ і мереж, то тепер їх застосовують до високопродуктивних обчислень. Процесори Intel Xeon, які ми використовуємо, не можуть досягти заявлених турбочастот у разі завантаження більшої кількості ядер. Поточна версія процесора Ampere Altra мала б працювати на частоті 3,0 ГГц для всіх ядер.

Сервери на базі Arm з Ampere Altra або Ampere Altra Max можна розглядати навіть для критично важливих завдань у режимі реального часу. Найліпша пропозиція — багато ядер з найвищою продуктивністю на Ват. Вузли (сервери) доведеться періодично перезапускати, тож потрібно проектувати надлишкову архітектуру ваших обчислювальних систем.

Цю статтю також можна читати англійською.