Спробував запустити програму X, використовуючи 8 ниток, і вона закінчилася за n хвилин .
Спробував запустити ту саму програму, використовуючи 50 ниток, і вона закінчилася за n * 10 хвилин .
Чому це відбувається і як я можу отримати оптимальну кількість потоків, які я можу використовувати?
Відповіді:
Це складне питання, яке ви задаєте. Не знаючи більше про природу ваших ниток, важко сказати. Деякі елементи, які слід враховувати при діагностиці продуктивності системи:
Чи процес / нитка
Усі ці три ресурси обмежені, і будь-який може обмежити продуктивність системи. Потрібно подивитися, на що (може бути 2 або 3 разом) ваша конкретна ситуація споживає.
Ви можете використовувати ntopі iostatта vmstatдіагностувати, що відбувається.
"Чому це відбувається?" легко відповісти. Уявіть, що у вас є коридор, в який ви можете помістити чотирьох людей вниз, поруч. Ви хочете перенести все сміття в один кінець, в інший кінець. Найбільш ефективна кількість людей - 4.
Якщо у вас є 1-3 людини, то ви пропустите використання коридору. Якщо у вас є 5 і більше людей, то принаймні один з цих людей весь час затримується в черзі за іншою людиною. Якщо все більше людей просто засмічує коридор, це не прискорює активність.
Таким чином, ви хочете мати стільки людей, скільки вам вміститься, не викликаючи черги. Чому у вас черга (або вузькі місця) залежить від питань у відповіді slm.
4це найкраще число.
Загальна рекомендація - n + 1 потоків, n - кількість наявних процесорних ядер. Таким чином, n потоків можуть працювати центральним процесором, поки 1 потік чекає дискового вводу / виводу. Маючи меншу кількість потоків, не вдасться повністю використовувати ресурс процесора (в якийсь момент завжди буде введення-виведення чекати), якщо більше потоків спричинить потоки, що борються за ресурс процесора.
Нитки виходять не вільними, але з накладними контекстними комутаторами, і - якщо дані потрібно обмінюватися між потоками, що зазвичай буває, - різними механізмами блокування. Це варто лише тоді, коли у вас є більше виділених процесорних ядер для запуску коду. У одноядерному процесорі звичайний процес (без окремих потоків), як правило, швидше, ніж будь-яка виконана нитка. Нитки не магічно змушують ваш процесор швидше працювати, це просто означає додаткову роботу.
Як інші відзначали, ( ОДС відповідь , EightBitTony відповідь ) це складне питання , і тим більше, так як ви не описати те , що ви thred робити і як вони це роблять.
Але остаточне введення більше тем може погіршити ситуацію.
У галузі паралельних обчислень існує закон Амдала, який може бути застосовним (або не може, не, але ви не описуєте деталі вашої проблеми, так що ....) і можуть дати загальне уявлення про цей клас проблем.
Суть закону Амдала полягає в тому, що в будь-якій програмі (в будь-якому алгоритмі) завжди є відсоток, який неможливо виконати паралельно ( послідовна частина ), і є ще один відсоток, який можна запустити паралельно ( паралельна частина ) [Очевидно ці дві порції складають до 100%].
Ця частина може бути виражена у відсотках від часу виконання. Наприклад, може бути 25% часу, витраченого на строго послідовні операції, а решта 75% часу витрачається на роботу, яка може виконуватися паралельно.
(Зображення з Вікіпедії )
Закон Amdahl передбачає, що для кожної заданої паралельної частини (наприклад, 75%) програми ви можете прискорити виконання лише поки що (наприклад, не більше 4 разів), навіть якщо для роботи використовуєте все більше процесорів.
Як правило, чим більше ви програмуєте, що не можете перетворити паралельне виконання, тим менше ви можете отримати, використовуючи більше виконавчих одиниць (процесорів).
Враховуючи, що ви використовуєте потоки (а не фізичні процесори), ситуація може бути навіть гіршою, ніж ця. Пам’ятайте, що потоки можуть бути оброблені (залежно від реалізації та наявного обладнання, наприклад, процесорів / ядер), обмінюючись тим самим фізичним процесором / ядром (це форма багатозадачності, як зазначено в іншій відповіді).
Це теоретичне прогнозування (приблизно щодо часу процесора) не вважає інших практичних вузькими місцями
що може бути обмежуючим фактором у практичних програмах.
Винуватцем тут має стати "КОНТЕКСТНЕ ВИМКНЕННЯ". Це процес збереження стану поточного потоку для початку виконання іншого потоку. Якщо ряд потоків мають однаковий пріоритет, їх потрібно перемикати, поки вони не закінчать виконання.
У вашому випадку, коли є 50 потоків, відбувається багато комутації контексту порівняно з просто запущеними 10 потоками.
Цього разу накладні витрати через зміну контексту - це те, що робить вашу програму повільною
ps ax | wc -lповідомляється про 225 процесів, і він аж ніяк не сильно завантажений). Я схильний піти з здогадками @ EightBitTony; недійсність кешу, ймовірно, є більшою проблемою, оскільки кожен раз, коли ви стираєте кеш, процесору доводиться чекати еони для коду та даних з ОЗУ.
Щоб виправити метафору EightBitTony:
"Чому це відбувається?" легко відповісти. Уявіть, у вас є два басейни, один повний і один порожній. Ви хочете перенести всю воду з одного на інший і мати 4 відра . Найбільш ефективна кількість людей - 4.
Якщо у вас є 1-3 людини, то ви не вистачаєте на використання відра . Якщо у вас є 5 і більше людей, то принаймні один з цих людей застрягає, чекаючи відра . Додавання все більшої кількості людей ... не прискорює діяльність.
Тож ви хочете мати стільки людей, скільки може одночасно виконати певну роботу (використовувати відро) .
Людина тут - це нитка, і відро являє собою який би ресурс виконання був вузьким місцем. Додавання більше тем не допоможе, якщо вони нічого не можуть зробити. Крім того, ми повинні підкреслити, що передача відра від однієї людини до іншої, як правило, повільніше, ніж одна людина, яка просто переносить відро на однаковій відстані. Тобто, два потоки, що обертаються на сердечнику, зазвичай виконують менше роботи, ніж одна нитка, яка працює вдвічі довше: це через додаткову роботу, виконану для перемикання між двома потоками.
Незалежно від того, чи обмежуючий ресурс виконання (bucket) - це процесор, або серцевина, або гіперпотоковий конвеєр інструкцій для ваших цілей, залежить від того, яка частина архітектури є вашим обмежуючим фактором. Зверніть увагу також, що ми припускаємо, що потоки повністю незалежні. Це лише в тому випадку, якщо вони не поділяють даних (і уникають будь-яких зіткнень кешу).
Як підказали кілька людей, для вводу / виводу обмежуючим ресурсом може бути кількість корисно введених операцій вводу / виводу: це може залежати від цілого ряду апаратних та ядерних факторів, але може бути набагато більшим, ніж кількість сердечники. Тут контекстний комутатор, який настільки дорогий порівняно з кодом, який пов'язаний з виконанням, є досить дешевим порівняно з кодом, пов'язаним з введенням / виводу. На жаль, я думаю, що метафора повністю вийде з-під контролю, якщо я спробую виправдати це відрами.
Зауважте, що оптимальне поведінка з пов'язаним кодом вводу / виводу, як правило, все ще має мати щонайменше один потік на трубопровід / ядро / процесор. Однак вам потрібно записати асинхронний або синхронний / не блокуючий код вводу / виводу, і порівняно невелике поліпшення продуктивності не завжди виправдає зайву складність.
PS. Моя проблема з оригінальною метафорою коридору - це настійно говорить про те, що ви маєте змогу мати 4 черги людей, 2 черги, що перевозять сміття, і 2, які повертаються, щоб зібрати більше. Після цього ви можете зробити кожну чергу майже до тих пір , як коридор, і додають люди зробили швидкість до алгоритму (ви в основному перетворили весь коридор в конвеєрній стрічці).
Насправді цей сценарій дуже схожий на стандартний опис взаємозв'язку між затримкою та розміром вікна в мережі TCP, тому він вискочив у мене.
Це досить просто і зрозуміло. Маючи більше потоків, ніж те, що підтримує ваш процесор, ви насправді серіалізуєте, а не паралелізуєте. Чим більше потоків у вас буде повільніше, тим вашою буде система. Ваші результати насправді є доказом цього явища.