Verwalten großes Datenmengen im Heap
-
Wenn es nur um Dateien geht könntest du einfach den Inhalt der Dateien vom Betriebssystem in den Adressbereich des Prozesses einblenden lassen. Das geht auf Unix mit mmap, unter Windows läuft das unter dem Stichwort "File mapping". Möglicherweise gibt es da auch was in boost.
-
@the live:
Auf nem 32 Bit System kann sich das was du beschreibst schon auszahlen.
Auf nem 64 Bit System würd' ich mir nix antun, und die Files einfach in std::vector<char> stecken.@manni66:
Memory-Mapping bringt ihm aber nix bezüglich fragmentierung des Adressbereichs.
-
hustbaer schrieb:
@manni66:
Memory-Mapping bringt ihm aber nix bezüglich fragmentierung des Adressbereichs.Man kann auch hierbei immer gleich große Blöcke der Datei mappen oder die Blöcke im Adressbereich verschieben (ohne zu kopieren!).
-
:o Das ging aber schnell. Schon mal Danke für die Antworten.
@manni66 Die Daten sollten sich aber aus Geschwindigkeitsgründen im Arbeitsspeicher befinden.
@hustbaer warum würdest Du unter einem 64-Bit System das nicht machen?
-
manni66 schrieb:
hustbaer schrieb:
@manni66:
Memory-Mapping bringt ihm aber nix bezüglich fragmentierung des Adressbereichs.Man kann auch hierbei immer gleich große Blöcke der Datei mappen oder die Blöcke im Adressbereich verschieben (ohne zu kopieren!).
*patsch*
Achje, hab ich wieder nicht weit genug gedacht.
Ja, man muss ja nicht immer das ganze File auf einmal mappen. Haste natürlich Recht
the live schrieb:
@hustbaer warum würdest Du unter einem 64-Bit System das nicht machen?
Weil das, was du da machen willst, das OS bzw. die MMU schon machen (nämlich kontinuierliche Bereiche aus kleinen Pages zusammenbasteln) - und die können das besser als du (performanter).
Der IMO einzige Grund es selbst zu machen, ist, wenn einem der Adressraum ausgeht. Bei 32 Bit ist man da heutzutage schnell an der Grenze.
Bei 64 Bit ... naja, da hast du SO viel Adressraum, da kannst du Files bis zum Abwinken reinladen und es wird immer noch genug zusammenhängender Speicher übrig sein.EDIT: OK, "einzige Grund" ist übertrieben. Aber das sind dann schon eher sehr spezielle Anwendungen wo man sowas trotz 64 Bit System selbst übernehmen würde.
-
Ok, danke damit hast du mir sehr geholfen
Muss mir wohl das mit den Paging noch mal genauer durchlesen
-
the live schrieb:
:o Das ging aber schnell. Schon mal Danke für die Antworten.
@manni66 Die Daten sollten sich aber aus Geschwindigkeitsgründen im Arbeitsspeicher befinden.
Das ist ja das Schöne daran: die sind im Arbeitsspeicher und du musst sie nicht einlesen. Schneller geht es bestimmt nicht
-
manni66 schrieb:
the live schrieb:
:o Das ging aber schnell. Schon mal Danke für die Antworten.
@manni66 Die Daten sollten sich aber aus Geschwindigkeitsgründen im Arbeitsspeicher befinden.
Das ist ja das Schöne daran: die sind im Arbeitsspeicher und du musst sie nicht einlesen. Schneller geht es bestimmt nicht
Nach dem Mappen ist erstmal noch nix im Arbeitsspeicher.
Und wenn man dann mit ungünstigen Mustern in dem gemappten Bereich rumpiekt, dann geht das garantiert viel langsamer, als wenn man die Datei vorher ohne Mappen komplett in den Speicher liest.Es sei denn man könnte dem System irgendwie mitteilen "lies das Ding was ich gemappt haben bitte jetzt gleich sofort und zwar vollständig".
-
ja aber die Dateien liegen nicht als Dateien im Dateisystem vor (zumindest nicht alle), sondern kommen über Netzwerk, desshalb müsste ich die Daten erst auf die Festplatte speichern, was aber nicht nötig ist (zumindest nicht bei allen).
Könntest Du natürlich nicht wissen, trotzdem Danke für den Tipp, vielleicht hilft er mir bei etwas anderem weiter.
-
Sobald die Daten gestreamt werden und speicherst du sie ja eh, dann lass sie doch abgespeichert. Wenn du schnelle Zugriffe haben willst lass die Datei geöffnet und greife zur Laufzeit darauf zu(vielleicht aber dann read_only). Allerdings nicht byte-wise sondern mit großen Blöcken, wobei ich immer noch nicht weiß, ob man die ideale Lese/Schreib Datengröße auslesen kann, da es ja Festplatten-spezifisch ist.
Wenn dein Netzwerk Gbit ist und du mit 100MB/s unterwegs bist, brauchst du dich eigentlich um die neueren Festplatten keine Gedanken machen. Außerdem musst du immer vom Worst-case ausgehen, also was ist, wenn der Stream mal größer als dein RAM ist? Wenn du wirkliche zeitkritische Blöcke im Code hast, kannst du dich immernoch um einen HHD Prefetch-Thread kümmern, aber die Frage ist, was du eigentlich brauchst?
-
Ich kann dir zwar leider nicht genau sagen was ich vor habe, aber du hast mir schon sehr geholfen, Danke!
-
the live schrieb:
Ich kann dir zwar leider nicht genau sagen was ich vor habe
ROFL
Ja, streng geheim, ganz viel wichtig.
-
Weniger weil es geheim ist sondern weil eine Erklärung was ich machen will recht lang wäre und niemanden etwas bringen würde.
-
Ja, aber meist fehlt eben genau die Szenariobeschreibung. Wenn du einen Mediaplayer bauen willst, könnten wir dich z.B. beruhigen, dass es schon welche gibt und die lesen die BluRays nicht komplett in den RAM und überlasten ihn.
Die meisten Probleme werden hier nämlich nicht genannt, sondern die Fehler die auf dem Weg entstehen.
---
Er: Wieso kommt hier ein Fehler?
int *i;
*i=5000;
Antwort: bla bla. Was willst du damit eigentlich erreichen?
Er: Eigentlich brauch ich in ii die Zahl 5000 und ich wollte sie dahinkopieren.
Antwort: int ii=5000;
Er: Oh ja stimmt danke, daran hab ich gar nicht gedacht...---
Wer hat hier wohl den Fehler gemacht?
-
PhilippHToner schrieb:
... Wenn du einen Mediaplayer bauen willst, könnten wir dich z.B. beruhigen, dass es schon welche gibt und die lesen die BluRays nicht komplett in den RAM und überlasten ihn...
Na toll, jetzt habe ich umsonst Unmengen an Arbeitsspeicher gekauft
Spaß bei Seite, um es einfach zu sagen es wird ein Filesystem basierend auf FUSE. Das ist auch nicht viel mehr Info als vorher, aber sonst tippe ich morgen noch.
