Wie groß kann ein Spiel unter 32 Bit Windows maximal sein? [Archiv]

Muh-sagt-die-Kuh

2003-11-08, 20:06:57

Aktuell ist der von einem Prozess nutzbare virtuelle Adressraum unter Windows und Linux 2 GB groß, in anderen Worten, das Spiel kann 2 GB Daten gleichzeitig im Speicher (ob ausgelagert oder nicht ist egal) halten.

Bei Spielen mit Level-basiertem Aufbau sollten 32-bit virtueller Adressraum noch eine Weile reichen, bei anderen Einsatzgebieten wird es jetzt schon kritisch.

GRiNSER

2003-11-08, 20:25:29

ähm 32 bit = 2 hoch 32 = ~ maximal 4 gb hauptspeicher adressierbar... mehr über virtuellen speicher nutzbar...

2003-11-08, 20:44:04

Exxtreme

2003-11-08, 20:48:34

Original geschrieben von GRiNSER
ähm 32 bit = 2 hoch 32 = ~ maximal 4 gb hauptspeicher adressierbar... mehr über virtuellen speicher nutzbar...
Ja, aber 2 GB sind maximal möglich. Die restlichen 2 GB sind für Windows selbst reserviert.

Endorphine

2003-11-08, 21:30:48

Aus genau diesem Grund ist AMD64 für Desktopsysteme derzeit ein reines Marketingfeature, wenn auch sinnvoll, da über die Masse der verkauften AMD64-Systeme diese mit ihrer Verbreitung als Steigbügelhalter für AMD64-Software dienen werden :)

Solange der Athlon64 im Sockel-754 und Sockel-939 aber sowieso nicht mehr als 4 GiB DDR-SDRAM verwalten kann hat man im praktischen Betrieb wenig davon. Dann reduziert sich der Vorteil darauf, dass der gesamte physikalische Adressraum für 32-Bit Anwendungen nutzbar wird, nicht nur 2 GiB. Für Desktopsysteme aber in den nächsten paar Jahren eher irrelevant.

Der Opteron ist die derzeit einzige CPU, die dank 8 GiB pro CPU wirklichen Nutzen aus AMD64 ziehen kann.

Edit: Aus diesem Grund verstehe ich auch Stimmen nicht, die ab nächstem Jahr keine 32-Bit CPUs mehr kaufen wollen. Für Anwendungen wo man's braucht: klar. Aber für normale PCs, die meist 512 MiB RAM haben, nächstes Jahr vielleicht 1 GiB? Nun ja, da halte ich SMT für weit sinnvoller, da hat jeder etwas von, wenn das OS halbwegs aktuell ist :)

grakaman

2003-11-08, 22:35:02

Windows kann sehr wohl Speicher über 4GB Adressieren. Das konnten allerdings schon immer die Server Versionen, deswegen verstehe ich die Diskussion nicht ganz. Dazu wird der PAE Mode der CPU benutzt, der einen 36Bit Speicherzugriff erlaubt (gibts ab Pentium Pro). Die Desktopversionen untersützen allerdings nur 4GB. Trotzdem kann man da auch den maximalen Prozeßspeicher in der boot.ini auf 3GB einstellen (W2k/XP). W2k3 Datacenter kann bis zu 64GB Hauptspeicher adressieren.

MfG

Ganon

2003-11-08, 22:44:35

Original geschrieben von grakaman
W2k3 Datacenter kann bis zu 64GB Hauptspeicher adressieren.
MfG

Aber nicht komplett. Der Speicher wird dann geteilt.

Endorphine

2003-11-08, 22:51:43

Mittels PAE36 adressierter Speicher ist deutlich langsamer als physikalisch adressierter. Es ist eher eine Notlösung als ein echter Ersatz für eine 64-Bit Architektur à la IA64 oder AMD64.

Für Mainstreamanwendungen halte ich PAE36 für ungeeignet. Eher eine Krücke, um den Xeon im Serverumfeld verwendbar zu halten.

Dass der Prozessspeicher auf 3 GiB anhebbar ist wusste ich nicht. Wo kann man das einstellen? Das wird das Leben von IA32-CPUs wohl noch eine Weile verlängern.

Birdman

2003-11-08, 22:52:05

Original geschrieben von grakaman
Windows kann sehr wohl Speicher über 4GB Adressieren. Das konnten allerdings schon immer die Server Versionen, deswegen verstehe ich die Diskussion nicht ganz. Dazu wird der PAE Mode der CPU benutzt, der einen 36Bit Speicherzugriff erlaubt (gibts ab Pentium Pro). Die Desktopversionen untersützen allerdings nur 4GB. Trotzdem kann man da auch den maximalen Prozeßspeicher in der boot.ini auf 3GB einstellen (W2k/XP). W2k3 Datacenter kann bis zu 64GB Hauptspeicher adressieren.
MfG
Pro Applikation stehen dann aber afaik immer noch nur 2 oder 3GB zur Verfügung - auch wenn da über Umwege 64GB im System drin stecken....

grakaman

2003-11-08, 22:57:16

