3. ein absolut "kranker" fehler

ein absolut "kranker" fehler

  • S

    otze schrieb:

    read muss virtual sein, da es 2 klassen gibt, 2 streamklassen, die dasselbe interface benutzen.

    schau dir diesbezüglich mal die c++ streams an

    ziel war bzw ist es, die klassen austauschbar zu machen, damit die eine im notfall(zb malloc versagt) für die andre einspringen kann.
    und dann gehts halt nich anders...

    wenn malloc einmal fehlschlägt, ist so ziemlich alles zu spät.

    aber nur mal so aus neugierde: wie schaffst du es, eine datei in 4kb blöcke aufzuteilen? std::list?

    jo. das wäre ne möglichkeit. uU auch ein vector.

    0
  • O

    4kb sind eine pagesize, das ist klar.
    geht bei größeren datenblöcken denn die performance so stark in die Knie, dass es sich lohnt sie aufzuteilen, oder hat das andre gründe?

    //edit (ich edite zuviel)
    wiegroß ist eigentlich der heap bei nem rechner mit 500mb ram und ner 1gb auslagerungsdatei? in der hilfe steht nur, dass heap das ist, was nicht stack ist, und das ist sehr vage^^

    0
  • C

    Die Größe des Heaps hängt vom Betriebssystem und der Rechner-Architektur ab.

    Bei 32Bit-Systemen und Windows 9x hat das Programm grundsätzlich maximal 2GB zur Verfügung. Bei Windows NT/XP sind es erstmal auch nur 2GB, mit einem Trick bekommt man IMHO auch 3GB (eine Linkeroption).
    Alle Adressen, die das Programm erhält, liegen innerhalb dieser 2GB. Also auch der Code und der Stack. Der Heap wird also niemals die vollen 2GB ausnutzen können.
    Der physikalisch vorhandene RAM ist bei einem halbwegs ernstzunehmenden Betriebssystem unwichtig für die Größe des Heaps.

    Wenn du unter Windows programmierst, schau dir mal memory mapped files an. Vielleicht kannst du das gebrauchen. Dabei bildet Windows eine Datei auf RAM-Speicher ab. Dank virtuellem Speicher ist das auch mit großen Dateien möglich, ohne dass der Speicherverbrauch des Programms um ein Byte steigt.

    0
  • O

    cd9000 schrieb:

    Die Größe des Heaps hängt vom Betriebssystem und der Rechner-Architektur ab.

    Bei 32Bit-Systemen und Windows 9x hat das Programm grundsätzlich maximal 2GB zur Verfügung. Bei Windows NT/XP sind es erstmal auch nur 2GB, mit einem Trick bekommt man IMHO auch 3GB (eine Linkeroption).
    Alle Adressen, die das Programm erhält, liegen innerhalb dieser 2GB. Also auch der Code und der Stack. Der Heap wird also niemals die vollen 2GB ausnutzen können.
    Der physikalisch vorhandene RAM ist bei einem halbwegs ernstzunehmenden Betriebssystem unwichtig für die Größe des Heaps.

    Wenn du unter Windows programmierst, schau dir mal memory mapped files an. Vielleicht kannst du das gebrauchen. Dabei bildet Windows eine Datei auf RAM-Speicher ab. Dank virtuellem Speicher ist das auch mit großen Dateien möglich, ohne dass der Speicherverbrauch des Programms um ein Byte steigt.

    erstmal danke für die info,das hat mir sehr geholfen 😉
    zum thema memory mapped files...ich schreib ja dateien in den heap um vielfach schnelleren zugriff auf sie zu haben, wie ist das denn mit memory mapped files? gibts da geschwindigkeitszuwächse?

    //edit is der code so in ordnung?

    string Filename("datei.dat");
