32Bit-Verklemmung: mal was offizielles, handfestes

[zeckensack]

Für diejenigen die meinen, 64 bit brauche kein Mensch bevor nicht mindestens 2GB physikalischer Speicher in den Maschinen steckt.
Hier (http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/009951.html) ist zu lesen, daß unter bestimmten Umständen (OpenGL auf NV35/256MB, Treiber-Init nach erfolgter Speicherbelegung) schon bei 800MB Schicht im Schacht ist. Der 'betroffene' in diesem Fall hat btw 1.5GiB physikalischen Speicher.

Kernaussage im Bezug auf die 64bit-ja-oder-nein-Frage: physikalische Speichermengen sind weitgehend wurscht. Logisch, x86-CPUs haben schließlich MMUs dafür. Virtueller Speicher ist zwar langsam, erfordert dafür aber Null Intervention auf der Applikationsebene. Was also wirklich zählt ist der virtuelle Addressraum, und der wird langsam knapp.

Originally posted by Mark Kilgard
The initialization of the OpenGL driver does require a fair amount of virtual address space. In general (without a 64-bit OS), applications are limited to somewhere between 3 and 2 gigabytes of virtual address space (depending on your OS).

Libraries such as OpenGL take up a fair amount of virtual address space because mappings must be established for OpenGL's data structures, mappings to AGP memory, and mappings to video memory.
<...>

NVIDIA is aware of that currently the virtual memory consumption by the driver is too great when GeForce cards with big memorys are combined with graphics applications demanding most of the available virtual address space. We are working to reduce the driver's virtual memory footprint to alleviate the problem you are experiencing.

Keep in mind that the OpenGL library isn't the only culprit usually. There are often other DLLs that may be consuming large chunks of your virtual address space.

Until NVIDIA can release a driver that reduces OpenGL's virtual memory footprint, the best advice is to intialize OpenGL early (creating your OpenGL context, with GLUT that means calling glutInit), minimizing the size of your application's own memory arrays, and checking if other DLLs are consuming an inordinate share of your virtual address space.

I hope this helps.

- Mark

[Endorphine]

Den Ansatz halte ich für nicht sonderlich sinnvoll. Ist es für den Fall nicht besser, erst einmal die Probleme in Treibern/Software und APIs zu beseitigen, statt an den Symptomen herumzudoktorn und einfach mit der 64-Bit Keule auszuholen?

Mal ganz unabhängig vom genauen Sachverhalt, diese Herangehensweise halte ich für äußerst fragwürdig.

Edit: Wenn ich das Zitat von Mark Kilgard lese stellen sich mir dabei die Nackenhaare auf, solche Treiber/API-Probleme einfach mit Hardware-Overkill zu beseitigen. Hier wäre es wohl 1000x sinnvoller, nVidia (und evtl. das ARB?) in die Verantwortung zu nehmen, statt nach 64-Bit Symptomlinderung zu rufen. Originally posted by Mark Kilgard
[...]
NVIDIA is aware of that currently the virtual memory consumption by the driver is too great when GeForce cards with big memorys are combined with graphics applications demanding most of the available virtual address space.

[...]

Until NVIDIA can release a driver that reduces OpenGL's virtual memory footprint, the best advice is to intialize OpenGL early (creating your OpenGL context, with GLUT that means calling glutInit), minimizing the size of your application's own memory arrays, and checking if other DLLs are consuming an inordinate share of your virtual address space.

[zeckensack]

Original geschrieben von Endorphine
Den Ansatz halte ich für nicht sonderlich sinnvoll. Ist es für den Fall nicht besser, erst einmal die Probleme in Treibern/Software und APIs zu beseitigen, statt an den Symptomen herumzudoktorn und einfach mit der 64-Bit Keule auszuholen?

Mal ganz unabhängig vom genauen Sachverhalt, diese Herangehensweise halte ich für äußerst fragwürdig.Das soll nur aufzeigen, daß Hardware-Zugriff in jeder Form virtuellen Addressraum kostet, der nur durch mehr Addressbits ersetzt werden kann, ganz unabhängig von physikalischen Speichermengen. Und, daß das Problem größer wird, je mehr Speicher Applikationen belegen. Daß Applikationen mit der Zeit größer werden, sollte bekannt sein.

Ich kann auf meiner 512MB-Maschine 1GiB Speicher anfordern und auch benutzen. Alles kein Problem. Wenn ich es geschickt mache, gibt es auch keinen großen Performanceverlust durch Swapping, und dann kann ich auf eine (hypothetische) Verpackung auch schreiben, daß 256MB RAM 'recommended' und damit ausreichend sind, obwohl ich viel mehr belege. Vor allem um die klare Unterscheidung zwischen physikalisch und virtuell ging es mir.



