非常に大きなテキストファイル(45 GB)があります。テキストファイルの各行には、次に示すように、スペースで区切られた2つの64ビット符号なし整数が含まれています。
4624996948753406865 10214715013130414417
4305027007407867230 4569406367070518418
10817905656952544704 3697712211731468838 ... ...
ファイルを読み取って、数値に対していくつかの操作を実行したい。
void process_data(string str)
{
vector<string> arr;
boost::split(arr, str, boost::is_any_of(" \n"));
do_some_operation(arr);
}
int main()
{
unsigned long long int read_bytes = 45 * 1024 *1024;
const char* fname = "input.txt";
ifstream fin(fname, ios::in);
char* memblock;
while(!fin.eof())
{
memblock = new char[read_bytes];
fin.read(memblock, read_bytes);
string str(memblock);
process_data(str);
delete [] memblock;
}
return 0;
}
私はc ++に比較的慣れていません。このコードを実行すると、これらの問題に直面しています。
ファイルをバイト単位で読み取るため、ブロックの最後の行が元のファイルの未完成の行に対応する場合があります(メインファイルの実際の文字列 "4624996948753406865 10214715013130414417"ではなく、 "4624996948753406865 10214")。
このコードは非常に遅く実行されます。 6GBのRAMを搭載した64ビットIntel Core i7 920システムで1ブロックの操作を実行するには、約6秒かかります。ランタイムを改善するために使用できる最適化手法はありますか?
ブースト分割関数に空白文字と共に「\ n」を含める必要はありますか?
C++でmmapファイルについて読みましたが、それが正しい方法であるかどうかはわかりません。はいの場合は、リンクを添付してください。
ブロックではなく、ストリーミングを実行するようにこれを再設計します。
より簡単な方法は次のとおりです。
_std::ifstream ifs("input.txt");
std::vector<uint64_t> parsed(std::istream_iterator<uint64_t>(ifs), {});
_
予想される値の数がおおまかにわかっている場合は、_std::vector::reserve
_を前もって使用すると、さらに高速化できます。
または、メモリマップファイルを使用して、文字シーケンスを反復処理することもできます。
Update上記のプログラムを変更して、_uint32_t
_ sを解析してベクターにしました。
4.5GiBのサンプル入力ファイルを使用する場合[1] プログラムは9秒で実行されます[2]:
_sehe@desktop:/tmp$ make -B && Sudo chrt -f 99 /usr/bin/time -f "%E elapsed, %c context switches" ./test smaller.txt
g++ -std=c++0x -Wall -pedantic -g -O2 -march=native test.cpp -o test -lboost_system -lboost_iostreams -ltcmalloc
parse success
trailing unparsed: '
'
data.size(): 402653184
0:08.96 elapsed, 6 context switches
_
もちろん、少なくとも402653184 * 4 *バイト= 1.5ギビバイトを割り当てます。したがって、45 GBのファイルを読み取る場合、ベクトルを保存するために推定15GiB RAMが必要です(再割り当て時に断片化がない場合):解析は10分45秒で完了します:
_make && Sudo chrt -f 99 /usr/bin/time -f "%E elapsed, %c context switches" ./test 45gib_uint32s.txt
make: Nothing to be done for `all'.
tcmalloc: large alloc 17570324480 bytes == 0x2cb6000 @ 0x7ffe6b81dd9c 0x7ffe6b83dae9 0x401320 0x7ffe6af4cec5 0x40176f (nil)
Parse success
Trailing unparsed: 1 characters
Data.size(): 4026531840
Time taken by parsing: 644.64s
10:45.96 elapsed, 42 context switches
_
比較すると、_wc -l 45gib_uint32s.txt
_を実行するだけで最大12分かかりました(ただし、リアルタイムの優先度スケジューリングはありません)。 wc
は非常に速い
_#include <boost/spirit/include/qi.hpp>
#include <boost/iostreams/device/mapped_file.hpp>
#include <chrono>
namespace qi = boost::spirit::qi;
typedef std::vector<uint32_t> data_t;
using hrclock = std::chrono::high_resolution_clock;
int main(int argc, char** argv) {
if (argc<2) return 255;
data_t data;
data.reserve(4392580288); // for the 45 GiB file benchmark
// data.reserve(402653284); // for the 4.5 GiB file benchmark
boost::iostreams::mapped_file mmap(argv[1], boost::iostreams::mapped_file::readonly);
auto f = mmap.const_data();
auto l = f + mmap.size();
using namespace qi;
auto start_parse = hrclock::now();
bool ok = phrase_parse(f,l,int_parser<uint32_t, 10>() % eol, blank, data);
auto stop_time = hrclock::now();
if (ok)
std::cout << "Parse success\n";
else
std::cerr << "Parse failed at #" << std::distance(mmap.const_data(), f) << " around '" << std::string(f,f+50) << "'\n";
if (f!=l)
std::cerr << "Trailing unparsed: " << std::distance(f,l) << " characters\n";
std::cout << "Data.size(): " << data.size() << "\n";
std::cout << "Time taken by parsing: " << std::chrono::duration_cast<std::chrono::milliseconds>(stop_time-start_parse).count() / 1000.0 << "s\n";
}
_
[1]od -t u4 /dev/urandom -A none -v -w4 | pv | dd bs=1M count=$((9*1024/2)) iflag=fullblock > smaller.txt
で生成
[2] 明らかに、これはファイルがLinuxのバッファキャッシュにキャッシュされていたためです-大きなファイルにはこの利点がありません
ボトルネックが発生していることは推測できます:
string str(memblock);
-メモリに45MBの長いセグメントを割り当てるため。
ここで説明するように、ファイルを1行ずつ読み取る必要があります。
プログラムのプロファイルを作成するために、以下で説明するように、各行の間にclock()を出力できます。
ファイルをメモリにメモリマップできますが、これはプラットフォームに依存します(UNIXでは、Windows CreateFileMapping/MapViewIntoFileでmmapになります)。それでも、32ビットシステムでは、十分な仮想メモリブロックが残っていない場合に問題が発生する可能性があります(64ビットシステムではその問題は発生しません)。
メモリマッピングは、ディスクからブロックごとにデータを読み取るよりも高速であると想定されています。
Linuxでは、C++ストリームの代わりにC <stdio.h>
を使用するとパフォーマンスが向上する場合があります(C++ストリームはFILE
- sの上に構築されるため)。 readline(3) または fgets(3) または fscanf(3) を使用できます。 setbuffer(3) などを使用して、より大きなバッファー(64Kバイトや256Kバイトなど)を設定することもできますが、(改善された)プログラムはI/Oバウンドであり、CPUバウンドではないでしょう。次に、 posix_fadvise(2) で遊ぶことができます
あなたはメモリマッピングの使用を検討するかもしれません mmap(2) & madvise(2) ( fopen(3) のm
モードも参照してください=)。参照 readahead(2)
最後に、アルゴリズムで許可されている場合は、ファイルを小さく分割してcsplit
、各ファイルを並列処理で処理することができます。