ich gebe einige Ergebniswerte (alles ints) in eine Datei aus, im moment einfach mit operator<< als text und mit komma getrennt.
Die Datei kann mehrere hundert MB oder noch mehr groß werden.

Im Moment speichere ich alles zwischen in einem Buffer und schreibe am Ende alles in die Datei, weil die Ergebniosse nicht in der richtigen Reihenfolge verfügbar sind.

Jetzt habe ich den plan, eine random-access datei zu verwenden und dann direkt an die richtige stelle zu schreiben. Dabei wollte ich das ganze dann auch binär machen, um 1. Platz zu sparen und 2. sicherzustellen, dass jeder int-wert die selbe länge hat, sodass ich auch beim einlesen einen random access nutzen kann. Wenn ich das mit text machen würde, müsste ich z.B. festlegen, das jede zahl genau 10 Stellen hat oder so.

Das mit random access habe ich gerade ausprobiert und scheint eigentlich ganz einfach zu sein mit ofstream::seekp. Jetzt gehts es noch um das binäre schreiben in die Datei. Wie es ausieht schreibt fstream auch im ios_base::binary modus die zahlen als text in die datei.

Muss ich das dann ungefähr so machen?:

int toWrite = 42;
int bigEndianVal = ToBigEndian(toWrite);
char * val = reinterpret_cast<char*>(&bigEndianVal);
ofs.write(val, sizeof(int));

Oder gibt es da etwas fertiges zu?
Und dann ist da noch die sache mit dem ToBigEndian, muss ich das dann auch selbst schreiben?

Meine Idee dazu wär das hier:

bool IsBigEndian()
{
   int test = 1;
   char * ptr = reinterpret_cast<char*>(&test);
   return ptr[3] == 1;
}

int ToBigEndian(int val);
{
   if(!IsBigEndian)
   {
       char * ptr = reinterpret_cast<char*>(val);
       std::reverse(ptr, ptr + sizeof(int));
   }
   return val;
}

Bist du sicher, dass du das mit der Endianess brauchst? Mich wundert sehr, dass du zwar davon ausgehst, dass int auf allen deinen Zielsystemen die gleiche Größe hat, aber nicht die gleiche Endianess.

Ein anderer Ansatz wäre, alles selber umzurechnen und dann zeichenweise auszugeben. Also fast so wie du es jetzt schon tust, bloß dass du beim Umrechnen der Endianess nicht den Wert der Zahl änderst (was ich ohnehin für sehr zweifelhaften Stil halte), sondern direkt das Ergebnis als chars (oder als Hexzahl - die wäre auch immer gleich groß, wenn du mit Nullen auffüllst. Braucht zwar etwas mehr Platz, aber ist dann wenigstens menschenlesbar) rausschreibst.

constexpr bool IsBigEndian()
{ 
   int test = 1; 
   char * ptr = reinterpret_cast<char*>(&test); 
   return ptr[sizeof(int)-1] == 1; 
}

bb

kennt dein compiler schon constexpr?
wieso nutzt du nicht die größe (des integers)?

constexpr bool IsBigEndian()
{ 
   int test = 1; 
   char * ptr = reinterpret_cast<char*>(&test); 
   return ptr[sizeof(int)-1] == 1; 
}

bb

Dummerweise muss eine constexpr-Funktion aus einem einzigen return-Statement bestehen (außer evtl. static_aserts, using-Direktiven oder -deklarationen, typedefs oder alias-Deklarationen oder null-Statements, also Zeugs, das das Verhalten des Programmes nicht direkt beeinflussen kann). Und ein reinterpret_cast-Ausdruck ist niemals ein konstanter Ausdruck...

Und ein reinterpret_cast-Ausdruck ist niemals ein konstanter Ausdruck...

stimmt^^

Und wrappe das auch lieber gleich in eine Klasse, die das Zeugs dann notfalls wieder im RAM cachen kann, das dürfte nämlich wesentlich flotter gehen.

Mein Ziel war es ja gerade, mit möglichst wenig RAM auszukommen.
Wenn ich später mal eine 8GB Ausgabedatei haben will, wird es schwierig 8GB zu cachen, da soviel speicher wahrscheinlich gar nicht vorhanden ist.
Außerdem will ich das ganze auf einem Cluster ausführen. Da muss ich am Anfang den maximalen Speicherbedarf angeben, wird dieser überschritten, wird das programm gekillt. Je mehr speicher ich angebe, desto länger dauert es, bis das Programm gestartet wird (das gilt übrigens auch für die Laufzeit).

unskilled schrieb:

wieso nutzt du nicht die größe (des integers)?

War ein Flüchtigkeitsfehler, danke.

Wenn wir 10ms pro IO annehmen, dann wären das 20 Milliarden ms = 20 Millionen Sekunden = 5555.55 Stunden = 231 Tage.
(Wenn es nicht eine einzelne Platte sondern mehrere in einem RAID Verbund sind, dann entsprechend weniger)

Nachdem das jetzt relativ lange ist...

Man könnte z.B. das Programm mehrfach hintereinander laufen lassen.
Sagen wir du hast 1 GB RAM, und das Ergebnis wird 8 GB gross. Dann lässt du das Programm einfach 8x laufen. Einmal für das erste GB des Ausgabefiles, einmal für das 2. GB und so weiter. Und verwirfst dabei immer alle Ergebnisse die du im aktuellen Durchlauf grad nicht brauchen kannst.

Falls die Berechnung der Werte deutlich länger als das lineare Lesen aus einer Datei braucht könntest du auch die Ergebnisse erstmal so wie sie anfallen in eine Datei schreiben. Dann musst du nur noch diese Datei 8x lesen um das fertige Output-File zusammenzubauen.

Mein Ziel war es ja gerade, mit möglichst wenig RAM auszukommen.
Wenn ich später mal eine 8GB Ausgabedatei haben will, wird es schwierig 8GB zu cachen, da soviel speicher wahrscheinlich gar nicht vorhanden ist.

Dann limitiere die Cachegröße. Wenn er voll ist, wird das Ergebnis auf die Platte geschrieben. Dann hast du zumindest nur seeks in eine Richtung und kürzere Sprünge.

Aber eventuell brauchst du gar keinen echten Random Access? Dann reicht es vielleicht, die Operationen blockweise durchzuführen.
Ich stelle mir das so vor, dass du deine Datei in einzelne Teile a xKB aufteilst. Wenn ein Block voll ist, wird er in die Datei geschrieben. Wenn deine Daten irgendeine Struktur haben, sollte auch die Cachegröße relativ klein bleiben.