Speicher allokierung eines sehr großen Arrays
-
ne darum gehts nich. Wenn ich das selbe mit int oder short oder irgendwas anderem mach und auf über 500mb komm kommt bad alloc.
-
bad_alloc bedeutet (afair), daß du nicht genug Speicherplatz für den Aufruf zur Verfügung hast (und Windows benötigt selber auch noch etwas Platz, so daß du irgendwo an der Grenze dessen ankommst, was du verwenden darfst).
PS: Hast du mal probiert, ob du das Array aufteilen und stückweise allocieren darfst? Oder kracht es auch, wenn du zwei 250MB-Blöcke nacheinander anfordern willst.
PPS: nur aus Neugierde: Wozu benötigst du so viel Speicher?
-
Nun genug Speicher ist eigentlich frei (meistens so ca. 1,3gb )
das mit dem Stückweisen allocieren muss ich mal ausprobieren.PPS: nur aus Neugierde: Wozu benötigst du so viel Speicher?
Für Mein Sieb des Eratosthenes (soll bis 4mrd laufen) daher brauch ich 4mrd bool werte, ich speicher die schon in unsigened shorts aber bei 500mb is halt trotzdem komischerweise schluss.
-
Es kommt noch ein Faktor dazu, nämlich die Fragmentierung des Adressraumes.
Wenn dein Programm z.B. eine DLL braucht, die eine "preferred base address" von 0x40000000 hat, dann liegt die mitten in dem für Usermode Programme verfügbaren Bereich von 2GB, und teilt ihn dadurch in 2 Bereiche von etwa 1GB. Selbst wenn also 2GB Speicher verfügbar wären kann das Betriebssystem einfach keinen Bereich > 1GB mehr hergeben, da der Adressraum einfach nichtmehr frei ist.Die meisten Windows DLLs haben zwar eine recht "brave" preferred base address, nämlich am oberen Ende des Usermode Adressraumes, so dass der Adressraum darunter nicht zerstückelt wird, aber es gibt auch ein paar die bei 0x4xxxxxxx ober 0x5xxxxxxx liegen.
Und selbstgebastelte DLLs liegen oft bei 0x10000000 (weil viele vergessen die "preferred base address" umzustellen, und das der Defaultwert von Visual C++ ist).Alles zusammen kann es also leicht passieren dass weniger als 1GB zusammenhängender Adressraum frei sind.
----
15 * 100MB anfordern wird also wesentlich öfter gutgehen als 1x 1,5GB.
-> wenn man so grosse Puffer auf einem 32 Bit System braucht sollte man also evtl. darüber nachdenken ob man diesen grossen Puffer nicht in mehrere kleinere zerteilen kann -- die bringt das System dann leichter wo unter.Mit einem 64 Bit Programm (was dann natürlich ein 64 Bit System braucht) hat man solche Probleme natürlich nicht so schnell -- der Usermode Bereich für 64 Bit Programme ist unter Win64 im Moment 8 Terabyte gross.
-
p.S.: wenn du bloss 4 Milliarden bools unterbringen willst, dann nimm doch einfach pro bool ein Bit. Entweder über std::vector<bool>, oder "handgestrickt".
Für 4 Mrd bools brauchst du schliesslich nicht mehr als 500MB Speicher. Und wenn du alle geraden Zahlen weglässt kommst du sogar mit 250MB aus. Und 250MB sollten auf jedem System leicht verfügbar sein. Auch zusammenhängend.
-
walljumper schrieb:
Nun genug Speicher ist eigentlich frei (meistens so ca. 1,3gb )
Aber ich glaube kaum, daß Windows diesen freien Speicher komplett für deinen Heap zur Verfügung stellen wird (da fällt auf jeden Fall der Platz für deinen Stack und Datensegment weg - von BS-eigenen Verwaltungsdaten und möglicher Heap-Segmentierung gar nicht zu reden).
PPS: nur aus Neugierde: Wozu benötigst du so viel Speicher?
Für Mein Sieb des Eratosthenes (soll bis 4mrd laufen) daher brauch ich 4mrd bool werte, ich speicher die schon in unsigened shorts aber bei 500mb is halt trotzdem komischerweise schluss.
Hat das einen praktischen Nutzwert oder wolltest du nur ausloten, was dein System aushält? An Optimierungen würde mir noch einfallen, nur ungerade Zahlen in deinem Array zu lagern (das verdoppelt schonmal die Kapazitäten), nur ein Bit pro Zahl abzulegen (damit bekommst du 16 bool-Werte in ein unsigned short) oder im Notfall auf die Festplatte auszuweichen.
-
Hmm ok das sind schonmal paar gute ideen. Dlls verwendet mein Programm keine.
Nur ungerade Zahlen speichern is schonmal nicht schlecht werd ich implementieren, aber am grundsätzlichen Problem ändert das nichts wenn ich den Bereich bis 8 mrd erweitere wäre wieder Schluss.Ein Bit pro Bool verwende ich bereits (handgestrikt)
Segmentieren hatt ich sowieso vor. Also auch gute idee
Mhh 64 Bit OS könnt ich nur aufm Laptop linux draufhauen und das klappt ja nich immer so toll.
-
hustbaer schrieb:
Und selbstgebastelte DLLs liegen oft bei 0x10000000 (weil viele vergessen die "preferred base address" umzustellen, und das der Defaultwert von Visual C++ ist).
hm guter Tipp
Wo kann man das denn im VS genau einstellen?
-
Pellaeon schrieb:
hustbaer schrieb:
Und selbstgebastelte DLLs liegen oft bei 0x10000000 (weil viele vergessen die "preferred base address" umzustellen, und das der Defaultwert von Visual C++ ist).
hm guter Tipp
Wo kann man das denn im VS genau einstellen?Naja, in den Projekteinstellungen.
Beim 2005er unter Linker -> Advanced -> Base Address.
-
oha ok das habe ich gefunden.
und was trägt man da jetz sinnvoll ein?
(Das sind so Sachen, die stehen leider kaum in Büchern, wenns um DLLs geht . Zumindest stands in keinem, dass ich gelesen habe^^)Also ich hab da "Basisadresse", da könnt ich jetzt einfach eine feste Adresse eintragen und "Feste Basisadresse". Das steht bei mir auf Standard, was "FIXED:[nein]" bedeutet laut Angaben in der IDE. Weis damit jetzt nicht wirklich viel anzufangen.
-
Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum MFC (Visual C++) verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Naja ob der Thread hier besser aufgehoben ist sei mal dahingestellt. Jedenfalls konnte ich mein Problem lösen, es lag wirklich daran das kein zusammenhängender Block von 500mb gefunden werden konnt mit 1mb blöcken konnte ich 1,2gb allokieren.
