Unterschied Adressraum vs Arbeits/Virtueller Speicher [Archiv]

avalanche

2005-06-12, 22:50:26

Da in einigen Threads immer gewettert wird, das der Adressraum bei aktuellen Games noch ausreicht, andere aber anderer Meinung sind, sollten wir uns mal damit beschäftigen, den Unterschied von Adressraum zu Arbeitsspeicher zu erklären.

Daher meine Frage:
Was ist der Adressraum?
Was gehört alles dazu?
Was macht man damit?
Warum wird der Adressraum eng, obwohl aktuelle Programme kaum 2GB nutzen?
Folgendes Problem: Ich bin mir nicht sicher, ob das alles so richtig ist, was ich erzähle. Das Folgende steht unter der Vorraussetzung, dass ich alles richtig verstanden habe. Hängt mich nicht auf, wenn was falsch ist.

Adressraum: Der Adressraum enstpricht der Breite der Speicheradresse. Wenn ich also einen 40 Bit großen Adressraum habe, dann hab ich 40 Bit zur Speicheradressierung.
"Was macht man damit?": Man addressiert einzelne Datenwörter im Speicher. Ich denke, dass unter "Speicher" sowohl RAM als auch das Swapfile fallen.
Genau da sehe ich das Problem. Sobald Swapfile + RAM die Größe erreichen, die nicht mehr mit dem gegebenen Adressraum verwaltbar ist, man also mehr als 2^40 Datenwörter hat, wirds kritisch.

Bitte berichtigt mich, wenn ich was verzapft hab.

EDIT: Das Problem ist denk ich garnicht mal das Benutzen vom Speicher, sondern das Haben des Speichers, bzw. das Haben der vielen Datenwörter.

Gast

2005-06-13, 00:07:35

bei 32bit adressen kann man 4gb adressieren. 2gb für den kernel (für treiber, buffer,...) 2gb für das programm. haben wollen ist kein problem, aber adressieren.

Coda

2005-06-13, 00:34:06

Ich versuch's mal.

Was ist der Adressraum?Der (virtuellen) Speicher den eine Applikation erreichen kann mit (linearer) Adressierung.
Man muss beachten dass jede App ihren eigenen 4GB (bei 32bit) großen Raum hat, die normalerweiße voneinander abgeschottet sind (außer man will es oder bei DLLs z.B.).

Es ist übrigens durchaus möglich mehr als 4GB swap zu haben. Und somit auch theoretisch möglich 10 Programme die jeweils 2GB fressen am laufen zu halten (happy swapping halt ;))

Die übersetzung in eine reelle physikalische Addresse wird von der CPU bei jedem Speicherzugriff ausgeführt. Wenn die Seite nicht im RAM vorhanden ist (also im Swap) wird eine Prozessor-Exception ausgeführt und das OS swapt.

Die Verwaltung von Swapspeicher ist für die App also völlig transparent und sie hat darauf keinerlei Einflussmöglichkeiten!

Was gehört alles dazu?Bei 32bit Systemen unter 2GB alle Daten die das Program im Speicher halten will oder muss. Über 2GB hat dann das OS Platz für Dinge wie I/O etc.

Was macht man damit?Gar nichts eigentlich. Es ist ja nur eine Größenangabe irgendwie...

Warum wird der Adressraum eng, obwohl aktuelle Programme kaum 2GB nutzen?Erstens geht der Platz für I/O aus, weil die Grafikkarten zuviel RAM haben und zweitens gibt es auch Speicherfragmentierung, wodurch die 2GB sehr schnell schmelzen können. Beim Speicher ist es ja nicht möglich einen allokierten Bereich zu verteilen, sondern er muss wirklich zusammenhängend sein. Verschieben ist auch nicht möglich, weil die Speicheraddresse sich nicht verändern darf, d.h. defragmentierung ist nicht möglich.

Mit 64bit hätte man diese Probleme wieder in weite Ferne gerückt... Man holt sich einfach ganz hinten nen neuen Block, es gibt ja "unendlich" Platz ;)

Das der Adressraum nicht ausreicht bei aktuellen Spielen kann ja gar nicht sein, weil sie dann eine Fehlermeldung produzieren würden.

GloomY

2005-06-14, 15:43:36

Ich habe mir mal erlaubt, die Thematik zu visualisieren. Die Vorlage dafür stammt aus Hennessy & Patterson's Computer Architecture. Ich habe sie aber noch um memory mapped I/O und memory mapped files erweitert, sowie den Adressraum ein bisschen größer gemacht.

(Im folgenden steht 'K' für 1024, nicht für 1000.)

http://img162.echo.cx/img162/7854/blub5gy.th.png (http://img162.echo.cx/my.php?image=blub5gy.png)
(Thanks to ImageShack for Free Image Hosting (http://www.imageshack.us))

Links ist der Adressraum eines Prozesses zu sehen. Das sind die Adressen, die das Programm sieht und mit denen es rechnet. Dieser Adressraum ist in Seiten mit einer Größe von 4kiB eingeteilt. Das ist bei x86 so, bei anderen Architekturen kann die Einteilung gröber oder feiner sein. Das ist aber nur ein Detail am Rande.
Rechts oben ist der Hauptspeicher zu sehen. Es wird ebenso in Einheiten aufgeteilt, die genau so groß wie die Seitengröße des Adressraums sind. Zur besseren Unterscheidung von den Seiten (engl.: pages) des Adressraums nennt man die Einteilungen des physikalischen Speichers Rahmen (engl.: frames).
Um auch hier wieder die beiden Adressen unterscheiden zu können, spricht man von der virtuellen Adresse, wenn man die aus dem Adressraum meint (links) und von der physikalischen Adresse, wenn man die des RAM-Speichers meint (rechts).

Damit man nun Daten speichern kann, gibt es eine (eindeutige) Zuordnung von Seiten auf Rahmen. Im Beispiel im Bild wären das die Seiten A, B und C. Aus diesen Seiten werden die virtuellen Adressen in physikalische Adressen des RAMs "übersetzt". Nehmen wir als Beispiel mal die Seite C: die virtuellen Adressen sind hier aus dem Intervall [8K, 12K] und werden auf die physikalischen Adressen aus dem Intervall [4K, 8K] abgebildet. Eine beliebige Adresse x aus dem Intervall C mit x = 8K + y wird damit auf die physikalische Adresse 4K + y abgebildet. Das "Offset" innerhalb einer Page wird also einfach zur Anfangsadresse des Rahmens dazuaddiert.

Bsp.: virtuelle Adresse 9582 erhält welche physikalische Adresse? 9582 ist 8192 + 1390. Also ist die physikalische Adresse 4096 + 1390 = 5486.

Bsp2.: virtuelle Adresse 6037. Da diese in B liegt und B auf das Intervall [24K, 28K] abgebildet wird, müssen wir folgendermaßen rechnen: 6037 = 4096 + 1941. Also lautet die physikalische Adresse 24K + 1941 = 26517.

Soviel zum Hauptspeicher. Neben der Adressierung von physikalischem RAM-Speicher werden die virtuellen Adressen des Adressraums aber auch noch für andere Dinge benutzt. Es gibt z.B. die Möglichkeit, dass Seiten auf die Festplatte ausgelagert werden (im Bild rechts Mitte). Das ist bei D der Fall. Der Inhalt von D lag früher mal im RAM-Speicher, wurde dann aber auf die Festplatte kopiert, die Zuordnung verändert und somit Platz für neue Rahmen im Hauptspeicher gemacht.

Der Adressraum wird also zum Adressieren des Hauptspeichers und der Daten im Swap-File (bzw. Swap-Partiton) benutzt.

Weiterhin gibt es noch anderen Speicher, welcher adressiert werden möchte. Das ist der Grafikspeicher, der rechts unten im Bild zu sehen ist.

Damit z.B. der Grafikkartentreiber Texturen in den Speicher der Grafikkarte laden kann, muss der Treiber den Grafikspeicher adressieren können. Das wird mittels "memory-mapped I/O" gemacht. Dabei wird eine gewissen Menge an virtuellen Adressen dem Grafikspeicher zugeordnet, genau so wie es beim Hauptspeicher der Fall war. In unserem Beispiel werden die Seiten I, J und K auf den Grafikspeicher abgebildet.
Dadurch dass das Programm einfach von diesen virtuellen Adressen lesen bzw. dort schreiben kann, unterscheidet sich ein Zugriff auf den Hauptspeicher nicht von einem Zugriff auf den Grafikspeicher, was die Programmierung vereinfacht.
Das gleiche gilt für andere I/O Geräte wie PCI Karten usw. Diese werden üblicherweise auch mit memory-mapped I/O angesprochen.

Die virtuellen Adressen werden als nicht nur zur Adressierung des Hauptspeichers und der Auslagerungsdatei benutzt sondern auch für memory mapped I/O.

Weiterhin gibt einige Fälle, wo memory-mapped Files zum Einsatz kommen. Das ist im Prinzip sehr ähnlich wie memory-mapped I/O, jedoch sind hier ganz einfach Dateien auf der Festplatte das Ziel der Zuordnung. Das ist in unserem Beispiel bei N der Fall. Wenn man also von einer Adresse aus dem Bereich N (52K bis 56K) ließt, ließt man also von der Festplatte (oder einem anderen Laufwerk). Auch hierfür wird ein Teil des Adressraums benötigt.

Wie ich hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=3145203#post3145203) schon mal erklärt habe, gibt es dann noch Seiten, die vom Kernel reserviert wurden, aber noch keinen physikalischen Speicher belegen.
Also geht hierfür auch wieder Adressraum verloren (in unserem Beispiel: F und G).

Weiterhin gibt es noch ein paar andere Fälle, die ich hier nicht aufgezählt habe, wo Adressraum verbraucht wird. Siehe dazu auch hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=208888).

Ich hoffe, dass es nun einigermaßen klar ist, wie Speicherverwaltung in modernen Betriebssystemen funktioniert. In meinem Beispiel habe ich nur einen Prozess gezeichnet, was natürlich in der Realität nicht hinkommt. Es gibt also noch ein paar mehr Adressräume (für jeden Prozess einen), die dann alle einen Teil ihrer Seiten dem physikalischen Speicher zuordnen bzw. I/O Speicher usw.

Ansonsten noch mal ein paar Anmerkungen zu meiner Grafik: Der Adressraum ist hier mehr als doppelt so groß wie der Hauptspeicher. In letzterem sind 5 Rahmen frei, jedoch ist es trotz doppelter Größe des Adressraums hier nicht möglich, mehr als drei Rahmen auf einmal anzufordern, weil es nicht genügend zusammenhängenden Platz im virtuellen Adressraum gibt. Der Verbrauch durch andere Dinge wie memory-mapped I/O usw. und die (externe) Speicherfragmentierung verhindern dies. Nicht gut, gar nicht gut :|

Coda

2005-06-14, 16:33:27

Der Adressraum wird also zum Adressieren des Hauptspeichers und der Daten im Swap-File (bzw. Swap-Partiton) benutzt.Das ist so nicht ganz richtig imho. Der swap wird ja vom OS verwaltet und die CPU löst nur Exceptions aus wenn die Seite nicht im DRAM vorhanden ist.

Banshee18

2005-06-14, 17:56:08

Weiterhin gibt einige Fälle, wo memory-mapped Files zum Einsatz kommen. Das ist im Prinzip sehr ähnlich wie memory-mapped I/O, jedoch sind hier ganz einfach Dateien auf der Festplatte das Ziel der Zuordnung. Das ist in unserem Beispiel bei N der Fall. Wenn man also von einer Adresse aus dem Bereich N (52K bis 56K) ließt, ließt man also von der Festplatte (oder einem anderen Laufwerk). Auch hierfür wird ein Teil des Adressraums benötigt.

Was sind das für spezielle Fälle?

Noch eine Frage: Es gibt ja Programme, mit denen man Ram angeblich defragmentieren kann. Müsste man dann nicht auch den Adressraum defragmentieren (was ja nicht möglich ist), da sonst die Daten im Ram nicht mehr richtig adressiert werden? Oder hab ich da die Zusammenhänge ganz falsch verstanden?
Sehr schön geschrieben, übrigens, war bestimmt viel Arbeit. :up:

MfG

Banshee

Edit: Man liest immer von 4GB Adressraum bei heutigen 32 Bit-CPUs. Wieviel sind es denn bei den 64-Bitern? :redface:

Gast 2005

2005-06-14, 18:10:51

Was sind das für spezielle Fälle?

Jede Anwendung kann den Dateizugriff so handhaben. Die Funktion der WinAPI dazu heißt CreateFileMapping();

Edit: Man liest immer von 4GB Adressraum bei heutigen 32 Bit-CPUs. Wieviel sind es denn bei den 64-Bitern? :redface:
Bei 32 Bit ist der Adressraum 2^32 Bit = 4GB.
Bei 64 Bit dementsprechend 2^64 Bit = (2^32) * (2^32), also das 2^32fache eines 32 Bit Adressraums. Also (ganz ungenau) etwa 16 Millarden Gigabyte.

Das ist aber alles Theorie, ich hab keine Ahnung wieviel die heutigen Athlon 64er praktisch ansprechen können.

StefanV

2005-06-14, 18:25:50

Bei 32 Bit ist der Adressraum 2^32 Bit = 4GB.
Bei 64 Bit dementsprechend 2^64 Bit = (2^32) * (2^32), also das 2^32fache eines 32 Bit Adressraums. Also (ganz ungenau) etwa 16 Millarden Gigabyte.

Das ist aber alles Theorie, ich hab keine Ahnung wieviel die heutigen Athlon 64er praktisch ansprechen können.
AFAIK 40bit Physischen Speicher (etwa 1TB, wenn ich mich nicht verschätzt hab) und 48bit 'virtuell', 256TB, wenn ich mich nicht verschätzt hab.

Das ganze kann man theoretisch natürlich noch a bisserl erweitern...

Coda

2005-06-14, 18:32:31

Noch eine Frage: Es gibt ja Programme, mit denen man Ram angeblich defragmentieren kann. Müsste man dann nicht auch den Adressraum defragmentieren (was ja nicht möglich ist), da sonst die Daten im Ram nicht mehr richtig adressiert werden? Oder hab ich da die Zusammenhänge ganz falsch verstanden?Das ist Bauernfängerei.

Banshee18

2005-06-14, 18:46:00

Das ist Bauernfängerei.
Schreib dir blos nicht die Finger wund. :biggrin:
Ist das, was ich geschrieben habe, so richtig? Was machen diese Programme dann? Irgendwas machen sie ja.

Coda

2005-06-14, 19:07:08

HellHorse

2005-06-14, 20:22:01

Das ist Bauernfängerei.
Naja, der Heap kann schon fragmentieren:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=1660249&postcount=7

Coda

2005-06-14, 20:26:58

Ich hab doch schon selber hier im Thread gesagt, dass Speicher natürlich fragmentieren kann. :rolleyes:

Nur ist es nicht möglich ihn zu defragmentieren, und schon gar nicht mit einem Userspace Program.

mrdigital

2005-06-14, 20:42:10

Im virtuellen Speicher kann man nichts defragmentieren und beim phsyikalischen ist es völlig egal wie die Pages im RAM verteilt sind, weil die Zugriffe eh immer gleich schnell sind im Gegensatz zu ner HD.

Abgesehen davon, dass ein Userspace Program darauf keinerlei Einfluss hat ;)
Naja, der Speicher kann schon fragmentieren, und wenn du dann mit malloc() dir (viel) Speicher holen willst, dann wird es fehlschlagen. Ausserdem spielt es für die Zugriffsgeschwindigkeit schon eine Rolle, ob man für jedes Byte neu adressieren muss, oder ob all meine Daten linear an einem Strang im Speicher liegen, in der Regel sind Caches auf Blockzugriffe optimiert und man wird doch arg bestraft, wenn man das Alignment mißachtet.

