Using boost :: iostreams :: mapped_file_source with std :: multimap

Ich muss eine ziemlich große Datenmenge analysieren - jede Datei hat ungefähr 5 Gigabyte. Jede Datei hat folgendes Format:

xxxxx yyyyy

Beide Schlüssel und Werte können wiederholt werden, die Schlüssel werden jedoch in aufsteigender Reihenfolge sortiert. Ich versuche, eine Speicherzuordnungsdatei für diesen Zweck zu verwenden und dann die erforderlichen Schlüssel zu finden und mit ihnen zu arbeiten. Das habe ich geschrieben:

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";
}

Grundsätzlich muss ich verschiedene Schlüsselbereiche ausfindig machen und diese Stücke herausziehen, um daran zu arbeiten. Beim ersten Versuch, eine Methode auf der Multimap zu verwenden, erhalte ich einen Segfehler. Zum Beispiel, wenn dasfind -Methode wird aufgerufen. Ich habe das @ ausprobieupper_bound, lower_bound und andere Methoden auch, und immer noch einen Segfault bekommen.

Das ist wasgdb gibt mir

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))

Könnte jemand bitte darauf hinweisen, was ich falsch mache? Ich konnte nur vereinfachende Beispiele für Speicherzuordnungsdateien finden - noch nichts Vergleichbares. Vielen Dank

EDIT: Weitere Informationen:

Die oben beschriebene Datei ist im Grunde eine zweispaltige Klartextdatei, die mir ein neuronaler Simulator als Ausgabe meiner Simulationen liefert. Es ist einfach so:

$ 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

Die erste Spalte enthält die Zeit, die zweite Spalte enthält die Neuronen, die zu diesem Zeitpunkt ausgelöst wurden (es handelt sich um eine Spike-Time-Rasterdatei). Tatsächlich ist die Ausgabe eine Datei wie diese von jedem MPI-Rang, der zum Ausführen der Simulation verwendet wird. Die verschiedenen Dateien wurden mit @ zu dieser Master-Datei zusammengefasssort -g -m. Weitere Informationen zum Dateiformat finden Sie hier:http: //www.fzenke.net/auryn/doku.php? id = manual: ras

Um die Feuerrate und andere Metriken des Neurons zu bestimmten Zeitpunkten der Simulation zu berechnen, muss ich - die Zeit in der Datei lokalisieren, einen Block zwischen [Zeit -1, Zeit] herausziehen und einige Metriken usw. ausführen auf diesem Stück. Diese Datei ist ziemlich klein und ich erwarte, dass die Größe einiges zunimmt, da meine Simulationen immer komplizierter werden und über längere Zeiträume laufen. Aus diesem Grund habe ich angefangen, mir Dateien mit Speicherzuordnung anzuschauen. Ich hoffe das klärt die Problemstellung etwas. Ich muss nur die Ausgabedatei lesen, um die darin enthaltenen Informationen zu verarbeiten. Ich muss diese Datei überhaupt nicht ändern.

Um die Daten zu verarbeiten, verwende ich wieder mehrere Threads. Da jedoch alle meine Operationen auf der Map schreibgeschützt sind, erwarte ich dort keine Probleme.

Antworten auf die Frage(4)

Ihre Antwort auf die Frage