Действительно ли Haskell / Clojure не подходит для динамических систем, таких как моделирование частиц?

9

В предыдущих вопросах мне говорили, что функциональные языки программирования не подходят для динамических систем, таких как физический движок, главным образом потому, что мутация объектов обходится дорого. Насколько реалистично это утверждение и почему?

MaiaVictor
источник
4
Вы можете найти github.com/linneman/particles-clj интересным. Due to the functional programming style the computational load will be distributed over the available CPU cores which can dramatically increase processing speed in some cases
2
Кто тебе сказал, что они не подходят? Ссылка на ответ / комментарий?
Андрес Ф.
7
@Dokkat: Я скептически отношусь к тому, что комментатор там очень много знает о функциональном программировании, если честно. Я взял бы это с большим зерном соли.
CA McCann
6
Кроме того, я бы также проигнорировал ответ, который начинается с «Чисто функциональный подход не подходит для игр ...», если автор не докажет, что он действительно пытался написать функциональную программу. В противном случае он просто угадывает, в чем, по его мнению, могут быть проблемы .
Андрес Ф.
1
Разработка игр @Dokkat имеет дополнительные ограничения, а не только симулятор частиц и физический движок (который может довольно хорошо вписаться в функциональное программирование) - производительность во время выполнения является ключевой для разработки игр (и иногда важнее, чем сама физика). Физический движок для горнодобывающей компании, предсказывающий взрывы, требует точности больше, чем производительность. С функциональным программированием, большую производительность можно получить легче, добавляя больше оборудования (чего не могут сделать игровые движки).

Ответы:

10

И Haskell, и Clojure допускают фактическую изменчивость, так что это не проблема для начала.

Кроме того, если ваши «изменяемые» данные состоят из промежуточных значений, которые обновляются постепенно в рамках более масштабных вычислений, вам может даже не понадобиться изменчивость, чтобы быть эффективной! Например, в Haskell продолжаются исследования техники, называемой объединением потоков , в которой компилятор объединяет циклы обработки, производителей данных и потребителей данных для полного устранения промежуточных структур данных.

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

Тем не менее, тяжелое сокращение чисел не играет на сильные стороны JVM, либо. Именно такого рода программы Фортран все еще существует.

CA Макканн
источник
1
Стоит отметить: в следующей версии 8.0 GHC будет поддерживаться режим строгой оценки для каждого модуля.
Эрик Каплун
8

Я не могу говорить за Clojure, но могу сказать, что на Haskell есть много очень хорошо настроенных пакетов ввода-вывода, которые позволят всю мутацию, какую вы захотите.

Вот ответ на вопрос, который я написал, где кто-то подробно описывает 3 наиболее распространенных из них и оценивает их эффективность: /programming/15439966/when-why-use-an-mvar-over-a-tvar/15440286 # 15440286

Вы также можете увидеть здесь простой график, показывающий показатели производительности веб-сервера haskell под названием Warp, который является приложением с высокой интенсивностью ввода-вывода.

В отношении Хаскелла существует много путаницы, правда в том, что у него есть фантастические возможности ввода-вывода со множеством пакетов для взлома, позволяющих использовать ввод-вывод множеством различных способов, многие из которых были сильно настроены. Причина, по которой люди предполагают, что это не так, в том, что Haskell делает все возможное, чтобы отделить ввод-вывод от всего остального, но это никак не влияет на характеристики производительности.

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

Еще одна монада, на которую стоит обратить внимание в отношении описанной вами системы, - это монада ST , специально предназначенная для деструктивных обновлений, выполняемых очень маленькими вызовами ввода-вывода, что обеспечивает высокую производительность.

Извините, я действительно не могу поговорить с Clojure, надеюсь, кто-то еще может дать подробности там.

Джимми Хоффа
источник