Der "64-Bit-Keule" gegenüber steht "Spaßbremsentum", verursacht vom Mißverständnis physikalischer/virtueller Speicher.

Das ist btw auch kein API-Problem, weil OpenGL bzgl Speichermengen gleich überhaupt nichts vorgibt - warum sollte es auch? Mark hat ja auch Besserung versprochen.

Edit: Wenn ich das Zitat von Mark Kilgard lese stellen sich mir dabei die Nackenhaare auf, solche Treiber/API-Probleme einfach mit Hardware-Overkill zu beseitigen. Hier wäre es wohl 1000x sinnvoller, nVidia (und evtl. das ARB?) in die Verantwortung zu nehmen, statt nach 64-Bit Symptomlinderung zu rufen. NVIDIA's GL-Treiber bringt hier das Faß zum Überlaufen, zugegeben, ebenso wie Mark Einsicht in die Problematik erkennen lässt.
Ein Eingriff seitens NV bringt bestenfalls 1GiB, IMO deutlich weniger. Das hört sich jetzt natürlich erstmal nach wahnsinnig viel an ...

Die Software-Industrie ist schon viel näher am Limit, als die meisten Leute glauben würden. Das Anpassen von Software an Speicherobergrenzen erfordert immer Speichermanagement innerhalb der Applikation. Wenn man da nicht höllisch aufpasst, fragmentiert man den Speicher so stark, daß das ganze nur ein paar Stunden lang läuft. Demirug hat dazu AFAIR schonmal aus dem Nähkästchen geplaudert, im Embedded-Kontext, wo Reboots nicht stattfinden und Programme jahrelang bei veränderbaren Data-Sets laufen müssen. Schmärzen!
Das lässt sich tatsächlich am leichtesten vermeiden, wenn man alles in den Speicher lädt, was man zur Laufzeit braucht. Level-Wechsel helfen bei Spielen, weil man da alles wegschmeißen und neuladen kann. Swapping macht dann den Rest.

Das sind trotz alledem Verzögerungstaktiken. NV kann den Treiber umbauen, Software-Devs können fürchterlich clever sein (und haben dabei tonnenweise Chancen für neue, hochinteressante Bugs), das wird vielleicht noch ein Jahr Software-Wachstum extra ermöglichen. Aber irgendwann ist einfach Schluß.

Auf einem hypothetischen 30bit-Prozessor könntest du kein grafisch anspruchsvolles aktuelles Spiel spielen. Keins. Zuwenig virtueller Addressraum. Es wird Zeit, das Problem an der Wurzel anzupacken (um mal ein Schlagwort gegen deine "Keule" zu setzen :bäh: ).

Zusatz-Zuckerl:
Gut ausgestattete VIA-Boards erlauben zB 3.5GB physikalischen Speicher. Bleiben noch 512MiB für HW-Mapping. Virtuellen Speicher brauchst du dann überhaupt nicht mehr, weil du ihn sowieso nicht mehr benutzen kannst. Im Zweifelsfall kannst du nicht mal den physikalischen Speicher voll nutzen, weil der Addressraum von der Hardware gebraucht, und überschrieben wird.

[Endorphine]

Irgendwie finde ichs grad komisch, dass ausgerechnet von dir meine Meinung bestätigt wird, dass der Wechsel auf 64-Bit Architekturen primär erst einmal nur mehr Adressraum bringt. Das entspricht ja auch genau meiner Meinung.

<ot>
Trotzdem hätte ich lieber einen IA64-Rechner als einen AA64-Rechner :naughty: AMDs Erweiterung schneidet mir viel zu wenig alte Zöpfe ab, auch wenn das Prinzip von IA32 -> AA64 mir wie eine exakte Reproduktion des Architekturfortschritts i80286 -> i80386DX vorkommt. Die unbedingte Kompatibilität und das übertreffen des Altarchitekturleistungsniveaus auf Kosten des 64-Bit Architekturfortschritts schmeckt mir aber trotzdem nicht so richtig. Ein stagnieren der 32-Bit Leistung auf ausreichend hohem Niveau (Hardware-Emulation) wäre mir deutlich lieber als der AA64-Ansatz.
</ot>

p.s. 3,5 GiB RAM gibt's nicht nur auf VIA-Boards =)