HellHorse

2005-06-14, 21:04:36

Nur ist es nicht möglich ihn zu defragmentieren, und schon gar nicht mit einem Userspace Program.
Doch schon, Garbage Collector / VM.

Xmas

2005-06-14, 21:19:35

Naja, der Speicher kann schon fragmentieren, und wenn du dann mit malloc() dir (viel) Speicher holen willst, dann wird es fehlschlagen.
Das wurde auch schon geschrieben

Ausserdem spielt es für die Zugriffsgeschwindigkeit schon eine Rolle, ob man für jedes Byte neu adressieren muss, oder ob all meine Daten linear an einem Strang im Speicher liegen, in der Regel sind Caches auf Blockzugriffe optimiert und man wird doch arg bestraft, wenn man das Alignment mißachtet.
Ähm, und Frames sind keine Blöcke und nicht aligned?

Coda

2005-06-14, 21:30:59

Naja, der Speicher kann schon fragmentieren, und wenn du dann mit malloc() dir (viel) Speicher holen willst, dann wird es fehlschlagen. Ausserdem spielt es für die Zugriffsgeschwindigkeit schon eine Rolle, ob man für jedes Byte neu adressieren muss, oder ob all meine Daten linear an einem Strang im Speicher liegen, in der Regel sind Caches auf Blockzugriffe optimiert und man wird doch arg bestraft, wenn man das Alignment mißachtet.Wo sage ich denn das Speicher nicht fragmentieren kann? Ließt eigentlich überhaupt jemand was ich schreibe? :crazy:

Was hat denn jetzt Alignment mit Speicherfragmentierung zu tun? Und es ist völlig egal wie die Daten in Speicher liegen, das wird alles durch prefetches kaschiert. Am Strang lesen geht auch kreuz und quer schnell.

Doch schon, Garbage Collector / VM.Du hast auch nicht gelesen um was es ging.

Aqualon

2005-06-14, 21:41:46

Schreib dir blos nicht die Finger wund. :biggrin:
Ist das, was ich geschrieben habe, so richtig? Was machen diese Programme dann? Irgendwas machen sie ja.Die verbrauchen kurzzeitig soviel Speicher, dass das OS den Rest in das Swapfile auslagert. Wenn das Programm beendet wurde, ist natürlich der angezeigte freie Speicher größer. Bringt aber nix bzw. verlangsamt sogar das OS. Wenn du etwas speicherlastiges startest, wird der Swapvorgang sowieso automatisch vorgenommen (mit dem "Defragmentierer" verlagerst du das nur) und wenn du den einfach so startest, werden alle Wechsel zu geöffneten Programmen länger dauern, weil ihre Daten erst wieder aus dem Swapfile in den Speicher kopiert werden müssen.
Doch schon, Garbage Collector / VM.
Die können das aber auch nur für Speicher machen, der ihnen selbst gehört. Aber es gibt kein Programm, das diese für den kompletten Speicher machen könnte.

Aqua

GloomY

2005-06-16, 02:33:35

Das ist so nicht ganz richtig imho. Der swap wird ja vom OS verwaltet und die CPU löst nur Exceptions aus wenn die Seite nicht im DRAM vorhanden ist.Jein. Die Seiten sind nur als "nicht im Haupspeicher" markiert. Bei einem Page Miss sucht das OS die entsprechenden Blöcke von der Platte. Dafür muss es auch wissen, wo es denn die Daten für die entsprechende Page suchen muss. Imho wird das auch in irgendeiner Datenstruktur im Kernel gespeichert.

Die Seite wird also auf "nicht im Hauptspeicher" abgebildet und das OS sucht dann die entsprechenden Blöcke, also kann man es imho auch so sehen, als wenn die Seiten auf Blöcke der Festplatte abgebildet würden. Der Mechanismus ist schon ein etwas komplizierterer, das gebe ich zu. Insofern war aber die Aussage mit der Zuordnung von Seiten auf Blöcke der Platte nicht ganz falsch, auch wenn das OS das macht und wenn beim Zugriff die zu lesenden Blöcke der Platte und ein Rahmen im Speicher ausgetauscht weden.

AnPapaSeiBua

2005-06-16, 16:31:19

GloomY

2005-06-16, 19:41:49

Wenn ich jetzt mit malloc oder new neuen Speicher reserviere, müsste es theoretisch doch möglich sein, dass der mir zugewiesene - in meinem Adressraum zusammenhängende Speicherblock - im physikalischen RAM und/oder Swap fragmentiert vorliegt. Es sollte doch dadurch möglich sein, knapp 2 GB "am Stück" zu reservieren.Wenn du 2 GB an zusammenhängendem Adressraum bekommst, dann (und nur dann) kannst du auch 2 GB reservieren. Das Problem ist aber, dass es sehr unwahrscheinlich ist, dass du ein 2 GB Stück in deinem 4 GiB Adressraum frei hast.

Wie das im RAM oder auf der Swap aussieht, ist vollkommen uninteressant. Das kann man ja auch beliebig hin- und herschieben, wenn man die Zuordnung entsprechend ändert, dass die Adressbereiche weiterhin auf ihre jeweiligen Daten im Speicher abgebildet werden.
Hatte mal vor einer Zeit an einer 3-GB-Maschine unter XP das Problem, keine großen Speicherblöcke reservieren zu können. In kleinen Häppchen von 1-MB-Blöcken konnte ich knapp 2 GB bekommen, aber einen Block von 1 GB bekam ich nicht. Ist da jetzt malloc zu blöd oder Windows?Genau das ist es, was man als externe Speicherfragmentierung (*) bezeichnet. Weder malloc noch Windows kann etwas dafür. Der Adressraum ist einfach zu klein und zu fragmentiert, als dass es genügend große Blöcke gibt, die man am Stück anfordern könnte. Dazu kommt speziell bei Windows auch noch folgendes Altlasten-Problem:

Bei Windows ist ein kleiner Teil des Adressraums (64kiB) von der Nutzung grundsätzlich ausgeschlossen. Dieser Teil liegt dazu noch ausgerechnet inmitten des 4 GiB Adressraums. Daraus ergibt sich, dass es schonmal gar nicht möglich ist, mehr als 2 GiB am Stück zu alloziiern, selbst wenn man den User-Adressbereich mittels "/3GB"-Switch in der boot.ini auf 3 GiB vergrößert.

http://blogs.msdn.com/oldnewthing/archive/2003/10/08/55239.aspx

Diese Einschränkung kommt noch aus den alten Tagen daher, als es WindowsNT für die Alpha gab. Da diese eine reine 64 Bit Architektur war, gab es keinen Befehl, der 32 Bit Werte laden konnte. Da die Alpha aber auf einem 32 Bit Betriebssystem laufen sollte, musste man dies durch das Emulieren mit mehreren Befehlen durchführen. Bloss musste man in der Nähe der 2 GB Grenze aufpassen, um nicht falsche Adressberechnungen durchzuführen. Daher beschränkte man sich auf den Bereich von 0 bis 2GiB - 64 KiB, womit man sich die Überprüfung sparen konnte. Es war somit eine Abwägung von Geschwindigkeit (+50%) gegenüber einem kleinen Adressbereich, der als unnutzbar verloren ging.

