3. new [] - bad alloc bei 2GB?

new [] - bad alloc bei 2GB?

  • _

    unskilled schrieb:

    Und ich hab mich schon ewig gefragt, wie die das wohl machen...
    Was machen dann so ne Tools überhaupt?

    bb

    http://www.chip.de/artikel/Geprueft-Diese-Tuning-Tools-helfen-wirklich-6_30428390.html

    Ziemlich billig, und im Anschluss dürfte es ewig dauern, bis der ganze Kram, der benötigt wird, wieder von der Auslagerungsdatei zurückgeschaufelt wurde...

    0
  • U

    _matze schrieb:

    unskilled schrieb:

    Und ich hab mich schon ewig gefragt, wie die das wohl machen...
    Was machen dann so ne Tools überhaupt?

    bb

    http://www.chip.de/artikel/Geprueft-Diese-Tuning-Tools-helfen-wirklich-6_30428390.html

    Ziemlich billig, und im Anschluss dürfte es ewig dauern, bis der ganze Kram, der benötigt wird, wieder von der Auslagerungsdatei zurückgeschaufelt wurde...

    Jopp - imho war das aber nur _ein_ Weg?! Hatte mich vor Ewigkeiten mal damit beschäftigt und ich dachte, dass die meisten RAM-Tools noch eine andere Option geboten hätten, die ich aber nie ganz verstanden hatte xD

    bb

    0
  • _

    Wenn ich sowas hier lese, wird mir echt schlecht: http://tipps4you.de/tipp-153-winxp.html (das ist wohl die "Nullen-Mwthode" auf's Wesentliche reduziert...)

    😮 😃

    0

  • It0101 schrieb:

    Vielleicht sollte er einfach sein Softwarekonzept nochmal überdenken.

    Ich kenne 3 Leute, die sich mit Renderen beschäftigen und keiner von denen wollte jemals 2GB allokieren...

    Vielleicht braucht er garkeine 2GB, sondern will bloss das Maximum rausholen. Was auch immer das Maximum ist.

    Keine Ahnung.

    Sagt er leider nicht 🙂

    0
  • *

    _matze schrieb:

    Das widerspricht ja der Vorgabe, dass die Anwendung auch unter x86 laufen soll. Andererseits widerspricht dem der Wunsch, 2 GB am Stück zu allozieren... toll, jetzt bin ich verwirrt... 😉

    Eine der beiden Vorgaben ist unrealistisch.

    0
  • V

    Warum nehmt Ihr eigentlich an, man können mehr Speicher bekommen, wenn man den Speicher nicht am Stück haben muß? Kennt jemand eine Freispeicherimplementierung, wo der Freispeicher nicht am Stück ist?

    0

  • volkard schrieb:

    Warum nehmt Ihr eigentlich an, man können mehr Speicher bekommen, wenn man den Speicher nicht am Stück haben muß? Kennt jemand eine Freispeicherimplementierung, wo der Freispeicher nicht am Stück ist?

    Äh.
    Alle?
    Unter Windows ist es garantiert so. Kannst du ja ausprobieren wenn dus nicht glaubst.

    0
  • V

    Mein Windows ist wohl kaputt. Ich kriege mit wiederholtem kleinen VirtualAlloc nicht mehr Speicher als bei einem großen. Vielleicht habe ich nur mit der Hardware Glück gehabt.

    0
  • ?

    Vielleicht solltest du mal deinen Rechner ordentlich ran nehmen, damit der Speicher wieder ordenrtlich durchfragmentiert wird.

    0
  • ?

    Defragminator schrieb:

    Vielleicht solltest du mal deinen Rechner ordentlich ran nehmen, damit der Speicher wieder ordenrtlich durchfragmentiert wird.

    😃 👍

    0
  • V

    Defragminator schrieb:

    Vielleicht solltest du mal deinen Rechner ordentlich ran nehmen, damit der Speicher wieder ordenrtlich durchfragmentiert wird.

    Das hilft ja nichts. Selbst wenn ich in den physikalischen Speicher Knoten mache, werden dessen Speicherseiten in den virtuellen Speicher des neuen Prozesses nicht fragmentiert eingeblendet, wozu auch?
    Fragmentierung in meinem Prozess bekomme ich durch eigene new-Aufrufe, wenn ich es drauf anlege. Das ist bestimmt nicht der Fall, wenn ich nur frühzeitig einen großen Happen Speicher anlege.

    0

  • @volkard:
    Der Adressraum wird nicht nur durch eigene "new" fragmentiert, sondern durch
    * PE Images die eingeblendet werden
    * Stacks
    * Shared Memory Bereiche welche von diversen DLLs verwendet werden
    etc.

    Auf meinem System (Win 7 x64) liegt die NTDLL.DLL in 32 Bit Prozessen z.B. bei 0x77570000. Dahinter kommen dann z.B. schonmal ~120MB freier Speicher.

    Ein Prozess der die VC++ Runtime DLL verwendet, und im Prinzip nichts tut ("_getch(); return 0;"), hat ca. 1,7 GB am Stück liegen, und nochmal fast 200MB frei in kleineren Stücken.

    Man kann nicht davon ausgehen, dass der freie Adressraum nicht fragmentiert wäre. Dass der Unterschied im Idealfall klein ist, ist schön. Verlassen würde ich mich trotzdem nicht darauf.

    Ein 32 Bit Programm das sich darauf verlässt > 1,5 GB zusammenhängenden Speicher zu bekommen, würde ich ganz einfach kaputt nennen. Bzw. persönlich würde ich die Grenze was ich für "OK" halte noch viel niedriger ansetzen.

    Und mit dem LAA Flag wird die Sache nurnoch schlimmer. Die Adresse der NTDLL.DLL ändert sich ja dadurch nicht, nur dass danach nicht bloss 120MB freier Adressraum kommen, sondern etwa 1GB.

    0
  • ?

    volkard schrieb:

    Fragmentierung in meinem Prozess bekomme ich durch eigene new-Aufrufe, wenn ich es drauf anlege. Das ist bestimmt nicht der Fall, wenn ich nur frühzeitig einen großen Happen Speicher anlege.

    Der User will die fancy 2GB Funktion aber erst einschalten, nachdem er 2 Stunden mit deinem Programm gearbeitet hat.

    0
Anmelden zum Antworten