Ефективність чисто функціонального програмування

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

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

Згідно з Піппенджером [1996] , при порівнянні системи Lisp, яка є чисто функціональною (і має сувору семантику оцінювання, не лінується), та тією, яка може мутувати дані, алгоритм, написаний для нечистого Lisp, який працює в O ( n ), може бути переведений до алгоритму в чистому Lisp, який працює за O ( n log n ) часу (на основі роботи Бен-Амрама та Галіля [1992] про моделювання пам'яті з випадковим доступом за допомогою лише покажчиків). Pippenger також встановлює, що існують алгоритми, для яких це найкраще, що ви можете зробити; є проблеми, що є O ( n ) в системі нечистоти, які є Ω ( n log n ) в чистій системі.

У цьому документі слід зробити кілька застережень. Найбільш важливим є те, що він не стосується ледачих функціональних мов, таких як Haskell. Bird, Jones та De Moor [1997] демонструють, що проблема, побудована Піппенджером, може бути вирішена ледачою функціональною мовою за O ( n ) час, але вони не встановлюють (і наскільки я знаю, ні в кого немає), чи не лінива функціональна мова може вирішити всі проблеми за той самий асимптотичний час роботи, що і мова з мутацією.

Проблема, побудована Піппенджером, вимагає, щоб Ω ( n log n ) була спеціально побудована для досягнення цього результату, і не обов'язково є репрезентативною для практичних проблем у реальному світі. Існує кілька обмежень щодо проблеми, які є трохи несподіваними, але необхідними, щоб доказ працював; зокрема, проблема вимагає, щоб результати обчислювались в режимі он-лайн, не маючи доступу до майбутнього вводу, і що вхід складається з послідовності атомів з необмеженого набору можливих атомів, а не набору фіксованого розміру. А робота лише встановлює (нижню межу) результати для нечистого алгоритму лінійного часу роботи; для проблем, які потребують більшого часу роботи, можливо, додаткові O (log n) фактор, побачений в лінійній задачі, може бути здатний "поглинатися" в процесі додаткових операцій, необхідних для алгоритмів з більшим часом роботи. Бен-Амрам [1996] коротко досліджує ці роз'яснення та відкриті питання .

На практиці багато алгоритмів можуть бути реалізовані чистою функціональною мовою при тій же ефективності, що і в мові зі змінними структурами даних. Для кращого посилання на методики ефективного впровадження чисто функціональних структур даних див. « Крісті функціональні структури даних» Кріса Окасакі [Okasaki 1998] (що є розширеною версією його тези [Okasaki 1996] ).

Кожен, кому потрібно реалізувати алгоритми на суто функціональних структурах даних, повинен прочитати Окасакі. Ви завжди можете уповільнити O (log n ) уповільнення за одну операцію, імітуючи змінну пам'ять із врівноваженим бінарним деревом, але в багатьох випадках ви можете зробити це значно краще, ніж це. тимчасові, які роблять амортизовану роботу поступово. Суто функціональні структури даних можуть бути складно працювати і аналізувати, але вони надають багато переваг, таких як референсна прозорість, яка корисна в оптимізації компілятора, паралельних і розподілених обчислень, а також у реалізації таких функцій, як версія, скасування та відкат.

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

Список літератури

• Бен-Амрам, Амір та Галіль, Zvi 1992. " Журнал про покажчики проти адрес" , 39 (3), с. 617-648, липень 1992 р.
• Бен-Амрам, Амір 1996 р. "Примітки про порівняння Піппенгера чистого і нечистого Лиса " Неопублікований рукопис, DIKU, Копенгагенський університет, Данія
• Bird, Richard, Jones, Geraint, and De Moor, Oege 1997. "Більше поспіху, менша швидкість: лінива проти нетерплячої оцінки" Журнал функціонального програмування 7, 5 с. 541–547, вересень 1997 р.
• Окасакі, Кріс 1996. Кандидатська дисертація "Чисто функціональні структури даних" , університет Карнегі Меллон
• Окасакі, Кріс 1998. "Чисто функціональні структури даних" Кембриджський університетський прес, Кембридж, Великобританія
• Pippenger, Nicholas 1996. Симпозіум ACM " Принципи мови мов програмування", сторінки 104–109, січень 1996 року

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

• Вищезгадана спілка-знахідка
• Хеш-столи
• Масиви
• Деякі графічні алгоритми
• ...

Однак ми припускаємо, що в "імперативних" мовах доступ до пам'яті є O (1), тоді як теоретично це не може бути настільки асимптотично (тобто для необмежених розмірів проблем), а доступ до пам'яті у величезному наборі даних завжди O (log n) , яку можна імітувати функціональною мовою.

Крім того, ми повинні пам’ятати, що фактично всі сучасні функціональні мови надають змінні дані, а Haskell навіть надає їх, не приносячи шкоди чистоті (монада ST).

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

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

Редагувати:

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

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

Якщо строга функція має складність O (f (n)) у строгій мові, то вона має складність O (f (n)) і в ледачій мові. Чому турбуватися? :)

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

Ескіз доказування: Враховуючи фіксовану верхню межу використання пам'яті, ви повинні мати змогу написати віртуальну машину, яка виконує імперативні набори інструкцій з такою ж асимптотичною складністю, як якщо б ви насправді виконували на цій машині. Це так, тому що ви можете керувати пам'яттю, що змінюється, як стійку структуру даних, даючи O (log (n)) читання та запис, але з фіксованою верхньою межею використання пам'яті, ви можете мати фіксований об'єм пам'яті, викликаючи їх розпад до O (1). Таким чином, функціональна реалізація може бути імперативною версією, що працює у функціональній реалізації VM, і тому вони повинні мати однакову асимптотичну складність.

Я б запропонував почитати про ефективність Haskell , а потім поглянути на ефективність ігор в іграх для функціональних мов порівняно з процедурними / OO.