new [] - bad alloc bei 2GB?
-
Willst du uns mal sagen was dein Programm mal können soll, außer viel Speicher brauchen. I wette, dass das was du vor hast auch mit viel weniger Speicher geht.
-
wetten dass schrieb:
Willst du uns mal sagen was dein Programm mal können soll, außer viel Speicher brauchen. I wette, dass das was du vor hast auch mit viel weniger Speicher geht.
Er möchte einen Software Renderer mit GPU Beschleunigung schreiben, so paradox dies auch klingen mag:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-249954-and-highlight-is-.html
-
Kontrasubjekt schrieb:
Ich verstehe noch nicht, wieso ich bei 32 bit x MB und bei 64 mehr bekommen soll, obwohl x noch unter 2GB liegt.
Dein Programm alloziert garantiert anderweitig schon Speicher, und das ist bei 64Bit dann kein Problem mehr, weil der gesamte Adreßraum deutlich größer ist. Also, was soll der Schmarrn, mach eine 64Bit Applikation draus. Alles andere ist nur Frickelei.
-
hustbaer schrieb:
Der Zugriff sollte so relativ schnell sein. Wenn du PageSize als Zweierpotenz definierst, dann wird die Divison zu einem Shift und der Modulo zu einem AND. Also beides sehr billige Operationen.
Ist jetzt natürlich bloss ein Beispiel. Ich weiss ja nicht welche Operationen (ausser Random-Access) du auf der Datenstruktur noch brauchst, und welche davon wirklich schnell sein müssen.
Leider alle. Zweierpotenz werd ich berücksichtigen, gute Idee.

Ich schätze ich habe bessere Chancen wenn ich vorher eine Ram defrag durchführen lasse, oder?
-
~john schrieb:
Also, was soll der Schmarrn, mach eine 64Bit Applikation draus. Alles andere ist nur Frickelei.
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...

-
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...
-
Kontrasubjekt schrieb:
hustbaer schrieb:
Der Zugriff sollte so relativ schnell sein. Wenn du PageSize als Zweierpotenz definierst, dann wird die Divison zu einem Shift und der Modulo zu einem AND. Also beides sehr billige Operationen.
Ist jetzt natürlich bloss ein Beispiel. Ich weiss ja nicht welche Operationen (ausser Random-Access) du auf der Datenstruktur noch brauchst, und welche davon wirklich schnell sein müssen.
Leider alle. Zweierpotenz werd ich berücksichtigen, gute Idee.

Ich schätze ich habe bessere Chancen wenn ich vorher eine Ram defrag durchführen lasse, oder?
RAM Defrag gibt's nicht. Tools die sowas angeblich können, lügen.
-
hustbaer schrieb:
Kontrasubjekt schrieb:
hustbaer schrieb:
Der Zugriff sollte so relativ schnell sein. Wenn du PageSize als Zweierpotenz definierst, dann wird die Divison zu einem Shift und der Modulo zu einem AND. Also beides sehr billige Operationen.
Ist jetzt natürlich bloss ein Beispiel. Ich weiss ja nicht welche Operationen (ausser Random-Access) du auf der Datenstruktur noch brauchst, und welche davon wirklich schnell sein müssen.
Leider alle. Zweierpotenz werd ich berücksichtigen, gute Idee.

Ich schätze ich habe bessere Chancen wenn ich vorher eine Ram defrag durchführen lasse, oder?
RAM Defrag gibt's nicht. Tools die sowas angeblich können, lügen.
Und ich hab mich schon ewig gefragt, wie die das wohl machen...
Was machen dann so ne Tools überhaupt?bb
-
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...
-
_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
-
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...)

-
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

-
_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.
-
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?
-
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.
-
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.
-
Vielleicht solltest du mal deinen Rechner ordentlich ran nehmen, damit der Speicher wieder ordenrtlich durchfragmentiert wird.
-
Defragminator schrieb:
Vielleicht solltest du mal deinen Rechner ordentlich ran nehmen, damit der Speicher wieder ordenrtlich durchfragmentiert wird.

-
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.
-
@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.