Das Ende des 32Bit-Adressraum

[odenter]

Na zum Beispiel das setzen der Bootoptionen. Das setzen des Flags IMAGE_FILE_LARGE_ADDRESS_AWARE macht erstmal gar nichts, ausser das der Header des erzeugten Binaries an einigen Stellen ein paar Flags gesetzt oder nicht gesetzt hat.

Ob und wie diese Option greift ist hier beschrieben:
http://msdn.microsoft.com/en-us/library ... 85%29.aspx

Ich kann ehrlich gesagt nicht glauben das es auf einem 32 Bit OS nicht lief, und nach setzen dieses Schalters ohne weitere Konfiguration am OS dann doch auf einmal lief nachdem es neu gebaut/gelinkt wurde.

EDIT:
Unter einem 64 Bit OS bekommt ein 32 Bit Prozess immer 4 GB Userspace.

[joggel]

Ich kann ehrlich gesagt nicht glauben das es auf einem 32 Bit OS nicht lief, und nach setzen dieses Schalters ohne weitere Konfiguration am OS dann doch auf einmal lief nachdem es neu gebaut/gelinkt wurde.

Ist schon ne Weile her als dieses Problem auftauchte.. ich lege jetzt mal nicht meine Hand dafür ins Feuer.
Aber soweit mich meine Erinerung nicht täuscht, liefs :)

[dot]

Unter einem 64 Bit OS bekommt ein 32 Bit Prozess immer 4 GB Userspace, egal ob das Flag gesetzt ist oder nicht.

Nein. Eben nur wenn das Flag gesetzt ist.

Ich kann ehrlich gesagt nicht glauben das es auf einem 32 Bit OS nicht lief, und nach setzen dieses Schalters ohne weitere Konfiguration am OS dann doch auf einmal lief nachdem es neu gebaut/gelinkt wurde.

Tat es ja nicht. Es lief dann als 32bit Prozess auf einem 64bit OS, eben weil es dort dann 4GB bekam...

[odenter]

Unter einem 64 Bit OS bekommt ein 32 Bit Prozess immer 4 GB Userspace, egal ob das Flag gesetzt ist oder nicht.

Nein. Eben nur wenn das Flag gesetzt ist.

Stimmt gerade überprüft.

Unter einem 64 Bit OS bekommt ein 32 Bit Prozess immer 4 GB Userspace, egal ob das Flag gesetzt ist oder nicht.

Nein. Eben nur wenn das Flag gesetzt ist.

Ich kann ehrlich gesagt nicht glauben das es auf einem 32 Bit OS nicht lief, und nach setzen dieses Schalters ohne weitere Konfiguration am OS dann doch auf einmal lief nachdem es neu gebaut/gelinkt wurde.

Tat es ja nicht. Es lief dann als 32bit Prozess auf einem 64bit OS, eben weil es dort dann 4GB bekam...

Hier ging es aber doch um 32 Bit Prozesse unter einem 32 Bit OS oder nicht?
Und eben da bringt das setzen der Option nichts, ohne weitere Schritte. Nichts anderes habe ich behauptet.

[dot]

Hier ging es aber doch um 32 Bit Prozesse unter einem 32 Bit OS oder nicht?
Und eben da bringt das setzen der Option nichts, ohne weitere Schritte. Nichts anderes habe ich behauptet.

...was ich schon in meinem ersten Post hier geschrieben hab. Das macht das Flag aber trotzdem weder Sinnlos, noch zu einer Notlösung oder einer Bastelei...

[Schrompf]

Zusammenfassung meiner Erfahrung:

Vorher:
std::bad_alloc sowohl bei mir (Windows7 64) als auch bei Andre (Windows7 32)

Nach Compiler-Flag /LARGE_ADDRESS_AWARE:
bei mir lief es prima (Windows7 64), bei Andre immernoch der gleiche Crash(Windows7 32)

Nach zusätzlichem User Address Space via "BCDEdit /set increaseuserva 2500"
bei mir lief es prima (Windows7 64), bei Andre jetzt auch (Windows7 32)

