Самый быстрый функциональный язык

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

Я знаю, что это не обязательно справедливо по отношению к некоторым языкам (Scala приходит на ум), учитывая, что они являются гибридами, но я просто хочу знать, какие из них превосходят какие по каким операциям и в целом.

— Фарук
источник

Языки не быстрые или медленные, реализации есть.

— Звездный синий

Языковые реализации не быстрые или медленные, программы запускаются с использованием этих языковых реализаций (по сравнению с некоторыми другими программами). Будьте благотворительны - когда кто-то говорит о том, что один язык программирования быстрее другого, очевидный способ, который имеет смысл, состоит в том, чтобы понять, что он говорит об определенных программах, выполняемых с использованием конкретных реализаций языка.

— igouy

@starblue: Это очень бойкий ответ, и не очень полезный. Хотя, безусловно, возможно создание двух реализаций одного и того же языка, одна из которых медленнее, чем другая, то, как вы это указываете, подразумевает, что не существует деталей дизайна языка, которые обязательно требуют определенных недостатков в реализации, что другие языки по своей дизайн, не требуют. И это просто неправда. (Особенно в этой конкретной теме; функциональные языки печально известны для них!)

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

@igouy "Реализация языка не быстрая или медленная" Это не так. CPythonпротив PyPyбыстро приходит в голову.

— NlightNFotis

@NlightNFotis - Сколько секунд занимает CPython? Сколько секунд занимает PyPy? Языковые реализации не являются быстрыми или медленными. Сколько секунд эта программа занимает с CPython?

— igouy

Ответы:

Согласно игре « Great Benchmarks Game» , ATS быстрее, чем остальные, с Haskell, Scala и одним из вариантов Common Lisp в жесткой схватке за скорость, близкую к этому. После этого Ocaml и F # находятся примерно в одной категории скорости, а Racket и Clojure отстают ...

Тем не менее, почти ничего из этого вообще ничего не значит. Это все вопрос проблемы, машины, компилятора, методов кодирования, а в некоторых случаях просто удачи. Вообще говоря, языки с прямым машинным кодированием, такие как Haskell, будут превосходить языки, скомпилированные в VM, такие как F #, и значительно превосходят чисто интерпретируемые языки. Также обычно статически типизированные языки быстрее, чем динамически типизированные, благодаря статическому анализу, позволяющему вычислять все операции над типами при компиляции, а не во время выполнения. Опять же, это общие правила, всегда будут исключения. «Парадигмы» имеют мало общего с этим.

— Мировой инженер
источник

Я знаю, что нужно учитывать множество факторов, и даже если бы все было идеально, они могли бы по-разному работать с разными данными, мой вопрос довольно расплывчатый. Спасибо за ссылку, действительно полезную - я никогда не знал, что ATS был таким быстрым

— Фарук

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

— DPM

На веб-сайте ATS говорится, что ATS поддерживает множество парадигм программирования - поэтому, прежде чем заявить, что 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. Вот почему я делаю это замечание ЗДЕСЬ.

— Стивен С

Поскольку вы хотите иметь свободу говорить - «(косвенная) мера реализации языка» - пожалуйста, объясните, почему кто-то другой не может быть свободным сказать - (косвенную) меру языка .

— igouy

@igouy - 1) Вы можете говорить, что хотите. Но это не делает тебя правым. 2) Рассмотрим случай, когда единственной реализацией языка является дерьмо. Мы измеряем это. Затем мы обновляем реализацию, тестируем ее, и производительность значительно улучшается. Означает ли это, что производительность языка улучшилась? Как это имеет смысл ... учитывая, что язык НЕ изменился !!!

— Стивен С.

Если вы смотрите на языки только по скорости исполнения, вам не хватает некоторых важных моментов. Скорость - это хорошо, но это не единственное.

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

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

По правде говоря, я бы посчитал, что скорость исполнения в наши дни довольно далеко в списке того, что я бы рассмотрел в большинстве случаев. (Хорошо, если бы я делал массивные числовые вычисления, я бы, вероятно, хотел бы использовать фортран для скорости, но в противном случае это просто недостаточно важно, чтобы иметь значение)

— Захари К
источник