TransDEM Forum

Eine weitere Neuerung, an der ich derzeit arbeite, ist eine 64 bit-Version von TransDEM.

Anlass waren die zunehmenden Berichte von Anwendern, an die Speichergrenzen zu stoßen, vor allem bei US-Strecken. Vor gut einem Jahr hatte sich die USGS geschlossen, die zuvorige kundenspezifische Erzeugung der DEMs auf vorgefertigte DEMs zu ändern, diese allerdings als gewaltig große Dateien anzubieten. Bei einer Auflösung von 1/3 Bogensekunde, mehr oder weniger der Standard für den Bau von US-Strecken in Trainz, muss man damit sehr sorgfältig vorgehen, weil nach dem Laden einer ersten solchen DEM-Datei das Hinzufügen der zweiten möglicherweise bereits die Bank sprengt. TransDEM bietet zwar Werkzeuge, mit denen man die Ausdehnung des DEMs und damit seine Größe reduzieren kann, entweder nach dem Laden, oder auch zu Beginn der Ladeprozedur (seit TransDEM 2.4), aber das erfordert oft mehr als einen Versuch.

Jetzt hat N3V angekündigt, für Trainz künftig ausschließlich auf 64 bit zu setzen. Für mich ein Anstoß, für TransDEM ebenfalls eine 64 bit-Version zu entwickeln. Diese wird zusätzlich angeboten werden und die 32 bit-Variante nicht ersetzen.

Der Quellcode wird für beide Varianten soweit wie möglich identisch gehalten. Der Anwender wird so auch in der 32 bit-Ausgabe von einigen der Verbesserungen profitieren, die primär auf die 64 bit-Ausgabe zielen.

Die 64 bit-Variante wird für die x64-Architektur ausgelegt. Das ist die, die auf dem heimischen PC üblicherweise verwendet wird. (Die Itanium-Architektur, bei Desktops oder gar Laptops praktisch nicht vertreten, wird nicht unterstützt.). Die 64 bit-Variante erfordert natürlich ein 64 bit Windows (x64). Ich teste mit Win 7, es sollte aber auch auf 64 bit Vista und vermutlich auch auf XP64 laufen (sofern überhaupt vorhanden) (Nicht vergessen, XP, das erfolgreichste Windows aller Zeiten, ist immer noch und zu Recht auf 30% aller Desktops/Laptops im Einsatz, trotz Abkündigung.)


Mein Testfall für 64 bit ist die Kombination von vier der 1 x 1 Grad NED DEMs mit 1/3 Bogensekunde Auflösung, als 10 m-Raster importiert und ohne die DEMs zu beschneiden.

Dies ist die Region der East Broad Top Kohlebahn im Osten der USA, 77 bis 79 Grad westlicher Länge, 39 bis 41 Grad nördlicher Breite. Das helle Rechteck nahe der Bildmitte wird von vier topografischen Karten 1:63000 gebildet, je 15 Bogenminuten abdeckend.




Beim Testen stellte sich heraus, dass das Zusammenfügen solcher gigantischer DEMs sehr langsam wurde und so entschloss ich mich, die entscheidenden DEM-Verarbeitungsschritte zu überarbeiten und die Schleifen möglichst zu parallelisieren. Das betrifft beispielsweise das Hinzufügen von DEMs (Merging) oder die Transformation in die benachbarte UTM-Zone. (Bereits in den letzten TransDEM-Versionen kam Zug um Zug schon mehrfach Parallelisierung zum Einsatz.) Damit sich Parallelisierung auch in der Praxis positiv auswirken kann, benötigt man allerdings mindestens eine Quad-Core-CPU. Sonst wird die Verarbeitung großer DEMs keine übermäßige Freude bereiten, auch nicht unter 64 bit. Außerdem empfiehlt sich ausreichend Hauptspeicher, mindestens 8 GB RAM, aber auch 12 oder 16 GB werden nicht schaden.

Dies hat mit der Art der Verarbeitung von DEMs in TransDEM zu tun, bei der viel temporärer Speicher zwischendurch erforderlich wird, und auch dem Undo-Stack (Rückgängig machen), bei dem von jeder größeren Aktion Kopien angelegt werden. Ohne entsprechenden Hauptspeicher benötigen die meisten DEM-Funktionen sehr viel mehr Zeit, weil sie virtuellen Speicher von und zur Festplatte schaufeln müssen.

Was sich nicht parallelisieren lässt, sind explizite Festplatten-Schreib/Lese-Aktionen, wie das Laden und Sichern von Dateien, oder auch solche Teilaufgaben, die von Natur aus seriell angelegt sind. Hier zwangsweise Parallelverarbeitung einzuführen, würde diese Aktivitäten sogar verlangsamen! Es sollte daher auch zukünftig etwas Geduld aufgebracht werden.

Auch unter 64 bit wird es weiterhin einige Grenzen geben. Die maximale DEM-Größe wird bei etwa 2 Milliarden Punkten liegen (2^31). Solch ein DEM wird etwa 8 GB Speicher belegen und bei 5 m Auflösung (1/9 Bogensekunden) einen Bereich von knapp 150 x 150 km abdecken. Bei geringerer Auflösung entsprechend mehr. Ich habe allerdings nicht untersucht, ob der Trainz Content Manager solche Datenfluten verkraften könnte.


Hier noch ein paar Beobachtungen, mit dem Process Explorer aufgenommen:

Der TransDEM-Prozess präsentiert sich als 64 bit-Image:




Allozierter Speicher des TransDEM-Prozesses nach dem Zusammenfügen von vier der 1 x 1 Grad DEMs:




Ablauf der ursprünglichen Schleifen beim Zusammenfügen von DEMs, eine serielle Angelegenheit, Hinzufügen einer Datei:




Nach der Parallelisierung, Hinzufügen aller drei DEM-Dateien in derselben Zeit. Man beachte die deutlich höhere CPU-Leistung, Grund für die Geschwindigkeitssteigerung: