Скільки процесорів слід використовувати за допомогою Hyperthreading?

Скажімо, у мене є серверний процесор з 18 ядрами, з гіперточкою, що означає, що я можу бачити 36 cpus у htop.

Щоб повністю використовувати процесор і не впливати на продуктивність однопотокових, я повинен прагнути, щоб усі 36 «ядер» працювали на 100%, а HT-ядра просто будуть робити менше роботи і все-таки звітуватимуть на 100%, або це матиме на увазі значення "повні" сердечники вже перериваються завданням на його "ядрі HT" і тим самим роблять менше однопотокових робіт?

Я знаю, що існує велика кількість змінних, які впливають на продуктивність HT, я просто хочу знати, що означають процесорні лічильники при роботі з HT.

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

Постає питання: коли наявність двох різних ниток призводить до того, що одна працює гірше? Прогнозування галузей та залежності між інструкціями не зміниться. Очікування доступу до пам'яті зараз ... два потоки конкурують за доступ до пам'яті, як за використання кешу, так і для пропускної здатності.

Якщо у вас є кілька процесорів, що працюють з HT, а інші - ні, це також означає, що ви присвоїте певні потоки одному чи іншому типу? Я думаю, що ні: ваші програми будуть запускати свої потоки на випадкових віртуальних ядрах. Тож як допомагає розділити конфігурацію? Оскільки кожен процесор має свій кеш-пам'ять, єдиний вплив пов'язаний з пропускною здатністю пам’яті та тягарем узгодженості кешу.

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

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

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

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

Що означає вимірювач процесора: він повідомляє про весь час, який не витрачається на пробіг холостого ходу. Обидва логічні потоки, призначені для ядра, не працюватимуть, хоча реальна робота над одним із них може бути невеликою. Час, витрачений на трубопровід, затримується протягом декількох циклів, поки результати не будуть готові, пам'ять витягнута, атомні операції обгороджені тощо. Так само не спричиняє, що нитка буде відкладена як "не готова", тому вона не буде простоювати, а час все ще відображається як використовується. Очікування в оперативній пам’яті не відображатиметься як простой. Тільки щось на зразок вводу / виводу змусить блокувати нитку і зупинить час зарядки до неї. Загалом, мутекс операційної системи зробить це так, але із зростанням багатоядерних систем це вже не є впевненою справою, оскільки "спінлок" не змусить нитку повернутися на полицю.

Таким чином, 100-відсотковий процесорний метр не означає, що все плавне плавання, якщо процесор часто затримується в очікуванні пам'яті. Менша кількість логічних ядер, що показують 90%, цілком може отримати більше роботи, оскільки вона закінчує хрускіт числа і тепер чекає на диску.

Тож не турбуйтеся про вимірювач процесора. Подивіться на реальні досягнення, тільки .

Лічильники процесорів дуже погані, щоб сказати вам, наскільки більше продуктивності ви можете вичавити із гіперточених процесорів. Для цього вам слід запустити власні орієнтири за різними тарифами переплати за основні фізичні ядра. Деякі навантаження, які найкраще працюють з HT повністю вимкнено, тому включіть цей випадок і в тестування. Це може бути 1: 2 (36 паралельних робітників), або 1: 1,5, або навіть 1: 2,5! Це залежить від вашої завантаженості.

Більш детально, HT реалізується на кремнії способами, що скорочують час процесора простоює, коли контекст потрібно переключити або не вдасться передбачити галузь. Це полегшує досягнення 100% використання одиниці виконання, ніж чисті хитрощі операційної системи. HT розвивалася з моменту впровадження, і в сучасних мікросхемах спостерігається більше паралелізму, ніж у тих, які ми використовували 10 років тому.

Є два профілі виконання, які впливатимуть на те, де оптимальна точка переплати:

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

Ви повинні побачити, що всі 36 ядер працюють на 100% - якщо припустити, що це може зробити програмне забезпечення (що не тривіально - планування може бути складним з багатьма ядрами, тому сприйняття нижче 100% є прийнятним).

Очевидно, що коли ви "розщеплюєте" руду з гіперточенням, значення цих 200% не є "2х100% - у виконаній роботі", але це невидимо для будь-яких вимірювань, які проводяться (що відбувається від використання процесора та не має поняття про виконану роботу). Скільки цієї роботи буде виконано, залежить від того, яка робота - десь вище 1,5 х роботи, яка очікується, що робота без гіпертрофування повинна очікуватися більшу частину часу.

Те, як реалізована гіпертехніка, залежить від конкретного процесора. Від Негалема до Skylake, Intel значно зменшила фіксований коефіцієнт (тобто 50/50) спільних частин трубопроводу, спрямовуючись на динамічно спільні структури.

У всякому разі, в загальних рисах, що дозволяє HT призвело до sligtly уповільнення виконання одного потоку, але з - за того , як планувальник працює Linux, це тільки в тому випадку , коли число або працює потік вище , ніж кількість фізичних ядер. Оскільки в таких ситуаціях (коли нитки> сердечники) ти зазвичай оцінюєш загальну пропускну спроможність максимальної важливості, гіперточення залишається чистою виграшею.

Як це можливо? Ключовим моментом для розуміння є те, що процесор не представляє фізичні ядра та віртуальні як рівні ядра, скоріше він розкриває останні таким чином, ніж планувальник Linux може уникнути планування на них, якщо є якісь інші фізичні ядра. Іншими словами, він спочатку використовує всі фізичні ядра, потім починає використовувати віртуальний.

Це означає, що, як правило, HyperThreading є дуже цінною особливістю (інші процесори, як Power8, використовують ще більш глибокі методи SMT), і щоб максимізувати пропускну здатність, ви повинні це ввімкнути, завантажуючи процесор мінімум одним потоком на віртуальне чи фізичне ядро. Для практичного прикладу, щоб отримати повну продуктивність з 18-ядерного процесора, вам слід використовувати щонайменше 36 потоків.

Існують два винятки:

1. якщо все, що ви хочете, це мінімізувати затримку з обмеженого набору потоків (де потоки <фізичні ядра), ви можете відключити HT
2. дуже старий процесор (Pentium4 і, набагато менший спосіб, Nehalem) мають негнучкі правила розподілу, які змушують ЦП розділяти багато ключових ресурсів у співвідношенні 50/50, незалежно від стану / навантаження другого потоку. У цьому випадку вам довелося порівняти ваш випадок використання, щоб переконатися, що додана пропускна здатність вартує значно меншої продуктивності одного потоку.