c++ - C++ヒープアロケータとSTLの最適化

Question

単純なインクリメントヒープアロケータを単純な圧縮デフラグツールと組み合わせて使用​​する、自己最適化メモリマネージャを作成しようとしています。

大まかなスキームは、最下位のメモリアドレスから上に向かってブロックを割り当て、最上位のメモリアドレスから下に向かって簿記情報を保持することです。

メモリマネージャはスマートポインタを返します-ブーストのintrusive_ptrは、実際のメモリブロックを指し、ブロックを簡単に移動できるように間接レベルを与える簿記構造体にとって最も明白なようです。

デフラグツールは、「生成」ブックマークからヒープを圧縮してプロセスを高速化し、一度に一定量のメモリのみをデフラグします。ブロック自体への生のポインタは、次のデフラグパスまで有効であるため、パフォーマンスが向上するまで自由に渡すことができます。

このための特定のアプリケーションはコンソールゲームプログラミングであるため、各フレームの最初または最後にデフラグパスを比較的安全に実行できます。

ですから、私の質問は、この種の割り当てスキームをSTLと組み合わせて使用​​した人がいるのではないかと思いますが、STLを完全に破壊してしまうのではないかと思います。std :: list <intrusive_ptr>がintrusive_ptrレベルで機能しているのを見ることができますが、stlリストノード自体の割り当てについては、next / prevポインターをオーバーライドして、intrusive_ptr自体にするか、またはこのより動的なものと並んで標準的なヒープアロケータ。

Answer 1

メモリ内でオブジェクトを移動する場合、これを完全に一般的に行うことはできません。これは、移動される可能性があることを認識しているオブジェクトでのみ実行できます。また、ロック機構も必要になります。オブジェクトで関数が呼び出されているときは、その関数を移動することはできません。

その理由は、C ++モデル全体がメモリ内の固定ポイントにあるオブジェクトに依存しているため、スレッドがオブジェクトのメソッドを呼び出している場合、このスレッドは一時停止され、オブジェクトが移動され、スレッドが再開されたときに災害が発生します。

移動される可能性のある別のオブジェクト（それ自体のサブオブジェクトを含む）への生のメモリポインタを保持しているオブジェクトは機能しません。

このようなメモリ管理スキームは機能する可能性がありますが、非常に注意する必要があります。ハンドルの実装、およびハンドル->ポインターロックのセマンティクスについて厳密にする必要があります。

STLコンテナーの場合、アロケーターをカスタマイズできますが、それでも固定のrawメモリーポインターを返す必要があります。移動する可能性のあるアドレスを返すことはできません。このため、STLコンテナを使用している場合、それらはハンドルのコンテナである必要があり、ノード自体は通常の動的に割り当てられたメモリになります。ハンドルの間接参照でオーバーヘッドが多すぎても、STLを使用して得られるよりもハンドルコレクションの断片化に問題がある場合があります。

ハンドルを直接理解するコンテナを使用することが唯一の前進である可能性があり、それでも、メモリに固定された従来のオブジェクトを使用するC++アプリケーションと比較して多くのオーバーヘッドが存在する可能性があります。

Answer 2

かなりよく知られている代替手法は、バディシステムです。追加のインスピレーションを得るためにそれを見てください。

Answer 3

STLコンテナは、ネイキッドポインタを使用して実装されます。

インスタンス化するときにカスタムアロケータを指定できますが（アロケータを使用してポインタを初期化するため）、（割り当てられた値はネイキッドポインタに格納されるため）それらのポインタがどこにあるかわからないため、できません。後で変更してください。

代わりに、STLのサブセットを自分で実装することを検討することもできます。STLコンテナーのバージョンは、マネージポインターを使用して実装できます。

Answer 4

これがコンソールゲームプログラミング用である場合、実行時にスコープ外の動的メモリ割り当てを禁止する方がはるかに簡単です。そして起動時に、しかしそれを達成するのは少し難しいです。

Answer 5

これについての私の見解は、断片化を恐れる必要がある場合、それはあなたがあなたの記憶の大部分であるデータ部分をいじくり回していることを意味し、この美徳だけではあなたはそれらの多くを持つことができないということです。これらがどうなるかはすでに知っていますか？レベルを下げてより具体的な決定を下し、他のコードやアプリケーションの一般的なパフォーマンスへの影響を少なくする方がよいかもしれません。

リストは、他のほとんどのSTLデータ構造と同様に、小さな断片の集まりであるため、デフラグメモリマネージャーに配置するのに非常に悪い例です。これを行うと、デフラグツールのパフォーマンスが低下したり、間接コストが低下したりするなど、あらゆる種類の明らかな悪い影響があります。IMOが意味をなす唯一の構造は、隣接する構造です。配列、両端キュー、ハッシュテーブルのメインチャンクです。 、それらのもの、そして特定のサイズを超えた場合にのみ、そしてそれらがもはやサイズ変更されない場合にのみ。これらの種類のものは、ここでも、一般的なソリューションではなく、特定のソリューションを必要とします。

すべてがどうなるかについてコメントしてください。