Startseite Forum Downloads Regeln
20. März 2019 13:16
DEUTSCH: Website wurde migriert! Nur noch Lesen mŲglich, Login deaktiviert. Mehr erfahren
ENGLISH: Page has been moved! All contents are read-only, login disabled. Read more
Trainz kaufen
Durch Kauf √ľber die
folgenden Links unterst√ľtzt
du das TrainzDepot.
TrainzDepot - Diskussionsforum
Benutzername
Passwort

Thema ansehen
TrainzDepot > TrainzDepot intern
->> Supportecke
Vorheriges Thema Nächstes Thema

search
Startbeitrag: TS 2010 - auch 32-Bit?
Autor TS 2010 - auch 32-Bit?   1  # 12  top
joachim



Themenstarter

Beiträge: 3464

Eingetreten: 01.01.70
Status: Offline
Eingetragen am 22.01.2010 10:54
Guten Morgen,

eine Frage hätte ich zum TS 2010:
Funktioniert dieser bei Windows 7
ausschließlich in der 64-bit Version.

Beste Gr√ľ√üe joachim
Bearbeitet von Basti am 22.01.2010 11:30
Autor RE: TS 2010 - auch 32-Bit?   11  # 12  top
ikael




Beiträge: 741

Eingetreten: 01.01.70
Status: Offline
Eingetragen am 23.01.2010 12:53
[ot]Was läuft denn hier in dem Thread?
Bei mir wird in der Statusleiste "Warten auf 1.1.1.1..." fortlaufend angezeigt (nur hier im Thread)[/ot]


edit: komisch, scheinbar auch nur auf der vorigen Seite, hm


ERLEDIGT, siehe Shoutbox

Bearbeitet von ikael am 23.01.2010 14:16
Autor RE: TS 2010 - auch 32-Bit?   12  # 12  top
geophil




Beiträge: 833

Eingetreten: 01.01.70
Status: Offline
Eingetragen am 23.01.2010 13:14
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.
Bearbeitet von geophil am 23.01.2010 13:16
Springe zu Forum:
Thema verlinken
URL:
BB-Code:
HTML: