基本的なハードウェアと機能的パラダイムがあまりにも異なるため、一般的に効率的ではないでしょうか？

SOからの質問に触発された：https : //stackoverflow.com/questions/6623391/how-to-gain-control-of-a-5gb-heap-in-haskell

FPの多くの長所と短所については長い議論の余地がありますが、現時点では、最新のハードウェアでのFPの主な効率に範囲を絞りたいと思います。

定説：

機能的パラダイムは不変性とステートレス（？）を意味しますが、機能的プログラムを実行するハードウェアはステートフルな有限オートマトンです。「純粋な機能」プログラムを「ステートフルなハードウェア」表現に変換すると、プログラマーはほとんど制御できず、オーバーヘッド（？）が発生し、ハードウェア機能の使用が制限されます（？）。

私は疑問の声明で正しいか間違っていますか？

FPは、現代の汎用コンピューターアーキテクチャでの主要なパフォーマンスペナルティを意味する/しないことを証明できますか？

編集： いくつかのコメントに応じて既に述べたように、質問は実装のパフォーマンスと詳細に関するものではありません。これは、プリンシパルオーバーヘッドの有無に関するものであり、ステートフルオートマトンでFPを実行するともたらされる可能性があります。

不変性には大きな誤解があります。

不変性はセマンティクスの機能ですが、実装における不変性を意味するものではありません。

簡単な例は、怠lazの実装です。

計算が遅延している場合、式の結果は概念的に値ですが、基礎となる実装は、評価される引数と値を作成する関数、および値を格納するスロットを含むサンクです。

初めて値を（言語で）尋ねると、計算が実際に実行され、その結果が評価され、返された値（またはハンドル）が返されます。

これは言語のセマンティクスでは透過的であり、この変数が値（または将来の値）にバインドされており、一度完了すると返される値を変更できないことを知っているだけです。基になるメモリ表現は変更されますが、それについては知りません。

同じセマンティック/実装の違いがほぼすべての言語に存在し、実際には最適化の中心にありますます。言語が何であれ、セマンティクスはいくつかのことを保証しますが、最適化の余地を残すために他のものを指定しないままにします。

現在、実際に機能する言語は、たとえばC ++ほど高速ではないのは事実です。ただし、Go（これはまだかなり誇大広告ですが）HaskellやLispよりも遅く、C＃Mono（source）も同様です。

信頼性の低いC ++またはCを使用してこれらのパフォーマンスを実現できることがわかったら、少し手放してください。

Haskellが今日急速に成長しており、コンパイラ/ランタイムに最適化の余地がまだあることに気付いた場合（たとえば、GHCが最近LLVMに切り替えたばかりで、Microsoft Researchはランタイムの改善に積極的に資金を提供しています）、間もなく改善されます。

楽しい：正規表現のプレイ、またはHaskellチームre2が、さまざまなシナリオでGoogleのCライブラリよりも優れた正規表現マッチャーを作成した方法。

機能的パラダイムは、狭い範囲で物事を分割するのに役立ちます。これは、コンピューターの進化を考えると、本当に良いことです。

マルチコアCPUには共有リソースの処理に大きな問題があり、同期コストは非常に高くつきます。機能的パラダイムにより、これらの問題のないプログラムを自然に表現できます。これは並列処理に非常に適しています。

さらに、SaaSおよびクラウドコンピューティングでサーバーファームをますます使用しています。したがって、同じアプリケーションを複数のマシンで実行する必要があります。この立場では、同期のコストはさらに高くなります。グーグルは、あなたが書くことができる関数型プログラミングとアルゴリズムに関するいくつかの研究を行い、いくつかの研究論文を発表しました。これは、彼らが呼び出し可能性の問題を抱えているため、彼らにとって重要なことです。

さらに、コンピューターのヒープ内でスタックを簡単に実行できます。リンクリストを使用して、連続していないスタックでも実行できます。これは、多くのプログラム言語でスタックトレースを生成するためにすでに行われています。したがって、これは問題ではありません。

OK、関数型プログラミングにはいくつかの制限があります。しかし、それはまた、現代のコンピューターにある問題を表現する自然な方法をもたらします。スケーラビリティもその1つであり、現実のものになりつつあります。

すでに複雑な並列システムを扱っている人は皆、私が話していることを知っています。

だから私は答えに微妙な違いがあるだろう。はい、機能には最新のハードウェアに問題がありますが、昔ながらのプログラミングにも問題があります。いつものように、長所と短所があります。重要なのは、必要なときに適切な選択を行えるように、それらが何であるかを知ることです。

現在の状態やそれがどれほど難しいかわからないので、実際には答えはありませんが、コンパイラが入力からそれらのものを保証するからといって、必ずしも出力にそれらがあるとは限りません。理論的には、十分にスマートなコンパイラーはこれらすべての問題を回避できますが、実際には、おそらく常に存在するでしょう。

しかし、それを見る別の方法は、Lispマシンの歴史を見ることです。正しく思い出せば、それらはもともとLispが当時のマシンとは違うという問題を克服するように設計されていました。これらのマシンの開発は最終的に停止しました。これは、デスクトップが十分に速くなり、非効率性を別のマシンをサポートするよりも安く使えるようになったためです。

一般に、パフォーマンスが最も重要なアプリケーションを除き、FP言語は十分に高速です。より高いレベルの言語を選択すると、より安全で、簡単で、保守しやすい、またはその他の優先度のために、微調整の制御とパフォーマンスの優先度を下げることができます。

最後に、プログラミングはすべてトレードオフに関するものであるため、手元のプロジェクトにとってより重要なものを選択する必要があります。

機能的パラダイムが不変性と無国籍を意味するのは事実ですが、完全に純粋なプログラミング言語はありません。最も純粋なHaskellでさえ、副作用を許します。

とはいえ、効率に関する質問に答えるために、HaskellとClojureの両方を使用しましたが、どちらにもパフォーマンスの問題はありませんでした。