new [] - bad alloc bei 2GB?

Kontrasubjekt

hustbaer schrieb:

@Kontrasubjekt
Mit 32 Bit Adressraum kannst du froh sein, wenn 500MB Adressraum am Stück frei sind.

Warum?

(Um Speicher geht's nicht - 2 GB geht auch mit nur 1GB RAM, WENN man ein 64 Bit OS hat, und einen 64 Bit Prozess verwendet)

OS ist 64 bit, nur das Programm ist 32.

Gibt es mögliche Lösungen?

SeppJ

Kontrasubjekt schrieb:

OS ist 64 bit, nur das Programm ist 32.

Gibt es mögliche Lösungen?

Du verätst uns, wieso du glaubst, lowlevel arrays zu brauchen und wir sagen dir, wieso du sie nicht brauchst

Kontrasubjekt schrieb:

(Um Speicher geht's nicht - 2 GB geht auch mit nur 1GB RAM, WENN man ein 64 Bit OS hat, und einen 64 Bit Prozess verwendet)

OS ist 64 bit, nur das Programm ist 32.

Gibt es mögliche Lösungen?

Programm für 64 Bit compilieren.

hustbaer

Kontrasubjekt schrieb:

hustbaer schrieb:

@Kontrasubjekt
Mit 32 Bit Adressraum kannst du froh sein, wenn 500MB Adressraum am Stück frei sind.

Warum?

Weil.

(Um Speicher geht's nicht - 2 GB geht auch mit nur 1GB RAM, WENN man ein 64 Bit OS hat, und einen 64 Bit Prozess verwendet)

OS ist 64 bit, nur das Programm ist 32.

Gibt es mögliche Lösungen?

Jo, 64 Bit Prozess machen.
Oder halt Speicher in kleineren Stücken anfordern. Mit kleineren Stücken kannst du wenigstens auf > 1GB kommen. Mit > 1,5 würde ich aber nicht rechnen.

Und natürlich kannst du das Bit in der PE Header setzen, das Windows mitteilt, dass dein Prozess mit 3 GB Usermode Adressraum (statt der üblichen 2 GB) klarkommt.

Kontrasubjekt

SeppJ schrieb:

Du verätst uns, wieso du glaubst, lowlevel arrays zu brauchen und wir sagen dir, wieso du sie nicht brauchst

Weil sie schneller sind als deque.

Programm für 64 Bit compilieren.

Hmm, nagut, wenn es nicht anders geht.

Weil.

Scheinbar bekomme ich regelmäßig 1,5GB.

unskilled

Kontrasubjekt schrieb:

SeppJ schrieb:

Du verätst uns, wieso du glaubst, lowlevel arrays zu brauchen und wir sagen dir, wieso du sie nicht brauchst

Weil sie schneller sind als deque.

kommt drauf an...
so bald du punkte löschst, die nicht am ende sind oder nicht nur am ende hinzufügen möchtest, ist deque 100%ig schneller...

bb

hustbaer

unskilled schrieb:

so bald du punkte löschst, die nicht am ende sind oder nicht nur am ende hinzufügen möchtest, ist deque 100%ig schneller...

sagt wer?

Scheinbar bekomme ich regelmäßig 1,5GB.

Dann freu dich
Auf 64 Bit Systemen sieht das ganze vermutlich wesentlich günstiger aus, als auf 32 Bit Systemen.
Trotzdem kannst du dich darauf nicht verlassen.

Mach einen 64 Bit Prozess draus.

Kontrasubjekt

Ich verstehe noch nicht, wieso ich bei 32 bit x MB und bei 64 mehr bekommen soll, obwohl x noch unter 2GB liegt . Bei besagten 1.95GB existiert weder einen Konflikt mit der 2GB Grenze noch mit dem maximalen Adressraum für 32bit.
Wie bekommen andere 32bit Programme so viel Speicher?

Drehleiter

Kontrasubjekt schrieb:

OS ist 64 bit, nur das Programm ist 32.

Gibt es mögliche Lösungen?

Vorausgesetzt Du links mit vc++ linker :

The /LARGEADDRESSAWARE option tells the linker that the application can handle addresses larger than 2 gigabytes. By default, /LARGEADDRESSAWARE:NO is enabled if /LARGEADDRESSAWARE is not otherwise specified on the linker line.

hustbaer

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 . Bei besagten 1.95GB existiert weder einen Konflikt mit der 2GB Grenze noch mit dem maximalen Adressraum für 32bit.
Wie bekommen andere 32bit Programme so viel Speicher?

Wie kommst du darauf dass sie das tun?
Worum geht's dir eigentlich überhaupt?
Die /LARGEADDRESSAWARE Option wurde vorgeschlagen, 64 Bit wurde vorgeschlagen...
Was willst du jetzt noch wissen?

Zieh dir vielleicht mal das Tool "VMMap" von Sysinternals, und guck dir damit den Adressraum deines Prozesses an. Dann siehst du ganz genau was wo überall belegt ist:
http://technet.microsoft.com/en-us/sysinternals/dd535533.aspx

_matze

unskilled schrieb:

Kontrasubjekt schrieb:

SeppJ schrieb:

Du verätst uns, wieso du glaubst, lowlevel arrays zu brauchen und wir sagen dir, wieso du sie nicht brauchst

Weil sie schneller sind als deque.

kommt drauf an...
so bald du punkte löschst, die nicht am ende sind oder nicht nur am ende hinzufügen möchtest, ist deque 100%ig schneller...

bb

Bist du da sicher? std::deque wird doch letztlich auch nur mit memmove, memcpy und Konsorten arbeiten. Und wieso sollte diese Implementation schneller arbeiten als was Eigenes (wenn man sich beim Programmieren nicht total blöd anstellt natürlich)? Ich lasse mich gerne eines Besseren belehren, aber ich bin da erstmal skeptisch.

Kontrasubjekt

hustbaer schrieb:

Die /LARGEADDRESSAWARE Option wurde vorgeschlagen, 64 Bit wurde vorgeschlagen...
Was willst du jetzt noch wissen?

Ich möchte wissen welches Problem dem bad_alloc zugrundeliegt. Das habe ich doch geschrieben.
Vermutet habe ich, dass der RAM fragmentiert ist und das sagen auch andere, nur frage ich mich wie ich meinen Speicher dennoch zusammentragen kann. Komme ich nicht drum herum 1.9 GB in 100MB stückchen anzufordern, oder gibt es andere Möglichkeiten?
Basierend auf dem 64 bit Vorschlag möchte ich wissen, welchen unterschied eine 64 bit Applikation macht obwohl weder der 32bit Adressraum noch der 2GB Raum überschritten wurde.
Large adress aware kann ich benutzen sobald ich über 2GB brauche. Es hat aber noch nichts mit dem aktuellen Problem zu tun, da ich nicht bei soviel bin.

Worum geht's dir eigentlich überhaupt?

Sicherstellen, dass ich genügend Speicher bekomme.

Zieh dir vielleicht mal das Tool "VMMap" von Sysinternals, und guck dir damit den Adressraum deines Prozesses an. Dann siehst du ganz genau was wo überall belegt ist:
http://technet.microsoft.com/en-us/sysinternals/dd535533.aspx

Ich gucks mir mal an, danke.

knivil

Brauchst du denn wirklich Random Access?

_matze

Mit so einem Mini-Progrämmchen kann man ja ganz schön rausbekommen, wieviel Speicher man am Stück kriegt.

int balloc=1024*1024*1024*2;
	char *arr=0;
	while(!arr) {
		balloc-=1024*1024;
		arr=(char*)realloc(arr,balloc);
	}
	printf("allocated: %d Bytes (%.2f MB)\n",balloc,balloc/1024./1024.);

Bei mir sind's im Moment genau 1450 MB (XP x64, 8 GB RAM, 32-Bit-Anwendung). Und bei euch?

volkard

_matze schrieb:

Bei mir sind's im Moment genau 1450 MB (XP x64, 8 GB RAM, 32-Bit-Anwendung). Und bei euch?

1212MB (XP32, 2GB Ram, keine Auslagerungsdatei)
1598MB (XP32, 2GB Ram, Auslagerungsdatei)
1619MB, wenn ich im BIOS-Setup die shared memory ranges runterschraube.

Ubrigens

int mb=0;
    while(malloc(1024*1024)) {
    	++mb;
			printf("allocated: %d MB\n",mb);
    }

gibt weniger MB.

Kontrasubjekt

knivil schrieb:

Brauchst du denn wirklich Random Access?

Jo.

_matze

Ins Nirwana zu allozieren gehört sich aber nicht, volkard (das darf man höchstens mit dem bcc, dem Buddha-C-Compiler).

_matze

Mit LAA-Flag komme ich auf 2047 MB (vorher 1450).

It0101

ohne LAA und mit Auslagerungsdatei unter 32Bit-WinXP mit 2GB RAM:

1987 MB

Edit: 32 Bit-Anwendung, IDE MSVC++ 6.0 !! -> alte Besen kehren gut ^^

hustbaer

Kontrasubjekt schrieb:

hustbaer schrieb:

Die /LARGEADDRESSAWARE Option wurde vorgeschlagen, 64 Bit wurde vorgeschlagen...
Was willst du jetzt noch wissen?

Ich möchte wissen welches Problem dem bad_alloc zugrundeliegt. Das habe ich doch geschrieben.

Das wurde doch schon beantwortet: es ist zu wenig zusammenhängender Adressraum vorhanden. Und ja, das nennt man "Fragmentierung".
Wenn bloss ein einzelnen Byte, genau in der Mitte des Adressraums belegt ist, hast du bereits keine Chance mehr, mehr als 1GB am Stück zu bekommen.

Nur weil das OS dem Prozess 2GB gibt, kannst du doch nicht davon ausgehen, dass nach geladenen DLLs, nach Anfordern von sonstigem Speicher, einblenden von Ranges zur Kommunikation mit den Kernel etc. auch nur annähernd 2GB übrig bleiben. Und die dann noch ab Stück.

Deine Annahme "2GB Adressraum, daher kann ich auch 2GB anfordern" ist einfach total falsch. Vollkommen. Mehr falsch geht nicht.

Komme ich nicht drum herum 1.9 GB in 100MB stückchen anzufordern, oder gibt es andere Möglichkeiten?

Wurde doch schon ca. 100x erwähnt: 64 Bit und LAA

Large adress aware kann ich benutzen sobald ich über 2GB brauche. Es hat aber noch nichts mit dem aktuellen Problem zu tun, da ich nicht bei soviel bin.

Dein Problem ist, dass du uns nicht glaubst. Natürlich bist du schon soweit. Mach es einfach. Ich verstehe nicht wieso du dich gegen eine Lösung streubst, die funktioniert, nur weil du der Meinung bist, dass du es "nicht brauchst".

Sollte die Verwendung von LAA bzw. einem 64 Bit Prozess ein Problem darstellen, dann wäre es vermutlich günstig, wenn du uns darauf hinweist, und auch verrätst WAS du denn da genau für ein Problem siehst.

Ansonsten, wie gesagt, bitte mach es einfach.