Ich denke, wir reden hier also alle vom selben Phänomen :-) Ob das nun ein Hack ist oder nicht, ist Anssichtssache. Ich würde kein Spiel damit ausliefern wollen, aber bei einem Tool für ein paar Team-Mitglieder stört es mich nicht.

[odenter]

Hier ging es aber doch um 32 Bit Prozesse unter einem 32 Bit OS oder nicht?
Und eben da bringt das setzen der Option nichts, ohne weitere Schritte. Nichts anderes habe ich behauptet.

...was ich schon in meinem ersten Post hier geschrieben hab. Das macht das Flag aber trotzdem weder Sinnlos, noch zu einer Notlösung oder einer Bastelei...

Richtig ich habe auch auf Dich verwiesen, was die Punkte anging.
Ich sehe diese Schalter /3GB, PAE und AWE als Bastellösungen, dann lieber gleich 64 Bit --> Thema erledigt.

[dot]

Ich sehe diese Schalter /3GB, PAE und AWE als Bastellösungen.

Was den /3GB Switch angeht, so kann ich das nachvollziehen. Aber was PAE und AWE betrifft, versteh ich nicht was daran eine Bastellösung sein soll!? Ich hoffe dir ist klar, dass diese Dinge sehr viel älter sind als 64bit...

[odenter]

Ich sehe diese Schalter /3GB, PAE und AWE als Bastellösungen.

Was den /3GB Switch angeht, so kann ich das nachvollziehen. Aber was PAE und AWE betrifft, versteh ich nicht was daran eine Bastellösung sein soll!?

Ok ich muss das weiter präzisieren. :)

Nur damit wir von dem gleichen reden PAE:
http://msdn.microsoft.com/en-us/library ... 85%29.aspx
Ich gehe im Moment nach wie vor von 32 Bit Betriebssystemen aus, nicht von einem 64 Bit OS.
Also unter einem 32 Bit OS ist PAE auf einer x86 Maschine gebastel. Es ist der Workaround doch mehr als 4GB anzusprechen.
Wenn Du sagst Du brauchst mehr als 4GB auf einem 32 Bit System, dann würde ich fragen wieso nimmste kein 64Bit? Oder pass halt Dein design an. :)


Nur damit wir von dem gleichen reden AWE:
http://msdn.microsoft.com/en-us/library ... 85%29.aspx
Mit AWE verbinde ich den MSSQL-Server und massive Probleme mit dem Server. Vielleicht schlecht implementiert (MS halt), vielleicht fehlte eine Konfigurationsoption im Server. Vielleicht wars noch irgendwie buggy, wer weiss. Bei mir hat sich das als Bastelei im Kopf festgesetzt.
Wenn Du mir ne Software zeigst die damit ohne Probleme läuft ändere ich vielleicht meine Meinung.

Diese beiden "PAE" und "AWE" sind sicher nicht älter als 64 Bit Betriebssysteme oder CPU's im allgemeinen. Was Windows Systeme angeht möglicherweise schon, und genau deshalb sind es die Workarounds. MS hat ja ein bischen gebraucht bis die ein brauchbares 64 Bit System für Desktops liefern konnte.

[dot]

Ich gehe im Moment nach wie vor von 32 Bit Betriebssystemen aus, nicht von einem 64 Bit OS.
Also unter einem 32 Bit OS ist PAE auf einer x86 Maschine gebastel. Es ist der Workaround doch mehr als 4GB zu anzusprechen.
Wenn Du sagst Du brauchst mehr als 4GB auf einem 32 Bit System, dann würde ich fragen wieso nimmste kein 64Bit? Oder pass halt Dein design an. :)

Ich glaub du hast da was falsch verstanden. Einem Prozess auf einem 32bit System mehr als 4GB RAM zur Verfügung zu stellen ist eben nicht der wesentliche Zweck von PAE. Der Sinn von PAE ist, dass das Betriebssystem mehr als 4GB RAM verwalten kann.
Mit PAE kann ich ein 32bit System auf einer x86 Maschine mit mehr als 4GB RAM laufen lassen und dabei den gesamten RAM nutzen, auch wenn jeder einzelne Prozess dabei nicht mehr als 2GB vom Kuchen bekommt.

