new [] - bad alloc bei 2GB?

Kontrasubjekt

Hey

Woran kann es liegen, dass ich einen Array von 1.95GB nicht bekomme obwohl ich 2.7 GB frei habe (laut Betriebssystem)?
Ich dachte zuerst dass eventuell das RAM fragmentiert ist und so ein großer Brocken nicht verfügbar ist, daher habe ich die 2GB in 3 Arrays von grob der selben Größe zerlegt. Aber auch hier bad_alloc. Fordere ich jedoch 1,6 - 1.7 GB an, bekomme ich die, auch in einem Stück.

Erlaubt vielleicht das BS nicht dass das freie RAM unter einen Grenzwert geht?
Wie kann ich bis zu 2,5 oder 3 GB mit einem Programm benutzen?

SeppJ

Genau 2 GB? das klingt verdächtig nach einer 31bit Grenze. Du erzeugst nicht zufällig 32bit Code?

Kontrasubjekt

1.95GB sind es, genauer 1.915.863.186 Bytes. Ja, 32 bit.

unskilled

Du magst zwar 2.35GB frei haben aber vrmtl kaum 1.95GB am Stück...
Wofür brauchst du so viel Speicher?
Wäre vll std::deque eine Alternative?

bb

Kontrasubjekt

unskilled schrieb:

Du magst zwar 2.35GB frei haben aber vrmtl kaum 1.95GB am Stück...
Wofür brauchst du so viel Speicher?
Wäre vll std::deque eine Alternative?

bb

Nein, ich brauche lowlevel arrays. Außerdem hat eine std::deque sich beim Versuch den Speicher zu holen eben aufgehängt.
Wie gesagt, auch mit kleineren Arrays komme ich nicht über 1.6 GB hinaus, sein sie 400 oder 700 MB groß.
Und nach mehrmaligen Versuchen sind irgendwie 300MB RAM verloren gegangen...

Ich brauch den Speicher für ein Netz aus Punkten in einem 3D Raum.

hustbaer

@Kontrasubjekt
Mit 32 Bit Adressraum kannst du froh sein, wenn 500MB Adressraum am Stück frei sind.
(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)

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?