p.p.s. Ich bin mal gespannt, ob AA64 tatsächlich Akzeptanz finden wird. 3Dnow war ja auch zuerst da und wurde dann von SSE torpediert.

[zeckensack]

Original geschrieben von Endorphine
Irgendwie finde ichs grad komisch, dass ausgerechnet von dir meine Meinung bestätigt wird, dass der Wechsel auf 64-Bit Architekturen primär erst einmal nur mehr Adressraum bringt. Das entspricht ja auch genau meiner Meinung.Im großen und ganzen stimme ich damit überein.
Mehr Register bringen ein wenig (5~10%?), und die ABI ist etwas 'leichter' in Bezug auf Funktionsaufrufe ("red zone").

Sind aber Peanuts.
Das einzige was wirklich stark profitiert, sind Operationen auf lange Integer, primär Kryptographie. Für den normalen Durchschnittskunden ist das natürlich irrelevant :)

<ot>
Trotzdem hätte ich lieber einen IA64-Rechner als einen AA64-Rechner :naughty: AMDs Erweiterung schneidet mir viel zu wenig alte Zöpfe ab, auch wenn das Prinzip von IA32 -> AA64 mir wie eine exakte Reproduktion des Architekturfortschritts i80286 -> i80386DX vorkommt. Die unbedingte Kompatibilität und das übertreffen des Altarchitekturleistungsniveaus auf Kosten des 64-Bit Architekturfortschritts schmeckt mir aber trotzdem nicht so richtig. Ein stagnieren der 32-Bit Leistung auf ausreichend hohem Niveau (Hardware-Emulation) wäre mir deutlich lieber als der AA64-Ansatz.
</ot>Das macht mich so langsam neugierig. Welcher Zopf (abgesehen von A20 - full ack dazu) soll ab?

p.s. 3,5 GiB RAM gibt's nicht nur auf VIA-Boards =)

p.p.s. Ich bin mal gespannt, ob AA64 tatsächlich Akzeptanz finden wird. 3Dnow war ja auch zuerst da und wurde dann von SSE torpediert. Ad VIA: war nur ein Beispiel ;)

3DNow vs SSE ist ein riesiges Kapitel für sich :grübel:

[StefanV]

Original geschrieben von Endorphine
p.s. 3,5 GiB RAM gibt's nicht nur auf VIA-Boards =)


Nö, aber in VIA Boards kann man 'ne 'Keule' reinpressen, soll heißen:
Registred ECC RAM...

WObei die Frage ist, ob auch Stacked RAMs funzen...

Mach das mal bei 'nem i845B/E/PE oder i865...

[Muh-sagt-die-Kuh]

Original geschrieben von zeckensack
Das soll nur aufzeigen, daß Hardware-Zugriff in jeder Form virtuellen Addressraum kostet, der nur durch mehr Addressbits ersetzt werden kann, ganz unabhängig von physikalischen Speichermengen. Und, daß das Problem größer wird, je mehr Speicher Applikationen belegen. Daß Applikationen mit der Zeit größer werden, sollte bekannt sein.Richtig...allerdings kann eine Applikation auf Windows Workstation Varianten sowieso nur 2 GByte ansprechen, so groß ist der User-Adressspace (optional 3 GB bei den großen Serverversionen). Wenn ich mich recht entsinne läuft ein Boot-Treiber wie der Grafiktreiber jedoch im Kernel-Adressspace und verkleinert somit den User-Adressspace nicht.

Wie das bei Linux aussieht muss mir jemand erklären ;)
Ich kann auf meiner 512MB-Maschine 1GiB Speicher anfordern und auch benutzen. Alles kein Problem. Wenn ich es geschickt mache, gibt es auch keinen großen Performanceverlust durch Swapping, und dann kann ich auf eine (hypothetische) Verpackung auch schreiben, daß 256MB RAM 'recommended' und damit ausreichend sind, obwohl ich viel mehr belege. Vor allem um die klare Unterscheidung zwischen physikalisch und virtuell ging es mir. Wieso verwendest du hier eigentlich MB für MegaByte aber GiB für GigaByte? Nur so interessehalber ;)

[Gast]

Wenn eine CPU mit höherer Bittiefe primär das "Addressraumproblem" aushebelt, drängt sich in mir die Frage auf, warum dann eigentlich Spielekonsolen wie PS2 mit 128 bittigen CPUs aufwarten wo doch gerade bei diesen der Addressraum sehr klein sein müsste.?

[zeckensack]