Original geschrieben von Birdman
Pro Applikation stehen dann aber afaik immer noch nur 2 oder 3GB zur Verfügung - auch wenn da über Umwege 64GB im System drin stecken....

Ja, pro Applikation stehen maximal 4GB zur Verfügung.

MfG

Muh-sagt-die-Kuh

2003-11-08, 23:01:17

Original geschrieben von grakaman
Windows kann sehr wohl Speicher über 4GB Adressieren. Das konnten allerdings schon immer die Server Versionen, deswegen verstehe ich die Diskussion nicht ganz. Dazu wird der PAE Mode der CPU benutzt, der einen 36Bit Speicherzugriff erlaubt (gibts ab Pentium Pro). Die Desktopversionen untersützen allerdings nur 4GB. Trotzdem kann man da auch den maximalen Prozeßspeicher in der boot.ini auf 3GB einstellen (W2k/XP). W2k3 Datacenter kann bis zu 64GB Hauptspeicher adressieren.

MfG PAE 36 ist vollkommen unbrauchbar, da lahm wie Hund (mindestens 30% Einbruch bei der Speicherleistung wenn ich mich recht entsinne). Außerdem bleibt der virtuelle Adressraum immer noch bei 4 GB.

Der Switch in der Boot.ini funktioniert übrigens nur ab Advanced Server....

grakaman

2003-11-08, 23:08:30

Original geschrieben von Muh-sagt-die-Kuh
PAE 36 ist vollkommen unbrauchbar, da lahm wie Hund (mindestens 30% Einbruch bei der Speicherleistung wenn ich mich recht entsinne). Außerdem bleibt der virtuelle Adressraum immer noch bei 4 GB.

Der Switch in der Boot.ini funktioniert übrigens nur ab Advanced Server....

Laut MS funktioniert das auch mit XP, aber leider doch nicht W2k Pro. Hier die Versionen:

Windows XP Professional
Windows Server 2003
Windows Server 2003, Enterprise Edition
Windows Server 2003, Datacenter Edition
Windows 2000 Advanced Server
Windows 2000 Datacenter Server
Windows NT Server 4.0, Enterprise Edition

Das sähe dann so aus:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /3GB

Exxtreme

2003-11-08, 23:42:54

Original geschrieben von Endorphine
Mittels PAE36 adressierter Speicher ist deutlich langsamer als physikalisch adressierter. Es ist eher eine Notlösung als ein echter Ersatz für eine 64-Bit Architektur à la IA64 oder AMD64.

AFAIK funktioniert PAE36 so ähnlich wie EMS-Speicher.

Endorphine

2003-11-09, 00:06:25

Original geschrieben von Exxtreme
AFAIK funktioniert PAE36 so ähnlich wie EMS-Speicher. AFAIK ist's exakt das gleiche Prinzip :) Deshalb ist PAE36 auch kein Leistungswunder.

Edit: Eine schöne Erklärung: http://www.fh-zwickau.de/doc/prmo/pmtutor/text/r_phys5.htm Wenn dieses umständliche Gepfriemel allerdings nur ~30% Speicherdurchsatz kosten sollte wäre es ja noch halbwegs vertretbar bei heutigen Durchsätzen im GiB/s-Bereich. Nur die Programmierer werden wohl stöhnen ;)

Exxtreme

2003-11-09, 00:15:08

Original geschrieben von Endorphine
AFAIK ist's exakt das gleiche Prinzip :) Deshalb ist PAE36 auch kein Leistungswunder.

Edit: Eine schöne Erklärung: http://www.fh-zwickau.de/doc/prmo/pmtutor/text/r_phys5.htm Wenn dieses umständliche Gepfriemel allerdings nur ~30% Speicherdurchsatz kosten sollte wäre es ja noch halbwegs vertretbar bei heutigen Durchsätzen im GiB/s-Bereich. Nur die Programmierer werden wohl stöhnen ;)
Also das ständige Rumkopieren von Speicherseiten dürfte IMHO weit mehr als 30% RAM-Leistung kosten.

zeckensack

2003-11-09, 02:30:40

Original geschrieben von GRiNSER
ähm 32 bit = 2 hoch 32 = ~ maximal 4 gb hauptspeicher adressierbar...Jein, wurde schon geklärt :)
mehr über virtuellen speicher nutzbar... Nein! Der virtuelle Speicher kann den Addressraum des Prozessors nicht vergrößern.

Tigerchen

2003-11-09, 05:38:22

Original geschrieben von Endorphine
Aus genau diesem Grund ist AMD64 für Desktopsysteme derzeit ein reines Marketingfeature, wenn auch sinnvoll, da über die Masse der verkauften AMD64-Systeme diese mit ihrer Verbreitung als Steigbügelhalter für AMD64-Software dienen werden :)

Solange der Athlon64 im Sockel-754 und Sockel-939 aber sowieso nicht mehr als 4 GiB DDR-SDRAM verwalten kann hat man im praktischen Betrieb wenig davon. Dann reduziert sich der Vorteil darauf, dass der gesamte physikalische Adressraum für 32-Bit Anwendungen nutzbar wird, nicht nur 2 GiB. Für Desktopsysteme aber in den nächsten paar Jahren eher irrelevant.