Dies ist bis heute in allen NT-basierten Betriebssystemen so geblieben, weil es nur einen gemeinsamen Code für alle Architekturen gibt (siehe Comments in obigem Link). D.h. selbst auf nativer 32 bit Hardware wie x86 wird der Adressbereich von 0x7FFF0000 bis 0x7FFFFFFF von Windows nicht benutzt. Dämlicherweise liegt das nun aber fast genau in der Mitte des 4 GiB Adressraums ;(

(*) "extern" deswegen, weil es auch noch den Begriff der internen Speicherfragmentierung gibt. Letzteres bezeichnet die Fragmentierung innerhalb einer Seite, während die externe Fragmentierung das Problem der nicht im Adressraum zusammenhängenden Seiten beschreibt, also eben die Fragmentierung "ausserhalb" der Seitengröße.

GloomY

2005-06-16, 20:30:30

Ich habe gerade noch mal etwas mehr zum Thema Speicherfragmentierung gesucht und gelesen. Dabei ist mir das (http://blogs.msdn.com/oldnewthing/archive/2004/08/12/213468.aspx#215933) in die Hände gefallen. Es geht um die Ausführung von Word und der Belegung des Adressraums mit DLLs und sonstigen Code-Seiten (wie das Programm Word selbst) mit ihrer Anfangs- und Endadresse. Zur besseren Lesbarkeit habe ich so Sachen wie Timestamp und Checksum weggelassen. Darum geht es hier ja auch nicht.
start end module name
01830000 0183f000 Vxdif
06470000 06582000 Apoint
10000000 1005b000 SKCHUI
30000000 30a4b000 WINWORD
30b00000 3145e000 mso
32520000 32532000 msohev
34eb0000 34ec9000 ENVELOPE
35190000 351a1000 SENDTO
35230000 35236000 envelopr
3c640000 3c666000 FNAME
3c740000 3c77d000 MOFL
3e000000 3e0f1000 srintl
3f000000 3f015000 MSSPELL3
3f100000 3f431000 MSGR3EN
48000000 4807d000 riched20
5bc50000 5bc88000 sptip
5cc10000 5ccbe000 sapi
60970000 60979000 mslbui
64e30000 64e6d000 icm32
6e210000 6e254000 CNBJUI2
6e2c0000 6e2dd000 CNBJDRV2
70ad0000 70bb6000 comctl32
70bc0000 70c50000 COMCTL32_70bc0000
71640000 71805000 AcGenral
71af0000 71b1a000 ShimEng
71b70000 71ba3000 UxTheme
71bf0000 71bf8000 WS2HELP
71c00000 71c18000 WS2_32
71c20000 71c31000 tsappcmp
71c40000 71c93000 NETAPI32
72e50000 72f9a000 msxml3
73070000 73096000 winspool
73aa0000 73ab4000 mscms
73b30000 73b36000 dciman32
744c0000 744e8000 msimtf
744f0000 7453b000 MSCTF
74540000 745d2000 mlang
74a80000 74aaf000 OLEACC
75970000 75a2a000 USERENV
75da0000 75e5a000 SXS
75e60000 75e82000 appHelp
75eb0000 75fb6000 browseui
75fc0000 76048000 urlmon
76260000 76270000 WINSTA
76290000 762ad000 imm32
762b0000 762f7000 comdlg32
76300000 76514000 msi
76520000 7653d000 CSCDLL
76540000 76590000 cscui
765a0000 766a0000 SETUPAPI
766d0000 766d9000 SHFOLDER
767a0000 767d5000 UNIDRVUI
767e0000 76823000 UNIDRV
768e0000 768e8000 LINKINFO
768f0000 76914000 ntshrui
76920000 76a77000 shdocvw
76aa0000 76acc000 WINMM
76f00000 76f08000 wtsapi32
76f50000 76f63000 Secur32
76f90000 7700e000 CLBCatQ
77010000 770d6000 COMRes
770e0000 7715d000 OLEAUT32
77160000 77285000 OLE32
77290000 772d9000 SHLWAPI
77380000 77b5e000 SHELL32
77b70000 77b84000 MSACM32
77b90000 77b98000 VERSION
77ba0000 77bf4000 msvcrt
77c00000 77c44000 GDI32
77c50000 77cf5000 RPCRT4
77d00000 77d8f000 USER32
77da0000 77e30000 ADVAPI32
77e40000 77f34000 kernel32
77f40000 77ffa000 ntdll
780c0000 78121000 MSVCP60Soweit ich das sehe, dürfte der größte zusammenhängende Adressbereich jener zwischen 0x1005b000 und 0x30000000 sein. Das sind ~536 MB. Wenn man also 600 MB RAM in einem Stück anfordern will, schlägt das schon fehl, weil der Adressraum durch die Nutzung von vielen DLLs so fragmentiert ist. Das Anfordern schlägt unabhängig davon fehl, wie viel RAM man wirklich frei hat. :|

AnPapaSeiBua

2005-06-16, 21:38:29

GloomY

2005-06-18, 18:23:46

Ah ja, danke. Hab vielleicht deshalb mehr (also 1 GB) bekommen, weil mein Programm nichts außer Speicher alloziieren machen sollte (war zu Testzwecken). Aber weiß der Geier, was das VS so alles dazulinkt...Ja, die Unmenge an DLLs, die dazugelinkt werden, wirkt sich hier negativ auf die Fragmentierung aus. Statisch gelinkte Libraries machen im übrigen nicht solche Probleme, weil diese dann in das Programm selbst reingepackt werden und damit nicht den Adressraum fragmentieren.

Wenn man natürlich nur wenig / gar keine DLLs einbindet, hat man (im Schnitt) größere zusammenhängende Blöcke, mit denen man deutlich mehr zusammenhängenden Speicher allozieren kann.

btw: Weiss jemand, warum die DLLs an so unterschiedliche Stellen geladen werden? Bei einigen System-DLLs kann ich das ja verstehen, weil diese immer an der gleichen virtuellen Adresse stehen müssen (z.B. Kernel32.dll für Syscalls zum Kernel). Aber für bei reinen User-DLLs ist das doch vollkommen egal, wo diese im Adressraum stehen. Warum kann man diese dann nicht alle hintereinander packen, um der Fragmentierung aus dem Weg zu gehen?
Aber vielleicht wird jetzt anderen klar, warum 64 Bit auch JETZT schon brauchbar ist. Manchmal ist es halt von Vorteil, einen größeren Block zu reservieren, seiens auch "nur" 500 MB. Bei der Größe ist's schon sehr wahrscheinlich, dass die nicht mehr am Stück frei ist bei einem 32-Bit-System. Da muss man Programmieren ständig drauf aufpassen.
Bei einem 64-Bit-System findet man ja leicht zusammenhängend mehrere GB im User-Adressraum. Ist ja kein Problem, den Adressbereich von sagen wir mal 50-52 GB zu bekommen. Wo das dann tatsächlich hingemappt wird, interessiert mich ja nicht.Volle Zustimmung. =)

Demirug

2005-06-18, 18:50:41

btw: Weiss jemand, warum die DLLs an so unterschiedliche Stellen geladen werden? Bei einigen System-DLLs kann ich das ja verstehen, weil diese immer an der gleichen virtuellen Adresse stehen müssen (z.B. Kernel32.dll für Syscalls zum Kernel). Aber für bei reinen User-DLLs ist das doch vollkommen egal, wo diese im Adressraum stehen. Warum kann man diese dann nicht alle hintereinander packen, um der Fragmentierung aus dem Weg zu gehen?

DLLs werden bevorzugt an die Adresse geladen die sie im Header angeben. wenn das nicht geht sucht der Loader eine andere Stelle die groß genug ist. In diesem Fall muss die DLL aber alle absoluten Zeiger anpassen. Dieser Vorgang kostet Zeit.

Desweiteren wird versucht DLLs möglichs in allen Prozessen an die gleiche Adresse einzublenden. Gelingt das nicht muss die DLL auch mehrfach in den physikalischen Speicher geladen werden.

GloomY

2005-06-19, 05:12:06

Demirug,

Ich kann in keinster Weise den Sinn dieser Aktionen verstehen. Weder die gleichen Adressen noch das mehrmalige Laden in den Speicher, falls die DLL nicht an der selben virtuellen Adresse anzufinden ist.

Warum? :conf2:

Demirug

2005-06-19, 09:02:25

Ist doch ganz einfach. Assemblercode enthält feste Speicheradressen für Speicherzugriffe. Vorallem in das Datensegement. Wenn nun die DLL nicht an die Addresse geladen wird für die sie compiliert wurde müssen diese Adressen angepasst werden, Ab diesem Moment kann der Code aber nur noch laufen wenn er an dieser neuen Addresse im Prozessraum zum liegen. Benötigt nun ein weiterer Prozess die gleiche DLL so muss sie wieder an der gleichen Adresse eingeblendet werden oder man braucht eine weitere Kopie im Speicher welche auch wieder für die entsprechende Adresse angepasst werden muss. Der ganze Vorgang wird als "relocated" bezeichnet und die DLLS enthalten extra ein Segment mit Informationen für diesen Vorgang.

ShadowXX

2005-06-19, 12:07:22

Danke an Gloomy & Demi für die technischen Ausführungen...Sie haben mir ein paar sachen der Speicherverwaltung erklärt, die ich bis jetzt noch nicht zu 100% verstanden hatte.

Auch Danke an Stefan, der einen Thread darüber eröffnet hat (ist so ein bisserl wie "Alles was Sie schon immer über Sex wissen wollten....aber sich nie getraut haben zu fragen....")

blackbox

2005-06-19, 12:33:20

Ah ja, danke. Hab vielleicht deshalb mehr (also 1 GB) bekommen, weil mein Programm nichts außer Speicher alloziieren machen sollte (war zu Testzwecken). Aber weiß der Geier, was das VS so alles dazulinkt...

Aber vielleicht wird jetzt anderen klar, warum 64 Bit auch JETZT schon brauchbar ist. Manchmal ist es halt von Vorteil, einen größeren Block zu reservieren, seiens auch "nur" 500 MB. Bei der Größe ist's schon sehr wahrscheinlich, dass die nicht mehr am Stück frei ist bei einem 32-Bit-System. Da muss man Programmieren ständig drauf aufpassen.
Bei einem 64-Bit-System findet man ja leicht zusammenhängend mehrere GB im User-Adressraum. Ist ja kein Problem, den Adressbereich von sagen wir mal 50-52 GB zu bekommen. Wo das dann tatsächlich hingemappt wird, interessiert mich ja nicht.

Naja, so richtig brauchbar ist es nicht. (Für den Desktopbetrieb):

In der Ct12-2005 steht ein sehr interessanter Artikel über WIndows 64bit:

- Selbst wenn man 4 Gbyte bei 32bit WIndows zur Verfügung hat, so verliert man durch Gerätschaften bis zu 1 GByte. Es bleiben für den Arbeitsspeicher also nur rund 3 - 3,5 GByte übrig.
- Windows 64 kann bis zu 16 TByte adressieren, dennoch entsteht unterhalb der 4 GByte Grenze ein Speicherloch, in dem all I/O Komponenten eingeblendet sind. (bis zu 1,5 GByte bei SLI Systemen)
- Mainsstream Mainboards haben 4 Speicherbänke, durch die maximale Speichergröße von 1GByte beträgt der Ausbau max. 4 GByte.
- Nur NForce 4 und Inteli955X beherrschen das Umblenden des Speichers oberhalb von 4 GBytes. Aber manche Boards lassen diese Option weg.

Mir wird klar, dass alleine Windows in der 64bit Version noch gar nichts bringt. Es auch von der HArdware abhängig.
Erstens ist der physikalische Speicher sowieso auf 4GByte beschränkt, weil es keine größere Module gibt.
Zweitens muss der Chipsatz und der Boardhersteller das Umblenden des Speichers oberhalb von 4GByte auch unterstützen.
Drittens je mehr Geräte ich anschließe, desto mehr Speicher verliere ich.

Ist das alles korrekt wiedergegeben? Denn so richtig vertstehe ich mir mit der Materie nicht aus.

Coda

2005-06-19, 12:46:56

- Selbst wenn man 4 Gbyte bei 32bit WIndows zur Verfügung hat, so verliert man durch Gerätschaften bis zu 1 GByte. Es bleiben für den Arbeitsspeicher also nur rund 3 - 3,5 GByte übrig.Vom Addressraum bleibt nur noch soviel übrig. Vorsicht != Speicher. Mit mehreren Programmen kann man die 4GB durchaus verwenden.
- Windows 64 kann bis zu 16 TByte adressieren, dennoch entsteht unterhalb der 4 GByte Grenze ein Speicherloch, in dem all I/O Komponenten eingeblendet sind. (bis zu 1,5 GByte bei SLI Systemen)Macht doch nix, es geht hier um virtuellen Addressraum. Es entsteht kein Loch im physischen Speicher.
- Mainsstream Mainboards haben 4 Speicherbänke, durch die maximale Speichergröße von 1GByte beträgt der Ausbau max. 4 GByte.Macht auch nichts, weil es um Speicherfragmentierung geht und da ist der reelle Speicherausbau irrelevant.
- Nur NForce 4 und Inteli955X beherrschen das Umblenden des Speichers oberhalb von 4 GBytes. Aber manche Boards lassen diese Option weg.Ich denke mal es geht hier um die IOMMU, die der A64 auch hat. Das hat nur was damit zu tun dass man den IO Raum von 32bit PCI Geräten auch oberhalb von 4GB einblenden kann. Für normale Speicheralloziierung ist das egal.
Mir wird klar, dass alleine Windows in der 64bit Version noch gar nichts bringt. Es auch von der HArdware abhängig.Nein. Alle EMT64T und AMD64 CPUs haben 48bit virtuellen Addressraum.
Erstens ist der physikalische Speicher sowieso auf 4GByte beschränkt, weil es keine größere Module gibt.Stichwort Speicherfragmentierung.
Zweitens muss der Chipsatz und der Boardhersteller das Umblenden des Speichers oberhalb von 4GByte auch unterstützen.Nein.
Drittens je mehr Geräte ich anschließe, desto mehr Speicher verliere ich.Von 2^48bit = 262144GB (!) virtuellem Addressraum verlierst du max. 2GB. Schlimm? ...
Ist das alles korrekt wiedergegeben?Nicht wirklich.

StefanV

2005-06-19, 13:04:42

- Nur NForce 4 und Inteli955X beherrschen das Umblenden des Speichers oberhalb von 4 GBytes. Aber manche Boards lassen diese Option weg.
Bei Intel Systemen...

Bei AMD Systemen schauts so aus, das das die IOMMU in der CPU drin ist, somit _ALLE_ A64 Systeme das ummmappen des Speichers beherrschen...

Schon wieder erstaunlich, wie Rückständig Intel in diesem Bereich ist ;)

Außerdem empfehle ich dir und anderen der '64bit-braucht-man-nicht' Fraktion, mal indiesen (http://forum-3dcenter.de/vbulletin/showthread.php?goto=newpost&t=228539) Thread reinzuschauen und mal das Bildchen vom Gloomy anschauen.

Oder, ums mal krass auszudrücken:

Jeder, der behauptet, das wir 64bit nicht brauchen, hat keinen Plan.

Coda

2005-06-19, 13:06:43

Eigentlich ist das bei AMD auch nur ein missbrauchter AGPGart, ich weiß nicht inwiefern es überhaupt vorgesehen war den dafür zu benützen. Vielleicht ist es ja erst den Linuxentwicklern aufgefallen, dass man sowas braucht und AMD hat bemerkt das es eben so geht.

Also Intel deswegen als "rückständig" zu bezeichnen halte ich für gewagt, vor allem weil sie es jetzt ja in die Chipsätze einbauen.

Gast

2005-06-19, 14:27:59

bei 32bit adressen kann man 4gb adressieren. 2gb für den kernel (für treiber, buffer,...) 2gb für das programm. haben wollen ist kein problem, aber adressieren.

- Da war doch was "zur Not" mit boot.ini und der /3GB Option. Wenn man keine onboard Grafik hat, läuft das imho erstaunlich gut.
- Ist seit XPsp2 nicht der PAE-Kernel mit am Board? Funzt /PAE denn?
- Lösen XP64/Longhorn das Problem wirklich? Imho ist da Userspace per Default "nur" 4GB groß. Also nur verdoppelt. Gibt es da wieder zB. eine
/5GB Option oder wie? Da kriegt zB. Solaris10 nur Lachkrämpfe (?)

2001 sagte man, XP atmet erst bei 512MB so richtig frei. Hat sich 2005 viel dran geändert? Ich hab letztens noch einen 256MB reingesteckt (768MB jetzt) und muss sagen, dass ich die 1GB-Startzeit von HL2 in dem Test von 3dcenter schlage. Wobei es natürlich auf die Systemkonfig ankommt. Klar. Von einem nF2-400/2.2Ghz Barton und einer 80GB/7200/8MB hab ich aber nicht soviel erwartet, wenn ich mir die 3dcenter Hardware da angucke. Oder leif der Virenscanner mit? :-)

blackbox

2005-06-19, 14:57:58

Bei Intel Systemen...

Bei AMD Systemen schauts so aus, das das die IOMMU in der CPU drin ist, somit _ALLE_ A64 Systeme das ummmappen des Speichers beherrschen...

Schon wieder erstaunlich, wie Rückständig Intel in diesem Bereich ist ;)