Original geschrieben von Muh-sagt-die-Kuh
Richtig...allerdings kann eine Applikation auf Windows Workstation Varianten sowieso nur 2 GByte ansprechen, so groß ist der User-Adressspace (optional 3 GB bei den großen Serverversionen). Wenn ich mich recht entsinne läuft ein Boot-Treiber wie der Grafiktreiber jedoch im Kernel-Adressspace und verkleinert somit den User-Adressspace nicht.

Wie das bei Linux aussieht muss mir jemand erklären ;)Windows ist halt ein bisserl verbaut. Daß man einen Fix für einen Design-Fehler als 'Server-Feature' verkauft, ist auch nichts neues. Wenn meine Coding-Guidelines ähnlich beknackt wären wie die von MS, dann würde ich auch keine unsigned-Typen benutzen wollen ;)

OpenGL-Treiber sind User-Land-DLLs, und erledigen einen Großteil ihrer Funktion auch dort.

Bzgl Linux, kA, die Limitationen werden dort aber ähnlich sein. Viel mehr als 3GiB User-Space sind einfach nicht machbar. 3.5GiB ist wahrscheinlich das Maximum, das man irgendwie noch zum Laufen bekommen kann.

Wieso verwendest du hier eigentlich MB für MegaByte aber GiB für GigaByte? Nur so interessehalber ;) Brainfart. Ich hätte MiB schreiben sollen.

[zeckensack]

Original geschrieben von Gast
Wenn eine CPU mit höherer Bittiefe primär das "Addressraumproblem" aushebelt, drängt sich in mir die Frage auf, warum dann eigentlich Spielekonsolen wie PS2 mit 128 bittigen CPUs aufwarten wo doch gerade bei diesen der Addressraum sehr klein sein müsste.? Die EE ist AFAIK ein 32bitter.

Die 128 Bit beziehen sich auf Vektorberechnungen, weil dort eben 4*32 Bit parallel durchgefeuert werden können. Das ganze ist genauso falsch wie DDR-Taktverdopplung, und wird aus dem gleichen Grunde trotzdem gemacht: die Durchschnittskunden sind mit großen Zahlen leichter zu beeindrucken.

[Gast]

Und wieder schlauer durch Zeckensack ;)
Danke, man du hast aber auch Ahnung von der Materie.
Studierst du nicht eigentlich Medizin? Wie schaffst du das alles zeitlich gesehen?

[zeckensack]

Original geschrieben von Gast
Studierst du nicht eigentlich Medizin?Nein :D
Wie schaffst du das alles zeitlich gesehen? Wer sagt denn daß ich alles schaffe? ?-)

[x-dragon]

Original geschrieben von zeckensack
...
Die Software-Industrie ist schon viel näher am Limit, als die meisten Leute glauben würden. Das Anpassen von Software an Speicherobergrenzen erfordert immer Speichermanagement innerhalb der Applikation. Wenn man da nicht höllisch aufpasst, fragmentiert man den Speicher so stark, daß das ganze nur ein paar Stunden lang läuft.
...
Das lässt sich tatsächlich am leichtesten vermeiden, wenn man alles in den Speicher lädt, was man zur Laufzeit braucht. Level-Wechsel helfen bei Spielen, weil man da alles wegschmeißen und neuladen kann. Swapping macht dann den Rest. ... Was das angeht brauch man sich ja eigentlich nur mal beispielsweise Morrowind und Gothic2 anschauen (sollte ja den meisten bekannt sein :)), die soweit ich weiß beide schon ihr eigenes "Dateisystem" verwenden, um die großen Datenmengen dynamisch verwalten zu können und so mit "nur" 512 MB auskommen können.

[zeckensack]

Original geschrieben von X-Dragon
Was das angeht brauch man sich ja eigentlich nur mal beispielsweise Morrowind und Gothic2 anschauen (sollte ja den meisten bekannt sein :)), die soweit ich weiß beide schon ihr eigenes "Dateisystem" verwenden, um die großen Datenmengen dynamisch verwalten zu können und so mit "nur" 512 MB auskommen können. Dateisysteme alleine bringen's nicht. Schon Doom I hatte quasi ein eigenes Dateisystem (*.wad). Das Speichermanagement spielt auch eine Rolle :)
Morrowind (NetImmerse) benutzt einen Puffer fester Größe (und höchstwahrscheinlich fester Position) für den "Exterior Cell Buffer", in welchem Oberwelt-Regionen gespeicher werden, und einen "Interior Cell Buffer" für die Innenräume. Siehe Morrowind.ini :)

