Найшвидша функціональна мова

Я нещодавно заглиблювався у функціональне програмування, особливо Haskell та F #, тим більше. Після деякого гуглювання навколо я не зміг знайти порівняльне порівняння більш помітних функціональних мов (Scala, F # тощо).

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

— Фарук
джерело

Мови не швидкі чи повільні, реалізація є.

— starblue

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

— igouy

@starblue: Це дуже глібова відповідь, і не дуже корисна. Хоча, безумовно, можливо створити дві реалізації однієї і тієї ж мови, одна з яких повільніше, ніж інша, але спосіб, який ви її помістили, означає, що не існує деталей мовного дизайну, які обов'язково потребують певної неефективності в застосуванні інших мов, їх дизайн, не вимагають. І це просто неправда. (Особливо в цій конкретній темі; функціональні мови для них горезвісні!)

— Мейсон Уілер

@igouy "Мовні реалізації не швидкі чи повільні" Це неправда. CPythonvs PyPyшвидко приходить в голову.

— NlightNFotis

@NlightNFotis - Скільки секунд займає CPython? Скільки секунд займає PyPy? Мовна реалізація не є швидкою чи повільною. Скільки секунд займає ця програма з CPython?

— igouy

Відповіді:

Відповідно до гри « Великі бенчмаркі» , ОВС швидше за решту з Haskell, Scala та одним із варіантів Common Lisp у грубій краватці за швидкістю, близькою за цю. Після цього Ocaml і F # знаходяться приблизно в одній і тій же категорії швидкості, коли Ракетка і Клуджуре відстають ...

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

— Світовий інженер
джерело

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

— Farouk

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

— DPM

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

— igouy

На веб-сайті Scala зазначено, що Scala інтегрує об'єктно-орієнтовані та функціональні функції. Ви перевірили, що програми Scala записані як функціональні програми, а не об'єктно-орієнтовані програми?

— igouy

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

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

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

Розглянемо, наприклад, Java. Припустимо, я пишу однопотоковий орієнтир, використовуючи виключно мовні функції класичної (Java 1.0) Java. Якщо я компілюю і запускаю за допомогою JDK 1.0, я отримаю низьку продуктивність ('оскільки у JDK 1.0 не було вбудованого компілятора коду). Якщо я перейду від JDK 1.1 до ... JDK 1.7, я, швидше за все, отримаю прогресивно кращі результати. Але це не пов'язано зі змінами мови Java ... тому що мій орієнтир використовує той самий підмножина мови. Скоріше, прискорення відбувається за рахунок вдосконалення компіляторів, системи виконання та / або впровадження бібліотек класів. Це все питання щодо впровадження .

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

— Стівен С
джерело

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

— igouy

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

— igouy

@igouy - це правда. Але багато людей не роблять цього, про що свідчить багато старих веб-сайтів, що заявляють, що "Java повільна. На жаль, цю дурницю читали буквально ціле покоління програмістів ... і це значно пошкодило репутацію Java. тому я зазначаю ТУТ.

— Стівен C

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

— igouy

@igouy - 1) Ви вільні сказати, що вам завгодно. Але це не робить тебе правильним. 2) Розглянемо випадок, коли єдиною реалізацією мови є лайно. Ми це орієнтуємо. Потім ми оновлюємо реалізацію, орієнтуємо її, і продуктивність значно покращилася. Чи означає це, що продуктивність мови покращилась? Як це має сенс ... враховуючи, що мова НЕ змінилася !!!

— Стівен С

Якщо ви дивитесь на мови лише на швидкості виконання, вам не вистачає деяких основних моментів. Швидкість - це гарна річ, але це не єдине.

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

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

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

— Захарій К
джерело