Außerdem empfehle ich dir und anderen der '64bit-braucht-man-nicht' Fraktion, mal indiesen (http://forum-3dcenter.de/vbulletin/showthread.php?goto=newpost&t=228539) Thread reinzuschauen und mal das Bildchen vom Gloomy anschauen.

Oder, ums mal krass auszudrücken:

Jeder, der behauptet, das wir 64bit nicht brauchen, hat keinen Plan.

Schon erstaunlich, wie du aus meinem Beitrag interpretieren kannst, dass ich zur der "64bit-braucht-man-nicht" Fraktion gehören soll. :confused:
Aber egal.
Ich gehe da pragmatisch vor. Und der Artikel in der CT zeigt es ganz gut, dass 64 Bit zur Zeit nur etwas für Experimentierfreudige ist.
Die theoretischen Vorteile von 64 bit sind unbestreitbar.
Wenn du sagst "Jeder, der behauptet, das wir 64bit nicht brauchen, hat keinen Plan." dann ist das natürlich im Kern (64 bit wird gebraucht, nicht die anderen Satzteile) richtig. Nur das kann man auch von jeder anderen Technologie sagen.
Außerdem diskreditierst du damit alle anderen Aussagen und hebst deine eigene Ansicht über die der anderen. Zusätzlich implizierst du durch diesen Satz deine "Nichtbereitschaft" zur einer Diskussion. Auf jeden Fall eignet sich dieser Satz auf gar keinen Fall für eine Grundlage zur einer Diskussion.

Demirug

2005-06-19, 15:06:31

- Da war doch was "zur Not" mit boot.ini und der /3GB Option. Wenn man keine onboard Grafik hat, läuft das imho erstaunlich gut.
- Ist seit XPsp2 nicht der PAE-Kernel mit am Board? Funzt /PAE denn?
- Lösen XP64/Longhorn das Problem wirklich? Imho ist da Userspace per Default "nur" 4GB groß. Also nur verdoppelt. Gibt es da wieder zB. eine
/5GB Option oder wie? Da kriegt zB. Solaris10 nur Lachkrämpfe (?)

/3GB funktioniert nur wenn die Applikation ebenfalls mit der 3 GB Option kompiliert wurde. Sonst gibt es wieder nur 2 GB.

Was Win64 angeht hast du scheinbar veraltete Informationen. Derzeit gilt folgendens:

Virtual Address Space
By default, 64-bit Microsoft Windows-based applications have a user-mode address space of 8 terabytes (7 terabytes on Itanium-based systems). However, applications can specify that the system should allocate all memory for the application below 2 gigabytes. This feature is beneficial for 64-bit applications if the following conditions are true:

A 2 GB address space is sufficient.
The code has many pointer truncation warnings.
Pointers and integers are freely mixed.
The code has polymorphism using 32-bit data types.
All pointers are still 64-bit pointers, but the system insures that every memory allocation occurs below the 2 GB limit, so that if the application truncates a pointer, no significant data is lost. Pointers can be truncated to 32-bit values, then extended to 64-bit values by either sign extension or zero extension.

To specify this memory limitation, use the /LARGEADDRESSAWARE:NO linker option. However, be aware that problems can occur when using this option. If you build a DLL that uses this option and the DLL is called by an application that does not use this option, the DLL could truncate a 64-bit pointer whose upper 32 bits are significant. This can cause application failure without any warning.

Coda

2005-06-19, 15:25:31

Und der Artikel in der CT zeigt es ganz gut, dass 64 Bit zur Zeit nur etwas für Experimentierfreudige ist.Nein tut er nicht, du hast da was falsch interpretiert.

Es gibt andere Gründe warum 64bit für Heimanwender zur Zeit noch nicht benötigt wird.

Gast mit wut

2005-11-28, 01:56:33

oh mann wenn ich das hier lese.
das hört sich ja an als ob der intel total am abfucken ist.
hilfe mit meinem @3900mhz p4 kann ich kein game mehr vernünftig zocken.....

mist direkt mal verkaufen (ach bekomm eh nichts für,ist ein intel deswegen gleich verschenken) und eine wundercpu von amd kaufen *g*

ne im ernst,wenn ich manche kommentare lese,ne ne da wird mir echt anders.

sorry wenn mal der unterschied so heftig ist wie damals zwischen dem p2/p3 und dem k6/k6-2 würde ich das noch verstehen aber so?????

und stromverbrauch.....ja ja sowas von ausgelutscht da träumt sogar meine oma noch von.
meistens sind es die leute die voll die dicken pc´s haben mit allem was so ne highend kiste so braucht (7800er sli,viele platten und was weiß ich nicht alles),die dann darüber philosofieren wie sparsam eine amd cpu ist.

hey es reicht!!!!!!
tschuldigung musste mal raus,ich meine keinen persönlich....

Coda

2005-11-28, 02:10:31

Hier geht es weder um AMD noch um AMD64 (x86-64) an sich. Mal abgesehen davon, dass auch Intel schon länger 64bit CPUs als AMD fertigt (Itanium).

Mir ist es unbegreiflich wie solch eine theoretische Diskussion ohne Nennung auch nur eines Herstellers solche Flames hervorbringen kann.

HisN

2005-11-28, 02:48:53

/PAE funktioniert .... scheinbar wie früher emm386 ..

Allerdings frage ich mich, wenn ich nur einen 4GB grossen Adressraum habe, wie werden dann die Geräte adressiert die nun in den Adressraum über 4GB gemappt werden?

Jedenfalls werden bei mir am Server mit aktivem PAE 4GB nutzbarer Speicher angezeigt.

Alex

sloth9

2005-11-28, 15:54:13

HisN

2005-11-28, 16:01:49

Drüber

Gute Antwort ... dann dürfte aber das OS/Der Proz doch nicht mehr drauf zugreifen können da es ausserhalb des Raumes liegt der adressiert werden kann.

sloth9

2005-11-29, 12:50:05

Gute Antwort ... dann dürfte aber das OS/Der Proz doch nicht mehr drauf zugreifen können da es ausserhalb des Raumes liegt der adressiert werden kann.

Nö.

Sonst würde es ja keinen Sinn machen, oder?

Die moderneren Intel-Prozessoren haben, was viele nicht wissen, einen 36-bittigen Adressbus.

Übrigens lassen sich viele Fragen schon per wikipedia (http://de.wikipedia.org/wiki/PAE) beantworten... :D

zeckensack

2005-11-29, 13:55:00

Es macht wirklich keinen Sinn, PCI-Ressourcen oberhalb der 4GiB-Grenze einzublenden, wenn man den Prozessor im 32Bit-Modus laufen lässt :rolleyes:
Weil ... wie korrekt erkannt wurde, da käme man dann garnicht mehr dran.

PAE erlaubt tatsächlich 36 Bit physikalische Adressen. Allerdings ist PAE einfach nur scheiße. Es funktioniert genauso wie EMS. Zeiger (=virtuelle Adressen) sind nach wie vor nur 32 Bit breit. Um den gesamten Speicher adressieren zu können werden Speicherbänke an bestimmten Adressen innerhalb des üblichen 32-Bit-Umfangs eingeblendet. Dh um auf bestimmten "hohen" Speicher zugreifen zu können, muss erst anderer "hoher" Speicher ausgeblendet werden, und entzieht sich somit dem Zugriff, bis er irgendwann später evtl wieder eingeblendet wird. Auch das Wiederfinden von Daten wird kompliziert, schließlich reicht nun nicht mehr ein einfacher Zeiger um Zugriff zu bekommen ... es muss wie bereits erwähnt erstmal die korrekte Bank virtuell eingeblendet werden, sonst landet man sonstwo.

"Wo kämen wir denn da hin?!"

Daraus kann man sich vielleicht 'nen Plattencache bauen, aber das war's dann auch schon wieder.

Soviel dazu, werter sloth9. Und ob du das mit den "modernen Intel-Prozessoren" ernst meinst, oder ob das witzig sein sollte ... ich befürchte ersteres.

Coda

2005-11-29, 16:45:14

Intel hat bei den EM64T-Prozessoren immer noch "nur" 36bit phyiskalischen Addressraum, der K8 hat 40bit, der Itanium aber sogar ganze 50bit (wozu auch immer).

Die 36bit (= 64GiB) werden für die Lebensdauer von Netburst aber sicher noch reichen ;)

sloth9

2005-11-29, 16:54:35

Ich meinte mit moderneren lediglich, das die ursprünglichen 32-bitter (386) von Intel das noch nicht konnten.

Was 64-bit angeht, so werde ich mir das Original kaufen...

Und PAE finde ich super, wer Windows auf Maschinen mit >4 Gig einsetzt, hat genau sowas verdient IMHO. :biggrin:

Edit: ich kriech datt mit dem editieren noch hin...

Coda

2005-11-29, 17:16:32

Was hat das mit Windows zu tun? Um auf einem 32bit-Prozessor mehr zu addressieren muss auch Linux oder jedes andere System PAE verwenden.

zeckensack

2005-11-29, 17:20:35

Ich meinte mit moderneren lediglich, das die ursprünglichen 32-bitter (386) von Intel das noch nicht konnten.Dann entschuldige bitte. Ich dachte schon du wolltest das ernsthaft als was neues anpreisen.

sloth9

2005-11-29, 17:23:58

Was hat das mit Windows zu tun? Um auf einem 32bit-Prozessor mehr zu addressieren muss auch Linux oder jedes andere System PAE verwenden.

Wer nicht Windows nimmt, braucht auch kein IA-32 nehmen, oder nicht?

StefanV

2005-11-29, 17:28:25

Wer nicht Windows nimmt, braucht auch kein IA-32 nehmen, oder nicht?
Windows XP x64 Edition (gibts AFAIK auch als 2003) :devil:

Coda

2005-11-29, 17:39:15

Wer nicht Windows nimmt, braucht auch kein IA-32 nehmen, oder nicht?Guten Morgen. Es gibt Windows schon einige Zeit als IA64 und x86-64 Versionen

sloth9

2005-11-29, 19:24:14

Windows XP x64 Edition (gibts AFAIK auch als 2003) :devil:

Klaro, aber die ist ja von AMD.

Die MIPS-/Alpha-Versionen sind doch seit NT 4.0 eingestellt, oder nicht? Daher landet man als Windows-Nutzer zwangläufig bei IA-32 und bei >4 Gig bei PAE (o. halt neuerdings AMDs Aufbohrung). Die IA-64-Ausgabe ist doch auch schon so gut wie tot (Workstation abgekündigt; nur noch Server).

StefanV

2005-11-29, 19:28:41

Klaro, aber die ist ja von AMD.

Die MIPS-/Alpha-Versionen sind doch seit NT 4.0 eingestellt, oder nicht? Daher landet man als Windows-Nutzer zwangläufig bei IA-32 und bei >4 Gig bei PAE (o. halt neuerdings AMDs Aufbohrung). Die IA-64-Ausgabe ist doch auch schon so gut wie tot (Workstation abgekündigt; nur noch Server).
Hö?!
WTF?!

Dir ist bekannt, das Windows XP x64 Edition sowohl auf dem K8 als auch auf neueren Pentium 4 läuft?!

BTW: wer spricht hier von IA-64?! :|

sloth9

2005-11-29, 19:36:38

Hö?!
WTF?!

Dir ist bekannt, das Windows XP x64 Edition sowohl auf dem K8 als auch auf neueren Pentium 4 läuft?!

BTW: wer spricht hier von IA-64?! :|

x64 ist vom AMD und Intel hat es quasi kompatibel nachgebaut.

Gab ja mal Gerüchte, der Prescott hätte ne eigene Version einer IA-32-Erweiterung.

Ging um folgendes: x86 kann nur 32 bit = 4 Gig. Mit PAE 36 = max. 64 Gig. PAE ist aber Scheisse. Daher Windows mit PAE auch Mist. Unices auf IA-32 auch, aber da kann man ja andere Architekturen nehmen.
Bei Windows nicht (bis vor kurzem); jetzt hat man ja die x64-Ausgabe von Windows.

sloth9

2005-11-29, 19:51:06

Guten Morgen. Es gibt Windows schon einige Zeit als IA64 und x86-64 Versionen

Einige Zeit? Je nach Rechnertyp/Upgradezyklus empfinde ich diese Versionen als ziemlich neu, gerade in Bezug auf andere BS.

Coda

2005-11-29, 19:54:59

Bei Windows nicht (bis vor kurzem); jetzt hat man ja die x64-Ausgabe von Windows.Äh und? Vorher hat man beim K8 auch keine andere Wahl gehabt X-D

x64 ist vom AMD und Intel hat es quasi kompatibel nachgebaut.Nicht nur quasi.

sloth9

2005-11-30, 00:45:03

Äh und? Vorher hat man beim K8 auch keine andere Wahl gehabt X-D

Nie bestritten.

BlackBirdSR

2005-12-03, 11:57:29

Frage:

Der Grafikspeicher wird in den virtuellen Adressraum der CPU eingeblendet?
Ist also von der 4GB Grenze direkt betroffen?

Demirug

2005-12-03, 12:11:53

Frage:

Der Grafikspeicher wird in den virtuellen Adressraum der CPU eingeblendet?
Ist also von der 4GB Grenze direkt betroffen?

Ja ist er. Von nVidia weiß ich das sie verdammte Probleme mit dem Treiber hatten als sie die ersten Karten mit 512 MB hatten (oder sogar schon bei 256MB)

Unter Vista wird das ja noch eine Spur heftiger.

StefanV

2006-01-10, 22:26:44

1. http://forum-3dcenter.de/vbulletin/...ad.php?t=228539
2. Tauscht man 'ne CPU nicht so schnell aus, wie 'ne GraKa, ganz ab davon, das ein NB idR 'ne längere Halbwertzeit hat.
3. Ists ein Irrtum, das einem eher der RAM als der Adressraum ausgeht, da allerhand 'Müll' da rein muss, auch, wenn das viele nicht verstehen wollen, so ist das doch nicht ganz unwichtig.
Nein,bei einem NB (mit max 2GB ram) wird das nicht passieren.

p.s. und komm mir jetzt nicht mit der Swap-File.Da kannst du deinen PC sowieso vergessen.(wenn er anfenget grosse Mengen zu swapen=slowization :D ohne Ende)
Anscheinend herrscht noch viel Diskussionsbedarf, was dieses (leidige) Thema betrifft...

Gast

2006-06-06, 00:57:21

Bei x86 bringt 64Bit auch einen Performance-Boost und das ist immer gut und brauchbar!

pco

2006-06-06, 08:23:40

Es gibt einen einzigen guten Grund nicht sofort zu WinXP-64 zu wechseln:
Mangelnder Support

Seitens M$, die das Betriebsystem eher stiefmütterlich behandeln
Seitens der HW-Hersteller, denn für "Hardwarexoten" wie Handys oder Palm-PDAs fehlen nach wie vor die Treiber
Seitens der SW-Hersteller, denn damit 64-Bit-Windows Spaß macht, sollten es hinreichend x64-Anwendungen geben.

Der DualCore-Bug (betrifft vor allem Spiele) war bei meinem letzten Versuch mit WinXP64 vor 3 Monaten noch nicht behoben. Auf WinXP32 ist der seit 5 Monaten Geschichte.

All das macht X64 für mich ein wenig unbrauchbar - leider.

Und so lange ich kein 64-Bit-OS einsetzen kann, brauchen wir über die tollen Vorzüge nicht zu diskutieren.

PCO

Coda

2006-06-06, 11:25:24

Gast[/POST]']Bei x86 bringt 64Bit auch einen Performance-Boost und das ist immer gut und brauchbar!
Nicht immer. Viel Pointerspielchen und das Gegenteil kann der Fall sein.

StefanV

2006-06-06, 12:12:44

Gast[/POST]']Bei x86 bringt 64Bit auch einen Performance-Boost und das ist immer gut und brauchbar!
Wenn man 64bit Integerwerte braucht, ja, wenn man das nicht braucht, nein, nicht wirklich.

BlackBirdSR

2006-06-06, 12:18:52

StefanV[/POST]']Wenn man 64bit Integerwerte braucht, ja, wenn man das nicht braucht, nein, nicht wirklich.

Zusätzliche Register, Skalar SSE2...
Wenn man es richtig anstellt, und je nach Anwendung sehr wohl.

Gast

2006-06-10, 23:05:34

Habt an der Stelle nur von Adressierung gesprochen, wie ich gesehen habe (hab den Thread schnell überfolgen)??

Naja, mit 32 Bit stößt man relativ schnell an Grenzen (rede jetzt von 32-bittigen Registern), wenn man im Bereich der Quantenmechanik bzw. allgemeinen Relativitätstheorie/Stringtheorie, also im Mikro- und Makrokosmos Berechnungen durchführt, die IMMER Parameter vom Gleitkomma-Typ haben.
Hab meine Berechnungen dann über ein AIX 5.3 (64-Bittig) mit 4 PowerPC-CPUs laufen lassen, was auch für solche Aufgaben eine mikrige Ausstattung ist.
Hier sind auch die 64-bittigen Register so gerade noch. Aber eigentlich auch zu ungenau. Es gibt Tricks, die Genauigkeit auch auf 32 bzw. 64 bit hin zu bekommen, aber dann geht die Performance in den Keller (leider).

Hier kann man relativ viel optimieren (selbst in Fortran optimiert), aber man darf wirklich keine Wunder erwarten. Wünschenswert sind ECHTE 256-bit Register oder mehr.

War jetzt etwas OT, aber die Bittigkeit ist nicht nur wichtig im Zusammenhang mit Speicher.

Was ich noch sagen möchte ist: Die 64-bit-Erweiterung von AMD ist mit einem Itanium (voll darauf ausgelegt) nicht vergleichbar.

__et_

2006-06-28, 13:05:16

Ich lassen meinen Haupt-PC immer gut 4-6 Wochen laufen ohne neu zu booten (wenn dann Ruhezustand). Bestimme Anwendungen die man wochenlang benutzt, werden immer langsamer. Als Beispiel Firefox (trifft auch auf andere zu). Der läuft die ganze Zeit, hat immer so 20-30 verschiedene Webseiten offen und in seit Reboot bestimmt an die 1000 verschiedene Webseiten in Tabs offen gehabt. Das macht den auf Dauer erheblich langsamer und braucht mehr Speicher. Das beenden und neustarten mit gleichen Webseiten resultiert in wesentlich schnelleres Ansprechverhalten.

Könnte dies ein Verhalten sein, was typisch ist für einen fragmentierten Heap? Die Anwendung hat in den letzten Wochen bestimmt unzählige Objekte erzeugt und wieder zerstört - dadurch soll dann ja die CPU-Last steigen, wenn man Speicher für neue Objekte sucht, oder?

Wenn man auf 64Bit Systemen genug Adreßraum hinten dran hat, würde dann auch eine Anwendung, deren Heap fragmentiert, nicht mehr so viel CPU-Last erzeugen? D.h. bekäme man zum Beispiel bei WinXP x64 ein besseres Ansprechverhalten, wenn bei dem 32bit Pendant der Heap bereits stark am fragmentieren ist? Oder ist das Problem ein anderes?

Kann ich irgendwie den Grad der Heap Fragmentierung messen?

Ich habe gelesen, daß es für C++ Memory-Manager geben soll, wodurch sich ähnlich wie bei Java ein fragmentieren des Heaps verhindern soll. Die sollen transparent funktionieren und nur mit modifizierten new und delete Aufrufen auskommen.
Ich habe hier z.B. eine kleine Server Anwendung (nichts wirklich Sinnvolles, nur Spielerei) - könnte ich eine bestehende Anwendung also einfach nur durch linken des Memory Managers und ersetzen von new und delete durch die spezifischen Aufrufe hier auf einen anderen Speichermanager umstellen?

danke

Viele

Neomi

2006-06-28, 13:38:20

__et_[/POST]']Ich habe gelesen, daß es für C++ Memory-Manager geben soll, wodurch sich ähnlich wie bei Java ein fragmentieren des Heaps verhindern soll. Die sollen transparent funktionieren und nur mit modifizierten new und delete Aufrufen auskommen.
Ich habe hier z.B. eine kleine Server Anwendung (nichts wirklich Sinnvolles, nur Spielerei) - könnte ich eine bestehende Anwendung also einfach nur durch linken des Memory Managers und ersetzen von new und delete durch die spezifischen Aufrufe hier auf einen anderen Speichermanager umstellen?

Nein, so einfach wird das nicht funktionieren. Um Fragmentierung zu verhindern, müssen ab und zu (z.B. dann, wenn ein neuer Block angefordert wird) existierende Blöcke verschoben werden. Da new und delete nicht wissen, von wo aus überall auf den Speicher verwiesen wird (die Stellen würden dann in einen ungültigen Speicherbereich zeigen, nicht gut), dürfen sie nichts verschieben. Für sowas sind schon "Smartpointer"-Objekte nötig, in denen Pointer gekapselt werden. Diese Objekte müssen sich dann beim Speichermanager anmelden, um bei Verschiebungen entsprechend angepaßt werden zu können.

Gast

2006-06-28, 13:43:03

BlackBirdSR[/POST]']Zusätzliche Register, Skalar SSE2...
Wenn man es richtig anstellt, und je nach Anwendung sehr wohl.

Nur dummerweise hat das mit 64 Bit gar nix zu tun.

HOT@Work

2006-06-29, 12:03:52

Gast[/POST]']Nur dummerweise hat das mit 64 Bit gar nix zu tun.

Aber mit der Architektur und das gibt letztendlich den Ausschlag.

HOT@Work

2006-06-29, 12:07:38

Gast[/POST]'][...]

Was ich noch sagen möchte ist: Die 64-bit-Erweiterung von AMD ist mit einem Itanium (voll darauf ausgelegt) nicht vergleichbar.

Was soll denn diese Formulierung? :|
AMD64 ist eine vollständige 64Bit Architektur. Dennoch ist sie nicht mit Itanium vergleichbar, da sich hier schon die Befehlssätze unterscheiden. Das hat nix mit voll darauf ausgelegt zu tun, das ist schlicht Blödsinn.
Itanium ist auf EPIC ausgelegt, AMD64 auf x86-64.

Chris Lux

2006-07-31, 23:46:51

Der DualCore-Bug (betrifft vor allem Spiele) war bei meinem letzten Versuch mit WinXP64 vor 3 Monaten noch nicht behoben. Auf WinXP32 ist der seit 5 Monaten Geschichte.

All das macht X64 für mich ein wenig unbrauchbar - leider.

hier muss ich nochmal nachfragen.

http://support.microsoft.com/contactus/?ws=support

hier steht, dass der bug unter xp32 und allen servern (auch x64) auftritt. xp64 ist nicht mit angegeben. den fix bekommt man ja auch so (ohne an ms zu zahlen), funktioniert der dann auch bei den servern?

wie äußert sich der bug denn? ich habe ein dual core system und den patch zwar jedes mal installiert, jedoch hatte ich vorher nie irgendwelche probleme bemerkt.

ollix

2006-08-18, 20:01:48

Das macht den auf Dauer erheblich langsamer und braucht mehr Speicher. Das beenden und neustarten mit gleichen Webseiten resultiert in wesentlich schnelleres Ansprechverhalten.

Könnte dies ein Verhalten sein, was typisch ist für einen fragmentierten Heap? Die Anwendung hat in den letzten Wochen bestimmt unzählige Objekte erzeugt und wieder zerstört - dadurch soll dann ja die CPU-Last steigen, wenn man Speicher für neue Objekte sucht, oder?

Wenn man auf 64Bit Systemen genug Adreßraum hinten dran hat, würde dann auch eine Anwendung, deren Heap fragmentiert, nicht mehr so viel CPU-Last erzeugen? D.h. bekäme man zum Beispiel bei WinXP x64 ein besseres Ansprechverhalten, wenn bei dem 32bit Pendant der Heap bereits stark am fragmentieren ist? Das finde ich recht interessant. Hat das jemand mal probiert? Oberflächlich betrachten macht das IMHO schon Sinn. Reagiert eine Anwendung im Dauereinsatz auf WinXP 64 besser als eine wo auf WinXP der Heap schon am fragmentieren ist - einfach weil man weniger CPU Last braucht um neuen Speicher zu finden? Oder wie verwaltet WinXP 64 seinen Speicher?

HellHorse

2006-08-18, 21:08:53

Ich habe gelesen, daß es für C++ Memory-Manager geben soll, wodurch sich ähnlich wie bei Java ein fragmentieren des Heaps verhindern soll.
Das glaube ich erst wenn ich es sehe, vorher halte ich es für technisch unmöglich.
Dazu müsste der Memory Manager compaction bieten was wiederum 'moving' voraussetzt. Nun sind aber alle C/C++ Memory-Manager die ich kenne konservativ (und ich sehe nicht, wie etwas anderes möglich wäre), da es in C/C++ keinen Unterschied zwischen einem Pointer und einem Integer gibt. 'moving' fällt also flach.

ollix

2006-10-02, 11:56:56

Hat das denn jemand mal getestet bzw, macht es Sinn, daß eine Anwendung im Dauereinsatz im 64bit OS weniger träge reagiert, da der Heap weniger fragmentiert bzw. das Suchen nach neuem Adressraum so einfach ist? Oder betrifft das wirklich erst Anwendungen, die bereits 2GiB an virtuellem Adressraum belegt haben?

StefanV

2007-02-27, 03:53:56

Da es anscheinend immer noch Diskussionsbedarf über den Adressraum gibt, sollten wir diesen Thread fortsetzen...

Ein kleiner versuch:

Der Adressraum ist der Bereich, in dem _ALLES_ was im Rechner steckt, reingeschmissen wird, um angesprochen zu werden.
Sozusagen die Anmeldung, da wird der Speicher reingeschmissen, aber auch jedes Gerät muss sich dadrin 'anmelden'.

Schaut dann also etwa so aus:

A|
D|.....|.............|Systemspeicher
R|----| Speicher |Zusatzspeicher (auf Karten)
E|
S|
S|
R|
A|-----|I/O Bereich (zum ansprechen von Komponenten)
U|
M|-----|Treiberbereich (also um Treiber einzubinden, die die Komponenten ansprechen)

Dazu kommt, das man das ganze nicht alles zusammen packt, nein, das wär ja zu einfach.
Manchesmal wird eine Komponente bzw ein Treiber in einem bestimmten Bereich erwartet, entsprechend muss vor und dahinter etwas frei bleiben.

Da ma nicht nur einen Treiber hat sondern mehrere (duzend/hundert), hat man sehr viel Luft dadrin, dazu kommt, das ein Teil des Adressraums vom OS beschlagnahmt wird, 512MiB gehen für die Adressierung des PCI Busses drauf...

Was passiert, wenn der Adressraum zuende ist, sieht man an Gothic 3, wenn man speichern möchte oder wenn man längere Zeit Supreme Commander spielt -> es schmiert einfach so mal ab...

ScottManDeath

2007-02-27, 06:56:31

Das glaube ich erst wenn ich es sehe, vorher halte ich es für technisch unmöglich.
Dazu müsste der Memory Manager compaction bieten was wiederum 'moving' voraussetzt. Nun sind aber alle C/C++ Memory-Manager die ich kenne konservativ (und ich sehe nicht, wie etwas anderes möglich wäre), da es in C/C++ keinen Unterschied zwischen einem Pointer und einem Integer gibt. 'moving' fällt also flach.

Sowas ist für C++ 0x09 geplant, auf der ISO WG21 Seite (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2142.html), unter "Transparent Garbage Collection for C++" gibts einigw Paper die das beschreiben. Es ist aber nicht sicher, ob das so in den Standard kommt, der Wunsch ist jedenfalls da.

HOT

2007-02-27, 10:36:25

@Stefan: ... oder Spiele laden einfach mal so ewig und ruckeln wie bekloppt in der Gegend rum, weil sie dauernd im Adressraum umschichten müssen. Gutes Beispiel hierfür: Vanguard. Ich werde nie verstehen, warum es davon keinen 64bit Client gibt, das ist einfach sinnlos so wie es ist.

greg

2007-03-29, 14:22:09

Gast

2007-03-29, 15:05:58

Also nochmal für Azubis: :)
(Alles ohne PAE!)
Mein Lehrer behauptet: Bei 32-Bit Systemen sind 4 GB nutzbar.
Durch die Geräte werden zwar einige MB beansprucht aber sie seien unter Windows wohl trotzdem nutzbar.
Frag ihn mal wie er bei ner GX2 auf die 1GB Speicher zugreifen will, wenn Windows den gesamten Adressraum seinen Programmen zur Verfügung stellt.
Alternativ soll er dir mal ein 32 Bit System zeigen, bei dem er ohne PAE >3,5 GB speicher nutzen kann

