Arbeitsspeicher voll auslasten

[Tockra]

Hey Leute,

ich lerne gerade C++ und wollte einfach mal just 4 fun den kompletten Arbeitsspeicher meines Rechners verwenden.
Ich habe dies also versucht über den Heap Bereich zu schaffen:

int main() {

	for (int i = 0;; i++) {
		new int;
	}
	return 0;
}

Nun ist mir klar, dass der Heap-Bereich des Programms nicht über 100% des Speichers verfügt, den das Programm zugewiesen bekommt, allerdings habe ich aktuell 8 GB verbaut und 2,1 GB sind in verwendung. Bei Ausführung knackt das Programm allerdings nicht die Grenze von 2GB verbrauch. Also scheint der Speicher irgendwie gedeckelt zu sein.
I need infos

 

[cvzone]

Ja, wird durch das LAA Flag (Large Adress Aware Flag) der Exe beschränkt. Ohne kann ein Programm nicht mehr RAM benutzen, da der Adressierungsraum nicht ausreicht.

Aber selbst mit wirst du die 8GB nicht voll schreiben können.

 

[untot]

Im Normalfall wird nach wie vor 32 Bit kompiliert, wenn man nicht explizit etwas anderes will.
Um die 8 GB voll adressieren zu können müsstest du das ganze mit einem 64 Bit Compiler machen.

 

[Jesterfox]

Mit LAA Flag gehen 3GB. Mehr ist bei 32 Bit nicht möglich. Lösung: ein 64 Bit Programm erstellen (Compiler-Optionen entsprechend setzen)

 

[Tockra]

Okay vielen Dank. Ich dachte da auch an die größeren Spiele, die ja alle den Arbeitsspeicher voll ausnutzen.

Wie genau komilier ich denn in visual Studio 2013 Ultimate in 64 bit?

 

[Jesterfox]

Das muss in den Eigenschaften vom Projekt sein, bei Build das Platform target auf x64 stellen.

 

[Tockra]

Jo danke, habs gerade auch gefunden . Funktioniert übrigens. Habe meine 8 GB voll bekommen.

Aber mal ne ganz doofe Frage:
Wieso sollte man eigentlich nicht standartmäßig für x64 programmieren? Klar dann können die Programme nicht mehr von 32 Bit Anwendern genutzt werden, aber das ist doch mittlerweile wirklich eine Minderheit, oder gibt es andere Nachteile ?

 

[Jesterfox]

Neben dem das noch nicht alle ein 64 Bit System haben gibt's auch immer da Probleme wo man mit anderen Programmen zusammenarbeiten will per API. Mit die größte Baustelle ist da MS Office...

 

[antred]

Warum so kompliziert? Starte doch einfach den Firefox.

 

[black90]

Wieso new INT ? Nimm doch malloc(), ganz im C Style
http://www.cplusplus.com/reference/cstdlib/malloc/

Das resierviert Speicher auf dem Heap und du kannst bestimmen wie groß es sein soll.
Die Funktion gibt dir auch zurück wenn sie fehlschlägt. Damit kannst es präziser austesten.

Stack ist hingegen temporär, d.h. du betrittst eine Funktion und hast Variablen die nicht malloc() sind, dann landen sie auf dem Stack und werden beim Funktionsende wieder entsorgt. Deswegen musst auch aufpassen wenn eine Funktion Pointer zurück gibt, dass diese auf einen Heap Bereich zeigen und nicht auf den Stack !

[Heap]---[Freispeicher]---[Stack]
Den Freispeicher teilen sich Heap und Stack, wächst einer über die Grenze des anderen, knallt es.
In Java z.b. bei Stack Overflow (zu lange Rekursion).

 

[antred]

Wieso new INT ? Nimm doch malloc(), ganz im C Style

Mal, anders rum gefragt, was ist an new verkehrt? Zumal der OP ganz explizit gesagt hat, daß er C++ lernt und nicht C.

Das resierviert Speicher auf dem Heap und du kannst bestimmen wie groß es sein soll.

