Haskell / Clojure는 실제로 입자 시뮬레이션과 같은 동적 시스템에 적합하지 않습니까?

이전 질문에서 기능 프로그래밍 언어는 물리 엔진과 같은 동적 시스템에는 적합하지 않다는 이야기를 들었습니다. 주로 객체를 변경하는 데 비용이 많이 듭니다. 이 진술은 얼마나 현실적이고, 왜 그런가?

Haskell과 Clojure는 실제 변경 가능성을 허용하므로 문제가 아닙니다.

그 외에도 "변경 가능"데이터가 더 큰 계산의 일부로 점진적으로 업데이트되는 중간 값으로 구성되는 경우 효율성을 높이기 위해 변경이 필요하지 않을 수도 있습니다! 예를 들어, Haskell에서 스트림 퓨전 ( stream fusion ) 이라는 기술에 대한 연구가 진행 중이며 , 여기서 컴파일러는 처리 루프, 데이터 생산자 및 데이터 소비자를 통합하여 중간 데이터 구조를 완전히 제거합니다.

Haskell의 주요 문제는 게으름입니다. 입력 데이터가 많고 출력 데이터가 많고 중요합니다. 게으름은 호의를 거의 얻지 않지만 여전히 약간의 오버 헤드를 부과합니다. 그것은 Haskell (실제로 사람들이하는 것)에서 이와 같은 프로그램을 작성할 수는 없지만 언어의 강점을 따르지 않으며 원하는 성능을 얻기 위해 평가 모델을 더 잘 이해해야합니다.

즉, 많은 수의 크 런칭은 JVM의 강점에도 영향을 미치지 않습니다. 그런 종류의 프로그램이 FORTRAN이 여전히 존재하는 이유입니다.

Clojure를 말할 수는 없지만 Haskell은 원하는 모든 변이를 ​​허용하는 매우 조정 된 IO 패키지가 많이 있다고 말할 수 있습니다.

다음은 누군가가 가장 일반적인 세 ​​가지를 자세히 설명하고 그 성과를 고려한 질문에 대한 답변입니다. https : //.com # 15440286

당신은 또한 볼 수 있습니다 여기에 높은 IO 집약적 인 응용 프로그램입니다 워프라는 하스켈 웹 서버의 성능 메트릭을 보여주는 간단한 그래프.

Haskell과 관련하여 이것에 대해 많은 혼란이 있습니다. 진실은 IO를 매우 다양한 방식으로 사용하기 위해 많은 패키지가있는 환상적인 IO 시설을 가지고 있으며, 많은 것들이 고도로 조정되었습니다. 사람들이 그렇지 않다고 생각하는 이유는 Haskell이 IO를 다른 모든 것과 분리하기 위해 많은 시간을 들였기 때문에 성능 특성에 영향을 미치지 않기 때문입니다.

그러나 성능 특성에 대해 말하면 사람들이 성능이 좋지 않다고 인식하는 이유는 지연된 평가로 인해 항상 직관적이지 않은 방식으로 작동하기 때문입니다. 그러나 이것은 당신이 말하는 시스템과 같은 파괴적인 업데이트를 수행하는 IO 컨텍스트에서 작업을 시작할 때 상당히 걱정해야 할 부분입니다. 또한 사람들은 성능 문제가 발생했을 때 리소스가 어디에서 도움이 될지를 계측하고 식별 할 수있는 내장 된 기능을 발견하는 경향이 있습니다.

설명하는 시스템을 살펴볼 가치가있는 또 다른 모나드는 ST의 모나드 (monad) 일 것입니다. ST 모나드 는 매우 작은 IO 호출로 수행되는 파괴적인 업데이트를 위해 특별히 성능을 향상시킵니다.

Clojure와 대화 할 수 없어서 죄송합니다. 다른 누군가가 세부 정보를 제공 할 수 있기를 바랍니다.