Оптимальна кількість ниток на ядро

Скажімо, у мене є 4-ядерний процесор, і я хочу запустити певний процес за мінімальний проміжок часу. Процес ідеально паралельний, тому я можу запускати шматки його на нескінченну кількість ниток, і кожна нитка займає стільки ж часу.

Оскільки у мене є 4 ядра, я не сподіваюся на швидкість запуску більше потоків, ніж ядер, оскільки одне ядро ​​здатне запускати один потік в даний момент. Я мало знаю про обладнання, тому це лише здогадка.

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

Якщо ваші потоки не роблять вводу-виводу, синхронізації тощо, і більше нічого не працює, 1 нитка на ядро ​​забезпечить вам найкращу продуктивність. Однак це, швидше за все, не так. Додавання більшої кількості потоків зазвичай допомагає, але після певного моменту вони призводять до деградації продуктивності.

Не так давно я робив тестування продуктивності на 2-х чотирьохядерній машині, що запускає додаток ASP.NET на Mono під досить пристойним навантаженням. Ми грали з мінімальною та максимальною кількістю потоків, і врешті-решт ми з’ясували, що для цієї конкретної програми у цій конкретній конфігурації найкраща пропускна здатність була десь між 36 та 40 потоками. Все, що виходило за ці межі, діяло гірше. Урок вивчений? Якби я був ти, я б протестував з різною кількістю ниток, поки не знайдеш потрібний номер для своєї програми.

Одне напевно: 4 к нитки займуть більше часу. Це багато перемикачів контексту.

Я згоден з відповіддю @ Гонсало. У мене є процес, який не робить I / O, і ось що я знайшов:

Зауважте, що всі потоки працюють на одному масиві, але різні діапазони (два потоки не мають доступу до одного індексу), тому результати можуть відрізнятися, якщо вони працювали на різних масивах.

Машина 1,86 - це повітряне середовище Macbook із SSD. Інший mac - це iMac з нормальним жорстким диском (я думаю, це 7200 об / хв). Машина Windows також має жорсткий диск 7200 об / хв.

У цьому тесті оптимальне число було рівним кількості ядер у машині.

Я знаю, що це питання досить старе, але все розвивалося з 2009 року.

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

У процесорах Intel кількість потоків визначається Hyperthreading, який складає всього 2 (якщо вони доступні). Але Hyperthreading скорочує час виконання на два, навіть якщо не використовується 2 нитки! (тобто 1 конвеєр, що ділиться між двома процесами - це добре, коли у вас більше процесів, не так добре інакше. Більше ядер, безумовно, краще!)

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

"Немає контекстної комутації", очевидно, не відповідає дійсності, якщо ви працюєте зі стандартною операційною системою, яка буде робити контекстну комутацію для всіляких інших речей поза вашим контролем. Але це головна ідея. Деякі ОС дозволяють виділити процесори, щоб лише ваша програма мала доступ / використання згаданого процесора!

З мого власного досвіду, якщо у вас багато вводу / виводу, корисні кілька потоків. Якщо у вас дуже велика робота з пам'яттю (читання джерела 1, читання джерела 2, швидке обчислення, запис), то більше тем не допоможе. Знову ж таки, це залежить від того, скільки даних ви читаєте / записуєте одночасно (тобто якщо ви використовуєте SSE 4.2 і читаєте значення 256 біт, що зупиняє всі потоки на їхньому кроці ... іншими словами, 1 потік, ймовірно, набагато простіше втілити в життя і Мабуть, майже настільки ж швидким, якщо насправді не швидшим. Це залежатиме від вашої архітектури процесів та пам'яті, деякі просунуті сервери управляють окремими діапазонами пам’яті для окремих ядер, тому окремі потоки стануть швидшими, припускаючи, що ваші дані належним чином подані ... ось чому, на деяких архітектури, 4 процеси будуть працювати швидше, ніж 1 процес з 4 потоками.)

