問題タブ [memory-pool]

OpenGL で VBO を処理するためのよりスマートなアルゴリズムを探しています。

現在、私は各モデルを 4MB の VBO に保存しています。モデルが 4MB を超える場合は、個別に保存されます。オブジェクトは、バインドの数を減らすためにモデルが一緒にプールされるように格納されます。

私が経験している問題は、まばらにしか使用されていない未使用の VBO をクリーンアップする方法です。これらのメモリ プールをより適切に管理する方法についてのリソースをいただければ幸いです。

私はどのような機能memalign()と機能を理解しようとしposix_memalign()ています。利用可能なドキュメントを読んでも役に立ちませんでした。

誰かがそれがどのように機能し、何のために使用されるかを理解するのを手伝ってくれますか? または、おそらく使用例を提供してください。

Linux メモリの仕組みを理解しようとしています。独自の単純なメモリ プール (断片化の少ないヒープ) を作成する必要があります。

割り当てられたメモリ アドレスを再利用するメモリ プール クラスと、そのクラスをラップするカスタム アロケータを使用しています。次のコード スニペットは、インターフェイスの基本的な概念を示しています。

確かに、このようなものの必要性は限られています。ただし、必要な状況では非常に便利です: - そのアロケーターを非常に素朴な方法で使用するクラスのアロケーター型を指定する (例: たとえそれが望ましい場合でも、より大きなピースの割り当てを回避する)。- 同じサイズのメモリの割り当てと割り当て解除を繰り返します。- アロケータを使用したい型のサイズが非常に小さい (例: char、short、int などの組み込み型)。

理論的には、実装は、実際の割り当てサイズの倍数を (基礎となるメモリ マネージャーから) 必要なたびに割り当てる memory_pool を利用できます。近接しているオブジェクトは、キャッシュやプリフェッチ アルゴリズムに適しています。私は、正しい割り当て、分割、および割り当て解除を処理するために、いくらかのオーバーヘッドを伴うこのようなメモリ プールを実装しました (ユーザーが割り当て解除に渡す各アドレスの割り当てを解除することはできません。各メモリ ブロックの先頭であるアドレスのみを割り当て解除する必要があります。以前に割り当てられている)。

次の非常に単純なコードを使用して、両方のケースをテストしました。

std::listが呼び出さallocactor::allocate(1, 0)れるたびに呼び出していpush_backます。unique()各要素が触れられ、次の要素と比較されることを確認します。しかし、結果は残念でした。ブロックごとに割り当てるメモリプールを管理するために必要な最小限のオーバーヘッドは、システムが得る可能性のある利点よりも大きくなります。

パフォーマンスが向上するシナリオを考えられますか?

編集: もちろん、よりもはるかに高速ですstd::allocator。

I need some clarifications for the concept & implementation on memory pool.

By memory pool on wiki, it says that

also called fixed-size-blocks allocation, ... , as those implementations suffer from fragmentation because of variable block sizes, it can be impossible to use them in a real time system due to performance.

How "variable block size causes fragmentation" happens? How fixed sized allocation can solve this? This wiki description sounds a bit misleading to me. I think fragmentation is not avoided by fixed sized allocation or caused by variable size. In memory pool context, fragmentation is avoided by specific designed memory allocators for specific application, or reduced by restrictly using an intended block of memory.

Also by several implementation samples, e.g., Code Sample 1 and Code Sample 2, it seems to me, to use memory pool, the developer has to know the data type very well, then cut, split, or organize the data into the linked memory chunks (if data is close to linked list) or hierarchical linked chunks (if data is more hierarchical organized, like files). Besides, it seems the developer has to predict in prior how much memory he needs.

Well, I could imagine this works well for an array of primitive data. What about C++ non-primitive data classes, in which the memory model is not that evident? Even for primitive data, should the developer consider the data type alignment?

Is there good memory pool library for C and C++?

Thanks for any comments!

Core Duo で Windows 7 を実行しています。私はしばらくの間 Codeblocks を使用してきましたが、これは GNU コンパイラーを使用していると思います。

私は、抽象クラスから継承する多くのコンポーネント クラスを持っています (または持つ予定です) Component。それぞれのコンポーネントの量が不確定な、不確定な量のコンポーネント タイプ用のメモリ プールを格納するシステムを確立するのに助けが必要です。議論のために後者が修正されているのかもしれませんが、絶対に必要なときにサイズを変更する方法を理解できます。

また、便利なことに、各コンポーネント タイプには、unsigned short0 から穴のない任意の ID ( ) があります。わーい！

それで、配列のサイズなどを追跡するための管理クラスがいくつかあると仮定すると、このようなものは機能しますか?