Spasstiger

2007-03-29, 19:23:11

Also nochmal für Azubis: :)
(Alles ohne PAE!)
Mein Lehrer behauptet: Bei 32-Bit Systemen sind 4 GB nutzbar.
Durch die Geräte werden zwar einige MB beansprucht aber sie seien unter Windows wohl trotzdem nutzbar.

Ich meinte dann:
Von den 4GB müssen alle Geräte (PCI(e),AGP,..) abgezogen werden, wodurch bei GraKas mit viel RAM nicht mehr viel Adressraum für den RAM bleibt, sprich ich kann unter einem BS/OS nicht mehr die 4GB nutzen.

Stimmt das soweit?
Zum einen muss natürlich der Speicher für die zusätzlichen Geräte wie die Grafikkarte adressiert werden, da gehen schonmal einige hundert MB flöten. Zum anderen weist Windows XP/Vista 32 Bit einer Anwendung immer 2 GB Adressraum + den Adressraum für die Zusatzgeräte zu (wobei in der Summe nicht mehr als 4 GB rauskommen können).
Mit dem /3GB-Parameter in der boot.ini kann man den nutzbarenAdressraum von 2 GB auf 3 GB erhöhen, aber das führt wohl in der Regel zu Stabilitätsproblemen.

Außerdem sind die meisten 32-Bit-Anwendungen auch so kompiliert, dass sie gar nicht mehr als 2 GB Adressraum nutzen können.

