Наскільки важлива багатопотокова редакція в сучасній галузі програмного забезпечення? [зачинено]

Я маю майже 3-річний досвід написання веб-додатків на Java за допомогою MVC фреймворків (як-от стійки). Я ніколи не писав багатопотокового коду до цих пір, хоча написав код для великих торгових мереж.

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

Це надзвичайно важливо.

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

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

• Зараз комп’ютери мають мережеву мережу, а сучасні програми розраховують на можливість отримання багатої інформації з різних джерел.

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

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

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

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

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

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

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

Нитки - це лише одна модель та схема реалізації для реалізації concurrentпрограм.

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

Я отримую кілька запитань щодо багатопотокової роботи під час інтерв'ю ...

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

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

Як мінімум, слід розуміти проблеми, пов'язані з одночасністю.

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

Здається, ви вже пишете багатопотоковий код.

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

Тому я б сказав, що важливо знати хоча б основи.

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

Коротка відповідь: Дуже.

Більш довга відповідь: Електронні комп'ютери (на основі транзисторів) швидко наближаються до фізичних меж технології. Ставати все важче і важче вичавити більше годин з кожного ядра, керуючи виробленням тепла та квантовими ефектами мікроскопічних схем (контурні контури вже розміщені так близько один до одного на сучасних мікросхемах, що ефект під назвою "квантове тунелювання" може зробити електрон "перестрибувати колії" з одного кола в інше, не потребуючи належних умов для традиційної електричної дуги); Таким чином, практично всі виробники чіпів зосереджуються на тому, щоб кожен годинник міг зробити більше, вкладаючи більше "одиниць виконання" у кожен процесор. Тоді замість того, щоб комп'ютер робив лише одну річ за годинник, він може робити 2, 4 або навіть 8. Intel має "HyperThreading", який в основному розбиває одне ядро ​​ЦП на два логічні процесори (з деякими обмеженнями). Практично всі виробники кладуть щонайменше два окремих процесорних ядра в один процесорний чіп, а поточний золотий стандарт для настільних процесорів - чотири ядра на мікросхемі. Вісім можливий, коли використовуються два мікросхеми процесора, є серверні материнські плати, призначені для «чотирьохядерних» процесорів (16 ЄС та додатково HT), а наступне покоління процесорів, ймовірно, матиме шість чи вісім на чіп.

Підсумок всього цього полягає в тому, що, щоб повною мірою скористатися тим, як комп’ютери набирають обчислювальну потужність, ви повинні мати можливість дозволити комп'ютеру "розділити і завоювати" вашу програму. Керовані мови мають принаймні потік GC, який обробляє управління пам'яттю окремо від вашої програми. Деякі також мають "перехідні" потоки, які обробляють інтероп COM / OLE (стільки для захисту керованої "пісочниці", скільки для продуктивності). Крім цього, вам дійсно потрібно почати думати про те, як ваша програма може робити кілька речей одночасно, і архітектуру вашої програми з функціями, розробленими для того, щоб дозволити асинхронному обробці частин програми. Користувачі Windows та Windows практично очікують, що програма виконуватиме довгі складні завдання у фонових потоках, які підтримують інтерфейс вашої програми (який працює в основному потоці програми) "чутливо" до циклу повідомлень Windows. Очевидно, що проблеми, які мають паралелізуючі рішення (як сортування), є природними кандидатами, але існує обмежена кількість типів проблем, які виграють від паралелізації.

Просто попередження про багатопоточність: Більше тем не означає кращої ефективності. Якщо не керувати ними належним чином, вони можуть сповільнити роботу системи. Актор Scala вдосконалює роботу нарізання Java та максимально використовує систему (згадував це як розробник Java).

EDIT: Ось кілька моментів, які слід пам’ятати про мінуси багатопотокової роботи:

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

Також це посилання може бути корисним приблизно таким же.

Це змусило мене замислитися, наскільки важливим є багатопотокове читання у поточному галузевому сценарії?

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

