Що являє собою належне використання потоків у програмуванні?

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

vb.net ide uses about 25 thread when not debugging
System uses about 100
chrome uses about 19
Avira uses more than about 50

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

ви повинні використовувати лише один потік на один процесор,

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

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

Для веб-сервера може бути доцільним запустити потік для кожного вхідного з'єднання (хоча для дуже сильно завантажених серверів є кращі способи).

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

Порада з однією ниткою на основу застосовується, коли метою є швидкість шляхом паралельного виконання.

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

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

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

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

Правило для ниток полягає в тому, що ви хочете, щоб принаймні один "активний" (здатний негайно виконувати його команди за вказаний час процесора) робочий потік для кожного "блоку виконання", доступного на комп'ютері. "Одиниця виконання" - це один логічний процесор інструкцій, тому чотириядерний чотириядерний сервер Xeon з гіпертоком має 32 ЄС (4 мікросхеми, 4 ядра на мікросхемі, кожна з гіперпотоків). У вашому середньому Core i7 було б 8.

Один потік в ЄС - це найповніше використання потужності процесора за умови, що потоки завжди будуть у робочому стані; це майже ніколи не відбувається, оскільки потокам потрібен доступ до некешованої пам’яті, жорсткого диска, мережевих портів і т. д., яких вони повинні чекати, і для цього не потрібна активна увага процесора. Таким чином, ви можете додатково підвищити загальну ефективність за допомогою більшої кількості потоків, що стоять у черзі, та йдуть вперед. Це дійсно доходить; коли CPU перемикає потік, він повинен кешувати регістри потоку, покажчик виконання та іншу інформацію про стан, яка зазвичай зберігається в найсумісніших роботах ЄС і дуже швидко отримує доступ, дозволяючи іншим членам ЄС у цьому чіпі CPU забрати його. Також потрібні потоки в ОС, щоб вирішити, на який потік слід перейти. Нарешті, коли ЄС перемикає нитки, він втрачає підвищення продуктивності конвеєрних труб, якими користується більшість процесорних архітектур; перед перемиканням ниток він повинен промивати трубопровід. Але оскільки все це в середньому займає набагато менше часу, ніж просто чекати, коли жорсткий диск або навіть оперативна пам’ять повернуться з інформацією, це вартує витрат.

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

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

Ви повинні використовувати одну нитку для:

Кожен процесор, який потрібно тримати зайнятий.

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

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

Кілька додаткових для захисту від несподіваного блокування, наприклад, помилок сторінки.

Кілька додаткових для захисту від очікуваного блокування, яке не варто оптимізувати, наприклад, у некритичному коді. (Наприклад, якщо вам дуже рідко потрібно робити запит DNS, напевно, не варто докладати зусиль, щоб виконувати запити DNS асинхронно. Просто створіть кілька додаткових потоків і полегшіть ваше життя.)

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

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

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

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

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