Archiv verlassen und diese Seite im Standarddesign anzeigen : Wieviel RAM geht wirklich unter 32bit WinXP auf aktuellen Boards???
pervert
2006-04-07, 05:03:35
Aktuelle Spiele brauchen immer mehr RAM - das merkt man spätestens, wenn man endlich den Schritt von 1 auf 2GB gewagt hat... Wenn man ein bischen "vorarbeiten" will oder kein Interesse an einer Auslagerungsdatei auf der Platte hat, bekommt man schnell Lust sich 4GB reinzustecken...
Doch wieviel RAM kann man störungsfrei (sprich ohne dass XP damit Probleme bekommt) mit aktuellen Chipsätzen, z. B. S939 Boards unter 32bit XP wirklich einsetzen und wie verhält es sich mit der Auslagerungsdatei?
Ich habe mal irgendwo gelesen, dass es nicht mehr als 4GB RAM sein darf INKLUSIVE Auslagerungsdatei und das bei manchen Chipsätzen nicht mehr als physikalische 3.5GB adressiert werden?
Kann man auf aktuellen A64 Boards (und natürlich auf den bald erscheinenden AM2) 4GB RAM wirklich nutzen und darf man dann keine zusätzliche Auslagerungsdatei mehr auf der Platte erstellen um das 4GB Limit nicht zu überschreiten?
Welche Probleme könnten auftreten wenn zuviel physikalischer und/oder virtueller Speicher zur Verfügung steht - z. B. 4GB physikalisch und 4GB Auslagerungsdatei auf der Platte??
Cherubim
2006-04-07, 05:48:59
ich kann mit meinem aktuellen system max 2.7GB von eingebauten 3GB benutzen (32Bit)
auf der 64Bit XP demo waren es die vollen 3GB.
X2 4200+
Asus A8N-SLI del
2x1GB MDT (+ 2x 512MB MDT)
The Cell
2006-04-07, 09:06:46
http://support.microsoft.com/?scid=kb;de;555223&x=7&y=10
Wünsche Spaß bei der Lektüre. ;)
Gruß,
QFT
pervert
2006-04-07, 09:53:01
Wenn ich das halbwegs richtig überblickt habe, lautet die Antwort auf meine Frage 4GB RAM + empfohlene 6 bis beliebig als Pagefile?
HellHorse
2006-04-07, 10:19:34
Aktuelle Spiele brauchen immer mehr RAM - das merkt man spätestens, wenn man endlich den Schritt von 1 auf 2GB gewagt hat... Wenn man ein bischen "vorarbeiten" will oder kein Interesse an einer Auslagerungsdatei auf der Platte hat, bekommt man schnell Lust sich 4GB reinzustecken...
http://support.microsoft.com/?scid=kb;de;555223&x=7&y=10
Die Ressource in kritischem kurzem Angebot kann zu bestimmtem Zeitpunkt nicht erhöht werden. Das bedeutet, dass ein architectural limit erreicht worden ist. Bei einigen häufig gemeldeten Architekturgrenzen in Windows wird berücksichtigt:
...
2. Virtuelles privates Adressraum für 2 GB pro Prozess
Fragen?
Bei mir sinds von 4GB eingebaut 3GB, mehr is nicht.
][immy
2006-04-07, 19:46:41
Aktuelle Spiele brauchen immer mehr RAM - das merkt man spätestens, wenn man endlich den Schritt von 1 auf 2GB gewagt hat... Wenn man ein bischen "vorarbeiten" will oder kein Interesse an einer Auslagerungsdatei auf der Platte hat, bekommt man schnell Lust sich 4GB reinzustecken...
Doch wieviel RAM kann man störungsfrei (sprich ohne dass XP damit Probleme bekommt) mit aktuellen Chipsätzen, z. B. S939 Boards unter 32bit XP wirklich einsetzen und wie verhält es sich mit der Auslagerungsdatei?
Ich habe mal irgendwo gelesen, dass es nicht mehr als 4GB RAM sein darf INKLUSIVE Auslagerungsdatei und das bei manchen Chipsätzen nicht mehr als physikalische 3.5GB adressiert werden?
Kann man auf aktuellen A64 Boards (und natürlich auf den bald erscheinenden AM2) 4GB RAM wirklich nutzen und darf man dann keine zusätzliche Auslagerungsdatei mehr auf der Platte erstellen um das 4GB Limit nicht zu überschreiten?
Welche Probleme könnten auftreten wenn zuviel physikalischer und/oder virtueller Speicher zur Verfügung steht - z. B. 4GB physikalisch und 4GB Auslagerungsdatei auf der Platte??
also ich kenne mindestens einen rechner (P4 ohne 64bit erweiterung etc) der 4GB speicher drin hat, dabei ein 32 bit Win XP Prof verwendet und auch 4GB verwenden kann. die auslagerungsdatei bzw pageing-file ist dabei auch etwa 4 gb groß. das ding dient als server und funktioniert einwandfrei. ich weiß ehrlichgesagt immernoch nicht warum das auch überhaupt ein problem sein sollte
LOCHFRASS
2006-04-07, 21:33:14
Mit PAE sollte das gehen, aber ob der A64 das kann? Zumindest beherrscht es meine Kiste (Presler auf i975X).
Bei mir geht das nur mit Linux, XP64 oder 2003 Server. Ist wahrscheinlich auch nen bisschen von der eingesteckten Hardware und dem eingesetzten Chipsatz abhängig. Aber 4GB auf nem XP32 hab ich noch nicht gesehen (auch nicht mit PAE). Auf meinem alten Intel-Board gingen 3,5GB.. das war das höchste der Gefühle und von der eingestellten Aperture-Sitze abhängig. 3,5GB gabs bei 32MB und wenn man 256MB eingestellt hat waren nur noch 2,87GB übrig.
Selbst Linux bekommt das nicht besser gebacken. Auf dem Intel-Board 3GB und jetzt auf den Nforce4 auch solange das SLI angeschaltet ist. Ohne SLI gehen wenigestens beim X64 und beim Linux die 4GB (ick würde sagen in den Rest des Speichers blenden sich die beiden Grakas ein)
Black-Scorpion
2006-04-07, 21:41:22
Mit PAE sollte das gehen, aber ob der A64 das kann? Zumindest beherrscht es meine Kiste (Presler auf i975X).
Glaube schon das der A64 das kann. ;)
(del)
2006-04-07, 21:48:22
Einfach reinziehen klick (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=3825147#post3825147)
Einfach reinziehen klick (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=3825147#post3825147)
Kommt wie üblich auf den Standpunkt an. Der Threadersteller wird schon seine Gründe haben warum 4GB und Du warum nicht.
Ich bin nen Photoshop-Fan, und mit XP64, CS2 und 4GB beschleunigst Du manche Filter-Operationen um 100%. Denn CS2 kann unter XP64 auch wirklich 4GB nutzen. Nur um mal drauf hinzuweisen das nicht alles hier Gamer sind :-) Alle 3D-Proggis gibts inzwischen in ner 64Bit-Version die so viel Speicher immer gut gebrauchen können und von Datenbanken und so will ich gar nicht reden.
pervert
2006-04-07, 22:01:19
Was genau bedeutet PAE und wie bekommt man das oder welche Chipsätze/CPUs können das? :-)
drdope
2006-04-07, 22:05:41
--> http://de.wikipedia.org/wiki/PAE
PAE -- Physikalische Adress Erweiterung *g* Anstatt 32Bit Speicheradressierung glaub ich 36bit. Ist praktisch nen Aufguss von EMM386. Mann kann dann Page-Weise Speicherhäppchen mit dem Bereich über 4GB austauschen.
Irgendwo hier gibts schon ne sehr gute Erklärung. Das Problem an der Sache ist, normalerweise Verwaltet das OS den Speicher und hier müssen sich die Applikationen darum kümmern etwas von diesen Speicher-Seiten abzubekommen, d.h. wenn die Applikation nicht mit der Option PAE kompiliert worden ist merkt sich gar nix vom vorhandenen Speicher und kann auch nicht drauf zugreifen.
Edit: hier sind die beiden Diskussionen darüber *g*
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=238751&highlight=4gb
und die technische Seite
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=228539&highlight=4gb
(del)
2006-04-07, 22:18:44
Kommt wie üblich auf den Standpunkt an. Der Threadersteller wird schon seine Gründe haben warum 4GB und Du warum nicht
Neeee :) Ich meinte, in dem Thread wurde doch ziemlich gut durchgequatscht was geht, wie es geht und was warum nicht geht.
Neeee :) Ich meinte, in dem Thread wurde doch ziemlich gut durchgequatscht was geht, wie es geht und was warum nicht geht.
*kreisch* Du hast auf jeden Fall den richtigen Thread gefunden... den hab ich vorhin auch schon gesucht :biggrin:
pervert
2006-04-07, 23:57:41
Um PAE muss man sich nur Gedanken machen, wenn man noch mehr als 4GB phy. RAM irgendwie sinvoll nutzen will? Oder nur dann, wenn man zwar 4GB hat, diese aber nicht komplett genutzt werden?
StefanV
2006-04-08, 01:13:27
Mehr als 2GB RAM machen unter einem 32bit Windows keinen Sinn!
Wer mehr nutzen möchte, muss sich wohl oder übel um 64bit Programme und Betriebssysteme kümmern...
Mehr als 2GB RAM machen unter einem 32bit Windows keinen Sinn!
Wer mehr nutzen möchte, muss sich wohl oder übel um 64bit Programme und Betriebssysteme kümmern...
Das müsste heissen... "mehr als 2GB Ram machen für Singletasking-Gamer" dann machts auch Sinn... Jemand der mehr als ein Programm gleichzeitig laufen lässt profitiert auch von 3GB.... und immer an den Disk-Cache denken oder die Ramdisk die man bauen könnte, oder an die Bildbearbeitungs-Jungens die mehr als eine grosse Anwendung laufen haben.
GloomY
2006-04-08, 01:53:19
Um PAE muss man sich nur Gedanken machen, wenn man noch mehr als 4GB phy. RAM irgendwie sinvoll nutzen will? Oder nur dann, wenn man zwar 4GB hat, diese aber nicht komplett genutzt werden?Damit die Applikation PAE benutzen kann, muss sie explizit dafür programmiert sein - unter Windows durch die Address Windowing Extensions (AWE). Außer ein paar Serveranwendungen wie Microsofts SQL-Server o.ä. wirst du kein einziges Programm finden, welches AWE und damit PAE benutzt.
Mit PAE sollte das gehen, aber ob der A64 das kann? Zumindest beherrscht es meine Kiste (Presler auf i975X).PAE ist uralt. Das kann der K7, wenn nicht sogar schon der K6.
(del)
2006-04-08, 12:59:13
Mehr als 2GB RAM machen unter einem 32bit Windows keinen Sinn!
Mal wieder: falsch.
Mehr als 2GB RAM machen unter einem 32bit Windows keinen Sinn!
Wer mehr nutzen möchte, muss sich wohl oder übel um 64bit Programme und Betriebssysteme kümmern...
Erzähl das mal jemandem der professionelle Bildbearbeitung mit entsprechend großen Dateien macht oder Adobe Aftereffects im Produktionsumfeld einsetzt ;)
Je nach Einsatzzweck macht dies für gewisse produktive Arbeiten natürlich Sinn bzw. ist z.T. alleine aufgrund des Cachings ein deutlicher Unterschied vorhanden.
GloomY
2006-04-08, 23:55:01
Mal wieder: falsch.In welchen Fällen ergibt denn deiner Meinung nach mehr als 2 GiB Sinn? Das sind dann die Fälle, in denen mehrere Prozesse jeweils viel Speicher benötigen. Für die meisten Alltagsszenarien geht es aber um einen einzigen Prozess, welcher sich am liebsten den gesamten physikalischen Speicher unter den Nagel reißen möchte. Und da ist halt (spätestens) bei 2 GiB schluss.
StefanV
2006-04-09, 00:00:55
Erzähl das mal jemandem der professionelle Bildbearbeitung mit entsprechend großen Dateien macht oder Adobe Aftereffects im Produktionsumfeld einsetzt ;)
Je nach Einsatzzweck macht dies für gewisse produktive Arbeiten natürlich Sinn bzw. ist z.T. alleine aufgrund des Cachings ein deutlicher Unterschied vorhanden.
Tjo, dann sollten sich diese jenen welchen halt um 64bit Programme und Betriebssysteme kümmern, da kann man dann so viel reinkloppen wie man will (also 4 bei einem 'Standardsystem', 8GB bei Dual Systemen)...
Das es keinen Sinn macht, sagte ich ja auch nicht, ich sagte ja auch nur, das es unter einem 32bit OS nicht viel Sinn macht...
Das müsste heissen... "mehr als 2GB Ram machen für Singletasking-Gamer" dann machts auch Sinn... Jemand der mehr als ein Programm gleichzeitig laufen lässt profitiert auch von 3GB.... und immer an den Disk-Cache denken oder die Ramdisk die man bauen könnte, oder an die Bildbearbeitungs-Jungens die mehr als eine grosse Anwendung laufen haben.
Wenn ich das wirklich machen würde, dann wär das erste, was ich machen würde, für einen 64bit Unterbau zu sorgen, dann nach Möglichkeit auch noch entsprechende Programme...
Das Problem ist ja, das Aufgrund diverser Zusatzkarten und so weiter der Adressraum schon so ziemlich voll ist, Pagefile und schießmichtot gehören da auch zu, das ganze ist bei 32bit Progrämmchen nicht mehr wirklich schön...
(del)
2006-04-09, 01:05:26
In welchen Fällen ergibt denn deiner Meinung nach mehr als 2 GiB Sinn? Das sind dann die Fälle, in denen mehrere Prozesse jeweils viel Speicher benötigen. Für die meisten Alltagsszenarien geht es aber um einen einzigen Prozess, welcher sich am liebsten den gesamten physikalischen Speicher unter den Nagel reißen möchte. Und da ist halt (spätestens) bei 2 GiB schluss.Ich hab keine Szenarien analysiert, sondern einfach die falsche Aussage als falsch bezeichnet. Inwiefern bist Du jetzt damit nicht allzusehr zufrieden, daß es Multitasking gibt? In Deinem Szenario möchte sich ein Prozess 2GB greifen. Das ist fein. Das kann er sogar. In meinem Szenario mit 3GB. In Deinem Szenario bekommt er nur 2GB minus das was mindestens vom Betriebssystem selbst schon belegt ist.
Mach ich dabei jetzt einen schweren Denkfehler oder schieben wir das ganze auf die späte Stunde? ;)
alpha-centauri
2006-04-09, 12:15:39
3,5 gbyte bei bestückten 4 gbyte sagte mal ein member hier im forum.
Muh-sagt-die-Kuh
2006-04-09, 12:24:26
In welchen Fällen ergibt denn deiner Meinung nach mehr als 2 GiB Sinn? Das sind dann die Fälle, in denen mehrere Prozesse jeweils viel Speicher benötigen. Für die meisten Alltagsszenarien geht es aber um einen einzigen Prozess, welcher sich am liebsten den gesamten physikalischen Speicher unter den Nagel reißen möchte. Und da ist halt (spätestens) bei 2 GiB schluss.Mit einer Server Version von Windows (32 bit) und dem /3GB Switch in der Boot.ini wird der virtuelle Adressraum eines Prozesses auf 3 GiB erweitert, unter Linux ist dies auch möglich.
HellHorse
2006-04-09, 13:01:30
Mit einer Server Version von Windows (32 bit) und dem /3GB Switch in der Boot.ini wird der virtuelle Adressraum eines Prozesses auf 3 GiB erweitert, ...
Was aber schon wieder speziell kompilierte Software benötigt.
GloomY
2006-04-09, 14:43:34
Mit einer Server Version von Windows (32 bit) und dem /3GB Switch in der Boot.ini wird der virtuelle Adressraum eines Prozesses auf 3 GiB erweitert, unter Linux ist dies auch möglich.Dazu musst man aber beim Linken des Programms diese Option dem Linker explizit sagen, weil er sonst den Addressbereich von 0x8000000 bis 0xBFFFFFFF nicht benutzten kann/darf. (AFAIK ist das eine Sache des Linkers und nicht des Compilers).
Außerdem geht es um WinXP, also keine Serverversionen. Ob der 3 GiB-Switch auch bei XP geht, weiss ich jetzt nicht mehr genau. Selbst wenn, hätte ihn aber der Großteil der Leute nicht eingeschaltet. Ein Programm, was mit 3 GiB Userspace gelinkt ist, würde daher wohl auf den meisten WinXPs nicht laufen. Solange der Einsatzzweck nicht ein ganz spezieller ist, wird das wohl für Entwickler keine Option sein. Oder kennst du ein Programm, welches nicht ohne den 3GiB-Switch läuft?
Zum anderen fehlt dem Kernel dann ja auch Addressraum, wodurch diese Option ja nicht für alle Leute akzeptabel zu nutzen ist. Wenn man Hardware im Rechner verbaut hat, die viel Addressraum durch Memory-mapped I/O verbraucht (2 Grakas, SCSI-Controller etc.), kann 1 GiB Addressraum im Kernel zu wenig sein. Man kann also auch nicht von den Leuten verlangen, dass diese bei der Installation eines Programms den 3GiB-Switch in der Boot.ini aktivieren, weil es möglicherweise dazu führen könnte, dass andere Hardware nicht mehr funktioniert.
Ein anderes Beispiel dafür, dass der Kernel manchmal nicht mit 1 GiB Addressraum auskommt, ist wenn man sehr viel Speicher verbaut hat. Wenn man mehr als 16 GiB RAM hat (um diesen mit PAE zu nutzen), muss der Kernel wieder mehr als 1 GiB Addressraum haben, weil er sonst nicht genug Platz für die Speicherverwaltung besitzt. (Klick (http://blogs.msdn.com/oldnewthing/archive/2004/08/06/209840.aspx)).
Du hast Recht, dass es die Möglichkeit gibt, den Addressraum auf 3 GiB zu erweitern, aber von dieser wird in der Praxis wohl nur in sehr seltenen Fällen Gebrauch gemacht. Die Antwort auf die Frage wieviel Speicher man denn nun wirklich in der Praxis benutzen kann, lautet daher in der Praxis: Höchstens 2 GiB RAM pro Prozess. Und da es selten mehrere Prozesse gibt, die gleichzeitig gigabyteweise RAM benötigen, ist das auch insgesamt das praktische Limit.
Zudem hat der 2GiB-Raum auch noch einige Löcher. Ich weiß nicht was die maximal allozierbare Größe ist, aber es ist deutlich weniger als 1GiB.
Mit PAE sollte das gehen, aber ob der A64 das kann? Zumindest beherrscht es meine Kiste (Presler auf i975X).
Jede CPU die AMD64 unterstützt muss PAE beherschen. Vor dem Wechsel in den 64 bit Modus ist das zuvor zu aktivieren.
GloomY
2006-04-09, 15:01:43
Ich hab keine Szenarien analysiert, sondern einfach die falsche Aussage als falsch bezeichnet. Inwiefern bist Du jetzt damit nicht allzusehr zufrieden, daß es Multitasking gibt? In Deinem Szenario möchte sich ein Prozess 2GB greifen. Das ist fein. Das kann er sogar. In meinem Szenario mit 3GB.Welche Software verwendet denn den 3GiB-Switch? An der Antwort dieser Frage wirst du sehen, warum der 3 GiB-Switch keine praktische Bedeutung hat.
In Deinem Szenario bekommt er nur 2GB minus das was mindestens vom Betriebssystem selbst schon belegt ist.Nein. Ein Prozess bekommt maximal 2 GiB. Die Addressbereiche, die vom Kernel belegt sind, liegen in den anderen 2 GiB des 4 GiB Addressraums. Also nicht 2 GiB minus das, was vom Kernel belegt ist.
Ich könnte mir auch vorstellen dass der 3GiB-Switch dem GPU-Treiber Performanceprobleme macht. 512MiB VRAM kann man ja nichtmal mit 2GiB Kerneladdressraum ganz einblenden.
Etwas mehr als 2GiB (2,5GiB) sind aber evtl. noch sinnvoll weil der Kernel braucht ja auch paar MiB. Das ist aber wirklich lächerlich wenig.
Soweit ich das richitg verstanden habe kann man also mit AMD64 und Windows64 mehr als 4 GB an Ram nutzen. Wieviele kann man also mit 64 bit CPU und Os theoretisch nutzen ? Gibt es da noch andere Begrenzungen ?
Black-Scorpion
2006-04-09, 19:18:30
Theoretisch 16 Exabyte wie man hier nachlesen kann.
http://www.msexchangefaq.de/konzepte/4gb.htm
BlackBirdSR
2006-04-09, 19:20:41
Theoretisch 16 Exabyte wie man hier nachlesen kann.
http://www.msexchangefaq.de/konzepte/4gb.htm
Und die zugehörige CPU (K8) erlaubt 1024GiB davon (bisher).
Das Problem dürfte aber wohl eher das Mobo sein....
oder gibt es für den Sockel 939 mobos mit mehr als 4 Ram slots ?
pervert
2006-04-09, 19:41:25
Das müsste heissen... "mehr als 2GB Ram machen für Singletasking-Gamer" dann machts auch Sinn... Jemand der mehr als ein Programm gleichzeitig laufen lässt profitiert auch von 3GB.... und immer an den Disk-Cache denken oder die Ramdisk die man bauen könnte, oder an die Bildbearbeitungs-Jungens die mehr als eine grosse Anwendung laufen haben.
Jo, so dachte ich mir das auch. Mag ja sein, dass ein Task nicht mehr als 2GB Adressieren kann und XP/32, aber dann kommt ja noch Pagefile und möglicherweise andere Appz oder mal ne RAM-Disk dazu...
StefanV
2006-04-09, 19:46:22
Das Problem dürfte aber wohl eher das Mobo sein....
oder gibt es für den Sockel 939 mobos mit mehr als 4 Ram slots ?
Das siehst du richtig...
Es gibt weder S939 MoBos mit mehr als 4 Slots noch Module mit mehr als 1GiB RAM.
Das alles wirds erst mit dem M2 geben.
(del)
2006-04-09, 20:25:05
Welche Software verwendet denn den 3GiB-Switch?Nicht die Soft, sondern das OS.
Nein. Ein Prozess bekommt maximal 2 GiB. Die Addressbereiche, die vom Kernel belegt sind, liegen in den anderen 2 GiB des 4 GiB Addressraums. Also nicht 2 GiB minus das, was vom Kernel belegt ist. Es ging mir um den physikalischen Speicher von nun 4GB (3GB). Auf welche Adressbereiche und wie sich das innerhalb der 4GB verteilt, ist nur eine Sache. Ein Prozess kann bei 2GB keine 2GB bekommen. Oder wird dann alles andere aus dem RAM komplett in die Auslagerungsdatei gehauen? Das glaub ich nicht.
Ich hab auf der Seite 1 schon einen thread verlinkt, wo Onkel probeweise 4GB im Rechner hatte (mit entsprechneder Hardware). War zwar kein semipro Test :), in der Zeit hat er aber kaum Vorteile und keine Nachteile feststellen können.
Je nachdem wieviel sich der Kernel krallen muß, hat man bei 4GB RAM mit dem /3GB Switch (zirka!) 3.25 bis 2.8GB für Userspace. Der Kernel wird nicht in dem für ihn konfigurierten 1GB eingeschlossen, Coda. Es gibt keine Probleme. Er fängt nur bei 4GB an und überlässt den Rest dem User. Den Rest, der beim Booten übrig bleibt.
Ìst der verlinkte Thread echt so schwer zu lesen? :frown:
Falls ich dennoch was total verkehrt verstanden habe, bitte um Berichtigung.
Nicht die Soft, sondern das OS.
Die Software muss das zusätzlich auch unterstützen.
The /LARGEADDRESSWARE option tells the linker that the application can handle addresses larger than 2 gigabytes.
Andernfalls bleibt es bei 2GiB. Grund? Kompatibilität zu idiotischen Programmen die das höchste Bit von Pointern für andere Dinge verwenden.
Je nachdem wieviel sich der Kernel krallen muß, hat man bei 4GB RAM mit dem /3GB Switch (zirka!) 3.25 bis 2.8GB für Userspace. Der Kernel wird nicht in dem für ihn konfigurierten 1GB eingeschlossen, Coda. Es gibt keine Probleme. Er fängt nur bei 4GB an und überlässt den Rest dem User. Den Rest, der beim Booten übrig bleibt.
WTH? Nein! Es sind definitiv immer 3GiB (es sei denn es wird eine andere Größe zwischen 2048 und 3072MiB angegeben, aber dann gilt das trotzdem für alle Programme gleich).
The /3GB parameter enlarges the user-mode virtual address space to 3 GB and restricts the kernel-mode components to the remaining upper 1 GB.
Der Kernel wird also sehr wohl auf diese 1GiB eingeschlossen.
Muh-sagt-die-Kuh
2006-04-09, 21:26:07
Du hast Recht, dass es die Möglichkeit gibt, den Addressraum auf 3 GiB zu erweitern, aber von dieser wird in der Praxis wohl nur in sehr seltenen Fällen Gebrauch gemacht. Die Antwort auf die Frage wieviel Speicher man denn nun wirklich in der Praxis benutzen kann, lautet daher in der Praxis: Höchstens 2 GiB RAM pro Prozess. Und da es selten mehrere Prozesse gibt, die gleichzeitig gigabyteweise RAM benötigen, ist das auch insgesamt das praktische Limit.Sicher? Programme fordern vom Betriebsystem dynamisch Speicher auf dem Heap an. Nehmen wir einfach mal C an, dort geschieht das mit malloc(), der Rückgabewert ist ein Pointer auf den Anfang des allozierten Speicherbereichs. Was spricht nun dagegen, dass dieser im Bereich zwischen 0x8000000 bis 0xBFFFFFFF liegt? Dem Programm ist es prinzipiell egal wo er liegt, so lange keine Access Violation auftritt.
P.S.: Das ist eine Vermutung aus dem Bauch heraus, ich hatte keine Lust nach Quellen zu suchen ;)
Was spricht nun dagegen, dass dieser im Bereich zwischen 0x8000000 bis 0xBFFFFFFF liegt?
Grund? Kompatibilität zu idiotischen Programmen die das höchste Bit von Pointern für andere Dinge verwenden.
Da man das nicht anders gewährleisten kann muss das Programm sich darum selbst bemühen.
Muh-sagt-die-Kuh
2006-04-09, 23:45:41
Da man das nicht anders gewährleisten kann muss das Programm sich darum selbst bemühen.Das ist klar, aber wieso geht man nicht einfach davon aus, dass Programme solchen Mist nicht machen? Machen sie es doch => Pech, dann schmieren sie eben ab...
Das ist klar, aber wieso geht man nicht einfach davon aus, dass Programme solchen Mist nicht machen? Machen sie es doch => Pech, dann schmieren sie eben ab...
Tja, das erzähl dann mal den Leuten die mit dem gleichen Betriebssystem sowohl Programme laufen lassen wollen die 3GiB brauchen und andere die damit abschmieren ;)
Andererseits ist es eine Tatsache, dass es so gemacht wurde, also müssen wir uns damit abfinden. Die Entscheidung dazu reicht übrigens in NT-4.0-Zeiten zurück. Ich denke damals hat man sich auch noch nicht so richtig Gedanken um diese irrsinnigen Mengen virtuellen Speichers gemacht ;)
Überhaupt finde ich die Diskussion sowieso mühselig. 64 bit ist ja anscheinend noch gerade rechtzeitig von AMD durchgedrückt worden um so einen Mist im Keim zu ersticken.
GloomY
2006-04-09, 23:57:41
Sicher? Programme fordern vom Betriebsystem dynamisch Speicher auf dem Heap an. Nehmen wir einfach mal C an, dort geschieht das mit malloc(), der Rückgabewert ist ein Pointer auf den Anfang des allozierten Speicherbereichs. Was spricht nun dagegen, dass dieser im Bereich zwischen 0x8000000 bis 0xBFFFFFFF liegt? Dem Programm ist es prinzipiell egal wo er liegt, so lange keine Access Violation auftritt.
P.S.: Das ist eine Vermutung aus dem Bauch heraus, ich hatte keine Lust nach Quellen zu suchen ;)Du hast Recht. Es ist möglich, wenn das Programm entsprechend gelinkt ist und das OS mit dem 3GiB-Switch gestartet wurde, dass dann zur Laufzeit angeforderter Speicher in diesem Bereich liegt.
Er meinte glaube ich dass das generell jedem Programm so in den Rachen geschoben werden sollte.
GloomY
2006-04-10, 00:16:15
Er meinte glaube ich dass das generell jedem Programm so in den Rachen geschoben werden sollte.Du meinst, dass generell jedes Programm einen 3 GiB-Addressraum bekommen sollte? Wie gesagt gibt es da mehrere Probleme: Zum einen könnte der Kernel dann zuwenig Addressraum bekommen (so dass dann einige Hardware nicht läuft) oder aber einige Programme laufen dann nicht mehr, weil diese explizit davon ausgehen, daß das oberste Bit eines Pointers nicht gesetzt ist. Oder aber ein Programm verwendet z.B. zum Berechnen von der Mitte des Abstands zweier Pointers die Formelc = (a+b)/2stattc = a + (b-a)/2Erstere Version kann bei Verwendung von Pointern aus dem "3 GiB-Bereich" bei der Arithmetik zu einem Überlauf führen (a+b > 2^32), welcher das Programm nicht mehr korrekt laufen lässt. ;(
Du meinst, dass generell jedes Programm einen 3 GiB-Addressraum bekommen sollte?
Nein, nicht ich. Bist du heut etwas übermüdet oder so? Zumindest scheinst du die Postings nicht richtig zu verfolgen. ;)
Aber hey, das zweite Problem war mir gar nicht bewusst. Aber wo braucht man sowas? :|
GloomY
2006-04-10, 00:19:20
Nein, nicht ich.Sorry, ich hab' mich falsch ausgedrückt. Du meintest, dass Muh-sagt-die-Kuh meinen könnte, daß... Richtig?
Bist du heut etwas übermüdet oder so? ;)Ist tatsächlich so. :| Ich glaub' ich geh' jetzt echt ins Bett ;(
Muh-sagt-die-Kuh
2006-04-10, 12:22:38
Er meinte glaube ich dass das generell jedem Programm so in den Rachen geschoben werden sollte.Exakt das meine ich. Wie machen es eigentlich andere Compiler / Linker Kombinationen als die von MS unter Windows? Gibt es bei denen auch so einen Switch?
Naja....die Diskussion ist zwar lustig, aber wie schon gesagt eigentlich hinfällig...mit einem 64 bit OS verschwinden diese Unzulänglichkeiten einfach.
Wie machen es eigentlich andere Compiler / Linker Kombinationen als die von MS unter Windows? Gibt es bei denen auch so einen Switch?
Wenn nicht bekommen sie nur 2GiB.
HellHorse
2006-04-10, 18:02:32
Das ist klar, aber wieso geht man nicht einfach davon aus, dass Programme solchen Mist nicht machen? Machen sie es doch => Pech, dann schmieren sie eben ab...
Jedes andere OS würde das auch so machen, schliesslich ist das das einzige vernüftige Verhalten. Ausser Windows, hier ist das ein zentrales Feature.
Da baut man sogar spezielle Hacks ein, dass Prozesse nicht abgeschossen werden, die eigentlich abgeschossen werden müssten, z.B. weil sie auf vor kurzem freigegeben Speicher zugreiffen (in einem geleakten 2000 Sourcereview fanden sich einige Perlen).
So läuft z.B. der Wise Installer auf Linux (Wine) nicht, weil ebensolche hacks fehlen.
Das läuft ins genau gleiche rein wie Ordner mit DOS-Gerätenamen.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.