AWE ist eine API, die es einem speicherintensiven Prozess ermöglicht, in einem beschränkten Adressraum mit physikalischem Speicher jenseits der Grenzen dieses Adressraums umzugehen. Mehr oder weniger eigentlich nichts anderes als mmap(), nur eben für Speicher. Für Anwendungen wie z.B. irgendwelche riesigen Datenbankserver doch sehr sinnvoll, wenn du mich fragst.

Rein konzeptionell sind PAE und AWE völlig orthogonal.
Aber natürlich wird der Zugriff über AWE auf Speicher jenseits von 4GB auf einem 32bit System auf x86 vom OS durch PAE realisiert werden...

"Bastelei" kann ich in beiden Fällen eigentlich keine erkennen.

PAE gibts seit dem Pentium Pro (1995), AWE seit Windows XP (2001).

MS hat ja ein bischen gebraucht bis die ein brauchbares 64 Bit System für Desktops liefern konnte.

Zwei Jahre find ich jetzt ehrlich gesagt nicht wirklich lange für sowas (die erste x64 CPU kam 2003 raus, die x64 Edition von Windows XP 2005)...

[odenter]

Ich gehe im Moment nach wie vor von 32 Bit Betriebssystemen aus, nicht von einem 64 Bit OS.
Also unter einem 32 Bit OS ist PAE auf einer x86 Maschine gebastel. Es ist der Workaround doch mehr als 4GB zu anzusprechen.
Wenn Du sagst Du brauchst mehr als 4GB auf einem 32 Bit System, dann würde ich fragen wieso nimmste kein 64Bit? Oder pass halt Dein design an. :)

Ich glaub du hast da was falsch verstanden. Einem Prozess auf einem 32bit System mehr als 4GB RAM zur Verfügung zu stellen ist eben nicht der wesentliche Zweck von PAE. Der Sinn von PAE ist, dass das Betriebssystem mehr als 4GB RAM verwalten kann.
Mit PAE kann ich ein 32bit System auf einer x86 Maschine mit mehr als 4GB RAM laufen lassen und dabei den gesamten RAM nutzen, auch wenn jeder einzelne Prozess dabei nicht mehr als 2GB vom Kuchen bekommt.

Schon klar.
Warum brauche ich das?
Nimm doch ne echte 64 Bit CPU mit 64 Bis OS und schreibe ne 64 Bit Anwedung, dann brauchste solche Workarounds nicht.

AWE ist eine API, die es einem speicherintensiven Prozess ermöglicht, in einem beschränkten Adressraum mit physikalischem Speicher jenseits der Grenzen dieses Adressraums umzugehen. Mehr oder weniger eigentlich nichts anderes als mmap(), nur eben für Speicher. Für Anwendungen wie z.B. irgendwelche riesigen Datenbankserver doch sehr sinnvoll, wenn du mich fragst.

Sehe ich anders. Das sind die MS Workarounds damit das was bei anderen schon vorher ging auch bei Ihnen geht, ohne das Sie alles neu machen müssen. Das nenne ich gebastel.

"Bastelei" kann ich in beiden Fällen eigentlich keine erkennen.

Ich kann damit leben, das Du solche Lösungen gut findest.

PAE gibts seit dem Pentium Pro (1995), AWE seit Windows XP (2001).

Und?
Um die 90er herum (91/92) gab es 64 Bit CPU's und die passenden Betriebssysteme.

MS hat ja ein bischen gebraucht bis die ein brauchbares 64 Bit System für Desktops liefern konnte.

Zwei Jahre find ich jetzt ehrlich gesagt nicht wirklich lange für sowas (die erste x64 CPU kam 2003 raus, die x64 Edition von Windows XP 2005)...

Dann vergleiche mal den Zeitraum zwischen dem ersten MS 64 Bit OS mit anderen Betriebssystemen.
Es beiben Workarounds damit das was woanders schon lange ging auch bei Microsoft geht. ;)

