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

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

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

Якщо я напишу ту саму програму в Scala (яка використовує JVM), чи буде ця реалізація швидшою? Якщо так, то чому? Це через стиль письма? Якщо це через стилю письма, тепер, коли Java включає в себе лямбда - вираження, не міг я досягти тих же результатів з допомогою Java з лямбда? Або це швидше, тому що Скала складе речі по-іншому?

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

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

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

TL; DR: Якщо рішення в Scala є більш ефективним при паралельній обробці, ніж одне в Java, це не через спосіб компіляції або запуску коду через JVM, а замість того, що рішення Java поділяє стан змін, що змінюється між потоками, або спричиняючи умови перегонів, або додаючи накладні витрати синхронізації, щоб уникнути їх.

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

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

Як правило, функціональне програмування не передбачає швидших програм. Це полегшує паралельне та паралельне програмування. Для цього є два основні ключі:

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

Одним з відмінних прикладів пункту №2 є те, що в Хаскеллі ми чітко відрізняємо детермінований паралелізм від недетермінованої одночасності . Немає кращого пояснення, ніж цитувати чудову книгу Саймона Марлоу Паралельне та паралельне програмування в Хаскеллі (цитати з розділу 1 ):

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

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

На додаток до цього, Марлоу згадує також вимір детермінізму :

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

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

У Хаскеллі паралелізм та паралельність функціонують навколо цих понять. Зокрема, те, що інші мови об'єднуються в один набір функцій, Haskell розбивається на дві:

• Детерміновані особливості та бібліотеки для паралелізму .
• Недетерміновані функції та бібліотеки для одночасності .

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

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

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

Моя програма швидша, ніж якби я перейшов із звичайними багатопотоковими утилітами на основі блокування? Я дуже сумніваюся в цьому. Акуратна річ у моєму випадку отримала стільки ударів від такого маленького долара - мій код, мабуть, дуже неоптимальний, але, оскільки це так просто паралелізувати, я отримав велику швидкість роботи з набагато меншими зусиллями, ніж правильне профілювання та оптимізація, і немає ризику перегонів. І це, я б сказав, головний спосіб функціонального програмування дозволяє писати "швидші" програми.

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

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

Це робить паралелізм у Haskell багато часу дуже простим, і насправді ведуться зусилля, щоб зробити його автоматичним. Для простого коду можна навіть розділити паралелізм і логіку.

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

Подальше читання
Паралелізм у Хаскеллі (HaskellWiki)
Паралельне та багатоядерне програмування в паралельному та паралельному програмуванні "Хаскелл у реальному світі"
в Хаскелл Саймоном Марлоу