Багатопоточність: В чому сенс більше ниток, ніж ядер?

Я подумав, що сенс багатоядерного комп'ютера полягає в тому, що він може запускати кілька потоків одночасно. У такому випадку, якщо у вас чотириядерна машина, який сенс одночасно працювати більше 4-х потоків? Чи не просто вони б крали час (ресурси CPU) один у одного?

Відповідь обертається навколо мети потоку, а це паралелізм: запускати відразу кілька окремих ліній виконання. У «ідеальній» системі у вас би виконувалася одна нитка на одне ядро: ніяких переривань. Насправді це не так. Навіть якщо у вас є чотири ядра та чотири робочих нитки, ваш процес і потоки будуть постійно вимикатися для інших процесів і потоків. Якщо ви працюєте з будь-якою сучасною ОС, кожен процес має принаймні одну нитку, а багато хто більше. Всі ці процеси запускаються одразу. Напевно, у вас на машині зараз працює кілька сотень ниток. Ви ніколи не отримаєте ситуацію, коли нитка запускається, не встигнувши з неї вкрастись. (Ну, ви можете, якщо це працює в режимі реального часу, якщо ви використовуєте ОС у режимі реального часу або навіть у Windows, використовуйте пріоритет потоку в реальному часі. Але це рідко.)

Відповідно до цього, відповідь: Так, більше чотирьох потоків на справжній чотирьохядерній машині може створити ситуацію, коли вони "крадуть час один у одного", але лише якщо кожен окремий потік потребує 100% процесора . Якщо потік не працює на 100% (як може не бути потоку в інтерфейсі користувача, або потік виконує невелику кількість роботи або чекає чогось іншого), то інший потік, який планується, насправді є хорошою ситуацією.

Це насправді складніше, ніж це:

• Що робити, якщо у вас є п’ять розрядів роботи, які потрібно виконати відразу? Більше сенсу запустити їх усі одразу, ніж запустити їх чотири, а потім запустити п'яту.

• Рідко для потоку справді потрібен 100% процесор. Наприклад, в момент використання дискового або мережевого вводу-виводу, можливо, потенційно витратити час на очікування, не роблячи нічого корисного. Це дуже поширена ситуація.

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

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

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

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

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

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

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

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

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

Розглянемо нитку, якій потрібно зчитувати дані з жорсткого диска. У 2014 році типове ядро ​​процесора працює на частоті 2,5 ГГц і може виконувати 4 інструкції за цикл. З часом циклу 0,4 нс процесор може виконувати 10 інструкцій за наносекунд. Якщо типовий час механічного жорсткого диска становить близько 10 мілісекунд, процесор здатний виконати 100 мільйонів інструкцій за час, необхідний для зчитування значення з жорсткого диска. Можуть бути значні поліпшення продуктивності на жорстких дисках з невеликим кешем (4 МБ буфера) та гібридних накопичувачах з кількома ГБ пам’яті, оскільки затримка даних для послідовного читання або зчитування з гібридного розділу може бути на кілька порядків швидшою.

Ядро процесора може перемикатися між потоками (вартість призупинення та відновлення потоку становить близько 100 тактових циклів), тоді як перший потік чекає на високий час затримки (що-небудь дорожче, ніж регістри (1 тактова частота) та оперативна пам'ять (5 наносекунд)) диск / вхід / вивід, доступ до мережі (затримка 250 мс), зчитування даних з компакт-диска або повільної шини або виклик бази даних. Якщо мати більше ниток, ніж ядер, це означає, що корисна робота може бути виконана, поки задачі з високою затримкою вирішені.

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

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

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

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

Більшість відповідей вище стосуються продуктивності та одночасної роботи. Я збираюся підійти до цього з іншого кута.

Візьмемо випадок, скажімо, спрощеної програми емуляції терміналу. Ви повинні виконати такі дії:

• стежте за вхідними символами з віддаленої системи та показуйте їх
• стежте за предметами, які надходять з клавіатури, і надсилайте їх у віддалену систему

(Реальні емулятори терміналів роблять більше, включаючи потенційно повторювані речі, які ви вводите на дисплей, але зараз ми передамо це.)

Тепер цикл для читання з віддаленого просто, відповідно до наступного псевдокоду:

while get-character-from-remote:
    print-to-screen character

Цикл моніторингу клавіатури та надсилання також простий:

while get-character-from-keyboard:
    send-to-remote character

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

loop:
    check-for-remote-character
    if remote-character-is-ready:
        print-to-screen character
    check-for-keyboard-entry
    if keyboard-is-ready:
        send-to-remote character

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

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

То чому б ви не використовували різьблення?

Добре, якщо ваші завдання пов'язані з процесором замість введення-виводу, нанизування фактично уповільнює вашу систему. Продуктивність постраждає. Дуже багато, у багатьох випадках. ("Зміна" - це поширена проблема, якщо ви скидаєте занадто багато потоків, пов'язаних з процесором. Ви закінчуєте витрачати більше часу на зміну активних потоків, ніж ви самі працюєте з вмістом ниток.) ​​Крім того, одна з причин, за якими логіка вище настільки простий, що я дуже свідомо вибрав спрощений (і нереальний) приклад. Якщо ви хотіли повторити те, що було набрано на екрані, тоді у вас з’явився новий світ боляче, коли ви впроваджуєте блокування спільних ресурсів. Що стосується лише одного спільного ресурсу, це не стільки проблема, але це стає все більшою і більшою проблемою, оскільки у вас є більше ресурсів для спільного використання.

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

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

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