[Schrompf]

Ob Gebastel oder nicht - "Mach halt einfach 64bit" ist eine Weltsicht, die ich mir nicht leisten kann. Gesegnet seien die Hobbybastler, denn sie brauchen sich keine Gedanken über ihre Zielgruppe machen. Von daher bin ich sehr dankbar für die schnelle und umfangreiche Hilfe, die es hier im Thread gehagelt hat. Ihr seid toll, ZFXler! :-)

[dot]

Ich gehe im Moment nach wie vor von 32 Bit Betriebssystemen aus, nicht von einem 64 Bit OS.
Also unter einem 32 Bit OS ist PAE auf einer x86 Maschine gebastel. Es ist der Workaround doch mehr als 4GB zu anzusprechen.
Wenn Du sagst Du brauchst mehr als 4GB auf einem 32 Bit System, dann würde ich fragen wieso nimmste kein 64Bit? Oder pass halt Dein design an. :)

Ich glaub du hast da was falsch verstanden. Einem Prozess auf einem 32bit System mehr als 4GB RAM zur Verfügung zu stellen ist eben nicht der wesentliche Zweck von PAE. Der Sinn von PAE ist, dass das Betriebssystem mehr als 4GB RAM verwalten kann.
Mit PAE kann ich ein 32bit System auf einer x86 Maschine mit mehr als 4GB RAM laufen lassen und dabei den gesamten RAM nutzen, auch wenn jeder einzelne Prozess dabei nicht mehr als 2GB vom Kuchen bekommt.

Schon klar.
Warum brauche ich das?
Nimm doch ne echte 64 Bit CPU mit 64 Bis OS und schreibe ne 64 Bit Anwedung, dann brauchste solche Workarounds nicht.

Einfach mal so die Anwendung auf eine andere Architektur und ein anderes OS portieren ist nicht nur Softwareseitig ein Problem.
Niemand der recht bei Sinnen ist, wird ein komplettes Rechenzentrum wegwerfen, nur weil irgendjemand sich einbildet "echte" 64bit CPUs und ein "echtes" 64bit OS verwenden zu müssen.

AWE ist eine API, die es einem speicherintensiven Prozess ermöglicht, in einem beschränkten Adressraum mit physikalischem Speicher jenseits der Grenzen dieses Adressraums umzugehen. Mehr oder weniger eigentlich nichts anderes als mmap(), nur eben für Speicher. Für Anwendungen wie z.B. irgendwelche riesigen Datenbankserver doch sehr sinnvoll, wenn du mich fragst.

Sehe ich anders. Das sind die MS Workarounds damit das was bei anderen schon vorher ging auch bei Ihnen geht, ohne das Sie alles neu machen müssen. Das nenne ich gebastel.

Dann nenn es Gebastel wenn du willst. Aber wenn du deshalb meinst, über MS herziehen zu müssen, dann darfst du auch die entsprechenden APIs auf anderen Systemen wie Unix, Linux, BSD, Solaris etc. nicht vergessen...

"Bastelei" kann ich in beiden Fällen eigentlich keine erkennen.

Ich kann damit leben, das Du solche Lösungen gut findest.

Im Gegensatz zu der Idee, einfach mal sämtliche x86 Hardware und Software wegzuwerfen, sind das zumindest Lösungen...

Die Tatsache, dass Kompatibilität in der realen Welt dann eben doch irgendwie nicht ganz egal ist, ist doch erst der Grund warum wir heute sowas wie x64 haben, statt dieser "echten" 64bit CPUs...

PAE gibts seit dem Pentium Pro (1995), AWE seit Windows XP (2001).

Und?
Um die 90er herum (91/92) gab es 64 Bit CPU's und die passenden Betriebssysteme.

Man sieht ja wie die sich durchgesetzt haben. Ich weiß, jetzt kommt gleich was von wegen böses kapitalistisches Microsoft und Monopol und sonstige Verschwörungen.
Wie jemand mal so schön gesagt hat: Es geht doch nichts über ein einfaches Weltbild :)

