Letzte Woche bei Railware

1.3.2004

Neulich fand sich ein Beitrag über PCs mit zwei Prozessoren und paralleler Verarbeitung im Forum. Ich liebe parallel laufende Prozesse und Threads und will nun mal was darüber schreiben. Als Modelleisenbahner mögen Sie sich vielleicht fragen, was denn eigentlich ein "Prozess" ist? Hmmmmh, mal sehen: eine brennende Kerze vom Anzünden bis zum Erlöschen ist z.B. ein Prozess. Oder Sie möchten mit dem Auto einen Freund in der nahen Stadt besuchen. Dann könnte ein Prozess mit dem Zusammenstellen der mitzubringenden Dinge beginnen und mit dem Einparken vor dem Haus enden. So ein Prozess kann jederzeit unterbrochen oder modifiziert werden. So könnten Sie die Kerze ausblasen oder auf der Autobahn noch kurz tanken. Unterwegs begegnen Ihnen viele andere Autos - das sind parallel zu Ihnen ausgeführte Prozesse.

Ein Prozess ist also nichts weiter als eine definierte Arbeit !

In einem PC sind Prozesse und Threads nichts weiter als Programmteile, die gleichzeitig abgearbeitet werden können. Ein Thread ist übrigens nur eine einfachere Form eines Prozesses, der von Windows schneller "verwaltet" werden kann. Einen Prozess in Windows kann man mit einem Exe-Programm gleichsetzen. Railware startet davon regelmäßig mindestens zwei: Gleisbild und Interface. Zu beiden gehören je nach Gleisbild und Funktionen eine Vielzahl von Threads mit den unterschiedlichsten Aufgaben. Der Prozessor des PC teilt nun seine Arbeit auf und werkelt für kurze Zeit an allen Prozessen herum. Und da das sehr schnell geht, merkt man die Unterbrechungen nicht. Modernste Intels kennen "Typerthreading" und können damit echte Parallelverarbeitung von Threads mit nur einem Prozessor bewerkstelligen. Echte Parallelverarbeitung von Prozessen wird aber erst mit sogenannten "Dual-Mainboards" möglich. Wie der Name vermuten läßt, werkeln dort 2 Intel (oder auch AMD) Prozessoren vor sich hin. Diese Mainboards findet man vielfach in File-, SQL- und Application- Servern, CAD-Systemen und Anderem.

So, dann wollen wir doch mal schauen, ob und wo wir eine Modellbahnsteuerung (hier Railware) wirklich beschleunigen können. Auf den ersten Blick scheint ja alles parallel abzulaufen: Züge fahren gleichzeitig, werden zur gleichen Zeit abgebremst und dergleichen mehr. Ereignisse (Rückmelder) kommen zur gleichen Zeit ins System und müssen gleichzeitig bearbeitet werden. Wirklich ? Wenn wir in kleineren Zeitabständen schauen, dann kann man nämlich leicht feststellen, das dem nicht so ist. Nach dem "einlaufen" eines Rückmelders muss ein neuer Fahrabschnitt reserviert werden, was zwar bei Railware wegen des dynamischen Routings mehr Zeit benötigt als das "Abklappern" einer fest konfigurierten Liste, aber das braucht kaum eine Millisekunde und der Job ist erledigt. Auch beim gleichzeitigen Anhalten mehrerer Züge ist es nicht viel anders: superschnell werden die einzelnen Lokbefehle berechnet, um dann gemächlich, nämlich seriell und nacheinander, an das langsame Digitalsystem und dessen Gleisprotokoll übertragen zu werden.

Nun könnte man natürlich auf die Idee kommen und z.B. für zwei Züge mittels vier Threads die nächsten Fahrabschnitte zu reservieren und neue Fahrbefehle oder Bremswege zu berechnen. Wunderbar, nur leider können die nicht einfach so unkontrolliert vor sich hinlaufen. Denn vom Erfolg der Fahrwegsuche des ersten Zuges hängen nicht nur die neuen Fahrbefehle ab, sondern auch die Berechnung des Fahrweges für den zweiten Zug. Nämlich dann, wenn diese sich zufällig kreuzen sollten. Darum müssen nahezu alle laufenden Threads synchronisiert werden, was die Parallelität nicht eben fördert.

Das man dafür Mutexe und andere "Schweinereien" verwendet, will ich hier mal nicht näher ausführen. Nicht näher erläutern will ich auch den Grund, warum Railware trotzdem (und mit Erfolg) so viele Threads verwendet, auch wenn sie nicht so viel an Geschwindigkeitsvorteilen bringen. Erfahrene Profis werden den Grund wohl wissen ...

Am gemächlichsten geht es also im Digitalsystem zu. Aber daran können wir nichts ändern und müssen es in der Regel auch nicht, denn die Geschwindigkeit der Digitalsysteme orientiert sich (jedenfalls meistens) an der Größe und den Erfordernissen durchschnittlicher Modellbahnanlagen. Wenn man denn überhaupt einen Geschwindigkeitsgewinn erzielen möchte, dann muss man den Hebel bei der Grafikausgabe ansetzen. Denn die dauert um Dimensionen länger als alle Berechnungen, die Railware mit den Zügen anstellen könnte. Und wie das im Leben so spielt: Windows erlaubt immer nur einem Prozessor, einem Prozess oder einem Thread Zugriff auf Windows Ressourcen. Wird an der Grafik gewerkelt, müssen alle anderen warten. Bevor Sie jetzt aber auf die Idee kommen eine neuen, superschnellen, Yoghurt- gekühlten 3D- Grafikenhancer bei der Mutter aller Schnäppchen zu erwerben - lassen Sie es bleiben !! Railware verwendet seit seiner Geburtsstunde hochentwickelte und für den Einsatzzweck optimierte Grafikausgabemethoden.

So, und nun erahnen Sie vielleicht den Grund, warum bei einem neueren PC die CPU- Auslastung kaum über die 40% Marke zu bekommen ist. Das heißt natürlich nicht, das ich nicht doch noch an verschiedenen Stellen des Systems Geschwindigkeitsvorteile herausholen könnte. Da ist noch genügend Potential, aber nirgendwo eine dringende Notwendigkeit. Und so halte ich mich noch einige Monate an drei wichtigen Entwicklergesetzen fest: "Optimiere nicht", "Optimiere noch nicht" und "Mache lieber etwas wichtiges".

Was man so alles mit seinem PC erleben kann und wie man ihn mit Sicherheit ungeeignet für Steuerungsaufgaben macht, das soll in einem der nächsten Berichte folgen.

Bis dahin viel Spaß mit Ihrer Modellbahnanlage und Railware wünscht Ihnen

Dieter Hinz

© Copyright by Andrea Hinz. Kontakt zum Railware Team
Alle Logos, Hersteller- und Produktnamen sind Warenzeichen ihrer jeweiligen Hersteller.