Der Opteron ist die derzeit einzige CPU, die dank 8 GiB pro CPU wirklichen Nutzen aus AMD64 ziehen kann.

Edit: Aus diesem Grund verstehe ich auch Stimmen nicht, die ab nächstem Jahr keine 32-Bit CPUs mehr kaufen wollen. Für Anwendungen wo man's braucht: klar. Aber für normale PCs, die meist 512 MiB RAM haben, nächstes Jahr vielleicht 1 GiB? Nun ja, da halte ich SMT für weit sinnvoller, da hat jeder etwas von, wenn das OS halbwegs aktuell ist :)

Im Sockel 754 Thread schreibst du was von 3,5 GByte.Kannst du mir das näher erläutern.Alle anderen hier scheinen ja der Meinung zu sein daß ohne Tricks bei 2 GByte Schluß ist.

Zool

2003-11-09, 08:08:23

Original geschrieben von Tigerchen

Im Sockel 754 Thread schreibst du was von 3,5 GByte.Kannst du mir das näher erläutern.Alle anderen hier scheinen ja der Meinung zu sein daß ohne Tricks bei 2 GByte Schluß ist.

Die Speicheradressen vom PCI-Subsystem liegen gerade im Bereich von 3.5GB...4GB. Deshalb kann ein mit 4GB aufgerüstete 32Bit-CPU auch nicht auf diesen Bereich zu greifen.

PAE ist doch ein wenig verbessert gegenüber dem alten EMS, immerhin kann es mit 4MB Kacheln umgehen, EMS nur mit 4K.
Aber paar GB mit 4MB Kacheln von den oberen 64GB in die unterten 4GB runterzuschaufeln dauert auch ewig.

Endorphine

2003-11-09, 10:48:24

Original geschrieben von Tigerchen

Im Sockel 754 Thread schreibst du was von 3,5 GByte.Kannst du mir das näher erläutern.Alle anderen hier scheinen ja der Meinung zu sein daß ohne Tricks bei 2 GByte Schluß ist. Das bezog ich eher auf die gesamte für alle Software nutzbare Hauptspeichergröße :) Leider kommen dann aber noch Softwarelimitationen hinzu, die beispielsweise bei Linux ohne Verrenkungen nur 2 GiB pro Prozess nutzbar machen, unter Windows sind's 3 GiB.

Zool hat's schon gesagt: die PCI-Architektur blendet die Speicherfenster der ganzen Controller in den Bereich von 3,5 - 4,0 GiB ein. Analog wie damals bei 16-Bit real mode: von 640 kiB bis 1 MiB konnte man nur Lücken zwischen den Speicherfenstern aufwändig als upper memory Blocks nutzen. Ohne diesen Trick war bei 640 kiB Schluss. Die ganze Geschichte wiederholt sich lediglich.

Dass für einen Prozess nur 2 oder 3 GiB nutzbar sind heisst ja nicht, dass der Rest nicht für andere Prozesse zur Verfügung steht.

Zool

2003-11-10, 07:55:32

Gibt es eigentlich irgendwelche Boards, die 64GB mit den 32Bit Prozessoren unterstützen? In den diversen Specs von Intel-E7501/5 basierten Boards ist auch immer bei 4GB Schluß.

micki

2003-11-10, 10:12:31

wenn ein spiel unter win98 läuft ist bei 512MB schluss :)

ich hab auch von 3GB gehört auf WXP

MfG
micki

Zool

2003-11-10, 11:05:31

Windows 9x ist ja auch kein echtes 32Bit-Betriebssystem, da es ja immer noch 16Bit-Dosleichen mitschleppt. Aber mit paar Kniffen (vcache und Co) kann man auch mehr als 512MB unter 9x nutzen. Aber ein einzelner Prozeß kann nur maximal 512MB recht und schlecht nutzen.

micki

2003-11-10, 11:31:01

Original geschrieben von Zool
Windows 9x ist ja auch kein echtes 32Bit-Betriebssystem, da es ja immer noch 16Bit-Dosleichen mitschleppt.
in wieweit ist das für die beantwortung der threadfrage wichtig?

MfG
micki

zeckensack

2003-11-10, 17:33:31

Original geschrieben von micki
wenn ein spiel unter win98 läuft ist bei 512MB schluss :)
Nein (http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/009951.html) :)

Es hängt von der verwendeten Hardware und den Treiberversionen ab. Man beachte Mark Kilgard's posting weiter unten, der verschwenderischen Umgang mit virtuellem Addressraum auf NV-OpenGL-Treibern einräumt.

Ich hatte jedenfalls mit Win98SE keine Probleme, 1,8GB Speicher zu belegen und einen initialisierten GL-Kontext zu fahren. Alles darüber wäre auch ein Wunder gewesen, Begründung im verlinkten Thread.

Crushinator

2003-11-10, 20:10:29

