Armed Assault

Entwickler Blog Eintrag vom 12.03.2008 - Breaking the 32 bit Barrier - Deutsche Übersetzung // German Language

Quelle: Developer´s Blog
Autor: Ondrej Španel
Übersetzer: Prison|Pencil

Durchbrechung der 32 Bit Barriere

Virtual Address Space Probleme

Seit ArmA publiziert wurde, wurden die größten Probleme, die Stabilität und Kompatibilität durch die Auslastung des Virtual Address Space verursacht. Das Problem ist, dass das Spiel eine große Menge an Daten im virtuellen Speicher ablagern muss, während der Virtual Address Space zur selben Zeit von vielen anderen Teilen des Systems genutzt wird, der signifikanteste Teil ist der Grafikkartentreiber. Das Problem trat schon auf, bevor ArmA veröffentlicht wurde, zu Zeiten von Operation Flashpoint, als die ersten Grafikkarten mit 256 MB RAM oder mehr auf den Markt kamen. Flashpoint war meistens weniger stabil als ArmA auf dem selben System. Der Grund dafür war, dass es Memory Mapping als ein Weg nutze, um sich Zugang zu Dateien zu verschaffen. Obwohl es schnell und einfach in seiner Handhabung ist, nutzt Memory Mapping eine großen Bereich des virtuellen Speichers aus. Als Workaround bieten wir einen Weg, um Zugang zu Dateien zu erhalten ohne sie zu mappen (die gut bekannte -nomap Befehlszeile kommt ins Spiel). Für ArmA haben wir den Dateizugang komplett überarbeitet, so dass Datei Mapping überhaupt nicht genutzt wird, sondern eine normale Datei API. Gleichzeitig haben wir den Wechsel zu Overlapped I/O vollzogen, so dass wir die Texturen und andere Resourcen im Hintergrund laden können. Wir (und du) haben auf den schmerzhaften Weg erfahren, dass dies dennoch nicht genug war.

Sind die Grenzen erreicht?

Was nun passiert ist, dass jedem Programm vom Betriebssystem 2 GB an virtuellen Speicher zur Verfügung gestellt wird. 2 Gigabyte hört sich etwas beschränkt an, aber so schlimm ist es nicht – nur wenige Leute haben derzeit mehr RAM in ihrem Computer. Was wichtig anzumerken ist: Wir sprechen hier nicht über RAM (physischen Speicher), sondern über den Adress Space. Die Applikation ist auf 2 GB Adress Space beschränkt, ob du also 512 MB RAM oder 4 GB RAM hast, spielt hierbei keine Rolle. Diese 2 GB werden für alles genutzt, was Programme benötigen. Heutige Grafikkarten-Treiber verbrauchen meist einige hundert MB. Noch schlimmer sind Systemkomponenten die nur kleine Teile des Virtual Adress Space verbrauchen, aber nur hier und dort. Dadurch wird der Speicher in einzelne Fragmente zersetzt und es entstehen eine Vielzahl von kleinen Regionen. Meine Erfahrung sagt mir, dass es fast unmöglich ist dem Spiel mehr als ungefähr 700-900 MB virtuellen Speichers zuzuweisen, ohne dass das System total unstabil wird. Wir reden hier natürlich nicht von einer großen Speicher-Zuweisung, sondern von kleinen 10-100 MB Häppchen. Als wäre das nicht genug, scheinen Treiber-Programmierer noch nicht bemerkt zu haben, dass Adress Space eine begrenzte Ressource ist. Die Treiber können oft nicht gut mit Fehlern bei den virtuellen Speicher-Zuweisung umgehen. Das bedeutet, wenn einem Spiel zu viel virtuellen Speicher zugewiesen werden, passieren sehr merkwürdige Sachen. Ein Dreieck kann den ganzen Bildschirm einnehmen oder es kommt plötzlich zum System-Neustart.

Die Zukunft - 64 Bit

Langfristig gesehen, ist die Lösung der Umstieg auf ein 64 Bit Betriebssystem. Natürlich muss auch das Spiel als 64 Bit Programm kompiliert werden. Eine solche Lösung ist keine realistische für ArmA, teilweise weil noch nicht genug Leute ein 64 Bit Betriebssystem nutzen, teilweise weil die Veränderungen so groß sind und zu viel Zeit und Ressourcen verschlingen würden. Wir haben diverse Experimente und Optimierungen mit gemischten Resultaten mit verschiedenen Patches durchgeführt (siehe diesem Forenthread). Leider hat keiner dieser Versuche gut funktioniert. Bei jeder Lösung hat entweder die Leistung oder die Stabilität des Systems darunter gelitten. Während wir zur gleichen Zeit die Arbeiten an ArmA 2 fortsetzten, mussten wir noch mehr Texturen einbringen, mehr Speicher zuweisen und dadurch wurden wir immer eingeschränkter. Das ging bis zu einem Punkt, an dem das Spiel auf den meisten Systemen nicht mehr stabil lief.