1. Ефективність пам’яті (наприклад: місце відліку).
2. Алгоритмічний
3. Багатопотоковість
4. SIMD
5. Інші оптимізації (статичні підказки прогнозування гілок, наприклад)

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

Ефективність пам'яті

Більшість може бути здивована моїм вибором ефективності пам'яті над алгоритмічною. Це тому, що ефективність пам’яті взаємодіє з усіма 4 іншими пунктами цього списку, і це тому, що її врахування дуже часто стосується категорії «дизайн», а не категорії «впровадження». Тут, мабуть, є трохи проблеми з куркою або яйцями, оскільки розуміння ефективності пам'яті часто вимагає врахування всіх 4 елементів у списку, тоді як усі 4 інші елементи також потребують врахування ефективності пам'яті. І все ж це в основі всього.

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

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

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

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

Алгоритмічний

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

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

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

Нарешті, алгоритми, як правило, більше входять до категорії «впровадження», ніж ефективність пам’яті. Їх часто простіше вдосконалити заднім числом навіть за допомогою неоптимального алгоритму, що використовується спочатку. Наприклад, низький алгоритм обробки зображень часто просто реалізується в одному локальному місці в кодовій базі. Пізніше його можна замінити на краще. Однак якщо всі алгоритми обробки зображень прив’язані до Pixelінтерфейсу, який має неоптимальне представлення пам'яті, але єдиний спосіб виправити це - змінити спосіб представлення кількох пікселів (а не один), то ми часто SOL і доведеться повністю переписати кодову базу на anImageінтерфейс. Те ж саме стосується заміни алгоритму сортування - зазвичай це деталізація про реалізацію, тоді як повне зміна базового подання даних про сортування або способу передачі через повідомлення може потребувати переробки інтерфейсів.

Багатопотоковість

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

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

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

SIMD

SIMD також трохи незручно, оскільки реєстри насправді стають все ширшими, планують ще ширше. Спочатку ми бачили 64-бітні регістри MMX, а потім 128-бітні регістри XMM, здатні паралельно виконувати 4 SPFP-операції. Тепер ми бачимо 256-бітні регістри YMM, здатні 8 паралельно. І вже є плани на 512-бітні регістри, які дозволять паралельно 16.

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

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

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

Інші оптимізації

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

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

Назад до багатопотокової роботи

Так чи інакше, наскільки важливою є багатопоточність з контексту виступу? На моїй чотирьохядерній машині він в ідеалі може робити речі приблизно в 5 разів швидше (що я можу отримати із гіперточенням). Було б значно важливіше моєму колезі, який має 32 ядра. І це стане все більш важливим у наступні роки.

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

Багатопотоковість поза продуктивністю

Багатопоточність не завжди стосується чистої продуктивності в прямому сенсі. Іноді його використовують для збалансування навантаження навіть за можливих витрат пропускної здатності, щоб покращити чутливість до користувача або дозволити користувачеві робити багатозадачність, не чекаючи, коли все закінчиться (наприклад: продовжуйте перегляд під час завантаження файлу).

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

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

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

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

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

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

Історично люди мусили боротися, виконуючи багатопотокове програмування вручну. Їм доводилося безпосередньо працювати з усіма основними компонентами (нитками, семафорами, мутексами, замками тощо).

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

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

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

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

Моя машина має 8 ядер. У диспетчері завдань у мене працює 60 процесів. Деякі, як VS, використовують до 98 ниток. Outlook використовує 26. Я очікую, що більша частина моєї пам’яті - це стеки, що виділяються для кожного з цих простоїв.

Я особисто чекаю виходу 300-ядерного комп'ютера, щоб мені не довелося чекати, коли Outlook відповість. Звичайно, до цього часу Outlook використовуватиме 301 нитку.

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

Це важливо для дизайнерів фреймворків та мов, а також програмістів для бек-енд-систем - не стільки для розробників додатків. Розуміння деяких основних понять, таких як блокування та запис асинхронного коду, ймовірно, варто.