TS 2010 - auch 32-Bit?

Die heute in vielen (auch im professionellen Anwendungsumfeld) anzutreffenden X86-64-Prozessoren, kurz X64, sind Erweiterungen der klassischen X86-Architektur. Sie sind keine "echten" 64-bit-Architekturen im klassischen Sinne, die vor knapp 20 Jahren mit der DEC Alpha auf den Markt kamen. Später hat auch Intel mit dem Titanium versucht, in diesem oberen Segment Fuß zu fassen, mit sehr mäßigen Erfolg.

Die X64 haben den großen Vorteil für den Normalverbraucher, dass sie sich sowohl unter 32- als auch unter 64-bit-Betriebssystemen betreiben lassen. Windows bietet entsprechende Varianten seit Jahren. Und zu Hause steht passende Hardware auch schon seit Jahren. Aber irgendwie ist es erst jetzt zum Anwender durchgedrungen, die Hardware entsprechend zu nutzen. Denn als Anwender hat man offensichtlich keine wirklichen Nachteile. Es läuft alles wie bisher. Insbesondere heißt das, man benötigt keine 64bit-Prozesse. Entsprechende Programme sind eh kaum zu finden. Die Migration einer Software auf 64bit ist nämlich verdammt aufwändig und fehleranfällig. Allerdings bringt die X64-Architektur einen angenehmen Nebeneffekt für bestehende Software. Mit minimaler Änderung kann ein 32bit-Prozess mehr Speicher nutzen.

Ein normaler 32bit-Prozess unter Windows 32bit kann maximal 2GB virtuellen Speicher für sich in Anspruch nehmen. Das ist völlig unabhängig davon, wieviel Speicher physikalisch vorhanden ist. Mit ein wenig Modifikation beim Linken (und ein paar notwendigen Prüfungen) kann aber ein solcher 32-Bit-Prozess dazu gebracht werden, mehr Speicher adressierbar zu machen, auch schon auf 32-bit-Systemen. Allerdings muss Windows dazu auch ein wenig modifiziert werden. Danach können bis zu 3GB (virtuell) für so einen Prozess vergeben werden. Da physikalisch selten mehr als 3GB überhaupt adressiert werden können (hängt vom Motherboard ab), kommt man hier ans allgemeine Limit.

Auf x64 geht es besser. Ein solcher modifizierte Prozess kann unter 64bit-Windows jetzt tatsächlich seinen ganzen 32bit-Adressbereich ausnutzen, also 4GB virtuell adressieren, wieder unabhängig davon, ob die physikalisch vorhanden sind. Nur kann man eben beim X64 und entsprechendem Motherboard physikalisch nicht nur mehr draufpacken sondern auch nutzen. Und dann die 4GB für den Prozess ausreizen.

Ich gehe mal davon aus, dass TS2010 diese Modifikation vorgenommen hat, wie übrigens auch TransDEM 2.0, und damit in die 3/4GB-Welt vorgedrungen ist. Damit bleibt es aber trotzdem ein ganz normaler 32bit-Prozess.

Was Mehrkernprozessoren angeht, da gibt es auch so manches Missverständnis. Seit NT 3.1, Anfang der 90er Jahre, spielt Windows in der Liga der "richtigen" Betriebssysteme mit. Einer der Schöpfer des NT-Kernels, Dave Cutler, hat NT einen "Fully preemptive task scheduler" verpasst, und gleich das passende Prozess und Threading-Modell dazu. Das gab es zuvor nur bei den "großen" Systemen und bei Unix (bis auf die Threads. Das dauerte bei Unix noch etwas). Mit dem Multitasking-Konzept konnten ganz gewöhnliche Anwendungen "parallel" arbeiten. Allerdings war das damals eine virtuelle Parallelisierung, stand doch normalerweise nur ein Prozessorkern zur Verfügung.

Im professionellen Umfeld änderte sich für die Software mit der Verbreitung von Multi-Prozessor- oder Mehrkern-Prozessoren gar nichts. Bei gut geschriebener Software musste nicht eine einzige Ziele geändert, oder neu kompiliert werden. Diese Prozesse nutzten die neuen Architekturen von Anfang an voll aus. Im Hobby-Bereich war das anders. Bis vor wenigen Jahren dominierte in der Spiele-Welt noch das DOS-Programmiermodell, das eigentlich ohne Betriebssystem auskommt. Eine Endlosschleife versucht ohne Rücksicht auf Verluste so viele Frames wie möglich zu produzieren. Spielprogrammierer taten sich unendlich schwer, parallele Ansätze aufzugreifen (Ausnahme: die Grafik selbst). Wobei man zugeben muss, Parallelisierung, selbst in ihrer heutigen Form, dem Multithreading, ist alles andere als trivial. Wenn man die notwendigen Verfahren nicht im Blut hat, sind Desaster mehr oder weniger vorprogrammiert. Vielleicht dauert es auch deswegen solange, bis Spiele einen weiteren Prozessorkern wirklich nutzen. Aber nochmal, die Softwareumgebung dazu ist seit 15 Jahren ausentwickelt. Das Problem besteht in den Köpfen der Entwickler, nicht in deren Entwickungsumgebung. Aus meiner Perspektive ist es faszinierend zu beobachten, wie Programme, die ich vor Urzeiten geschrieben habe, heute ohne jede Anpassung ganz automatisch auf Mehrkernsystemen für wunderbare Lastverteilung sorgen.