問題タブ [data-oriented-design]

Richard Fabian のData Oriented Designでは、オブジェクトが持つことができるさまざまなプロパティが個別の配列に分割され、これらの配列内のデータを処理することによって機能が作成される、ゲーム用のコンポーネント ベースのオブジェクトの例を示しています。彼はレンダリングの例を挙げています:

私が混乱しているのは、このコードがキャッシュフレンドリーであるということです。私が理解していることから、データ指向設計は、特定の操作に必要な関連データを連続したメモリに保持することでパフォーマンスを向上させるため、データを反復処理して更新すると、キャッシュミスの数が減ります。ただし、この例では、レンダリングには 3 つの異なる「コンポーネント」からの情報が必要であるため、反復ごとに異なるデータ配列にアクセスすることになります。また、コンポーネントがそれぞれと対話する必要がある場合に ID を検索する必要があるため、パフォーマンスが低下する可能性があることは言うまでもありません。他人のデータ。

データ指向設計を実践するために、非常に単純な 2D ゲームに取り組んでいます。上記のパターンに従ってオブジェクトを移動させるなど、ゲームの基本的な動作をモデル化するとしたら、次のようになります。

次に、物理の更新で、対応するinで各Positioninを更新します。positionsArrayVelocityvelocitiesArray

キャッシュがこの操作に必要なデータを単一の構造体に結合する方がよいのではないでしょうか:

位置を更新するために必要なデータがすべて連続して保存されていますか?

私は C++ で共有ライブラリを作成しており、ライブラリによって行われるすべてのヒープ割り当てを、ライブラリの特定の部分の初期化時に割り当てられる単一の連続したブロックに配置するという (主に教育的な) 目標を持っています。mallocこれは、最初に 2 つのスタック (1 つは永続メモリ用の大きくポップできないスタック、もう 1 つはセカンダリ ランタイム スタックとして余分な機械を備えたスタック) と、半永続データ用のバイナリ バディ システムを実装する単一のもので実現します。

この自己課せられた制約を考慮して、これが過度に XY 状況に変わる前に、私が解決しようとしている問題について説明します。私のライブラリには、いくつかのプロパティ、構造体、たとえばAとを持つことができるこれらのアイテムがありBます。個別の継承による OO アプローチの代わりに、ECS のようなデータのフラット化を行っています。アイテムは単なる ID であり、私は各プロパティを別々の配列に持っている人を記録しています。したがって、5 つのアイテムがあり、おそらく {1, 3, 4, 5} がプロパティ A を持ち、{2, 3, 4} がプロパティ B を持つ場合、コードは次のようになります。

これらの配列はすべて、配列に例示されているように、固定サイズを与え、null 終了によってプログラム関連のサイズを「動的に」変更することにより、私の制約に従って割り当てることができます (これはスパースのアドホックな実装に過ぎないことを認識しています)。配列（プログラムを書いた時点でサイズが分かっているので気に入っています）。さて、私のライブラリに必要な機能は次のとおりです。ユーザーがアイテムのインスタンスを (最大数まで) 作成し、事後にプロパティを追加/削除できるようにしたいと考えています。

そのために、ユーザーが面倒な ID ではなく名前で項目を参照できるようにしたいと考えています。次に、API で次の関数を公開する必要があります

同様の機能をスクリプト (現在は Lua) に公開したいので、名前をメモリに保存する必要があります。頭に浮かぶ解決策は、文字列をキーとして、アイテム ID を値として持つ、あ​​る種の連想マップです。マップ自体とキーとしてstd::unordered_mapの動的割り当てのために、私は避けてきました。std::string現在、私が行っているのは、書き込み対象の を定義し、const char** itemNamesそれらを基本的な線形検索して、すべてのエントリCreateItemを比較するcharことだけです。char私はそれをベンチマークしておらず、特に面倒だとは思いませんが、より適切で（理論的に）より効率的な、よりエレガントなソリューションを期待してこの質問をしています。