多分sizeof(FooComponent)Paramsに入れます。

それから（私が本当に何をすべきかわからなくなり始めたところ）関数内でmalloc( START_COUNT * component_size)

このようにメモリを割り当てた経験はありません。私は簡単に次のようなものを設定できます

vector< vector<Component*>* >また
map<unsigned short, vector<Component*> >

しかし、それは（1つには醜い）連続したプールを提供しません。キャッシュフレンドリーが必要です:)

アイデア？パターン？イディオム？ヘルプ？

「Linux ネットワークの内部構造を理解する」と「Linux カーネルを理解する」という 2 冊の本やその他の参考文献を読むことで、私はかなり混乱しており、「メモリ キャッシュ」と「メモリ プール」の手法について明確にする必要があります。

1) それらは同じ技術ですか、それとも異なる技術ですか?

2) 同じでない場合、違いを生むもの、または明確な目標は何ですか?

3) また、スラブ アロケータはどのように導入されますか?

「純粋な」C/C++ (それが何を意味するかは問わない) のみを検討するよう、回答者に依頼してもよろしいですか? STLは大丈夫です。ブーストはありません。

共有メモリ内の C++ オブジェクトの割り当てと割り当て解除のために、独自の C++ メモリ プール クラス (Linux システム上) を作成しています。複数のプロセスで同じオブジェクトにアクセスするには、これが必要です。POSIX セマフォを使用してメモリ プール オブジェクト操作へのアクセスを制御しますが、基本的な割り当て/割り当て解除に関する質問がありました。私のコードは、同じプールから割り当てられた同じサイズのオブジェクトに対してのみ機能します。現時点では、プールの動的な拡大と縮小に関連する問題は無視できます。

合計 MAXFOOOBJECTS 個の Foo オブジェクトに対して定義された共有メモリ セグメントがあるとします。共有メモリ セグメントを次のように定義します。

この共有メモリを使用するすべてのプロセスによって、メモリは次のように解釈されます。

次のように定義されたオブジェクト Foo があるとします。

さて、私の質問は次のとおりです。

1. 前述のスキームは、皆さん (新規と削除のそれぞれに O (1)) には問題ないように見えますか?それとも、まったく重要な何かが欠けていますか? すぐにわかる問題の 1 つは、たとえば Foo オブジェクト配列が最小ヒープとして解釈される場合、new と delete を実行するたびにヒープ プロパティを強制終了することです。
2. このプールが最小ヒープに使用されないことを保証する場合 (たとえば、タイマー管理手法で必要な場合)、前述のスキームに問題はありますか?
3. 反対に、共有メモリ内の Foo 配列を最小ヒープまたは最大ヒープとして (つまり、新規および削除中に) 管理し、新規または削除ごとに O (lg n) の最悪のケースを招く可能性があります。コメントはありますか？
4. 望ましい他の方法はありますか？

BoostGraphLibraryとの両方を使用するプログラムのパフォーマンスの向上に取り組んでいますboost::bimap。プロファイリングにより、ほとんどの時間がメモリの割り当てと割り当て解除に費やされていることが明らかになりました。adjacency_listグラフライブラリのクラスを使用するようにすると、boost::fast_pool_allocatorパフォーマンスが大幅に向上します。残りのメモリ割り当ての大部分はで発生するboost::bimapため、そこでカスタムアロケータを使用して実験したいと思いました。ドキュメントには、アロケータをバイマップの最後のテンプレートパラメータとして指定できると記載されていますが、アロケータ自体のテンプレート引数のタイプについては記載されていません。たとえば、タイプXとY、

何を記入する必要がありZますか？

過去数日間、これについて多くのことを検索しましたが、それに答えるものは何も見つかりませんでした.

大きなメモリ プールを作成しました。さて、プールにアクセスするのは初めてで、そのプールから 5 つの要素の配列を割り当てたいとしましょう。それから配列に開始アドレスを与えて、それを操作できるようにします。

次に、次のようなループで配列を実行します。

通常の割り当て方法では、i=5 のときに例外が発生するはずでしたが、私の場合は、指定された開始アドレスの後に大きなメモリが割り当てられているため、発生しません。書き込み/アクセスしてはいけないアドレスへの書き込み/アクセスを防ぐにはどうすればよいですか? 方法はありますか？

前もって感謝します。

JVM内でTunered Generationプールを見つける方法を探しています。以前は、このプールを「Tunered Gen」という名前で見つけようとしましたが、場合によっては、このプールは「PS Old Gen」と名付けられました。そこで、すべての古いオブジェクトが格納されているプールを見つけるためのより一般的な方法を考えました。

どう思いますか？多分誰かが別の解決策を提案できますか？

よろしく、 マキシム