I have a rather large amount of data to analyse - each file is about 5gigs. Each file is of the following format:
xxxxx yyyyy
Both key and value can repeat, but the keys are sorted in increasing order. I'm trying to use a memory mapped file for this purpose and then find the required keys and work with them. This is what I've written:
if (data_file != "")
{
clock_start = clock();
data_file_mapped.open(data_file);
data_multimap = (std::multimap<double, unsigned int> *)data_file_mapped.data();
if (data_multimap != NULL)
{
std::multimap<double, unsigned int>::iterator it = data_multimap->find(keys_to_find[4]);
if (it != data_multimap->end())
{
std::cout << "Element found.";
for (std::multimap<double, unsigned int>::iterator it = data_multimap->lower_bound(keys_to_find[4]); it != data_multimap->upper_bound(keys_to_find[5]); ++it)
{
std::cout << it->second;
}
std::cout << "\n";
clock_end = clock();
std::cout << "Time taken to read in the file: " << (clock_end - clock_start)/CLOCKS_PER_SEC << "\n";
}
else
std::cerr << "Element not found at all" << "\n";
}
else
std::cerr << "Nope - no data received."<< "\n";
}
Basically, I need to locate ranges of keys and pull those chunks out to work on. I get a segfault the first time I try to use a method on the multimap. For example, when the find
method is called. I tried the upper_bound
, lower_bound
and other methods too, and still get a segfault.
This is what gdb
gives me:
Program received signal SIGSEGV, Segmentation fault.
_M_lower_bound (this=<optimized out>, __k=<optimized out>, __y=<optimized out>, __x=0xa31202030303833) at /usr/include/c++/4.9.2/bits/stl_tree.h:1261
1261 if (!_M_impl._M_key_compare(_S_key(__x), __k))
Could someone please point out what I'm doing wrong? I've only been able to find simplistic examples on memory mapped files - nothing like this yet. Thanks.
EDIT: More information:
The file I described above is basically a two column plain text file which a neural simulator gives me as the output of my simulations. It's simple like this:
$ du -hsc 201501271755.e.ras
4.9G 201501271755.e.ras
4.9G total
$ head 201501271755.e.ras
0.013800 0
0.013800 1
0.013800 10
0.013800 11
0.013800 12
0.013800 13
0.013800 14
0.013800 15
0.013800 16
0.013800 17
The first column is time, the second column is the neurons that fired at this time - (it's a spike time raster file). Actually, the output is a file like this from each MPI rank that is being used to run the simulation. The various files have been combined to this master file using sort -g -m
. More information on the file format is here: http://www.fzenke.net/auryn/doku.php?id=manual:ras
To calculate the firing rate and other metrics of the neuron set at certain times of the simulation, I need to - locate the time in the file, pull out a chunk between [time -1,time] and run some metrics and so on on this chunk. This file is quite small and I expect the size to increase quite a bit as my simulations get more and more complicated and run for longer time periods. It's why I began looking into memory mapped files. I hope that clarifies the problem statement somewhat. I only need to read the output file to process the information it contains. I do not need to modify this file at all.
To process the data, I'll use multiple threads again, but since all my operations on the map are read-only, I don't expect to run into trouble there.
You're trying things you don't really understand :) No problem.
Multi maps aren't laid out sequentially in memory. (They're node-based containers, but I digress). In fact, even if they were, chances would be slim that the layout would match that of the text input.
There's basically two ways you can make this work:
Keep using the
multimap
but use a custom allocator (so that all allocations are done in the mapped memory region). This is the "nicest" from a high-level C++ viewpoint, /but/ you will need to change to a binary format of your file.If you can, this is what I'd suggest. Boost Container + Boost Interprocess have everything you need to make this relatively painless.
You write a custom container "abstraction" that works directly on the mapped data. You could either
Using these you can devise an interator (Boost Iterator
iterator_facade
) that you can use to implement higher level operations (lower_bound
,upper_bound
andequal_range
).Once you have these, you're basically all set to query this memory map as a readonly key-value database.
Sadly, this kind of memory representation would be extremely bad for performance if you also want to support mutating operations (
insert
,remove
).If you have an actual sample of the file, I could do a demonstration of either of the approaches described.
Update
Quick Samples:
With boost::interprocess you can (very) simply define the multimap you desire:
Notes:
I chose
flatmap
(flat_multimap
, actually) because it is likely more storage efficient, and is much more comparable to the second approach (given below);Note that this choice affects iterator/reference stability and will favours read-only operations pretty heavily. If you need iterator stability and/or many mutating operations, use a regular
map
(or for very high volumes ahash_map
) instead of the flat variations.I chose a
managed_mapped_file
segment for this demonstration (so you get persistence). The demo shows how 10G is sparsely pre-allocated, but only the space actually allocated is used on disk. You could equally well use amanaged_shared_memory
.If you have binary persistence, you might discard the text datafile altogether.
I parse the text data into a
shared::multi_map<double, unsigned>
from amapped_file_source
using Boost Spirit. The implementation is fully generic.There is no need to write
iterator
classes,start_of_line()
,end_of_line()
,lower_bound()
,upper_bound()
,equal_range()
or any of those, since they're already standard in themulti_map
interface, so all we need to is writemain
:Live On Coliru
I implemented it exactly as I described:
const char*
region mapped;boost::iterator_facade
to make an iterator that parses the text on dereference;boost::string_ref
- which avoids dynamic allocations for copying strings.parsing is done with Spirit Qi:
Qi was chosen for speed and genericity: you can choose the
Key
andValue
types at instantiation time:I've implemented
lower_bound
,upper_bound
andequal_range
member functions that take advantage of underlying contiguous storage. Even though the "line"iterator
is not random-access but bidirectional, we can still jump to themid_point
of such an iterator range because we can get thestart_of_line
from anyconst char*
into the underlying mapped region. This make binary searching efficient.Note that this solution parses lines on dereference of the
iterator
. This might not be efficient if the same lines are dereferenced a lot of times.But, for infrequent lookups, or lookups that are not typical in the same region of the input data, this is about as efficient as it can possibly get (doing only minimum required parsing and
O(log n)
binary searching), all the while completely bypassing the initial load time by mapping the file instead (no access means nothing needs to be loaded).Live On Coliru (including test data)
For the curious: here's the disassembly. Note how all the algorithmic stuff is inlined right into
main
: http://paste.ubuntu.com/9946135/data_multimap = (std::multimap<double, unsigned int> *)data_file_mapped.data();
, as far I can read from the boost documentation, you have missunderstood that function, that casting will not work, you need to fill the the multimap with the char* provided bydata()
I edit to add a bit more detailed content, for example after the mapping, you can do
std::getline(data_file_mapped, oneString);
And after that, deliver the content on the line (you can use a stringstream for that task) and fill your multimap.
Repeat the process until the end of the file.