Rekursionstiefe und Exceptions
-
Caligulaminus schrieb:
Skym0sh0 schrieb:
Mein Rechner hat 16GB RAM [..] Wieso lässt mich mein OS oder der Compiler nur [..]
Caligulaminus schrieb:
Ist das 'n 64-Bit-Build?
Skym0sh0 schrieb:
Nein.
...
Typisches Vorurteil. Windows 32 kann mit PAE die ganzen 16GB nutzen. Nur einzelne Applikationen sind auf 4GB begrenzt, dafür sind diese schneller weil Pointer kompakter dargestellt sind.
-
pae schrieb:
Caligulaminus schrieb:
Skym0sh0 schrieb:
Mein Rechner hat 16GB RAM [..] Wieso lässt mich mein OS oder der Compiler nur [..]
Caligulaminus schrieb:
Ist das 'n 64-Bit-Build?
Skym0sh0 schrieb:
Nein.
...
Typisches Vorurteil. Windows 32 kann mit PAE die ganzen 16GB nutzen. Nur einzelne Applikationen sind auf 4GB begrenzt, dafür sind diese schneller weil Pointer kompakter dargestellt sind.
Unabhängig davon wieviel Speicher das Betriebsystem verwenden kann, standardmäßig sind Prozesse auf 2gb beschränkt, weil angenommen wird das viel Platz für DLLs und andere geteilte Daten benötigt werden. Lösung: http://msdn.microsoft.com/en-us/library/wz223b1z.aspx
-
pae schrieb:
Typisches Vorurteil. Windows 32 kann mit PAE die ganzen 16GB nutzen. Nur einzelne Applikationen sind auf 4GB begrenzt
Geht es hier um mehr als eine?
Skym0sh0 schrieb:
Ja ok, ich kann mit 32Bit nur 4GB adressieren. Aber das sind immer noch weiter mehr als 2Gb...
Win32 rückt m.W. nur ~2G pro Prozess rum.
-
Skym0sh0 schrieb:
Bashar schrieb:
Ich versteh nicht, wieso du immer noch fragst.
Weil es anfangs hieß, dass jeder dumme Compiler das wegoptimiert.
Das stimmt erstens nicht, und zweitens höchstens, wenn die Optimierung aktiviert ist.
Ausserdem hätte es ja sein können, dass Visual Studio der Benutzerfreundlichkeit oder was, im Debugmodus irgendwelchen Nichtexistenten Quellcode zeigt (wie z.B. bei Releasecompilierungen)
Im Call-Stack-Fenster im Debugger steht hoffentlich kein Quelltext, sondern die gegenwärtige Aufrufhierarchie. Und da türmen sich entweder die rekursiven Aufrufe oder sie tun es nicht.
-
pae schrieb:
Windows 32 kann mit PAE die ganzen 16GB nutzen.
Das ist theoretisch korrekt, praktisch aber völlig falsch. Die meisten Windows-Systeme, die einem so unterkommen, können kein PAE - Microsoft verkauft dies als Enterprise-Feature, für das man gefälligst eine der teureren Server-Versionen kaufen soll. Siehe auch http://msdn.microsoft.com/en-us/windows/hardware/gg487503.aspx
pae schrieb:
Nur einzelne Applikationen sind auf 4GB begrenzt, dafür sind diese schneller weil Pointer kompakter dargestellt sind.
Das ist mindestens eine sinnentstellend vereinfachte Darstellung. Die breiteren Zeiger können zu einem Performanceverlust führen, weil mit ihnen eine größere zu verarbeitende Datenmenge einher geht, aber es gibt viele Bereiche, in denen die neuen 64-Bit-Instructions große Geschwindigkeitsvorteile bringen -- memcmp, strlen und derlei können kräftig davon profitieren, dass sie in doppelt so großen Schritten arbeiten können. GMP holt aus dem gleichen Grund für einige Operationen nochmal grob Faktor 4 raus.
64-Bit-Binaries bedeuten nicht automatisch einen Performancegewinn, aber sie gegenüber 32-Bit-Builds als generell langsamer darzustellen, geht an der Realität vorbei.
-
seldon schrieb:
pae schrieb:
Windows 32 kann mit PAE die ganzen 16GB nutzen.
Das ist theoretisch korrekt, praktisch aber völlig falsch. Die meisten Windows-Systeme, die einem so unterkommen, können kein PAE - Microsoft verkauft dies als Enterprise-Feature, für das man gefälligst eine der teureren Server-Versionen kaufen soll. Siehe auch http://msdn.microsoft.com/en-us/windows/hardware/gg487503.aspx
Da widerspricht dir deine Quelle etwas. Es wird sehr wohl PAE unterstützt und verwendet. Ohne dem wäre das No-Execution-Bit nicht verwendbar, welches seit Windows XP mit SP 2 unterstützt wird. Die Begrenzung auf 4GB ist künstlich (Lizenz und Treiber Probleme).
seldon schrieb:
pae schrieb:
Nur einzelne Applikationen sind auf 4GB begrenzt, dafür sind diese schneller weil Pointer kompakter dargestellt sind.
Das ist mindestens eine sinnentstellend vereinfachte Darstellung. Die breiteren Zeiger können zu einem Performanceverlust führen, weil mit ihnen eine größere zu verarbeitende Datenmenge einher geht, aber es gibt viele Bereiche, in denen die neuen 64-Bit-Instructions große Geschwindigkeitsvorteile bringen -- memcmp, strlen und derlei können kräftig davon profitieren, dass sie in doppelt so großen Schritten arbeiten können. GMP holt aus dem gleichen Grund für einige Operationen nochmal grob Faktor 4 raus.
64-Bit-Binaries bedeuten nicht automatisch einen Performancegewinn, aber sie gegenüber 32-Bit-Builds als generell langsamer darzustellen, geht an der Realität vorbei.
Ich habe das so verstanden das es an dieser Stelle um 32-Bit mit PAE ging und nicht um 64-Bit. 32-Bit mit PAE hat keinerlei Vorteile gegenüber der normalen 32-Bit Ausführung, aber ein aufwändigeres Paging. Das kann nur langsamer sein.
-
Skym0sh0 schrieb:
= keine Tailrekursion?!
Im DebugßModus wird dein Compiler diese Optimierung auch schwer vornehmen.
-
knivil schrieb:
Skym0sh0 schrieb:
= keine Tailrekursion?!
Im DebugßModus wird dein Compiler diese Optimierung auch schwer vornehmen.
Hä?
Und genau solche Aussagen verwirren total. Heisst das jetzt, dass die Optimierungvorgenommen wird und das Wort "schwer" das unterstreichen soll. Oder heisst das, dass es eben nicht optimiert wird, weils schwer geht?!
-
Ob dein Compiler tail-call-Optimierung durchfuehrt, siehst du nur am generiertem Maschinencode. Gewoehnlich wird im Debugbuild keine Optimierung vorgenommen, d.h. auch keine tail-calls aufgeloest. D.h. der Debugger hilft dir nicht. Zwar gibt es XYZ-Optionen mancher Compiler, die Optimierung auch bei Debugbuilds aktivieren, ist aber nicht der Regelfall.
-
Heisst das jetzt, dass die Optimierungvorgenommen wird und das Wort "schwer" das unterstreichen soll.
Sieht nach einem Anglizismus aus ("hardly" falsch übertragen).
-
"Es ist schwer moeglich" ist eine Redewendung, hat nichts mit Angel zu tun und ist weit ueber Sachsen hinaus bekannt. Wenn etwas bspw. fuer den Compiler schwer ist, so muss er entsprechend unterstuetzt werden. In diesem Fall muss ihm gesagt warden: Obwohl es ein Debugbuild ist, versuche doch Endrekursion als Iteration aufzuloesen. Ob er es dann schafft, ist eine andere Frage. Es kann fuer ihn ebenfalls schwer sein und bedarf der Unterstuetzung durch Umstrukturierung des Codes.
-
@pae
pae schrieb:
Typisches Vorurteil. Windows 32 kann mit PAE die ganzen 16GB nutzen. Nur einzelne Applikationen sind auf 4GB begrenzt, dafür sind diese schneller weil Pointer kompakter dargestellt sind.
Typisches Halbwissen.
32 Bit Desktop Windows Versionen können insgesamt nur 4 GB verwenden, auch mit PAE. Weil Windows dieses Limit absichtlich eingebaut hat.
Sogar die "günstigen" 32 Bit Standard Server Versionen haben dieses Limit.
Einzig die teuren "Datacenter" oder "Advanced" 32 Bit Versionen verwenden mehr als 4 GB (abgesehen von 64 Bit Versionen natürlich, die das alle können).
Wobei dort natürlich immer noch das 2 bzw. 3 GB Limit für Usermode Adressraum pro Prozess gilt (bzw. knapp 4 GB auf 64 Bit Windows Versionen).Wer mehr verwenden will muss also ein 64 bittiges Windows verwenden oder $$$$ für ne teure 32 Bit Advanced/Datacenter/... Server Lizenz hinlegen (sinnlos).
@seldon
PAE kann so ziemlich jede Windows Version seit Windows XP. Nur dass PAE Support bei Windows nicht gleichbedeutend mit "mehr als 4 GB nutzen können" ist. Weil das OS wie gesagt ein Limit eingebaut hat. D.h. du kannst die PAE Funktionen verwenden, funktioniert alles super, aber mehr als 4 GB kannst du damit trotzdem nicht verwenden.Das Limit greift auf die physikalische Adresse des RAMs. Daher bleiben dann in Wirklichkeit sogar noch weniger als 4 GB übrig -- man verliert den Teil der zur Kommunikation mit diverser Hardware (Chipset, Grafikkarte, ...) verwendet wird. Und dieses Adress-Limit gilt eben auch für RAM das über die PAE Extensions angesprochen wird.
--------------
Hier ein Artikel wo das ganze gut erklärt wird: http://geoffchappell.com/notes/windows/license/memory.htm
Und hier ein Artikel mit Anleitung & Link zu einem Tool mit dem man das Limit rauspatchen kann: http://www.raymond.cc/blog/make-windows-7-and-vista-32-bit-x86-support-more-than-4gb-memory/
Und noch ein Artikel von Mark Russinovich mit weniger Details, der das 4 GB Limit aber auch bestätigt: http://blogs.technet.com/b/markrussinovich/archive/2008/07/21/3092070.aspx
-
knivil schrieb:
Ob dein Compiler tail-call-Optimierung durchfuehrt, siehst du nur am generiertem Maschinencode.
Im Callstack sollte man es auch sehen, oder?
Also wenn man im Callstack die Rekursion sieht, dann ist sie vermutlich auch wirklich da. Wenn man sie nicht sieht, ist sie sicher nicht da.
-
hustbaer schrieb:
Also wenn man im Callstack die Rekursion sieht, dann ist sie vermutlich auch wirklich da. Wenn man sie nicht sieht, ist sie sicher nicht da.
Ja schon, aber das Dilemma ist ja, dass ich im Debugmodus erwarte, dass er die Endrekursion nicht aufloest. Sie wird also da sein. Erfahrung mit Debuggen im Releasemode habe ich nur wenig. D.h. ich Weiss nicht ob er im Releasebuild Zusatzinfos eibaut, um dann beim Debuggen zu sagen: hey du hast grad Funktion XY aufgerufen, auch wenn dass so im Machinencode nicht steht. Warum koennte der Compiler/IDE sowas machen: Weil er im Debugmodus laeuft.
-
Ich meinte nur man könnte auch erstmal den Release-Build im Debugger anwerfen, und wenn man da die Rekursion im Callstack nicht sieht, dann kann man ziemlich sicher sein dass der Compiler sie auch entfernt hat.
Man muss also nicht unbedingt den Assembler-Code checken.Ob Compiler Tail-Recursion im Debug Mode wegmachen oder nicht weiss ich nicht, hab ich ehrlich gesagt noch nie ausprobiert.
-
Wie definiert ihr denn einen Debug-Modus? Ist mir noch nie aufgefallen, dass Compiler sowas haben. Ich kann NDEBUG definieren oder nicht, ich kann Optimierungen einschalten oder nicht, ich kann Debugsymbole erstellen lassen oder nicht, ich kann die Library mit oder ohne Debuginformationen linken etc., das ist alles separat voneinander. Ich habe beim VC++ natürlich vordefinierte Debug- und Release-Konfigurationen, aber das ist auf IDE-, nicht auf Compilerebene.
-
Kurze Frage: Weiss jemand aus dem Kopf wie viel Speicher mir mein Betriebsystem geben kann?
Windows 8 Prof. 64 Bit
Das LAA-Flag ist aktiviert.Theoretisch sollte ich ja damit 2^64 Byes (müssten wenn ich mich jetzt nicht vertue 16 Exabyte sein) adressieren können.
Praktisch kommen mir meine "nur" 16GB Ram und meine 3 terabyte HDD (für die etwaige Auslagerungsdatei) in die Quere.Bei einem kleinen Test, der aber eher vertrauensunwürdig ist, hab ich den verdacht erlangt, das ich an 64GB rankomme. Irgendwo im Web hab ich das auch bestätigt gefunden, aber andere Quellen sagten 128GB.
Hat da jemand ne Idee von euch?
Edit: AHA! Sowas hab ich gesucht gehabt. Ok, das machts mir was klarer.