Windows läuft übrigens auch auf Itanium...

[joggel]

Ich glaube, ich habe gestern doch etwas durcheinander gebracht.
Auf Win7-64 gab es einen crash mit einem bestimmten (sehr grossen) Datensatz.
Compiler-Flag /LARGE_ADDRESS_AWARE gesetzt => funktionierte auf 64-Bit-OS.
Ob es mit den selben Daten auf einem 32-Bit-OS funktionierte, kann ich nicht sagen.

[simbad]

Ich gehe im Moment nach wie vor von 32 Bit Betriebssystemen aus, nicht von einem 64 Bit OS.
Also unter einem 32 Bit OS ist PAE auf einer x86 Maschine gebastel. Es ist der Workaround doch mehr als 4GB zu anzusprechen.
Wenn Du sagst Du brauchst mehr als 4GB auf einem 32 Bit System, dann würde ich fragen wieso nimmste kein 64Bit? Oder pass halt Dein design an. :)

Ich glaub du hast da was falsch verstanden. Einem Prozess auf einem 32bit System mehr als 4GB RAM zur Verfügung zu stellen ist eben nicht der wesentliche Zweck von PAE. Der Sinn von PAE ist, dass das Betriebssystem mehr als 4GB RAM verwalten kann.
Mit PAE kann ich ein 32bit System auf einer x86 Maschine mit mehr als 4GB RAM laufen lassen und dabei den gesamten RAM nutzen, auch wenn jeder einzelne Prozess dabei nicht mehr als 2GB vom Kuchen bekommt.

Schon klar.
Warum brauche ich das?
Nimm doch ne echte 64 Bit CPU mit 64 Bis OS und schreibe ne 64 Bit Anwedung, dann brauchste solche Workarounds nicht.

Du weisst aber, das eine 64-Bit Anwendung nicht immer schneller ist als eine 32-Bit Anwendung? Wenn ich also viele Rechenintensive Prozesse habe, in einem Multiprozessor-System, die alle viel speicher brauchen, sagen wir mal 2GB, dann werde ich den Teufel tun und ein 64-Bit OS und eine 64-Bit Anwendung zu verwenden.
Wenn du mit 64-Bit Pointern arbeitest, was ja in einer 64-Bit Anwendung nicht ungewöhnlich ist, und deine Anwendung 2GB RAM braucht, dann sind von den 8Byte Addresse 4Byte immer 0. Das bedeutet, das du fleissig und völlig sinnfrei nullen transportierst. Das ist bei einem 32-Bit Prozess nicht der Fall.
Ich habe eine Zeit lang einen "HP-Netserver LH6000R" betrieben. Da waren 6 900MHz Xeons drin und 8GB RAM. Das war so eine Maschine wo man ohne PAE ziemlich mies ausgesehen hätte, und die keinen 64-Bit support hat.

AWE ist eine API, die es einem speicherintensiven Prozess ermöglicht, in einem beschränkten Adressraum mit physikalischem Speicher jenseits der Grenzen dieses Adressraums umzugehen. Mehr oder weniger eigentlich nichts anderes als mmap(), nur eben für Speicher. Für Anwendungen wie z.B. irgendwelche riesigen Datenbankserver doch sehr sinnvoll, wenn du mich fragst.

Sehe ich anders. Das sind die MS Workarounds damit das was bei anderen schon vorher ging auch bei Ihnen geht, ohne das Sie alles neu machen müssen. Das nenne ich gebastel.

"Bastelei" kann ich in beiden Fällen eigentlich keine erkennen.

Ich kann damit leben, das Du solche Lösungen gut findest.

PAE gibts seit dem Pentium Pro (1995), AWE seit Windows XP (2001).

Und?
Um die 90er herum (91/92) gab es 64 Bit CPU's und die passenden Betriebssysteme.