Das kannst du mit new genau so (ok, penibel gesehen nennt sich das dann free store und nicht heap, ist aber praktisch gesehen das selbe). char *myMem = new char[4000];

Die Funktion gibt dir auch zurück wenn sie fehlschlägt. Damit kannst es präziser austesten.

Tut new auch, nur eben in Form einer Exception (es sei denn, du parametrierst es mit std::nothrow, dann gibt's einen nullptr zurück).

 

[aphex.matze]

Hmm, wie groß ist denn ein int und welchen Wertebereich hat es dann? (Zeile 3)

 

[TrebuTurbo]

Hmm, wie groß ist denn ein int und welchen Wertebereich hat es dann? (Zeile 3)

Das ist abhängig von der Implementierung.
Wenn man im "Desktopbereich" entwickelt sind es fast immer 32bit. Das ist grob von -2 Milliarden bis +2 Milliarden.
Durch den Standard garantiert sind hingegen mindestens 16bit.

Darum am besten die Integertypen aus cstdint nutzen, denn diese haben eine garantierte Größe. Existiert z.B. kein 64bit Integer auf der Platform, ist der Typ auch nicht definiert.

 

[7H3 N4C3R]

Wieso new INT ? Nimm doch malloc(), ganz im C Style
http://www.cplusplus.com/reference/cstdlib/malloc/

Das resierviert Speicher auf dem Heap und du kannst bestimmen wie groß es sein soll.
Die Funktion gibt dir auch zurück wenn sie fehlschlägt. Damit kannst es präziser austesten.

Das wird dir wenig sagen und Speicher auch nicht auslasten, da der Speicher bei allen modernen Betriebssystem nur vorgemerkt wird, aber nicht auch tatsächlich zur Verfügung steht. Das nennt sich overcommitten. Mach mal ein malloc auf mehr GB als du RAM hast. Wird funktionieren.

Erst wenn man eine Page tatsächlich anfasst - also lesend oder schreibend darauf zugreift - wird sie tatsächlich für deinen Prozess reserviert. Läuft grob so: die CPU löst einen Pagefault aus, weil der virtuellen Adresse auf die zu zugreifen willst, kein physikalischer Speicher zugeordnet ist. Das Betriebssystem reagiert auf den Pagefault, sieht "hey der hat da was angefordert, ich geb dem jetzt auch tatsächlich den physikalischen Speicher". Erst wenn jetzt kein physikalischer Speicher zur Verfügung steht, werden vielleicht lange nicht benutzte Pages in den Swap geschoben oder irgendein Programm gekillt um Speicher zu schaffen. Unter Linux z.B. ist letzteres der allseits beliebte OOM Killer.

 

[black90]

Ähm jein. Normal werden Sachen eines aktiven Prozesses vollständig im RAM gelassen, zumindest unter Linux.
Ausgelagert werden nur inaktive Dinge, z.B. nach LRU Verfahren oder der RAM verschwendende Prozess wird abgeschossen. Windows wird dann sicher einfach nur hängen bis man Reset drückt und die manuellen kills des Taskmanager weiter ignorieren

Werde das aber noch mal testen, bin der Meinung dass malloc() schon knallt wenn das RAM voll ist.
Bei 32 Bit also nach spätestens 4GB, da dann die virtuellen Adressen durchgemapt sind und das swappen eben nicht beim aktiven Prozess stattfindet.

man page malloc()

By default, Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the memory really is available. In case it turns out that the system is out of memory, one or more processes will be killed by the OOM killer. For more information, see the description of /proc/sys/vm/overcommit_memory and /proc/sys/vm/oom_adj in proc(5), and the Linux kernel source file Documentation/vm/overcommit-accounting.

 

[wayne_757]

Das wird dir wenig sagen und Speicher auch nicht auslasten, da der Speicher bei allen modernen Betriebssystem nur vorgemerkt wird, aber nicht auch tatsächlich zur Verfügung steht. Das nennt sich overcommitten.

Diese Unix-Seuche namens overcommit gibt es unter Windows nicht. Dort gibt es auch kein fork, weshalb man auch kein overcommit benötigt.

P.S. Mag Linux mehr als Windows