Speicher ohne Adresse

Dann an dem einen Tag, kam eine Idee auf. Es war so eine Idee, wie sie für gewöhnlich auftaucht, aus dem Nichts. Wie es bei solchen Ideen üblich ist, scheinen sie sehr offensichtlich, wenn das System erst einmal implementiert ist. Ich habe jedoch vorher niemals von der Nutzung dieser Idee gehört und deswegen bin ich auch ziemlich stolz darauf, die Technik erfunden zu haben. Ich nenne sie Non-addressable Memory Store.
Die Technik basiert auf der Nutzung der File Mapping API. Ja du hast richtig gehört. Es ist die selbe API, die die Probleme in Flashpoint verursacht hat, aber dieses Mal wird sie auf eine ganz andere Art genutzt. Dateien werden nicht gelesen, sondern Speicher wird zugewiesen:
Beim Start des Spieles wird genug Speicher reserviert und übergeben indem die CreateFileMapping API genutzt wird. Dadurch wird physischer Speicher verbraucht, aber kein virtueller Adressraum.
Wenn ein Datenset ausgelagert oder wieder abgefragt wird, wird eine temporäre Ansicht über die Nutzung von MapViewOfFile erzielt, diese Funktion wird wieder zerstört, sobald der Zugang zu den Daten beendet ist. Dadurch wird ein sehr geringer Anteil an virtuellen Speicher verbraucht (64 KB). Typischerweise werden nur ein paar Datensets zur gleichen Zeit direkt in den Speicher mit diesen Verfahren geholt.
Windows kann mit diesem Verfahren sehr gut umgehen. In der Theorie existiert über die Mapping Datei ein Backup des Speichers, in der Praxis wird aber nichts in die Datei geschrieben, solange es genug physikalischen Speicher gibt. Die kompletten Informationen werden nur über den physikalischen Speicher verwaltet. Der Speicher der auf diese Art gelagert wird ist nicht auf irgendeiner virtuellen Adresse zu finden. Er wird über den Offset des File Mappings identifziert. Adressen werden nur temporär vergeben, wenn der Inhalt aus dem Zwischenspeicher gelesen wird. Das ist möglich, weil die Daten im Cache glücklichweise ortsunabhängig gespeichert werden (sie enthalten keine Zeiger).

Die Barriere ist gebrochen

Diese Technik erlaubt theoretisch selbst bei einer 32 Bit Applikation die Nutzung von mehr als 32 Bit. Die Größe wird nur von möglichen Größe der Mapping Datei und vom freien Arbeitsspeicher beschränkt. Deswegen wäre es mit einem 32 Bit Betriebssystem möglich Daten von über 3 GB zu verwalten. Mit einem 64 Bit Betriebssystem wären es natürlich um einiges mehr. Das ist etwas, was wir nicht in ArmA realisieren werden, da die Experimente gezeigt haben, dass ein Dateicache über 512 MB sehr wenig Verbesserungen mit sich bringt, weil nicht so viel Daten gelesen werden. Für manch andere Programme kann es aber eine brauchbare Option sein. Die Technik ist nicht auf Dateicaching beschränkt, sie kann auch dazu genutzt werden Inhalte abzulagern, es gibt nur eine bedeutende Einschränkung: Das Programm darf niemals auf den zugewiesenen Speicher mit normalen, permanenten Zeigern verweisen, da der Zeiger ungültig werden würde, wenn der Speicher ausgelagert wird. In ArmA beträgt der interne Dateicache zwischen 100-500 MB, je nachdem wieviel RAM du in deinem System hast (oder es hängt davon ab, was für ein Wert du für den Befehl -maxmem nutzt). Mit dieser neuen Methode wird fast kein virtueller Speicherplatz benötigt. Diese paar hundert MB scheinen auszureichen, um das restliche System glücklich zu machen. So weit so gut, das unbeliebte "Cannot allocate system memory surface" Problem scheint somit auf fast allen von uns getesten Systemen behoben zu sein, ohne das wir den Speicher des Spiels begrenzen mussten.

KommentareInhalt:Kommentare