[C++] Verbesserung für Schreiben und Lesen binärer Dateien

Hallo Leute,

ich simuliere Genome. Dabei fallen riesige Datenmengen an. Um von dieser Datenmenge nicht überwältigt zu werden, möchte ich das ganze jetzt in binären Dateien speichern. Im Moment habe ich das so gelöst, dass ich in einem Character von einem byte jeweils acht Infos speichere (0 oder 1). Bei Einlesen das ganze wieder rückwärts. Vorteil des ganzen ist, es ist für einen Laien leicht nachzuvollziehen ist. Mich würde aber interessieren, ob jemand bessere Vorschläge hat, vor allem hinsichtlich von Speicherplatzbedarf und Geschwindigkeit. Ich habe schon eine Weile gesucht, aber bislang noch nichts gefunden, was für diesen speziellen Fall passt, und ich auch mit meinem Wissen verstehen und weitergeben kann.

Schöne Grüße,
Aui

Ich könnt' mir vorstellen, dass du die Berechnung von a mit einer Schleife und bissl Bitschubsen schneller und lesbarer hinbekommst.

Zitat:

---

Ich könnt' mir vorstellen, dass du die Berechnung von a mit einer Schleife und bissl Bitschubsen schneller und lesbarer hinbekommst.

---

Ich habe das mit dem Bitschubsen versucht, aber die Verbesserung in Hinsicht auf die Geschwindigkeit ist nicht sonderlich groß (8% weniger Zeit). Das kann aber auch daran liegen, dass ich zu wenig über Bitshift weiß. Ein Problem daran ist auch, dass ich das ganze auch anderen Leuten erklären muss/soll.

@lokicall: Hättest Du einen Vorschlag, wie man das wirklich besser machen kann? Oder zumindest eine gute Anleitung für die Anwendung von Bitshift und Erzeugung von binären Dateien?

Grüße,
Aui

Hier noch zwei zusätzliche Hinweise, die zur Beschleunigung führen können:

Du verwendest in der innersten Schleife über k immer Konstrukte der Form

Code:

---

Pop[i][j][k+0]

---

Damit wird jedesmal Pop[i][j] neu ausgewertet. Es könnte besser sein, die Referenz auf Pop[i][j] zu merken und immer wieder zu verwenden.

In der inneren Schleife überprüfst Du in einer if-Abfrage immer auf

Code:

---

k+8 <= numSNPchrom[i]

---

Versuche mal, ob Du den Code nicht so umstellen kannst, dass das if aus der inneren Schleife herausfällt. Wenn ich den Code richtig verstanden habe, läuft die k-Schleife in 8er Schritten hoch und für das letze Stückchen (numSNPchrom[i]%8) wird eine Extrabehandlung gemacht. Das sollte sich umstellen lassen.

Hast Du schon mal mit höchster Laufzeitoptimierung compiliert? Das kann Faktoren bringen (gegenüber Debug oder keine Optimierung).

Wenn du beim Einlesen schon vorher weißt, wie groß ein Vektor werden wird, dann kannst du den gleich in dieser Größe erzeugen, bzw. mit resize() auf entsprechende Größe bringen.

Bei push_back() in einen leeren Vektor kann es zur einer internen Vergrößerung und u.U. zu einem Kopieren bestehender Inhalte kommen.

Ciao,
_

Also richtig leserlich find ich den code nicht.
Sieht aus wie C mit Vectoren :-) würd mir schwertun, das anderen zu erklären.

Um aber angepasste Vorschläge zu bringen, fehlt mir bisserl der Background.

Wenn ich richtig verstehe, musst du 3 dimensionale Vectoren (Matrix) speichern. Und die Matrizen koennen richtig fett werden ?
Pro index soll auch nur ein bool (wahr falsch) gespeichert werden ?

Das ganze soll dann binaer serialisiert werden koennen ?
Wo liegt das der Schwerpunkt bei der Performancebetrachtung ?
Groesse des Datenstroms ? Performance das Ding auf die Platte zu kriegen ?

Die Daten sollen nur von Deinem Prog lesbar sein ? Versioniert ? Andere Plattformen (little endian big endian) spielen eine Rolle ?

in welchen groessenordnungen bewegst du Dich ? gib mal paar Zahlen, inklusive Puffer, womit auf der sicheren Seite bist.
Kriegst deine Matrizen komplett in den hauptspeicher, oder solltest lieber sequentiell lesen und speichern koennen ?

Musst du unbedingt per Index auf die daten zugreifen koennen ? also wahlfrei in der Matrix von posi zu posi springen, oder kommen deine Abfragen immer in gewisser reihenfolge ?

prinzipiell würd ich versuchen so konstrukte wie sowas ZZZ[x][y][v] zu vermeiden.
kann man auch in eine dimension umrechnen.

Prinzipiell wuerd ich natuerlich deine Datenhaltung auch kapseln. Aber denk dir gehts ned so ums Design hier, sondern (hoffentlich) erstmal nur um Performance ?

Ciao ....

Hallo Leute,

hat ein wenig gedauert, aber jetzt hatte ich ein wenig Zeit das ganze zu überarbeiten. Nochmals Danke für die ganzen Vorschläge. Ich hoffe, ich habe alle berücksichtigt. Das mit dem dreifach gekapselten Vektor war auch nur eine einfache Lösung für das Posting hier.

Jedenfalls braucht das Ausgeben der Daten jetzt nur noch ungefähr ein Drittel der Zeit, das Einlesen etwa die Hälfte.

Schöne Grüße,
Aui