Welche CPU soll denn das gewesen sein? DEC-Alpha und HP-PA. Die HP-PA sind auch erst mitte der 90er auf 64-Bit umgestellt worden. Das bedeutet, das nur die DEC-Alpha Prozessoren als 64-Bitter designed worden sind.
Sun-SPARC sind erst 95 auf 64-Bit umgebaut worden. Itanium gabs damals noch nicht.
Ein Verbreitung von 64-Bittern war damals (91/92) eher nicht gegeben.

@dot:
Das PAE bereits im PPro existierte war ja ganz nett, aber gab es denn dafür Chipsätze? Ich weiß noch, das Compaq da ein Problem hatte bei Ihren 4xPPro Maschinen, das die nicht mehr als 640MB installieren konnten, weil der darüber liegende Speicher wegen eines Design-Fehlers, bei Compaq glaube ich, ab Adresse 0 aufgetaucht ist.

Starke Verbreitung von 64-Bit Systemen gibt es erst seit ein paar Jahren, seit Intel und AMD Massenmarkt fähige CPUs in 64-Bit anbieten und der Hauptspeicher GByte weise verschenkt wird. Und erst seit diesem Zeitpunkt macht es auch Sinn das System zu wechseln, sofern man denn dafür auch einen Bedarf hat.

[Artificial Mind]

Außerdem ist dies nicht das erste Mal, dass Games soetwas "brauchen".

Zwei Beispiele:
Sacred 2 ist ohne Large Adress Aware Patch nahezu unspielbar.
Skyrim ist nach etwas längerem Spielen (sprich, man lädt einen Spielstand, der zB mehr als 20h Spielzeit hat) ohne Large Adress Aware Patch keine 15 Minuten lang spielbar.

Beides aus eigener Erfahrung.

[Krishty]

Nicht zu vergessen GTA IV, das irgendwas in der Größenordnung eines GiBs an Texturen in einen 2-GiB-Adressraum pressen wollte.

Beim allerersten S.T.A.L.K.E.R. war das Flag auch ein Muss, wenn man in extra hoher Auflösung spielen wollte.

Du weisst aber, das eine 64-Bit Anwendung nicht immer schneller ist als eine 32-Bit Anwendung? Wenn ich also viele Rechenintensive Prozesse habe, in einem Multiprozessor-System, die alle viel speicher brauchen, sagen wir mal 2GB, dann werde ich den Teufel tun und ein 64-Bit OS und eine 64-Bit Anwendung zu verwenden.
Wenn du mit 64-Bit Pointern arbeitest, was ja in einer 64-Bit Anwendung nicht ungewöhnlich ist, und deine Anwendung 2GB RAM braucht, dann sind von den 8Byte Addresse 4Byte immer 0. Das bedeutet, das du fleissig und völlig sinnfrei nullen transportierst. Das ist bei einem 32-Bit Prozess nicht der Fall.

Zeiger und Mengenangaben machen bei 99 % der Programme einen geradezu lächerlich geringen Teil der Datenmenge aus. Es gibt viele Stellen, wo x86 schneller / platzsparender / einfacher ist als x64 und umgekehrt noch mehr; da gehe ich völlig konform – aber die sind alle so absurd bedeutungslos, dass meine Anwendung schon enorm exotisch und optimiert sein muss, damit ich mich bewusst gegen x64 entscheide.

(Mein Lieblingsgrund für x64 ist z.B. nicht der große Adressraum, sondern die hohe Gleitkommaleistung bei geringem Registerdruck.)

[Artificial Mind]

Oh mir ist grade aus aktuellem Anlass eingefallen, das es noch ein anderes tolles Beispiel gibt, wo man 64-Bit auch ohne Grafikansprüche braucht: _MINECRAFT_

Lief grade zum ersten Mal bei mir stabil über 4h lang. Bei 5GB Ramverbrauch, der Client. Dem Server reichen schon 3GB. waren meine 12GB RAM mal endlich über längere Zeit ordentlich gefüllt.

[BeRsErKeR]

Ich kam mit meinen 2 GB bislang immer ohne Probleme klar. Auch mit Minecraft. :)

[Artificial Mind]

auch 256² Texturepack?^^