2012-03-06 11 views
2

私は以下のような状況のC/C++混在プロジェクトで作業しています。アプリケーション層のプリフェッチシステムを構築する方法

非常に小さなチャンク(まれに大きなチャンクも同様です)を1つずつ順番に処理する必要があります。理想的には、私はそれらを一度連続して読むべきです。このケースでは、大きなチャンクをバッファに読み込んで後で消費する方が、必要なときに即座にそれぞれを読み込むよりも、より良い解決策になると思います。

問題は、どのようにキャッシュサイズのバランスをとるかです。私が利用できる既知のアルゴリズム/ライブラリはありますか?


UPDATEは:君たち返信用

おかげで(タイトルを変更する)と私はボックスで働いキャッシュメカニズムの異なるレベルがあります理解しています。しかし、私の場合は十分ではありません。

私はここで重要なことを忘れたと思います。実際には、エンジンへの読み込みを要求することは私にとってあまりにもコストがかかる既存のフレームワーク上にアプリケーションを構築しています。 (はい、私はエンジンがOSとディスクレベルのキャッシュを利用すると信じています)。そして、私がしようとしているのは確かにアプリケーションレベルのプリフェッチシステムを構築することです。

思考?

+0

これはおそらく、あちこちで一定の読み込みが行われない限り、心配する価値はありません。ディスクは大量のデータをキャッシュできます。私は一般的に64 MBまで考えると、キャッシュに要求したものよりも多くを引き出すことがあります。それ以外にも、セクター分のデータ(おそらく2〜4KB)を引き出すことをお勧めします。 –

+1

最新のOSは、64MBだけでなく、すべての空きメモリをディスクキャッシュとして使用します。 – BatchyX

+0

ドライブに組み込まれているハードウェアを指していたのかもしれません。 –

答えて

0

一般に、(キャッシュを2回実行するリスクがあるため)独自のキャッシュを作成するのではなく、OSが提供するものを使用するようにしてください。 Linuxの場合は、readahead()でOSレベルのキャッシュを要求することができます。私は窓が同等であるかどうかわからない。

ブロックレベル(つまりディスク)パラメータもあり、blockdev --setraで設定します。あなたのシステム上でそれを変更するのは良い考えではないでしょう(ただし、この1つのタスクに専念している場合を除きます)、そこにある値(blockdev -getra)が通常のチャンクサイズよりも大きい場合は、他に何か。

[また、質問のコメントに記載されている他の点に対処するために、OSはファイルデータを空きメモリにキャッシュしますが、未読ファイルを先読みするとは思いません上記の要件)。誰か他の人が知っている場合は、詳細を投稿してください...]

+0

答えをありがとう。しかし、私の場合はOSレベルのキャッシュでは十分ではありません。質問の私の更新を参照してください。 – Reinhard

+0

はあなたの後ろのものと同じものです - http://dl.acm.org/citation.cfm?id=1251047(私は "pre-fetch memory management heuristic"を検索しました - 私は "キャッシュ"はここで助けていない)。 –

+0

ありがとう!これについて研究し、後でここに戻ってきます。 – Reinhard

0

read()の代わりにmmap()ファイルを送信しようとしましたか?場合によっては、これはより効率的な場合もあり、場合によってはそうでない場合もあります。ただし、アプリケーションよりもハードウェアのことが分かっているため、通常はシステムを最適化することをお勧めします。 mmap()は、ファイル全体が必要であることをシステムに知らせるので、より最適になるかもしれません。

+0

実際に私は自分でファイルを読んでいません、あなたをここで誤解して申し訳ありません。 – Reinhard

+0

@Reinhard:私が正しく理解すれば、アプリケーションはフレームワークに読み取りを発行し、フレームワーク自体はデータへのシステムレベルのアクセスを処理しますか?そして、システム自体からではなく、フレームワークからデータをキャッシュするためのより良い方法を探したいのですか?その場合は、フレームワーク自体に大きく依存しているので、あなたの質問に答えることは可能だと思います。あなたがここであなたを助けることができる唯一の人であるので、これを扱う良い方法で直接フレームワークを書いた人々に尋ねるのがよいでしょう。 – LiKao

関連する問題