8

この件に関する決定的な情報を見つけることができないようです。Haskell ゲームの実装はたくさんありますが、私が見つけたのは小さなゲームであり、それらのアプローチがスケーリングするかどうかは不明です。同様に、Haskell プログラムで状態を保持すること (主に State モナドを使用) に関する情報はたくさんありますが、そのようなメソッドの効率が命令型言語の状態に匹敵するかどうかについてはほとんど情報がありません。

私は非常に単純なグラフィックスを持つシミュレーターに取り組んでいるため、Haskell での開発が非常に望ましいものになっています。ただし、できるだけ多くのエンティティをシミュレートしたいので、効率が非常に重要です。Haskell を使用するために多少のパフォーマンスの低下は許容できますが、このシミュレーションのステートフルな性質により、Haskell コードが他の選択肢である C++ よりも桁違いに遅くなることが心配です。

タイトルが示すように、Haskell はこのタイプのアプリケーションとどのように比較されますか? 実装されたステートフルな高性能 Haskell プログラムへのリンクに加えて、Haskell で使用するアプローチの提案をいただければ幸いです。

状態を維持する方法のより具体的な例が必要な場合は、それを提供できますが、各反復で大幅に変化する座標の膨大なコレクションを考えるだけで十分です。

ありがとう！

4

1 に答える 1

11

現状では、あなたの質問に直接答えることはできません。

TL;DR: パフォーマンスの問題が発生する理論的な理由はありません。そして確かに、「桁違いに」パフォーマンスが低下する理由はわかりません。ただ、具体的なシナリオがないと大雑把な発言しかできません。

Haskell は、C++ と同様に、ベア メモリにアクセスしてビットをシャッフルできます。したがって、理論的には「桁違いに遅い」という心配はありません。実際、状態を変更可能なメモリのブロブやスタックに割り当てられたフレームなどとして表現したい場合、Haskell (GHC 実装) はそれをサポートしています。結局のところ、Haskell で書かれたオペレーティング システムがあります。

この分野で役立ついくつかのイディオムとライブラリ:

  • ボックス化されていない厳密なフィールド
  • ST モナド (生メモリへの安全なアクセス)
  • vector および repa ライブラリ -- 高性能ベクトル

デバイスドライバーをプログラミングしていない限り、絶対的な低レベル制御は必要ないでしょう。

アルゴリズムが適切である限り、問題はありません。

Haskell の GHC 実装は非常に高速な割り当て (バンプ ポインター) を備えており、不変データを安価にします。不変データの使用に固有のペナルティはなく、並列化が容易になり、コードの保守が容易になります。したがって、可能であれば、Haskell のイディオムに固執してください。

できるだけ多くのエンティティをシミュレートしたいので、効率が非常に重要です。

GHC には非常に効率的なアロケーターとガベージ コレクターがあり、オブジェクトは安価でオーバーヘッドが少ないため (適切なデータ表現を使用する場合)、ここで問題はないと思います。たとえば、ベンチマーク ゲームでは、バイナリ ツリー ベンチマーク テスト アロケーターのパフォーマンス -- C++ と GHC Haskell は、このマイクロ テストの執筆時点では同点です。

最終的には、基本的に Haskell を使用するためにペナルティを支払う必要はありません。必要に応じて命令型アルゴリズムを使用できますが、おそらくその必要はないでしょう。単純なアルゴリズムを使用するという間違いを犯さないでください (可変配列の代わりに不変リストを使用するなど)。これは断然最大のリスクです - 新しいユーザーとして、非効率的なアプローチを使用する可能性があります - 助けを求めてプロフィールを作成してください :)

余談ですが、10 年前に Haskell の新しいユーザーがFragを書きましたが、これは完全に許容できるパフォーマンスでした。GHCもだいぶ賢くなりましたね…

于 2013-03-06T17:12:41.530 に答える