HANDLE Filehandle=CreateFileForMapping(*Filename,GENERIC_READ,0,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL|FILE_FLAG_RANDOM_ACCESS);
readpointer=CreateFileForMapping(Filehandle,NULL,PAGE_READONLY,0,0,NULL);
//mit dem pointer arbeiten
buffer[3]=readpointer[3];
    0
  • S

    Wenn du ne Datei in den Speicher mappst, dann liegt sie im Speicher. Genau wie deine Datei 🙂 nur dass das mappen schneller ist.

    0
  • O

    es gibt noch eine letzte frage,dann is dieses thema für mich abgeschlossen ;9
    shade, du hast ja ein paar posts vorher gesagt, dass es besser wär, den großen dateibuffer in 4kb große teile aufzuspliten.
    Jetzt mal ganz abgesehen davon, wie mam das am besten implementiert,wie kann ich folgende situation regeln?

    Ich hab jetzt also einen 25*4kb großen Buffer,und eine funktion will mithilfe eines pointers drauf zugreifen.
    so, nun haben wir ein problem:
    solange nur aus dem ersten der 25 teilbuffer gelesen wird ist alles in ordnung,
    will man aber das 4097.Byte lesen(also das erste byte des 2. buffers) trifft man auf eine ziemlich harte mauer: zwischen 2 buffern können x unbesetzte Bytes liegen,vom sprung von byte 4096 zu 4097 müssen also noch x bytes übersprungen werden,und das problem ist, dies dem pointer mitzuteilen...gibt es überhaupt eine möglichkeit, das zu regeln?

    also im endeffekt, soll es der funktion erlaubt sein den übermittelten void pointer umzucasten,und dann zb x=*pointer[4097] aufzurufen(das entspricht auch in etwa dem, was man "in freier wildbahn"(ergo D3DXCreateTextureFromFileInMemoryEx()) antrifft.

    0
  • S

    Das geht dann natuerlich nicht...
    Ich wuerde hier eine eigene Stringklasse empfehlen. Diese Klasse zeigt nur auf den Speicher wenn dies moeglich ist - wenn es nicht moeglich ist, muss eben doch kopiert werden. allerdings treten solche situationen ja hoffentlich nicht allzuoft auf (wenn doch, dann uU die Bloecke vergroessern).

    Aber du hast doch sowieso das Problem, dass du keine echten C strings hast, da du sie ja nicht gut NULL terminieren kannst...

    0
  • O

    null terminieren is das kleinste problem...
    25*4kb blöcke und der 26. block isn nullzeiger^^

    hm was haltet ihr denn von der idee:
    es ist klar, dass man nicht wirklich eine 100mb datei im speicher haben sollte.
    dann gäbs doch den alternativ weg, dass der user eine Klasse hat, die zuerst nur einen "suchstream" auf die datei öffnet.
    wenn der Programmierer dann an dem bereich ist, der für ihn nützlich ist, kann er einen xkb buffer erzeugen, der mit den daten gefüllt wird..
    der programmierer kann dann weiter suchen, und weitere buffer erzeugen,und dann mit diesen wesentlich kleineren buffern arbeiten.
    wenn man ihm dann noch die wahl zwischen "an einem stück" oder "in handlichen 4k blöcken" lässt, dürfte es dann auch bei funktionen die die pointer benötigen keine probleme geben.
    Vielleicht lässt man dem Programmierer aber auch eine weitere wahlmöglichkeit:
    wenn der programmierer weis, dass er einfach nur linear durch die datei durchmuss,dann würde sich vielleicht die anschaffung eines 100kb großen(in 4kb buffer aufgeteilt) Buffers lohnen, der sich sozusagen immer die nächsten 100kb streamt, und wenn man dann am ende ist, automatisch die nächsten 100 bekommt.die größe des Buffers da muss man vielleicht noch mit rum experimentieren, was die beste speicherleistung bei dem wenigsten performance verlust ist.

    0
  • S

    otze schrieb:

    null terminieren is das kleinste problem...
    25*4kb blöcke und der 26. block isn nullzeiger^^

    Das loest das Problem nicht.

    Ich kenne DirectX nicht, deshalb weiss ich nicht was fuer Strings es erwartet - aber sollten die nicht 0 terminiert sein? Wenn ja - wie machst du es dann?

    es ist klar, dass man nicht wirklich eine 100mb datei im speicher haben sollte.

    Wenn die Datei groesser als x MB ist, dann ladest du die Datei nur haeppchen Weise.

    zB liest du den ersten Block ein - wenn der User jetzt woanders hinseekt, laedts du den Block (uU halt auch mehrere Bloecke im RAM halten).
    So kostet das nachladen zwar etwas - aber ich nehme an die Algorithmen lassen sich so optimieren, dass sie nie weit seeken, so wird das nachladen minimiert.

    0
  • O

    ah shade dann haben wir uns missverstanden 😉
    directx will in solchen fällen nur ein zeiger auf das erste byte der datei im speicher und die größe der datei, also nix mit string klasse^^

    0
Anmelden zum Antworten