Noch ein einfaches Beispiel:
Bei einem PC mit 4 GB RAM, einer 512 MB Grafikkarte und noch weiteren Geräten, die insgesamt 100 MB an Speicher verwaltet haben wollen, bekommt jede Anwendung unter WinXP 32 Bit pauschal 2 GB an virtuellem Adressraum zugewiesen. Auch wenn 30 Anwendungen offen sind, steht jeder Anwendung 2 GB an virtuellem Speicher zu Verfügung (/3GB-Paramter aus Stabilitätsgründen nicht gesetzt).
Hat man jetzt einen PC mit zwei Grafikkarten, die je über 1 GB VRAM verfügen und noch einen Raid-Controller mit 512 MB onboard, stehen jeder Anwendungen statt 2 GB virtuellem Adressraum nur noch 1,5 GB zur Verfügung (4 GB - 2*1GB - 512 MB).

Nutzbar sind aber bei beiden Rechnern jeweils die vollen 4 GB RAM insofern mehrere Anwendungen offen sind (wobei sich der Windows-Kernel davon auch ein paar hundert MB wegnimmt).

Coda

2007-03-29, 19:55:57

Hat man jetzt einen PC mit zwei Grafikkarten, die je über 1 GB VRAM verfügen und noch einen Raid-Controller mit 512 MB onboard, stehen jeder Anwendungen statt 2 GB virtuellem Adressraum nur noch 1,5 GB zur Verfügung (4 GB - 2*1GB - 512 MB).
Nein, das ist definitiv falsch. Es sind immer mindestens 2GiB. Ansonsten würde dir alles um die Ohren fliegen. In dem Fall muss der Treiber mit weniger leben und pagen.

Nutzbar sind aber bei beiden Rechnern jeweils die vollen 4 GB RAM insofern mehrere Anwendungen offen sind (wobei sich der Windows-Kernel davon auch ein paar hundert MB wegnimmt).
Tut er nicht. Das ist ein Problem mit PCI.

Spasstiger

2007-03-29, 20:00:33

Nein, das ist definitiv falsch. Es sind immer mindestens 2GiB. Ansonsten würde dir alles um die Ohren fliegen. In dem Fall muss der Treiber mit weniger leben und pagen.
Hm, ok, war mir neu. Macht aber Sinn, wenn die Anwendungen auf 2 GB Adressraum ausgelegt werden.
Und warum sollten auch die Hardwaretreiber immer den Luxus bekommen, den Speicher direct-mapped nutzen zu können, während das OS den RAM immer mit Paging behandeln muss. ;)

Tut er nicht. Das ist ein Problem mit PCI.
Ok. Aber welchen Speicherbedarf hat denn der Kernel von Windows XP (32 Bit) grob?

Coda

2007-03-29, 20:01:35

Spasstiger

2007-03-29, 20:06:04

Moderne OS benützen kein Paging (abgesehen von PAE). Das Feature wurde folgerichtlich aus der ersten Version von x86-64 auch entfernt und später nur wieder eingeführt um Virtualisierung besser zu ermöglichen.
:confused: Ich dachte Paging wäre das zentrale Element der virtuellen Speicherverwaltung. Wie wird denn dann der Speicher adressiert, wenn nicht über Seitentabellen?

Coda

2007-03-29, 20:09:20

Sorry, ich war bei Segmentierung. Brainfart.

Das OS könnte den Speicher aber auch direkt ansprechen ;)

Ok. Aber welchen Speicherbedarf hat denn der Kernel von Windows XP (32 Bit) grob?
Keine Ahnung. Weniger als 50MiB würde ich schätzen.

greg

2007-03-29, 20:32:20

Das mit den 2GB virtueller Speicher pro Anwendung versteh ich ja noch.

Nutzbar sind aber bei beiden Rechnern jeweils die vollen 4 GB RAM insofern mehrere Anwendungen offen sind (wobei sich der Windows-Kernel davon auch ein paar hundert MB wegnimmt).
Aber wieso werden dann in Windows niemals die 4GB angezeigt?
Ich dachte bisher das durch die Adressknappheit die Kapazitäten, die die Peripherie wegnimmt nicht von OS/BS genutzt werden können.

Sprich man könnte auch ein GB RAM ausbauen und trotzdem hätte man nicht weniger RAM zur Verfügung da er eh nicht angesprochen werden konnte.

Coda

2007-03-29, 20:46:26

Du bekommst 3,5GiB angezeigt weil PCI sich den physikalischen Speicher zwischen 3,5 und 4GiB schnappt.

greg

2007-03-29, 20:48:40

Den ich dann auch nicht nutzen kann? Sprich ich könnte 512MB auch ausbauen ohne Effekt?

reunion

2007-03-29, 21:06:15

Ja, ohne Adressen kein Speicher.

Coda

2007-03-29, 22:14:59

Den ich dann auch nicht nutzen kann? Sprich ich könnte 512MB auch ausbauen ohne Effekt?
Japp. Allerdings kann dieser Speicher auf 64-Bit-Systemen wieder genützt werden indem er >4GiB eingeblendet wird. Das nützt einem 32-Bit-Betriebssystem freilich nichts.

greg

2007-04-23, 18:51:53

So hab wieder Berufsschule und der Herr Lehrer möchte am besten eine schlüssige Argumentation mit Quellen...

Ich würde ihm als Quelle Adressraum (http://de.wikipedia.org/wiki/Adressraum) nennen.

Meine Argumentation im kurzen:
-Adressraum bestimmt durch CPU (Anzahl der Adressleitungen)
-In den Adressraum fallen RAM sowie jede menge Peripheriegeräte die auch mitverwaltet werden müssen
-ergo --->Es kann niemals der ganze Adressraum für den Arbeitsspeicher genutzt werden
- Fazit: für Geräte mit viel RAM (ab 2 GB) 64-Bit :)

Was ich noch nicht verstehe ist:
Warum fällt die Festplatte, USB Geräte (Sticks, Wechselplatten) oder sonstige per Peripherie angeschlossene Geräte nicht in den Adressbereich?

greg

2007-04-24, 17:34:10

Warum fällt die Festplatte, USB Geräte (Sticks, Wechselplatten) oder sonstige per Peripherie angeschlossene Geräte nicht in den Adressbereich?
Bitte sagt mal was dazu :smile:

PatkIllA

2007-04-24, 17:42:03

Warum fällt die Festplatte, USB Geräte (Sticks, Wechselplatten) oder sonstige per Peripherie angeschlossene Geräte nicht in den Adressbereich?Weil die nicht per Memory Mapped IO die Daten austauschen. Das Einblenden in den Adressraum ist längst nicht für alle Geräte sinnvoll.
Mit 64 Bit könnte man allerdings dann auch ganze Platten in den Adressraum einblenden. Auf Betriebssystemebene geht das mit Dateien sogar.

Wie sieht das eigentlich mit dem Einblenden von Geräteresourcen bei Hotplug aussehen? Wird das unterstützt?

Gast

2007-08-18, 14:36:02

Hallo,

ich finde es schade, dass es speziell für Windows noch recht wenig 64Bit-Software gibt, d.h. einen Firefox oder gar das komplette MS Office 2007 läuft unter XP/Vista x64 nur im 32-Bit-Kompatibilitätsmodus.

Dabei ist es weniger der Fakt, dass 64Bit einfach cool sind ;-) , sondern der stetig wachsende Speicherausbau von PCs. Beim Desktop ist seit einiger Zeit eben 2GB RAM Standard, einige Leute werden auch schon seit längerem die 4GB Marke erreicht oder durchbrochen haben.

Unsere Software dagegen, inkl. OS, ist aber meistens noch rein 32Bit. Zum Glück wirds dank Vista auch endlich Treiber für x64-Systeme geben, denn sonst gibts ja kein tolles "Vista-ready"- oder "Vista-certified"-Logo...

Für mich komplett unverständlich ist aber die Ankündigung von MS, dass auch der Vista Nachfolger noch eine 32Bit Version bekommen soll. Das ist doch totaler Quatsch! Bis dahin sind evtl. schon 8GB Ram Standard im Desktop-PC, wer will da noch ein 32Bit-OS???
Und da die CPUs seit einigen Jahren alle x64 können, dürfte es in ein paar Jahren kaum jemanden geben der den Vista-Nachfolger auf einem dann Uralt-PC ohne x64 installieren will...

Warum also kompilieren die Software-Hersteller ihre Sachen nicht einfach auch mal als x64 durch (in Visual Studio ja überhaupt garkein Problem!), oder warum liefert MS sein Office 2007 nicht auch als 64-Bit-Version aus?

Grüße,
KK

Gast

2007-08-18, 15:02:28

Hallo,

ich finde es schade, dass es speziell für Windows noch recht wenig 64Bit-Software gibt, d.h. einen Firefox oder gar das komplette MS Office 2007 läuft unter XP/Vista x64 nur im 32-Bit-Kompatibilitätsmodus.

für was? für firefox wäre 64bit absolut sinnlos, das programm würde nur etwas mehr speicher brauchen und ansonsten gleich gut wie die 32bit-version laufen. bei office ist es ähnlich, wobei hier zumindest anwendungsfälle denkbar wären in denen 64bit vorteile bringt, in 99% der fälle aber wohl nicht.

bei manch anderer software ist es allerdings doch ziemlich unverständlich noch immer nicht auf 64bit zu setzen, beispielsweise bei photoshop. das würde von 64bit ordentlich profitieren.

Zum Glück wirds dank Vista auch endlich Treiber für x64-Systeme geben, denn sonst gibts ja kein tolles "Vista-ready"- oder "Vista-certified"-Logo...

leider nicht, vista-ready-logo gibt es auch wenn es nur 32bit-treiber gibt.

Warum also kompilieren die Software-Hersteller ihre Sachen nicht einfach auch mal als x64 durch (in Visual Studio ja überhaupt garkein Problem!), oder warum liefert MS sein Office 2007 nicht auch als 64-Bit-Version aus?

ich würde mal sagen the right tool for the right job, es macht keinen sinn mit kanonen auf spatzen zu schießen. software die es nicht braucht sollte auch weiter in einer 32bit-umgebung laufen, das spart speicher und erhöht die kompatibilität.
auch wenn 64bit-hardware mittlerweile stark verbreitet ist sieht es beim betriebssystem leider ziemlich schlecht aus. WinXP64 ist praktisch nicht existent und auch vista wird großteils nur als 32bit-version ausgeliefert, von non-ms-betriebssystemen brauchen wir erst garnicht reden.

Spasstiger

2007-08-18, 15:55:40

Bei 64-Bit-Browsern hat man das Problem, dass auch alle Plugins als 64-Bit-Version vorliegen müssen. Deshalb ist z.B. der Internet Explorer x64 auch kaum zu gebrauchen, es gibt einfach keine Plugins dafür (Flash, Realplayer, etc.).

HOT

2007-08-18, 16:13:49

Wieviel vom Adressraum frei ist, bestimmt nicht nur der Speicher, denn es gibt viele andere Geräte, die ebenfalls adressiert werden müssen. Ich weiss nicht genau, wer jetzt den physikalischen Adressraum aufteilt, aber ich vermute, dass dies das BIOS übernimmt.
Bei Grafikkarten wird üblicherweise nur ein Teil des Grafikspeichers physikalisch adressiert, um auch Grafikkarten mit 512MB unter 32Bit zu ermöglichen (wie das genau zusammenhängt müsste man mal NV fragen, die können da sicher einiges zu sagen). Beispiel: Ein QuadSLI System würde 4x 256MB = 1GB Adressraum für sich selbst adressieren. 2 GX2 haben aber 4x 512MB VRAM. Aber auch Soundkarten, SCSI/SATA Controller und andere Geräte bedienen sich am Adressraum. Moderne Mainboards reservieren >512MB des oberen Adressraumes für Geräte, während der rest für den RAM genutzt wird. Somit sieht man unter WinXP dann auch sehr oft 3,5GB RAM, wenn man 4 GB eingebaut hat.
Der Virtuelle Adressraum unter Windows betrifft nicht den physikalischen Speicher, sondern die Software, die verwendet wird. So reserviert Windows sich standardmässig 2GB des Adressraums für Kernel+Treiber (Kernelspace) usw. Der restliche Adressraum (2GB) kann quasi in Instanzen von Software genutzt werden (Userspace).
Hardwaretreiber (z.B. Treiber für Onboardgeräte oder Chipsatz) reservieren aber oft mehr Adressraum im Kernelspace als die Hardware im gesamten Adressraum und somit gehen oft mehr als 1GB des Adressraums für Kernel+Treiber drauf, obwohl diese Geräte phyiskalisch nur 512MB des physikalischen Adressraums adressieren. Es gibt sehr viele Fälle in denen der 3GB Schalter (der ja den Kernelspace für eine LA-Erweiterung des Userspace räumt) genau deswegen nicht mehr funktioniert. Meiner Meinung nach sollte man die Finger davon lassen, weil moderne Hardware selbst viel Adressraum möchte.
Es gilt also die Faustregel: Mehr als 3GB RAM macht bei Win32 einfach keinen Sinn, weil der nicht sinnvoll genutzt wird und mehr als 2GB macht für Win32 keinen Sinn, wenn nicht mehrere Speicherhungrige Anwendungen gleichzeitig gefahren werden. Denn der Speicher liegt in beiden Fällen brach. Um den für den angepeilten Anwendungszwecke nutzen zu können, muss ein 64Bit OS her - es gibt keine andere Lösung.

