Czy Haskell / Clojure faktycznie nie nadaje się do układów dynamicznych, takich jak symulacja cząstek?

W poprzednich pytaniach powiedziano mi, że funkcjonalne języki programowania nie są odpowiednie dla systemów dynamicznych, takich jak silnik fizyki, głównie dlatego, że mutowanie obiektów jest kosztowne. Jak realistyczne jest to stwierdzenie i dlaczego?

Zarówno Haskell, jak i Clojure umożliwiają faktyczną zmienność, więc na początek nie stanowi to problemu.

Poza tym, jeśli twoje „zmienne” dane polegają na stopniowym aktualizowaniu wartości pośrednich w ramach jakiegoś większego obliczenia, być może nawet nie potrzebujesz zmienności, aby była wydajna! Na przykład w Haskell trwają badania nad techniką zwaną fuzją strumieniową , w której kompilator łączy w sobie pętle przetwarzania, producentów danych i odbiorców danych w celu całkowitego wyeliminowania pośrednich struktur danych.

Głównym problemem związanym z Haskellem jest tutaj lenistwo - w programie do łamania liczb, w którym masz dużo danych wejściowych i wiele danych wyjściowych, a wszystko to jest ważne, lenistwo ma bardzo mało przysług, ale wciąż nakłada pewne koszty ogólne. Nie oznacza to, że nie możesz pisać takich programów w Haskell (ludzie to robią), ale nie wykorzystuje to mocnych stron tego języka i musisz lepiej zrozumieć model ewaluacji, aby uzyskać pożądaną wydajność.

To powiedziawszy, ciężkie zgniatanie liczb również nie wpływa na mocne strony JVM. Tego rodzaju program sprawia, że ​​FORTRAN wciąż istnieje.

Nie mogę mówić w imieniu Clojure, ale mogę powiedzieć, że Haskell ma wiele bardzo dostrojonych pakietów IO, które pozwolą na wszystkie mutacje, których możesz potrzebować.

Oto odpowiedź na pytanie, które napisałem, w którym ktoś wyszczególnia 3 najczęstsze i dotyczy ich wydajności: /programming/15439966/when-why-use-an-mvar-over-a-tvar/15440286 # 15440286

Można również zobaczyć tutaj prosty wykres pokazujący wskaźniki wydajności serwera internetowego haskell o nazwie Warp, który jest aplikacją o wysokim stopniu obciążenia.

W przypadku Haskell istnieje wiele nieporozumień. Prawda jest taka, że ​​ma fantastyczne funkcje IO z wieloma pakietami hackage'ów do korzystania z IO na wiele różnych sposobów, z których wiele zostało bardzo zestrojonych. Powodem, dla którego ludzie przypuszczają, że tak nie jest, jest to, że Haskell dokłada wszelkich starań, aby oddzielić IO od wszystkiego innego, ale nie ma to wpływu na charakterystykę wydajności.

Mówiąc teraz o charakterystyce wydajności, powodem, dla którego ludzie uznają ją za słabą, jest leniwa ocena, która powoduje, że zachowuje się ona w sposób niekoniecznie intuicyjny. Jest to jednak coś, o co musisz się martwić znacznie mniej, gdy zaczynasz pracować w kontekście IO, wykonując destrukcyjne aktualizacje, takie jak system, o którym mówisz. Kolejne osoby mają tendencję do stwierdzania, że ​​gdy mają problemy z wydajnością, wbudowane urządzenia do instrumentowania i określania, gdzie idą zasoby, bardzo pomagają.

Kolejną monadą, na którą warto zwrócić uwagę na system, który opisujesz, byłaby monada ST, która jest specjalnie przeznaczona do destrukcyjnych aktualizacji wykonywanych przez bardzo małe wywołania IO, zapewniając jej doskonałą wydajność.

Przepraszam, ale naprawdę nie mogę rozmawiać z Clojure, mam nadzieję, że ktoś inny może podać tam szczegóły.