2011-12-09 18 views
7

私は、12個の物理コアと24個の論理コア、および192ギガビットのラムを意味するデュアル・キオン・チップを搭載したマシン上で動作するCアプリケーション(VStudio 2010、win7 64ビット)を用意しています。 編集:OSはwin7です(Windows 7,64ビットなど)。大量のディスクへの書き込みを最適化する

アプリには24個のスレッドがあり(各スレッドには独自の論理コアがあります)、計算が行われ、大量のC構造の別の部分が埋めら​​れます。すべてのスレッドが完了したとき(そしてスレッドが完全に均衡しているため、同時に完了したとき)の構造は、約60ギガバイトです。

(私はハードウェアの設定を制御しているので、RAID 0を実行している6台の2TBドライブを使用します。つまり、物理的な書き込み制限は平均シーケンシャル書き込み速度の約6倍、つまり約2ギガ/秒。)

これをディスクにする最も効率的な方法は何ですか?明らかに、I/O時間は計算時間を矮小化します。このトピックに関する私の研究から、write()(fwrite()とは対照的に)のように思えます。しかし、バッファサイズの設定などの点で、ソフトウェア側では他にどのような最適化を行うことができますか?mmapはより効率的でしょうか?

+0

他の人がこの質問を簡単に見つけるのに役立つ、あなたが書きたい言語のタグを追加してください。 – Buddha

+0

計算にはどのくらい時間がかかりますか? –

+0

'mmap'タグがあります。それはあなたのシステムで利用可能ですか? –

答えて

6

あなたの状況に最適なものを判断するのは難しいです。

最初に行う最適化は、ファイルを事前に割り当てることです。そうすることで、ファイルシステムのサイズを拡張する必要はありません。ディスク操作を最適化する必要があります。ただし、実際のゼロをディスクに書き込まないでください。ちょうど長さを設定します。

次に、mmapとwriteの選択肢があります。これは、使用するオペレーティングシステムによっても異なります。 Unixでは、mmapとpwriteの両方を試みます。 pwriteは、各スレッドがファイルのオフセットを越えずに目的のファイル位置でファイルに書き込むことができるので便利です。

mmapは、ファイルキャッシュにコピーを作成するのではなく、スレッドがファイルキャッシュに直接書き込むため、うまくいく可能性があります。おそらく60 GBはファイル全体をmmapするには大きすぎるので、各スレッドは自分自身のmmapウィンドウを必要とするでしょう。

Windowsでは、重複した非同期IOを試してみることをお勧めします。これは、Win32 API呼び出しでのみ行うことができます。

+1

Windowsにはmmap(CreateFileMapping、MapViewOfFile)と同等の機能があり、Zanがリストアップしたのと同じ理由でうまくいく可能性があります。 –

+1

そして、同じ理由(それはOSが使用するものです)でマップされたファイルは、Windows上でも良いパフォーマンスです。プラスウィンドウでネットワークドライブ上のファイルをマップできます。 Unixはnfs上でmmapを行うことができませんでしたが、それは変更されていますか? –

8

mmap()またはboost mmapは、ほとんどの場合、常に最適な方法です。 OSはあなたよりスマートで、キャッシュするものを心配してください!

あなたはOSは何も言っていませんでしたが、Linuxではmadviseと同等のブーストヒントが実際にパフォーマンスを向上させる可能性があります。

+1

+1、常に、誰かができるだけ多くの細部を汗ばませてください! –

関連する問題