greg

2007-08-23, 10:06:00

doch PAE^^

Mumins

2007-10-17, 08:33:10

Beim Desktop ist seit einiger Zeit eben 2GB RAM Standard

Das glaube ich sicher nicht. Standard ist 1GB, nur die wenigsten haben 2GB.

_DrillSarge]I[

2007-10-17, 09:10:25

hier wird immer nur von 4gb geredet. seit win2000 gibts großraum pae (bis 32gb). jedoch ist dies a) nur in der server-variante von win2k drin und b) benötigt man dafür speziell zertifizierte treiber.
theoretisch ist es kein problem, die ganzen systemresourcen hochhiefen zu lassen. das problem sind die treiber, welche3 nicht darauf ausgelegt sind.

PatkIllA

2007-10-17, 09:22:10

I[;5940113']hier wird immer nur von 4gb geredet. seit win2000 gibts großraum pae (bis 32gb). jedoch ist dies a) nur in der server-variante von win2k drin und b) benötigt man dafür speziell zertifizierte treiber.
theoretisch ist es kein problem, die ganzen systemresourcen hochhiefen zu lassen. das problem sind die treiber, welche3 nicht darauf ausgelegt sind.
Das ist aber nur eine Krücke. Wenn du das in einem Programm nutzen willst muss der Programmierer von Hand vorher die passende Seite einblenden und hat auch immer noch 2GB(?) am Stück.

HOT

2007-10-17, 10:35:45

I[;5940113']hier wird immer nur von 4gb geredet. seit win2000 gibts großraum pae (bis 32gb). jedoch ist dies a) nur in der server-variante von win2k drin und b) benötigt man dafür speziell zertifizierte treiber.
theoretisch ist es kein problem, die ganzen systemresourcen hochhiefen zu lassen. das problem sind die treiber, welche3 nicht darauf ausgelegt sind.
Das wird nicht genutzt, wenn die Anwendung das nicht explizit unterstützt. Das tut fast keine Anwendung, nur einige grosse Datenbanken usw. PAE ist für die Betrachtung der Adressraumproblematik absolut irrelevant.

_DrillSarge]I[

2007-10-17, 10:40:01

Das wird nicht genutzt, wenn die Anwendung das nicht explizit unterstützt. Das tut fast keine Anwendung, nur einige grosse Datenbanken usw. PAE ist für die Betrachtung der Adressraumproblematik absolut irrelevant.
genauso nutzen die wenigsten programmen mehr als 2gb unter 32bit.

HOT

2007-10-17, 10:46:40

I[;5940346']genauso nutzen die wenigsten programmen mehr als 2gb unter 32bit.
Bezug? Es gibt kaum Software die PAE nutzt, weil PAE einfach unbrauchbar langsam ist. Es gibt aber genügend Spiele z.B. die mit mehr als 2GB Adressraum durchaus etwas anfangen können. Der HDRO Client z.B.

_DrillSarge]I[

2007-10-17, 10:50:02

Bezug?
ich kenns von spielen, wenn man 4gb reinhaut (3.5 oderso verfügbar) skaliert es im ramverbrauch nicht so wie bis zu 2gb. es kann auch daran liegen, dass nicht mehr daten da sind ;). zudem wird bei speicherfressern wie photoshop/ premiere explizit empfohlen 64bit os etc. einzusetzen.

PatkIllA

2007-10-17, 11:03:02

HOT

2007-10-17, 11:16:06

I[;5940368']ich kenns von spielen, wenn man 4gb reinhaut (3.5 oderso verfügbar) skaliert es im ramverbrauch nicht so wie bis zu 2gb. es kann auch daran liegen, dass nicht mehr daten da sind ;). zudem wird bei speicherfressern wie photoshop/ premiere explizit empfohlen 64bit os etc. einzusetzen.
RAM fressen != Adressraum fressen, bitte trennen. Der Adressraum ist schon am Ende, wenn das Programm ~1,5GB RAM schlucken, weil dann das Risiko, dass kein Speicherbereich mehr gefunden werden kann der gross genug ist, sehr hoch wird. Folge: Der Adressraum muss defragmentiert werden, Speicher muss freigegeben werden. Das kostet recht viel Leistung. Mit mehr Adressraum und LAA Bit kann man das umgehen. So kann man viele Games mit dem CFF Explorer das LAA aktivieren um mehr Resourcen nutzen zu können, Beispiele dafür sind Armed Assault und Gothic3.
Der HDRO Client hat LAA standardmässig aktiv, er läuft auf maximalen Details so flüssiger und mit weniger nachladen auf Systemen auf dem der Adressraum >2GB ist.

Edit: mir fällt grade auf, dass der Vanguard Client seit letztem Patch das LAA Bit ebenfalls standardmässig aktiv hat :). MMOs als Technologievorreiter :D.

_DrillSarge]I[

2007-10-17, 11:16:44

RAM fressen != Adressraum fressen, bitte trennen.
m'kay ;)

Avalox/Gast

2007-10-17, 11:28:10

Wie ist dieses denn beim Max OS X Rechner gelöst?

Der Mac ist schließlich der erste EFI PC. Eigentlich die beste Voraussetzung um Hardware schön weit außerhalb allen physikalischen Speichers einzubinden.

Hmm. Wenn man dieses mal richtig zu Ende denkt, wäre dort sogar eine native 64Bit Bios Emulation möglich, auf die ein XP64 oder Vista 64 aufsetzen könnte. Wie würde sich dieses XP/Vista dann verhalten? Würde es klar kommen und sich über die neu geschaffene Ordnung im System freuen(!)?

Wird wohl nicht so einfach sein, den sonst hätte Apple nicht nur den 32Bit Bios Emulation nachgeschoben? Oder hat es etwa doch nur den Grund, nur einem 32Bit Spielkram Windows den Zugang zum Apple Rechner zu erlauben?

Man, wann kommen denn endlich EFI Windows PCs? Der PC Markt ist aber auch was träge..

_DrillSarge]I[

2007-10-17, 11:35:05

Man, wann kommen denn endlich EFI Windows PCs? Der PC Markt ist aber auch was träge..
in solchen punkten ja. siehe pci, siehe agp. hab mich auch schon mehrfach gefragt, wegen der einführung von efi. schließlich machen da alles "riesen" mit (sogar die bios-hersteller). irgendjemand muss sich ja dagegen stemmen. seltsam
€: wahrscheinlich ist momentan alles >2gb für den mainstream markt uninteressant. 1gb sind ja erst standard.

Avalox/Gast

2007-10-17, 11:48:58

I[;5940503']in solchen punkten ja. siehe pci, siehe agp. hab mich auch schon mehrfach gefragt, wegen der einführung von efi. schließlich machen da alles "riesen" mit (sogar die bios-hersteller). irgendjemand muss sich ja dagegen stemmen. seltsam

Na ein riesiger Bremser ist Microsoft.
Ich denke da steckt das Kalkül hinter aus dem grade aktuell werdenden 4GB PC Dilemma so viel Kohle wie möglich zu ziehen.

Eine grosse Schweinerei ist es schon mal gewesen Windows Vista nicht gleich ausschließlich als 64Bit OS auf den Markt zu bringen. Da dürfte auch Intel ein Wort mitgesprochen haben. Intel sieht eben die 64Bit Zeit noch nicht gekommen. Bzw. wollten sich lange nicht eingestehen, dass x86 64Bit der Weg ist und hetzen nun hinterher.

Ich bin wirklich der Meinung, dass das Gespann Intel/MS ein riesiger Bremser ist.

Apple wird sich krankgelacht haben, als Intel auf der Matte stand und seine CPUs als PowerPC Alternative angeboten hat. Die werden gesagt haben, aber nur wenn der Rest eben PC 2.0 ist und schwupp haben wir mit dem Apple PC eine moderne Plattform. (na ja fast, die verwendete CPU ist eigentlich konzeptionell nicht ganz auf der Höhe der Zeit, aber praktisch).

_DrillSarge]I[

2007-10-17, 13:17:26

Ich bin wirklich der Meinung, dass das Gespann Intel/MS ein riesiger Bremser ist.
weiß nicht. das in vista halt sowas wie efi /64bit-only nicht drin ist, stört mich auch, da eh der großteil der leute, welche vista kaufen aufrüsten müssen und die, die es nicht müssen haben halt schon "high-end".
Intel hat ja die komfortable position, dass amd im high-end nichts aufzubieten hat und auch sonst die core-dinger mehr leistung bieten im vergleich zu den top a64x2. dafür bekommt intel im servergeschäft sowohl von amd als auch von sun/ibm mächtig auf die fresse ;).

Gast

2007-10-19, 18:25:15

StefanV

2007-11-20, 16:52:10

Adressraumfragmentierung scheint _DAS_ Problem momentan zu sein bzw das man einfach den vorhandenen Speicher nicht nutzen kann....

Gast

2007-11-20, 17:58:13

Na ein riesiger Bremser ist Microsoft.
Ich denke da steckt das Kalkül hinter aus dem grade aktuell werdenden 4GB PC Dilemma so viel Kohle wie möglich zu ziehen.

wieso? eine vista-lizenz ist sowohl für die 32 als auch für die 64bit-version gültig, MS verdient da nichts doppelt.

Schnuller4u

2008-01-06, 12:24:52

Gast

2008-01-06, 12:41:32

Das gilt für Windows aber nicht für Mac OS X! :cool:

Und wie kommst du darauf?

Gast

2008-01-06, 12:48:58

Und wie kommst du darauf?
Weil MacOS für den Kernel und den Userspace extra 4GB Räume hat...
Was dazu führt das doppelt soviele Contextswitches durchzuführen sind, was dazu führt das der Kernel arschlahm ist.

Schnuller4u

2008-01-06, 12:56:20

Weil MacOS für den Kernel und den Userspace extra 4GB Räume hat...
Was dazu führt das doppelt soviele Contextswitches durchzuführen sind, was dazu führt das der Kernel arschlahm ist.
Das ist richtig. Arschlahm ist aber extrem übertrieben!

But while all other common 32 bit operating systems like Linux, Windows and the BSDs split the address space into 2 GB for user and 2
GB for kernel (2/2) or 3 GB for user and 1 GB for kernel (3/1), the i386/x86_64 version of XNU uses a 4/4 split: While the kernel is running,
the user's data is not mapped into its address space, and while user code is running, the kernel is not mapped. So user and kernel can each have 4 GB of address space with the disadvantage of being less efficient in copying of
data between user and kernel. But this way, kernel mode can map more devices into its address space (like video cards with a lot of
memory), and manage more RAM, thus pushing out the limit when a true 64 bit kernel is required.
http://events.ccc.de/congress/2007/Fahrplan/attachments/986_inside_the_mac_osx_kernel.pdf

Folien ab Seite 46: http://events.ccc.de/congress/2007/Fahrplan/attachments/1053_inside-macosx-kernel.pdf

Gast

2008-01-06, 13:02:08

Wie ist dieses denn beim Max OS X Rechner gelöst?

Der Mac ist schließlich der erste EFI PC.

Booting

While PowerPC-based Macs use OpenFirmware, Intel-based machines use EFI (“Extensible Firmware Interface”). Both kinds of firmware are a lot more powerful than the 16 bit BIOS still shipping on PCs. While EFI can boot off USB and supports GPT partitioning and FAT32 file systems, the rest of the feature sets of OpenFirmware and EFI are pretty similar:
Both can boot off FireWire, and both support APM (“Apple Partition Map”) partitioning and the HFS file system, as well as firmwarelevel drivers. BootX is the bootloader for OpenFirmware, and boot.efi the bootloader for EFI. Both can decode HFS and can therefore read the kernel from the root partition. If there is a “KEXT cache”, i.e. a file with all prelinked KEXTs suited for this configuration, that is newer than the newest file in /System/Library/Extensions and newer than the running kernel, the boot loader will load this cache; otherwise, it will go through all KEXTs and load the appropriate ones by comparing them to the entries of the “device tree” which has been passed from the firmware to the bootloader. Later, a KEXT cache will be written to disk to speed up the next boot. This is somewhat similar but more flexible than the Linux “initrd” approach.
http://events.ccc.de/congress/2007/Fahrplan/attachments/986_inside_the_mac_osx_kernel.pdf

http://img186.imageshack.us/img186/891/biosnn4.jpg

http://img86.imageshack.us/img86/8097/efiik1.jpg

Gast

2008-01-07, 00:41:28

Das ist richtig. Arschlahm ist aber extrem übertrieben!

Na wenn man sich Benchmarks zwischen zwischen z.B. Linux und XNU anguckt wo extreme Last getestet wird, dann schneidet Linux doch schon um Welten besser ab.

Gast

2008-01-07, 13:53:59

Na wenn man sich Benchmarks zwischen zwischen z.B. Linux und XNU anguckt wo extreme Last getestet wird, dann schneidet Linux doch schon um Welten besser ab.

Das ist nicht so klar und da gab es auch viel Kritik, z.B.
"Ich halte die Schlüsse, die AnandTech aus seinen Experimenten zieht, für zu gewagt. Sie selbst reden ja auch meist von "könnte" und an mehreren Stellen davon, daß sie keine harten Fakten hätten. Beispielsweise "We can't prove it […] we might be right, but it doesn't give us cold hard facts".

Sie haben keine harten Fakten, weil sie Prozeßerzeugung messen und nicht Thread-Erzeugung. Zwar besteht ein Prozeß aus mindestens einem Thread, aber die Geschwindigkeit zum Starten eines neuen Prozesses ist nicht allein auf die Geschwindigkeit zum Starten eines Threads zurückzuführen.

MySQL ist ein Prozeß mit vielen Threads. Der verwendete lmbench-Benchmark (der nichts mit MySQL zu tun hat) mißt jedoch keine Thread-Erzeugung, sondern nur Prozeßerzeugung. Und ob nur Thread-Erzeugung für MySQL wirklich das ist, was seine Geschwindigkeit stark beeinflußt?

Es wurde für die Experimente eine selbsterstellte Version von MySQL eingesetzt, die nicht die möglichen Optimierungen für Mac OS X verwendete. Es wurde ferner nicht die aktuelle Compiler-Version verwendet.

Ich bin eher der Meinung von rediculousfish, daß sie besser MySQL untersuchen sollten nach der Ursache. Wenn es ein Problem mit Threads auf Mac OS X gäbe, dann müßten andere Programme die gleichen Probleme haben."http://macmark.de/osx_xnu.php

Armaq

2008-08-05, 16:26:34

Da ich gerade mit diesem Problem kämpfe, belebe ich Leichen neu.

Mit meinen 320MB der Grafikkarte sowie den 3 GB installiertem Hauptspeicher, werde ich also nie mehr als 2 GB nutzbar bekommen unter Vista 32?

Coda

2008-08-05, 16:34:40

Mehrere Applikationen können die 3GiB ausschöpfen. Eine nicht solange du nicht 3GiB Userspace einstellst.

Armaq

2008-08-05, 17:58:09

Mehrere Applikationen können die 3GiB ausschöpfen. Eine nicht solange du nicht 3GiB Userspace einstellst.
Wie geht das?

Coda

2008-08-05, 18:06:06

Die Frage ist etwas weit gefasst. Da müsste ich dir jetzt nochmal den kompletten virtuellen Speicher erklären.

Grob gesagt hat jede Applikation einen virtuellen 4GiB großen Speicherraum von dem Seiten über eine Tabelle auf physikalischen RAM abgebildet werden. Damit können mehrere Applikationen natürlich auch wenn sie nur 2GiB virtuellen Adressraum für sich beanspruchen können zusammen den kompletten physikalischen RAM auslasten.

In einem 64-Bit-System können mehrere 32-Bit-Prozesse zusammen auch mehr als 4GiB RAM verwenden. Und vor allem haben sie dort auch den kompletten 4GiB großen virtuellen Adressraum zur Verfügung anstatt immer 2GiB davon an das OS abtreten zu müssen.

Armaq

2008-08-05, 18:07:20

Ich meinte eher, wie kann ich das einstellen? Also in WinVista 32Bit?

Edit: Ah ich glaube ich habe verstanden. Mehr als 2 GiB kann ein 32Bit Programm gar nicht auslasten?

Coda

2008-08-05, 18:10:23

Die 3GiB Userspace? Davon würde ich dir abraten. Das gibt nur Probleme.

Armaq

2008-08-05, 18:16:33

Ok. Ich dachte nur an Gothic3, wobei das ja wohl mit dem neuesten Patch eh mehr als 2 GiB ansprechen kann als Exe. Es ist aber richtig, das Vista mir im Taskmanager nur 2046 anzeigt und er aber 3 als installiert meldet (auch externe Programme wie CPUZ)?

Coda

2008-08-05, 18:18:32

Ok. Ich dachte nur an Gothic3, wobei das ja wohl mit dem neuesten Patch eh mehr als 2 GiB ansprechen kann als Exe.
Nicht wenn du nicht die 3GiB Userspace freischaltest.

Ist ein 64-Bit-Vista wirklich keine Alternative? Das würde das Problem elegant erledigen. Du kannst den selben Key wie für die 32-Bit-Version verwenden.

Armaq

2008-08-05, 18:21:53

Ich hab ein 64Bit Vista als Upgrade hier, ich scheue den Aufwand etwas. Aber da ich nur so echte 3GiB nutzen kann, werde ich es wohl machen müssen. :D
Also 64Bit.
Wie ist das eigentlich mit 32Bit Treibern? Ich hab hier ein Headset, dass hätte nur 32bit Treiber, soweit ich weiss.

Coda

2008-08-05, 18:23:32

32-Bit-Treiber laufen nicht.

Ich habe aber das gleiche Problem mit einer Spezialhardware. Da verspricht mir der Hersteller schon seit Anfang 2008 64-Bit-Treiber.

Armaq

2008-08-05, 18:35:01

Actionhank

2008-08-05, 19:40:23

Es ist übrigens durchaus möglich mehr als 4GB swap zu haben. Und somit auch theoretisch möglich 10 Programme die jeweils 2GB fressen am laufen zu halten (happy swapping halt ;))

Hab aus Spaß mal die erste Seite gelesen und zu obigem Zitat habe ich eine Frage: Ist es jetzt mit einem 32bit OS möglich, mehreren Anwendungen 2 GB (virtuellen) Speicher zuzuweisen? Und wenn ja, wie geht das, wenn das OS ja eigentlich nur 32bit an Adressen zuweisen kann?

Coda

2008-08-05, 19:45:27

Jeder Prozess hat eine eigene Seitentabelle die seine virtuellen Adressen auf die physikalischen abbilden.

Actionhank

2008-08-05, 20:12:25

Jeder Prozess hat eine eigene Seitentabelle die seine virtuellen Adressen auf die physikalischen abbilden.
Ok. Aber es ist schon noch so, dass bei einem 32bit OS mit 6gb ram 2gb komplett nutzlos sind oder? oder funktioniert das paging auch auf ram?

Coda

2008-08-05, 20:34:00

Da bin ich mir nicht so sicher. Mit PAE könnte es evtl. gehen die ganzen 6GiB auf die Prozesse zu verteilen, aber da habe ich nie ne verlässliche Aussage gefunden.

Gast

2008-08-05, 21:12:54

Da bin ich mir nicht so sicher. Mit PAE könnte es evtl. gehen die ganzen 6GiB auf die Prozesse zu verteilen, aber da habe ich nie ne verlässliche Aussage gefunden.

Genau so ist es. Ein Prozess alleine kann unter 32Bit zwar auch nicht mit PAE 6GiB verwenden, aber die 6GiB können von mehreren Prozessen voll genutzt werden.

Gast

2008-08-05, 21:35:03

mit awe (address windowing extensions) kann das auch ein prozess. wird aber nur von den windows serverversionen unterstützt und auch da nichmal von allen

Coda

2008-08-05, 22:03:14

Das mit AWE war mir bekannt. Das mit mehreren Prozessen habe ich mir auch schon gedacht, aber sicher war ich mir nicht. Ergibt aber Sinn, da die Pagetable ja genauso wie mit 64 bit erweitert wird.

kruemelmonster

2008-08-07, 17:01:00

Dann muss ich erstmal herausfinden, wofür ich überhaupt Treiber bekomme. Sollte sich das als zu schwerwiegend erweisen, werde ich die Aktion wohl sein lassen.

Edit: Danke für den Tipp, aber leider ist auch die Wlankarte nicht 64Bit freundlich. Damit hat sich die Sache erledigt.

Über Windows Update kommen auch ne Menge Treiber die es so in freier Wildbahn nicht (oder nur schwer beschaffbar) gibt. Meine TV-Karte z.B. ist da so ein Kandidat.
Im Zweifelsfall sollte man mit ner Zweitinstallation (ohne Key) gucken welche Hardware denn nun wirklich läuft oder nicht läuft.

Armaq

2008-08-07, 18:39:48

Meine Wlan-Karte ist eben nicht übers Update zu haben. Das habe ich ja schon hinter mir, ausserdem kein Inet ohne Wlan. :)