Dazu kommen Speicherbereiche dynamischer Größe für das Zeug, was man durch die Gegend schleppen und irgendwo anders auf den Boden schmeißen kann.

Die Meldung "Clearing Data", wenn man einen Spielstand lädt, sollte als Hinweis genügen: bevor neue Daten geladen werden, werden erstmal die alten weggeschmissen, um Speicherfragmentierung zu verhindern.

Trotzdem ist Morrowind nicht frei von Problemen. Wer intensiver gespielt hat, dem wird aufgefallen sein, daß zB das Herumfuhrwerken in einem gut gefüllten Inventar immer langsamer wird, je länger Morrowind läuft. Spiel beenden und Neustarten hilft.

[BUGFIX]

Das mit dem Adressraum ist ja gut und schön - aber solange man sich immernoch mit 16 IRQ Adressen (BIOS) rumschlagen muss, überzeugt es mich nicht wirklich.

Mal ne andere Frage: wenn ich für ein x86-64 Prozessor ein C++ Prog schreibe und einen Pointer auf int deklariere - will der dann 64 BIT oder 32?

MfG

BUGFIX

[Ganon]

Original geschrieben von zeckensack
Bzgl Linux, kA, die Limitationen werden dort aber ähnlich sein. Viel mehr als 3GiB User-Space sind einfach nicht machbar. 3.5GiB ist wahrscheinlich das Maximum, das man irgendwie noch zum Laufen bekommen kann.


Also in den Kernel-Konfigurationen habe ich die zwei Schlüssel gefunden:

---
CONFIG_NOHIGHMEM:

Linux can use up to 64 Gigabytes of physical memory on x86 systems.
However, the address space of 32-bit x86 processors is only 4
Gigabytes large. That means that, if you have a large amount of
physical memory, not all of it can be "permanently mapped" by the
kernel. The physical memory that's not permanently mapped is called
"high memory".

If you are compiling a kernel which will never run on a machine with
more than 960 megabytes of total physical RAM, answer "off" here (default
choice and suitable for most users). This will result in a "3GB/1GB"
split: 3GB are mapped so that each process sees a 3GB virtual memory
space and the remaining part of the 4GB virtual memory space is used
by the kernel to permanently map as much physical memory as
possible.

If the machine has between 1 and 4 Gigabytes physical RAM, then
answer "4GB" here.

If more than 4 Gigabytes is used then answer "64GB" here. This
selection turns Intel PAE (Physical Address Extension) mode on.
PAE implements 3-level paging on IA32 processors. PAE is fully
supported by Linux, PAE mode is implemented on all recent Intel
processors (Pentium Pro and better). NOTE: If you say "64GB" here,
then the kernel will not boot on CPUs that don't support PAE!

The actual amount of total physical memory will either be auto
detected or can be forced by using a kernel command line option such
as "mem=256M". (Try "man bootparam" or see the documentation of your
boot loader (grub, lilo or loadlin) about how to pass options to the
kernel at boot time.)
---

und

---
CONFIG_1GB:

If you have 4 Gigabytes of physical memory or less, you can change
where the kernel maps high memory.

Typically there will 128 megabytes less "user memory" mapped
than the number in the configuration option. Saying that
another way, "high memory" will usually start 128 megabytes
lower than the configuration option.

Selecting "05GB" results in a "3.5GB/0.5GB" kernel/user split:
On a system with 1 gigabyte of physical memory, you may get 384
megabytes of "user memory" and 640 megabytes of "high memory"
with this selection.

Selecting "1GB" results in a "3GB/1GB" kernel/user split:
On a system with 1 gigabyte of memory, you may get 896 MB of
"user memory" and 128 megabytes of "high memory" with this
selection. This is the usual setting.

Selecting "2GB" results in a "2GB/2GB" kernel/user split:
On a system with less than 1.75 gigabytes of physical memory,
this option will make it so no memory is mapped as "high".

Selecting "3GB" results in a "1GB/3GB" kernel/user split:

If unsure, say "1GB".
---

Vielleicht kann der eine oder andere was damit Anfangen! Den Quellcode dazu ist wohl etwas zu groß für das Forum!
:D

[Muh-sagt-die-Kuh]

Original geschrieben von Ganon
Vielleicht kann der eine oder andere was damit Anfangen! Den Quellcode dazu ist wohl etwas zu groß für das Forum!
:D OK, das bestätigt zeckensacks Hypothese, dass die Aufteilung bei Linux im großen und ganzen der Windows Aufteilung entspricht und 3 GB User-Space das Maximum sind.