Фактична ефективність залежатиме від того, наскільки добровільно вийде кожен потік. Наприклад, якщо потоки взагалі НЕ мають вводу / виводу і не використовують системних служб (тобто вони на 100% пов'язані з процесором), оптимальним є 1 потік на ядро. Якщо потоки роблять все, що вимагає очікування, тоді вам доведеться поекспериментувати, щоб визначити оптимальну кількість потоків. 4000 потоків мали б значне планування накладних витрат, тому, ймовірно, це теж не оптимально.

Відповідь залежить від складності алгоритмів, які використовуються в програмі. Я придумав метод обчислення оптимальної кількості ниток, зробивши два вимірювання часу обробки Tn і Tm для двох довільних кількості ниток 'n' і 'm'. Для лінійних алгоритмів оптимальною кількістю потоків буде N = sqrt ((m n (Tm * (n-1) - Tn * (m-1))) / (n Tn-m Tm)).

Прочитайте, будь ласка, мою статтю щодо розрахунків оптимальної кількості для різних алгоритмів: pavelkazenin.wordpress.com

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

З Вікіпедії :

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

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

Якщо питання передбачає слабке масштабування, відповіді @ Гонсало достатньо. Однак якщо питання передбачає сильне масштабування, є ще щось додати. При сильному масштабуванні ви припускаєте фіксований розмір робочого навантаження, тому при збільшенні кількості потоків розмір даних, над якими потрібно працювати кожному потоку, зменшується. На сучасних процесорах доступ до пам’яті дорогий і бажано підтримувати локальність, зберігаючи дані в кешах. Отже, ймовірна оптимальна кількість потоків може бути знайдена, коли набір даних кожного потоку вміщується в кеш ядра кожного я (я не збираюся детально обговорювати, чи це кеш-пам'ять системи L1 / L2 / L3 системи).

Це справедливо навіть тоді, коли кількість ниток перевищує кількість ядер. Наприклад, припустимо, що в програмі працює 8 довільних одиниць (або AU), які будуть виконані на 4-х основній машині.

Випадок 1: запустіть чотири нитки, де кожна нитка повинна заповнити 2AU. Кожен потік займає 10 секунд ( з великою кількістю пропусків кешу ). З чотирма ядрами загальна кількість часу становитиме 10 s (10s * 4 потоки / 4 ядра).

Випадок 2: запустіть з восьми ниток, де кожна нитка повинна заповнити 1AU. Кожен потік займає лише 2s (замість 5s через зменшену кількість пропусків кешу ). З чотирма ядрами загальна кількість часу складе 4s (2s * 8 потоків / 4 ядра).

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

4000 ниток за один раз досить великі.

Відповідь - так і ні. Якщо ви робите велику кількість блокувань вводу-виводу в кожному потоці, то так, ви можете показати значні прискорення роботи, мабуть, до 3 або 4 потоків на логічне ядро.

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

Орієнтир.

Я б почав збільшувати кількість потоків для програми, починаючи з 1, а потім переходити до чогось типу 100, запускати три-п’ять випробувань для кожної кількості потоків і будувати собі графік швидкості роботи проти кількості потоків .

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

Ви не можете знати, поки не тестуєте.

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

Ви можете використовувати man сторінку про команду 'ps'.

man ps

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

1. ps -aux| wc -l
2. ps -eLf | wc -l

Обчислення кількості користувальницького процесу:

1. ps --User root | wc -l

Також ви можете використовувати "htop" [Довідник] :

Встановлення на Ubuntu або Debian:

sudo apt-get install htop

Встановлення на Redhat або CentOS:

yum install htop
dnf install htop      [On Fedora 22+ releases]

Якщо ви хочете скласти htop з вихідного коду, ви знайдете його тут .

Ідеал - 1 нитка на серцевину, поки жодна з ниток не блокується.

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

Одним із прикладів безлічі потоків ("пул потоків") по відношенню до одного на ядро ​​є використання веб-сервера в Linux або Windows.

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

У Windows сервер буде реалізований за допомогою портів завершення вводу-виводу - IOCP, що зробить подія програми: якщо введення / виведення завершиться, ОС запустить резервний потік для його обробки. Коли обробка завершена (як правило, з іншою операцією вводу-виводу, як у парі-відповіді на запит), потік повертається до порту (черги) IOCP, щоб чекати наступного завершення.

Якщо жодне введення-виведення не завершено, обробка не проводиться і жодна нитка не запускається.

Дійсно, Microsoft рекомендує не більше одного потоку на ядро ​​в реалізаціях IOCP. Будь-який I / O може бути приєднаний до механізму IOCP. МОК також може бути розміщений заявкою, якщо це необхідно.

Якщо говорити з точки зору обчислень та пам'яті, пов'язаної з пам'яттю (наукові обчислення), 4000 ниток зроблять роботу програми дуже повільною. Частина проблеми - це дуже великі витрати на комутацію контексту і, швидше за все, дуже погана локальність пам'яті.

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

Сподіваюся, це має сенс, Перевірте використання процесора та пам'яті та поставте деяке порогове значення. Якщо значення порогового значення перекреслено, не дозволяйте створювати новий потік ще дозволяти ...