Zu dem 6GiB-Problem. Ich habe es getestet und mit PAE kann ich die 3 GB nutzen. Ich fange einfach an wahllos Programme und Dateien zu öffnen, mein "angezeigter" Speicher füllt sich bis 1.4GiB und danach mache ich munter weiter, ABER das kleine Sidebartool bleibt bei 1.4 GiB stehen, obwohl die Festplattte nicht rödelt. D.h. für mich die 3 GiB werden ausgenutzt.
Vista zeigt mir auch 3 an, sagt aber nur 2 wären nutzbar. Wie auch immer, 3 GiB mit PAE sind definitiv ok, da ich dann beim Beenden von z.B. G3 nicht immer so ewig warten muss.

Gast

2008-08-07, 18:52:56

btw bei win xp ohne service pack 2 kann man die kompletten 4 gig nutzen erst mit sp2 wurde pae dahingehend kastriert das man nur noch 4 gig addressbereich hat.

Armaq

2008-08-08, 17:15:05

Da hier halbwegs fähige Leute mitlesen, wollte ich fragen, inwieweit kann es sein, dass meine Wlankarte bei 3 GB den Dienst verweigert? Seitdem ich die optimale 3GB-Config gefunden habe (2 von 4 Riegeln der 512MB-Sparte waren defekt), will meine Wlankarte nicht mehr so richtig mein Netzwerk anzapfen. Im Klartext ist sie korrekt installiert, verbindet sich aber nicht, obwohl der FritUSBStick dies durchaus macht. Windows gibt keine Fehlermeldung, aber die Karte weigert sich beharrlich, was kann ich tun? Liegts an den 3 GB und dadurch ausgeblendeten Bereichen des Speichers?

HOT

2008-08-08, 17:21:47

btw bei win xp ohne service pack 2 kann man die kompletten 4 gig nutzen erst mit sp2 wurde pae dahingehend kastriert das man nur noch 4 gig addressbereich hat.
Nein, definitiv falsch. Alle NT-Varianten, egal ob NT3.51, NT4, NT5 (Win2k) NT5.1, (WinXP), NT5.2 (Win2003), NT6 (Vista) oder NT6.1 (Win2008), stellen 2GB Userspace und 2GB Kernelspace zur Verfügung. Sowas ändert sich nicht einfach so, das ist einfach eine Gegebenheit des OSses und der dahintersteckenden CPU-Architektur.

Da hier halbwegs fähige Leute mitlesen, wollte ich fragen, inwieweit kann es sein, dass meine Wlankarte bei 3 GB den Dienst verweigert? Seitdem ich die optimale 3GB-Config gefunden habe (2 von 4 Riegeln der 512MB-Sparte waren defekt), will meine Wlankarte nicht mehr so richtig mein Netzwerk anzapfen. Im Klartext ist sie korrekt installiert, verbindet sich aber nicht, obwohl der FritUSBStick dies durchaus macht. Windows gibt keine Fehlermeldung, aber die Karte weigert sich beharrlich, was kann ich tun? Liegts an den 3 GB und dadurch ausgeblendeten Bereichen des Speichers?
Nutzt du den /3GB Switch? Wenn ja, kein Wunder. Ansonsten kann das keinen Einfluss haben.

Armaq

2008-08-08, 17:25:38

Ich habe ihn mal eingetippt, aber Vista meinte der Befehl dazu wäre nicht bekannt. Wie kann ich das umstellen bzw. wie kann ich das rausfinden? Wobei er wie gesagt meinte, dass der Befehl unbekannt ist und ich ihn auch nicht in der Vista Knowledgebase gefunden habe.

Gast

2008-08-08, 19:04:11

Das stimmt schon ich meine jetzt auch den nutzbaren speicher insgesamt und da gibt es ab sp2 einen einschnitt
http://www.microsoft.com/whdc/system/platform/server/PAE/pae_os.mspx

Sephiroth

2008-08-09, 02:01:24

btw bei win xp ohne service pack 2 kann man die kompletten 4 gig nutzen erst mit sp2 wurde pae dahingehend kastriert das man nur noch 4 gig addressbereich hat.
Du beziehst dich da sicher auf KB888137 (http://support.microsoft.com/kb/888137/en) in Verbindung mit dem Blog-Eintrag (http://blogs.technet.com/markrussinovich/archive/2008/07/21/3092070.aspx)?
Windows Client Memory Limits
64-bit Windows client SKUs support different amounts of memory as a SKU-differentiating feature, with the low end being 512MB for Windows XP Starter to 128GB for Vista Ultimate. All 32-bit Windows client SKUs, however, including Windows Vista, Windows XP and Windows 2000 Professional, support a maximum of 4GB of physical memory. 4GB is the highest physical address accessible with the standard x86 memory management mode. Originally, there was no need to even consider support for more than 4GB on clients because that amount of memory was rare, even on servers.

However, by the time Windows XP SP2 was under development, client systems with more than 4GB were foreseeable, so the Windows team started broadly testing Windows XP on systems with more than 4GB of memory. Windows XP SP2 also enabled Physical Address Extensions (PAE) support by default on hardware that implements no-execute memory because its required for Data Execution Prevention (DEP), but that also enables support for more than 4GB of memory.

What they found was that many of the systems would crash, hang, or become unbootable because some device drivers, commonly those for video and audio devices that are found typically on clients but not servers, were not programmed to expect physical addresses larger than 4GB. As a result, the drivers truncated such addresses, resulting in memory corruptions and corruption side effects. Server systems commonly have more generic devices and with simpler and more stable drivers, and therefore hadn't generally surfaced these problems. The problematic client driver ecosystem lead to the decision for client SKUs to ignore physical memory that resides above 4GB, even though they can theoretically address it.