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

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

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

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

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

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

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

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

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

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

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

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

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