Original geschrieben von Endorphine
(...) Leider kommen dann aber noch Softwarelimitationen hinzu, die beispielsweise bei Linux ohne Verrenkungen nur 2 GiB pro Prozess nutzbar machen, unter Windows sind's 3 GiB. Wenn man einen entsprechenden Kernel der Distri einspielen und neubooten Verrenkung nennen kann, Agree. =) Aber hier fällt irgendwie auch der Hinweis unter den Tisch, daß Windows nur unter folgenden Systemen 3 GiB pro Prozeß überhaupt (erst durch Angabe im Boot.ini) unterstützt:

XP Professional
Server 2003+
2000 Advanced Server+
NT Server 4.0, Enterprise Edition
Dass für einen Prozess nur 2 oder 3 GiB nutzbar sind heisst ja nicht, dass der Rest nicht für andere Prozesse zur Verfügung steht. Wenn man Microsoft (http://www.microsoft.com/whdc/hwdev/platform/server/pae/PAEmem.mspx) glauben darf: Wird mit /3GB kein Speicher mehr Oberhalb von 16 GiB benutzt. =)

Tigerchen

2003-11-11, 16:04:57

Original geschrieben von crushinator
Wenn man einen entsprechenden Kernel der Distri einspielen und neubooten Verrenkung nennen kann, Agree. =) Aber hier fällt irgendwie auch der Hinweis unter den Tisch, daß Windows nur unter folgenden Systemen 3 GiB pro Prozeß überhaupt (erst durch Angabe im Boot.ini) unterstützt:

XP Professional
Server 2003+
2000 Advanced Server+
NT Server 4.0, Enterprise Edition
Wenn man Microsoft (http://www.microsoft.com/whdc/hwdev/platform/server/pae/PAEmem.mspx) glauben darf: Wird mit /3GB kein Speicher mehr Oberhalb von 16 GiB benutzt. =)

Aha.Dann ist für Otto Normaluser also doch bei 2GByte Schluß.Das würde Endorphine's These das der Adressrraum der heutigen 32Bit Prozessoren noch sehr lange groß genug ist schon ins wanken bringen.

Wenn dem so ist denke ich es ist schon an der Zeit 64 Bit einzuführen.Damit in 2 Jahren,wenns richtig eng im Speicher wird,die Marktdurchdringung von 64 Bit Systemen groß genug ist so daß es sich lohnt echte 64 Bit Games und Anwendungen rauszubringen.

Crushinator

2003-11-11, 16:54:15

Original geschrieben von Tigerchen
Aha.Dann ist für Otto Normaluser also doch bei 2GByte Schluß.Das würde Endorphine's These das der Adressrraum der heutigen 32Bit Prozessoren noch sehr lange groß genug ist schon ins wanken bringen. Er wird mit Sicherheit nicht daran gedacht haben, daß es heute schon viele Anwendungen gibt, die auch mehr als 3 GiB anfordern könnten, oder er meinte, daß diese Anwendungen für Otto-Normal nicht in Frage kämen. Ich jedenfalls kenne genügend Fälle (SMP-Renderer, SQL-Server, VMWare Server etc.) und habe fast täglich mit ihnen zutun. Nur hat man nicht jeden Tag einen Advanced- oder gar Datacenter-Server zur Verfügung - mit denen es zwar auch nicht klappt - jedoch ordentlich viel RAM. ;)
Wenn dem so ist denke ich es ist schon an der Zeit 64 Bit einzuführen.Damit in 2 Jahren,wenns richtig eng im Speicher wird,die Marktdurchdringung von 64 Bit Systemen groß genug ist so daß es sich lohnt echte 64 Bit Games und Anwendungen rauszubringen. Agree, aber man darf auch nicht vergessen, daß auch der normale RAM-Bedarf mit dem Sprung zu 64-Bit etwas zunimmt. Es stellt sich dann auch noch die Frage, ob z.B. ein Game wirklich mehr als 2 oder 3 GiB bräuchte und wie die Performance angesichts der verfügbaren RAM-Bandbreite dabei aussähe.

Tigerchen

2003-11-11, 17:15:17

Wegen der Spieleleistung:
Marc Reim von Epic scheint da keine Bedenken zu haben.

Wegen dem normalen RAM-Bedarf:
Außerdem bläht sich der Code bei AMD`s Lösung ja noch recht moderat auf.Und mehr Register gibts auch noch.

Crushinator

2003-11-11, 17:34:44

Original geschrieben von Tigerchen
Wegen der Spieleleistung:
Marc Reim von Epic scheint da keine Bedenken zu haben. Meinst Du nicht, daß er keine Bedenken hat, weil UT2K3 nie jenseits von mehreren GiB alloziieren bräuchte? Ich möchte damit sagen: Wenn schon 64-Bitter für Games, dann nur wegen der Register und nicht weil man mehr RAM alloziieren kann. ;)

Xmas

2003-11-11, 17:41:07

Zumindest bei den Engine-Tools kann man davon ausgehen dass sie sich über mehrere GiB RAM freuen würden.

Tigerchen

2003-11-11, 18:07:33

Original geschrieben von crushinator
Meinst Du nicht, daß er keine Bedenken hat, weil UT2K3 nie jenseits von mehreren GiB alloziieren bräuchte? Ich möchte damit sagen: Wenn schon 64-Bitter für Games, dann nur wegen der Register und nicht weil man mehr RAM alloziieren kann. ;)

Na ja.Erinnert mich irgendwie an den Spruch eines gewissen Bill G. daß 640KByte genug seien.

Endorphine

2003-11-11, 20:16:40

Wie schon erwähnt: mir geht es hauptsächlich darum, dass AMD bei Desktopprozessoren in die 64-Bit Werbeschlacht einsteigt. Und da wird die 64-Bit Fähigkeit IMHO momentan noch überhaupt nicht ausgenutzt. Ganz davon zu schweigen, dass der Sockel-754 Athlon-64 gar nicht über 4 GiB Hauptspeicher hinauskommt (mit DDR400-SDRAM sind IIRC sogar nur 1 GiB möglich). Reines Marketing zur Zeit. Dagegen ist SMT für jedermann sofort produktiv nutzbar.

Dass die 64-Bit Architektur Sinn macht steht doch ausser Frage. Es gibt unendlich viele Anwendungen abseits von typischen Desktopaufgaben, die den grossen Adressraum dringend benötigen. Und für diese ist der Opteron schon jetzt eine sehr schöne Plattform. Weitaus günstiger als ein Itanium²-Deerfield System und auch mit einer top 32-Bit Leistung.

Derzeit deckelt wie schon erwähnt auch der Hype um DDR400-SDRAM die mögliche Hauptspeichergrösse im Desktopbereich. Dieses technisch fragwürdige Konstrukt erlaubt nur 256-MBit ICs, was bei 16 ICs pro DIMM gerade einmal 512 MiB pro Modul erlaubt. Der Speicherbus ist ebenfalls schon ohne OC über dem Limit und erlaubt bei halbwegs annehmbarer Zuverlässigkeit nur noch zwei ungepufferte 16-IC DIMMs pro Kanal. Macht also bei single-channel gerade mal ein (!) GiB und bei dual-channel auch nur zwei GiB. Da das OS auch Speicherplatz für sich beansprucht können derzeitige Athlon-64 Systeme also schon per Definition gar nicht an die Grenzen stossen. Das wird sich erst mit DDR2 ändern.

Endorphine

2003-11-11, 20:19:33

Original geschrieben von crushinator
Aber hier fällt irgendwie auch der Hinweis unter den Tisch, daß Windows nur unter folgenden Systemen 3 GiB pro Prozeß überhaupt (erst durch Angabe im Boot.ini) unterstützt:

XP Professional
Server 2003+
2000 Advanced Server+
NT Server 4.0, Enterprise Edition
Wenn man Microsoft (http://www.microsoft.com/whdc/hwdev/platform/server/pae/PAEmem.mspx) glauben darf: Wird mit /3GB kein Speicher mehr Oberhalb von 16 GiB benutzt. =) Interessante Seite :) Hochoffiziell vor allem.

Wenn man bedenkt, dass die PCI-Architektur ohnehin bei 3,5 GiB deckelt ist es IMHO aber gar nicht so furchtbar, dass pro Prozess nur 3,0 GiB nutzbar sind. Und bei modernen Rechnern mit so viel Speicher wird wohl auch kaum jemand alte Windowsversionen nutzen. Das geht IMHO für die Praxis OK, auch wenn's in der Theorie recht eng klingt.

zeckensack

2003-11-11, 20:38:52

Original geschrieben von Endorphine
Wie schon erwähnt: mir geht es hauptsächlich darum, dass AMD bei Desktopprozessoren in die 64-Bit Werbeschlacht einsteigt. Und da wird die 64-Bit Fähigkeit IMHO momentan noch überhaupt nicht ausgenutzt. Ganz davon zu schweigen, dass der Sockel-754 Athlon-64 gar nicht über 4 GiB Hauptspeicher hinauskommt (mit DDR400-SDRAM sind IIRC sogar nur 1 GiB möglich). Reines Marketing zur Zeit.
<schnipp>*wiederhol* :)
Physikalischer Speicherausbau ist kein Grund für oder gegen virtuellen Adressraum. Swapping ist für viele Applikationen mit riesigen Datasets durchaus akzeptabel (wenn auch schlechter als physikalischer Speicher, 'türlich).

Mit 64bit-'Segmenten' kann ein Spiel ala Morrowind zB die komplette Welt in den Speicher klatschen (~1GB komplett, inklusive der diversen offiziellen und 3rd party plugins, die ich ich hier rumliegen habe; möglicherweise ist das komprimiert?). Die virtelle Speicherverwaltung würde dann ganz automatisch dafür sorgen, daß die jeweils benötigten Daten 'on demand' von der Platte in den physikalischen Speicher (und wieder zurück) geschaufelt werden. Paging ist für Applikationen völlig transparent. Das ist immens viel einfacher, als der Korks der heute betrieben werden muß.

Crushinator

2003-11-11, 21:18:20

Original geschrieben von Tigerchen
Na ja.Erinnert mich irgendwie an den Spruch eines gewissen Bill G. daß 640KByte genug seien. Du verstehst mich anscheinend falsch. Ich möchte keineswegs behaupten, daß das heutige völlig ausreichend sei, sondern viel mehr daß z.Z. eine Otto-Normal-App nicht mal an die Hälfte dieser 2 GiB kratzt und deshalb die Register primär interessanter sind, da sie sofort sinnvoll nutzbar wären, nutzbares OS natürlich vorausgesetzt.

Endorphine

2003-11-11, 21:23:01

Original geschrieben von zeckensack
*wiederhol* :)
Physikalischer Speicherausbau ist kein Grund für oder gegen virtuellen Adressraum. Swapping ist für viele Applikationen mit riesigen Datasets durchaus akzeptabel (wenn auch schlechter als physikalischer Speicher, 'türlich).

Mit 64bit-'Segmenten' kann ein Spiel ala Morrowind zB die komplette Welt in den Speicher klatschen (~1GB komplett,
[...] OK, dann ist Morrowind eine Ausnahme, die die Regel bestätigt :)

Generell ist das natürlich richtig. Nur: welche Desktopapplikation benötigt zur zeit und in absehbarer Zukunft mehr als 3 GiB Prozesspeicher (jetzt gleich, ob ausgelagert oder nicht)? Mir will derzeit einfach nichts einfallen, abgesehen von ICQ, wenn man in der Message-history DB Einträge löscht und sich der Speicherbedarf bei jedem Löschvorgang um ~100 MiB vergrössert :flower:

Ich denke, dass es schon realistisch ist, dass 64-Bit Adressraum derzeit noch nicht notwendig ist. Die Zeit bis dieser notwendig wird wird langsam knapp, aber derzeit limitiert im Desktopbereich in 99% anderes als der Adressraum. Ich bin gar schon wieder gewagt, den Nutzen mit SMT zu vergleichen ;)

Man kann natürlich auch in die andere Richtung denken und sagen, dass AMD einfach der Zeit voraus ist.

KEINPLAN

2003-11-11, 21:34:52

Xmas

2003-11-11, 21:49:52

Original geschrieben von KEINPLAN
Es soll auch leute geben, die mehr als eine anwendung am laufen haben!
Kleine liste
icq, winamp, word, cute ftp, 2-3 Browser, fire wall, excel, Page mill, esel, win mx und noch ein paar andere dinge!
Die haben aber doch schon alle ihren eigenen virtuellen Adressraum.

KEINPLAN

2003-11-11, 22:00:42

Original geschrieben von Xmas
Die haben aber doch schon alle ihren eigenen virtuellen Adressraum. Ja aber warum sollte das den unbedingt noch virtuell sein?
Es geht nun auch richtig.

Crushinator

2003-11-11, 22:34:20

Original geschrieben von KEINPLAN
Ja aber warum sollte das den unbedingt noch virtuell sein?
Es geht nun auch richtig. "virtuell" verliert im Falle von genügend physikalischem Speicher automatisch seine langsam anmutende Wirkung und behält dabei die Vorteile wie z.B. völlig getrennte und verschiebbare Adreßräume, gut geschützt gegenüber unerlaubten Zugriffen. =)

Endorphine

2003-11-12, 12:22:11

Ich möchte jetzt auch mal in den Reigen von "PSE36 RAMDisk und PAE36 sucken" einstimmen. :bäh: Wenn man folgendes bedenkt (Zitat von Micros~1): 2. Large Cache
Using additional PAE-enabled memory for a data cache is also possible. If the operating system supports this feature, applications need not be recoded to take advantage of it. Windows Advanced Server and Datacenter Server support caching on a PAE platform and can utilize all of the available memory. Man muss sich also auch noch verrenken, um aus dem Speicher oberhalb von 4G noch eine ordentliche Performance rauszuholen, ohne dass die CPU endlose Takte mit warten verbringt. Standardmässig unterstützt das Tag-RAM der Cachecontroller natürlich auch nur maximal 4 GiB. Mir wäre es neu, wenn wenigstens der Xeon-MP da mehr könnte (wobei das beim Gallatin denkbar ist, der ohnehin modifizierte Caches mitbringt).

Wen's interessiert und wer Stoff für künftige Flames braucht ;)
-> http://www.microsoft.com/whdc/hwdev/platform/server/pae/pae_os.mspx#XSLTsection126121120120

Schon grausig, was man da so lesen muss.

Matti

2003-11-12, 12:40:50

theoretisch kann ein Programm unter Windows 2 GB Speicher belegen, aber in der Praxis blockiert Windows die Speicheranforderungen schon viel früher, deshalb war ja auch der Gigabyte-Bug in Quickbench8, auf einem Rechner mit 1 GB RAM den gesamten freien Speicher (ca.900MB) allokieren geht nicht...

Tigerchen

2003-11-12, 17:09:22

Original geschrieben von Endorphine
OK, dann ist Morrowind eine Ausnahme, die die Regel bestätigt :)

Im Gegenteil.Morrowind und Gothic sind Vorboten echter Speicherfresser unter den Games.

Generell ist das natürlich richtig. Nur: welche Desktopapplikation benötigt zur zeit und in absehbarer Zukunft mehr als 3 GiB Prozesspeicher (jetzt gleich, ob ausgelagert oder nicht)? Mir will derzeit einfach nichts einfallen, abgesehen von ICQ, wenn man in der Message-history DB Einträge löscht und sich der Speicherbedarf bei jedem Löschvorgang um ~100 MiB vergrössert :flower:

Ich denke, dass es schon realistisch ist, dass 64-Bit Adressraum derzeit noch nicht notwendig ist. Die Zeit bis dieser notwendig wird wird langsam knapp, aber derzeit limitiert im Desktopbereich in 99% anderes als der Adressraum. Ich bin gar schon wieder gewagt, den Nutzen mit SMT zu vergleichen ;)

Tja da werden wir uns wohl nicht einig.Ich finde eine sanfte Migration sollte schon heute einsetzen.Dann kann Unreal 4 ruhig "64Bit Only" erscheinen und alle sagen "Was solls,64 Bit hab ich ja eh schon im Gehäuse.

Und außerdem.Bringen denn die neuen Register nicht zusätzlichen Nutzen der den von SMT bei weitem übersteigt?

Man kann natürlich auch in die andere Richtung denken und sagen, dass AMD einfach der Zeit voraus ist.

War INTEL das mit dem i386 nicht auch?
In wie weit wurden die Fähigkeiten des i386 bei Erscheinen ausgenutzt?
Und welchen Einfluß hat er wohl bei der Entwicklung weg von DOS in Richtung Windows gehabt?

zeckensack

2003-11-12, 18:44:17

Original geschrieben von Endorphine
OK, dann ist Morrowind eine Ausnahme, die die Regel bestätigt :)

Generell ist das natürlich richtig. Nur: welche Desktopapplikation benötigt zur zeit und in absehbarer Zukunft mehr als 3 GiB Prozesspeicher (jetzt gleich, ob ausgelagert oder nicht)? Mir will derzeit einfach nichts einfallen, abgesehen von ICQ, wenn man in der Message-history DB Einträge löscht und sich der Speicherbedarf bei jedem Löschvorgang um ~100 MiB vergrössert :flower:Kernthese:
Wenn 64bit-CPUs weit genug verbreitet wären, um deren volle und kompromisslose Nutzung in Applikationen zu rechtfertigen, wären diese Applikationen auch längst anders strukturiert und würden Addressraum weit jenseits der 2 GiB nutzen, anstatt alle fünfzig Meter Level-Wechsel zu forcieren, was ja nur bedeutet "Daten wegschmeißen (um virtuelle Adressen freizumachen), Daten nachladen".

Die Entwicklung in diese Richtung ist unaufhaltsam.
Art Assets von Spielen:
Quake II: 350 MB
Unreal I: 340 MB
Ultima IX: 570 MB
Kingpin: 570 MB
Quake III: 580 MB komprimiert (ZIP/deflate)*
Dino Crisis 2: 630 MB :naughty:
Grandia 2: 850 MB
Unreal Tournament I: 880 MB*
Anachronox: 1,1 GB
Arcanum: 1,2 GB
Diablo 2 (+LOD): 1,4 GB
Etherlords I: 1,47 GB*
NOLF 2: 1,72 GB
Neverwinter Nights: 1,85 GB
Wizardry 8: 1,89 GB

Außer bei den markierten* Spielen (for your reference only), handelt es sich um zusammenhängende Welten, die in Levels zerhackstückt wurden. Diablo 2 macht im Grunde vor, wie alle diese Spiele aussehen könnten: keine merkbaren Ladezeiten beim Levelwechsel (D2 hat dafür noch andere, harte Limitierungen wie zB fixe Tilesets pro Abschnitt, eine maximale Anzahl verschiedener Gegnertypen pro Abschnitt, etc).

*diese Spiele 'zählen nicht', weil die feste Levelstruktur hier unverrückbar Teil der Spielmechanik ist.

micki

2003-11-13, 10:46:55

Original geschrieben von zeckensack
Nein (http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/009951.html) :)

Es hängt von der verwendeten Hardware und den Treiberversionen ab. Man beachte Mark Kilgard's posting weiter unten, der verschwenderischen Umgang mit virtuellem Addressraum auf NV-OpenGL-Treibern einräumt.

Ich hatte jedenfalls mit Win98SE keine Probleme, 1,8GB Speicher zu belegen und einen initialisierten GL-Kontext zu fahren. Alles darüber wäre auch ein Wunder gewesen, Begründung im verlinkten Thread.

es ging um die von windows direckt für ein spiel verwaltete speichermenge.

wenn du so willst, kann ich mir sicherlich auch einen treiber schreiben der im untersten ring auf 4GB ram rummatscht und über handles auf texturen etc. ein paar TB auf platte auslagert.

MfG
micki

Gast

2003-11-19, 08:29:35

Original geschrieben von Matti
theoretisch kann ein Programm unter Windows 2 GB Speicher belegen, aber in der Praxis blockiert Windows die Speicheranforderungen schon viel früher, deshalb war ja auch der Gigabyte-Bug in Quickbench8, auf einem Rechner mit 1 GB RAM den gesamten freien Speicher (ca.900MB) allokieren geht nicht...

Habe jetzt ein ähnliches Problem will auf einem 2GB Rechner mit XP 1.5GB resevieren (Simualtionsproggi, mit .2003 geschrieben), geht aber nur bis etwa 1GB. Gibt es für den Gigybyte-Bug einen Patch?

Matti

2003-11-28, 17:04:20

nein, leider interessiert sich MS wieder mal überhaupt nicht für die Fehler in Windows :(

Deshalb wird ab Quickbench 8.5 der Speicher-Stabilitäts-Test nur noch mit max 512 MB gemacht. Und den Windows-Festplatten-Cache durch komplettes Füllen des RAM's zu leeren, geht auf Rechnern mit >=1GB auch nicht. Deshalb mußte ich beim HDD-Test die Testdatei größer machen, so daß das Ergebnis nicht durch den Cache verfälscht wird.

Was jetzt dein Problem angeht:
Du könntest versuchen ob es was bringt, wenn man nicht einen großen Speicher-Block allokiert, sondern mehrere kleine, so daß du insgesamt dann trotzdem auf 1,5 GB kommst. Wenn das nicht geht, wirste dir wohl oder übel eine eigene Auslagerungs-Datei programmieren müssen.

Tigerchen

2004-08-16, 16:36:46

Kernthese:
Wenn 64bit-CPUs weit genug verbreitet wären, um deren volle und kompromisslose Nutzung in Applikationen zu rechtfertigen, wären diese Applikationen auch längst anders strukturiert und würden Addressraum weit jenseits der 2 GiB nutzen, anstatt alle fünfzig Meter Level-Wechsel zu forcieren, was ja nur bedeutet "Daten wegschmeißen (um virtuelle Adressen freizumachen), Daten nachladen".

Die Entwicklung in diese Richtung ist unaufhaltsam.
Art Assets von Spielen:
Quake II: 350 MB
Unreal I: 340 MB
Ultima IX: 570 MB
Kingpin: 570 MB
Quake III: 580 MB komprimiert (ZIP/deflate)*
Dino Crisis 2: 630 MB :naughty:
Grandia 2: 850 MB
Unreal Tournament I: 880 MB*
Anachronox: 1,1 GB
Arcanum: 1,2 GB
Diablo 2 (+LOD): 1,4 GB
Etherlords I: 1,47 GB*
NOLF 2: 1,72 GB
Neverwinter Nights: 1,85 GB
Wizardry 8: 1,89 GB

Außer bei den markierten* Spielen (for your reference only), handelt es sich um zusammenhängende Welten, die in Levels zerhackstückt wurden. Diablo 2 macht im Grunde vor, wie alle diese Spiele aussehen könnten: keine merkbaren Ladezeiten beim Levelwechsel (D2 hat dafür noch andere, harte Limitierungen wie zB fixe Tilesets pro Abschnitt, eine maximale Anzahl verschiedener Gegnertypen pro Abschnitt, etc).

*diese Spiele 'zählen nicht', weil die feste Levelstruktur hier unverrückbar Teil der Spielmechanik ist.

Jetzt ist Doom 3 erschienen und 1 GByte RAM sind schon Pflicht. Trotzdem sind die Level nicht gerade riesig. Endorphines Einsatz für SMT und gegen 64 Bit hat sich damit als grundfalsch erwiesen. Die Begrenzungen des 32 Bit Adressraums werden im Sauseschritt immer deutllicher.

RaumKraehe

2004-08-16, 16:49:37

Wie groß ein Spiel
sein kann .. von 96KB siehe Krieger Demo bis hin zu mehreren CDs ... wobei es total uniteressant ist welcher Adressraum.

Ich denke der Threadstarter meinete etwas anderes:

Wie groß darf eigentlich eine Executable unter Win. 32 Bit sein. Das würde mich auch mal interessieren. Zumindest habe ich noch keine 2 GB *.exe Dateien gesehen.

Matti

2004-08-16, 17:22:23

Gas

2004-08-16, 17:32:46

Jetzt ist Doom 3 erschienen und 1 GByte RAM sind schon Pflicht.

Also ich spiels mit 512MB und das funktioniert ausgezeichnet, somit ist deine Aussage falsch.

RaumKraehe

2004-08-16, 17:39:51

Die Datei kann beliebig groß sein, z.B. SFX-Archive. Aber Code- & Daten-Segmente sind in der Größe begrenzt.

Aber doch nicht größer als das größtmögliche Fassungsvermögen des RAMS des jeweiligen Systems?

Hab aber auch noch keine 1 oder 2 GB Archive gesehen. Also mag sein das es die gibt aber wenn dann nicht auf PCs. Es sind ja doch eher kleine Dateien, gesplittet. Was natürlich auch daher kommt das die häppchen ja auch auf eine CD-passen würden. Obwohl das im Zeitalter der DVD-R ja auch langsam egal ist.