기능적 패러다임이 기본 하드웨어와 너무 다양하여 일반적으로 효율적이지 않습니까?

SO의 질문에서 영감을 얻었습니다 : /programming/6623391/how-to-gain-control-of-a-5gb-heap-in-haskell

FP의 여러 장단점에 대해서는 오랜 논쟁이 될 수 있지만, 현재 는 현대 하드웨어에서 FP의 주요 효율성 으로 범위를 좁히고 싶습니다 .

명제:

기능적 패러다임은 불변성과 상태 비 저장 (?)을 의미하지만, 기능 프로그램을 실행하는 하드웨어는 상태 저장 유한 자동 마타입니다. '순수한 기능'프로그램을 '상태 저장 하드웨어'표현으로 변환하면 프로그래머가 거의 제어 할 수없고 오버 헤드 (?)가 발생하며 하드웨어 기능 (?)의 사용이 제한됩니다.

의문의 진술에서 내가 옳고 그른가?

FP가 현대의 범용 컴퓨터 아키텍처에서 주요 성능 저하를 암시하지 않음을 증명할 수 있습니까?

편집 : 일부 의견에 대한 답변으로 이미 언급했듯이 문제는 구현 성능 및 세부 사항에 관한 것이 아닙니다. Stateful Automata에서 FP를 실행하면 발생할 수있는 주요 오버 헤드 가 있는지 여부 에 관한 것입니다.

불변성에 대한 큰 오해가 있습니다.

불변성은 시맨틱의 특징이지만 구현에서 불변성을 의미하지는 않습니다.

간단한 예는 게으름의 구현입니다.

계산이 게으른 경우 표현식의 결과는 개념적으로 값이지만 기본 구현은 평가할 인수와 값을 작성하는 함수 및 값을 저장하는 슬롯을 포함하는 썽크입니다.

처음으로 (언어로) 값을 물어 보면 실제로 계산이 수행되고 결과가 평가되며 사용자에게 돌려주는 값 (또는 핸들)이됩니다.

이것은 언어 의미론에서 투명하며,이 변수는 값 (또는 미래 값)에 바인딩되어 있고 일단 완료되면 반환 될 값을 변경할 수 없다는 것만 알고 있습니다. 기본 메모리 표현이 변경되지만 알 수는 없습니다.

모든 언어에 대해 동일한 의미 / 구현 차이가 있으며 실제로 최적화 의 핵심입니다 . 언어가 무엇이든, 시맨틱은 어떤 것들을 보장하지만, 다른 것들을 지정하지 않으면 최적화의 여지를 남겨 둡니다.

예를 들어, 실제로 기능적인 언어는 C ++만큼 빠르지 않습니다. 그러나 Go(여전히 과대 광고입니다) Haskell 또는 Lisp보다 느리고 C # Mono ( source )도 느립니다 .

C ++ 또는 C가 이러한 성능을 얻는 데 얼마나 신뢰할 수 있는지 알면 조금 놓아두고 싶을 것입니다.

Haskell이 오늘날 빠르게 성장하고 있고 컴파일러 / 런타임에 최적화 할 여지가 여전히 많다는 것을 알게되면 (예 : 온실 가스가 최근에 LLVM으로 전환 된 것처럼, Microsoft Research는 런타임 개선에 적극적으로 자금을 지원하고 있습니다), 곧 개선 될 것입니다.

재미 : 정규 표현식에서의 플레이 또는 Haskell 팀 re2이 여러 시나리오에서 Google의 C 라이브러리 보다 성능이 뛰어난 정규 표현식 매처를 만든 방법 .

기능적 패러다임은 범위를 좁히는 데 유용합니다. 이것은 컴퓨터가 어떻게 진화 하는지를 고려할 때 정말 좋습니다.

멀티 코어 CPU는 공유 리소스를 다루는 데 큰 문제가 있으며 동기화 비용은 실제로 비쌉니다. 기능적 패러다임을 통해 자연스럽게 문제가없는 프로그램을 표현할 수 있습니다. 이것은 병렬 처리에 정말 좋습니다.

또한 SaaS 및 클라우드 컴퓨팅에서 서버 팜을 점점 더 많이 사용하고 있습니다. 따라서 동일한 응용 프로그램이 여러 컴퓨터에서 실행되어야합니다. 이 위치에서 동기화 비용은 훨씬 더 비쌉니다. 구글은 여러분이 작성할 수있는 함수형 프로그래밍과 알고리즘에 관한 몇 가지 연구와 논문을 발표했습니다. 이것은 스캐 빌리티 문제가 있기 때문에 그들에게 중요한 것입니다.

또한 컴퓨터의 힙에 스택을 쉽게 연결할 수 있으며 링크 된 목록을 사용하여 연속적이지 않은 스택을 만들 수도 있습니다. 이것은 많은 프로그래밍 언어에서 스택 추적을 생성하기 위해 수행됩니다. 따라서 이것은 문제가되지 않습니다.

기능 프로그래밍은 몇 가지 한계를 암시합니다. 그러나 그것은 현대 컴퓨터에서 우리가 가지고있는 패러다임에서 다루기가 매우 어려운 문제를 표현할 수있는 자연스러운 방법을 제공합니다. 확장 성은 그 중 하나이며, 실제로 거래되고 있습니다.

복잡한 병렬 시스템을 이미 다루고있는 모든 사람들은 내가 말하는 것을 알고 있습니다.

그래서 나는 대답을 뉘앙스로 만들 것입니다. 예, 기능에는 최신 하드웨어에 문제가 있지만 일반 오래된 프로그래밍에도 문제가 있습니다. 항상 그렇듯이 장점과 단점이 있습니다. 요점은 그들이 무엇인지 아는 것이므로 필요할 때 적절한 선택을 할 수 있습니다.

현재 상태를 알지 못하거나 얼마나 어려울 지 모르지만 실제로 대답이 없습니다. 그러나 컴파일러가 입력에서 해당 내용을 보장한다고해서 반드시 출력에 해당 내용이 있음을 의미하지는 않습니다. . 이론적으로 충분히 똑똑한 컴파일러는 이러한 모든 문제를 해결할 수 있지만 실제로는 항상 존재할 것입니다.

그러나 그것을 보는 또 다른 방법은 Lisp 기계의 역사를 보는 것입니다. 내가 올바르게 기억한다면, 그들은 원래 Lisp가 당시의 기계와 다른 점과 동일한 문제를 극복하도록 설계되었습니다. 데스크탑은 다른 머신을 지원하는 것보다 비 효율성을 더 싸게 살 수있을만큼 빠르게 빨라지면서 이러한 머신의 개발은 결국 중단되었습니다.

일반적으로 성능이 가장 중요한 응용 프로그램을 제외하고 FP 언어는 여전히 빠릅니다. 더 높은 수준의 언어를 선택하면 더 세밀한 조정 제어 및 성능의 우선 순위를 낮추어 안전하고, 쉬우 며, 유지 관리가 용이 ​​한 또는 기타 우선 순위를 지정할 수 있습니다.

결국 프로그래밍은 트레이드 오프에 관한 것이므로 프로젝트에 더 중요한 것을 선택하면됩니다.

기능적 패러다임은 불변성과 무국적을 의미하지만, 완전히 순수한 프로그래밍 언어는 없습니다. 가장 순수한 Haskell조차도 부작용을 허용합니다.

즉, 효율성에 대한 귀하의 질문에 대답하기 위해 Haskell과 Clojure를 모두 사용했으며 성능 문제도 발견하지 못했습니다.