Також дивіться це пов’язане питання: Практичне використання для потоків

Я категорично не згоден із твердженням @ kyoryu, що ідеальне число - це один потік на процесор.

Подумайте про це так: чому ми маємо багатообробні операційні системи? Більшість комп'ютерних історій майже всі комп'ютери мали один процесор. Ще з 1960-х років усі "справжні" комп'ютери мали багатопроцесорні (також багатозадачні) операційні системи.

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

дозволимо відкласти аргументи про те, чи були версії Windows перед NT багатозадачними. Відтоді кожна реальна ОС мала багатозадачність. Деякі не піддають це користувачам, але це все одно є, роблячи такі речі, як прослуховування радіо мобільного телефону, розмова з чіпом GPS, прийняття вводу миші тощо.

Нитки - це лише завдання, які трохи ефективніші. Немає принципової різниці між завданням, процесом та потоком.

Процесор - це страшна річ, тому готові використовувати багато речей, коли можна.

Я погоджусь, що для більшості процедурних мов, C, C ++, Java тощо, написання належного безпечного коду для потоків - це велика робота. Сьогодні на ринку є 6 основних процесорів, а 16 основних процесорів недалеко, я очікую, що люди відійдуть від цих старих мов, оскільки багатопотоковість стає все більш важливою вимогою.

Незгода з @kyoryu - це лише ІМХО, інше - факт.

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

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

Багато потоків будуть сплячими, очікуючи введення користувача, вводу / виводу та інших подій.

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

Процесор або процесор - це фізичний чіп, який підключається до системи. Процесор може мати декілька ядер (ядро - це частина мікросхеми, яка здатна виконувати інструкції). Ядро може з'являтися в операційній системі як кілька віртуальних процесорів, якщо воно здатне одночасно виконувати кілька потоків (потік - це єдина послідовність інструкцій).

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

Кожен процес має окремий адресний простір та стек. Процес може містити кілька потоків, кожна з яких може одночасно виконувати інструкції. Усі потоки в процесі мають однаковий адресний простір, але кожен потік матиме свій стек.

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

Ідеальне використання ниток - це дійсно одне на ядро.

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

Також типові мови програмування дещо ускладнюють використання 1 потоку на процесор. Мови, розроблені навколо паралельності (наприклад, Erlang), можуть полегшити використання зайвих ниток.

У тому випадку, як розроблені деякі API, у вас немає іншого вибору, як запустити їх в окремий потік (що завгодно з блокуючими операціями). Прикладом можуть бути бібліотеки HTTP Python (AFAIK).

Зазвичай це не є великою проблемою (якщо це проблема, ОС або API повинні постачатися з альтернативним асинхронним режимом роботи, тобто:) select(2), оскільки це, ймовірно, означає, що нитка буде спати під час очікування I / O завершення. З іншого боку, якщо щось робить важкі обчислення, вам доведеться помістити його в окрему нитку, ніж, скажімо, нитку GUI (якщо ви не любите мультиплексування вручну).

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

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

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

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

У відповідь на ваше друге запитання: більшість процесів / потоків не пов'язані з процесором (тобто не працюють постійно і безперебійно), а натомість зупиняються і чекають часто, коли введення-виведення закінчиться. Під час цього очікування інші процеси / потоки можуть працювати без "крадіжки" з коду очікування (навіть на одній основній машині).

Потік - це абстракція, яка дозволяє Вам писати код так просто, як послідовність операцій, не знаючи про те, що код виконується переплетеним з іншим кодом, або припаркований в очікуванні IO, або (можливо, дещо більш обізнаний) в очікуванні інших потоків події чи повідомлення.

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

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

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