Mehrprozessor- bzw. Multicore-Fähigkeit von Zusi 3?

[Gerald Hunker]

Bis Zusi 3 erscheint, werde ich mir einen neuen PC bauen, so viel steht schon fest. Beim Design habe ich bislang noch alle Freiheiten.
Da stellt sich z.B. auch die Frage, ob mit einem Quad-Core Prozessor überhaupt eine Leistungsverbesserung zu erzielen wäre. Also meine Frage: Wie gut skaliert Zusi 3? Wie intelligent macht Zusi 3 von mehreren CPU-Kernen Gebrauch, und falls ja: gibt es da eine Grenze?

Die Antwort hat Zeit. Bitte keine Vermutungen, nur Fakten, Fakten, Fakten

Gruß vom Roten Heuler

[Andreas Miniberger]

Also eines ist Fix, das beim Laden der Strecke Zusi3 auf jedenfall von meheren Kernen profitiert. Das steht irgendwo in einem anderen Thema hier.

[Roland Ziegler]

Noch mal zum Grundsätzlichen: Multi- und auch Mehrkernprozessoren stellen auf der Softwareseite keinerlei neue Herausforderung dar. Der Preemptive Task Scheduler als Voraussetzung gehört seit den frühen 80er Jahren zu professionellen Betriebsystemen dazu, sehr früh auch auf mehr als eine CPU ausgelegt. Mit Anfang der 90er zog neben dem Multiprocessing auch das leichtgewichtigere Multithreading allgemein ein, mit Linux und Windows (NT) als Schlusslichtern. Ein einziger Prozessor reichte, um so etwas zu nutzen. Jede Anwendersoftware, die dafür ausgelegt ist, kann prinzipiell auch Multi- und Mehrkernprozessoren voll ausschöpfen, ohne eine einzige Codezeile zu ändern. Die sich stellende Frage: Ist denn die Software dafür ausgelegt? 3D-Anwendungen wurden noch bis in die jüngste Zeit als ganz klassische Endlosschleife programmiert, die in einem einzigen Thread entweder Eingaben verarbeitete oder, wenn keine Eingabe vorlag, mit maximaler Frequenz Bilder berechnete. Da ist dann auch bei mehreren CPUs oder Kernen nichts weiter herauszuholen. Multi-Threaded-Software demgegenüber ist vom Ansatz her weniger trivial, birgt sie doch bestimmte gemeine Fußfallen, denen man mit Synchronisierung entgegenwirken muss. Und bei solchen Synchronisierungen sind etliche Überlegungen vonnöten, um verschiedene Aufgaben möglichst zu entkoppeln, so dass die Threads jeweils von anderen unbehelligt vor sich hin arbeiten können. Ein typisches Konzept für Anwendungen wie Zusi sind zwei Threads, von denen einer als Versorger läuft, der andere als Verarbeiter. Andere Konzepte sind die tatsächlicher Parallelverarbeitung, wo exakt gleiche Tätigkeiten z.B. auf einen Thread-Pool verteilt werden. Dort wird auch Lastverteilung skaliert. Dies ebenfalls seit vielen Jahren, lange bevor jemand an Dual- oder Quadcore dachte. (In den 80er gab es mal Sonderlösungen, z.B. Transputer. Die erforderten eine spezielles Software-Design.) Threads kann man sich unter Windows z.B. mit dem Process Monitor von Sysinternals anschauen. Da wird man staunen, wie viele es davon gibt.

[Carsten Hölscher]

DirectX unterstützt für den 3D-Teil nur einen Thread (kann sein daß es unter Vista inzwischen etwas anders aussieht, da war mal irgendwas...) und von daher ist es bei typischen 3D-Anwendungen wie Zusi angesichts der anfallenden Rechenarbeiten nicht sinnvoll, mehr als 2 Kerne zu benutzen. Weitere Prozessoren können natürlich für weitere Anwendungen benutzt werden, aber die sollten sich eigentlich auch einfach abschalten lassen, während man Zusi fährt.

Carsten

[Roland Ziegler]

Gängige Frameworks für Benutzeroberflächen waren und sind durch die Bank single-threaded, da bildet DirectX keine Ausnahme. Das heißt natürlich nicht, dass die ganze Anwendung single-threaded sein muss. DirectX11 führt m.W. Multi-Threading in der Form ein, dass die Versorger auch noch auf unteren DirectX-Ebenen in separaten Threads laufen können, der Auswerter, in dem Fall der Renderer, bleibt single-threaded. Multi-Threading mit Benutzeroberfläche heißt, dass entweder eine mittelbare Synchronisierung stattfinden muss und darzustellende Ergebnisse aus Fremd-Threadsdarüber ausgetauscht werden, oder eine Form von Active-Object zum Einsatz kommt, d.h. der GUI-Thread für externe Aufgaben "missbraucht" wird und dabei sogar Rückgabewerte liefern kann. Im Ansatz ist so etwas in jedem GUI-Framework vorhanden. Java und .Net schaffen eine elegante OO-Kapselung dazu, aber auch Delphi beherrscht das Verfahren. Im Stellwerk wird dergleichen zum Einsatz kommen, wobei die rein ereignisgesteuerten Stellwerks-Threads derart anspruchslos sind, dass sie keinen der Prozessorkerne zum Husten bringen werden.

[Gerald Hunker]

Weitere Prozessoren können natürlich für weitere Anwendungen benutzt werden, aber die sollten sich eigentlich auch einfach abschalten lassen, während man Zusi fährt.

Carsten

Und ich war mir so sicher, dass ich mich klar ausgedrückt hatte
Es ist doch nicht so, dass mich die zusätzlichen Kerne stören! Wenn die im Leerlauf vor sich hindümpeln, dann kratzt mich das primär gar nicht. Ich stelle mir nur vor, dass es bei Zusi 3 einiges zu rechnen geben wird. Wenn Zusi 3 so wird, wie es sich in der Vorschau darstellt (was ich seeehr begrüßen würde), dann ist da für die CPU(s) einiges zu tun. Wäre doch schade, wenn da nur 1 CPU arbeitete und die übrigen nix tun können, weil das Design es nicht zulässt - oder? Schlimmstenfalls hätte man dann 4 Kerne im System und das Bild ruckelt trotzdem. Das würde mir dann definitiv keinen Spaß machen.
Und darauf zielte meine Frage.
"Kann sein daß es unter Vista inzwischen etwas anders aussieht, da war mal irgendwas..." - oops, das klingt in meinen Ohren nicht gut!

Gruß vom Roten Heuler

[Roland Ziegler]

Gehe ich recht in der Annahme, dass Dir technische Erklärungen wenig sagen?

[Carsten Hölscher]

Ist Roter Heuler Dein Name?
Zusi 3 soll auch unter xp laufen.
Wie Roland schon ausführlich beschrieb, ist es (wegen der nötigen Synchronisation) Unsinn zu glauben, daß es möglich ist, ein Programm durch Verdoppelung der CPUs doppelt so schnell laufen zu lassen, schon gar nicht bei Anwendungen wie Zusi. Wenn schon die 2. CPU nicht ausgelastet ist, was soll da die dritte noch tun?

Carsten

[Peter Zimmermann]

Ist Roter Heuler Dein Name?

Wohl kaum, wenn ich mir das Avatar anschaue; so nannte man die historischen Elektrotriebwagen ET25 und ET65.

[Christopher Spies]

Hallo Carsten!

Wie Roland schon ausführlich beschrieb, ist es (wegen der nötigen Synchronisation) Unsinn zu glauben, daß es möglich ist, ein Programm durch Verdoppelung der CPUs doppelt so schnell laufen zu lassen

Man nennt es auch Amdahls Gesetz.

schon gar nicht bei Anwendungen wie Zusi.

Eigentlich ist Zusi doch eine Anwendung, die stark von Multiprozessorsystemen profitieren könnte .
Zumindest theoretisch lässt sich das Rendern nahezu beliebig parallelisieren (spätestens die Grafikkarte arbeitet ohnehin massiv-parallel). Dass DirectX das nicht kann, steht auf einem anderen Blatt.
Die Fahrphysik lässt sich ebenfalls nahezu beliebig parallelisieren, jeder Zug könnte seinen eigenen Physik-Thread bekommen. Gleiches gilt für den "Autopiloten".
Dass es einen eigenen Prozess nur für das Nachladen der Streckendaten im Hintergrund geben soll, wurde im Forum ja schon mehrfach angekündigt.

Wenn es jedoch in der Praxis nur einen Renderprozess gibt, der den weitaus größten Teil der Berechnungen beinhaltet und somit nur einen (dafür aber entsprechend leistungsfähigen) Prozessorkern benötigt...
... dann bringt es vermutlich nichts, den Rest der Anwendung in viele Prozesse aufzuteilen, die dann vermutlich doch alle gemeinsam auf einem weiteren ebenso leistungsfähigen Kern laufen und diesen noch nicht einmal auslasten.

Mehr als zwei Kerne können dann nur dazu dienen, Virenscanner, Firewall und MP3-Player noch nebenher laufen zu lassen. Schade eigentlich.

Gruß,
- Christopher

[astauder]

Ich persönlich würde mich momentan lieber für einen sehr hoch getakteten Dual Core entscheiden als für einen niedrig getakteten Quad Core.
Ich rede hier nur von preisgleichen CPUs . Einen hoch getakteten Quad kann man natürlich auch bekommen, der kostet aber noch zuviel und ist in drei Jahren auch Alteisen.
Man möge mich korrigieren, wenn ich falsch liege, aber noch bestimmt doch wohl die Taktfrequenz die Leistungsfähigkeit der CPU . Dabei meine ich natürlich die Schnelligkeit bei Rechenaufgaben.

Grundsätzlich verfahre ich persönlich nach dem folgenden Schema:
Alle drei Jahre ein neues Kernbundle (Mainboard; CPU; RAM; Grafikkarte) aber nicht die jeweils aktuelle Preisoberklasse, sondern möglich günstiges Preis-Leistungsverhältnis.
Das ist besser, als sich einen PC aus der Preisoberklasse für das doppelte Geld zu kaufen und dann sechs Jahre daran festzuhalten.

Aber es kann ja jeder so machen wie er denkt.

Gruß Arno

[Carsten Hölscher]

Zumindest theoretisch lässt sich das Rendern nahezu beliebig parallelisieren (spätestens die Grafikkarte arbeitet ohnehin massiv-parallel). Dass DirectX das nicht kann, steht auf einem anderen Blatt.

Was intern in der Graka passiert hat mit den Threads der Anwendung nichts zu tun. Zugriffe auf die Graka müssen synchronisiert werden, sonst gibt's fundamentale Fehler. Hätte ich also zwei Threads, die Graka-relevantes machen, müßten die sich sowieso synchronisieren (ist bei mir auch der Fall in dem Moment wo der Ladethread was in den Graka-Speicher schiebt - der Ladethread spart also nur beim "Drumrum", nicht beim unmittelbaren Beschicken der Graka).

Fahrphysik und Autopilot kosten keine nennenswerte Rechenzeit.

Carsten

[F(R)S-Bauer]

Wie währe es denn den oder die Fahrdienstleiter, also die Fahrwegsuche aus zu Lagern?

Wir haben ja in Zusi 2 den Effekt des stotterns bei tiefen Suchen.

Vielleicht würde ein Konzept mehrer den jeweiligen Modulen / Bereichen zugeornete FDL als eigenständige Threads mehr Abwechslung ins Spiel bringen, und es ermöglichen z.B ein Regelwerk zur Blockadevermeidung durch den Streckenbauer zu erstellen, was dann auf den 2 oder 3 CPU Kern läuft.

Ausserdem könne sich das Vorteilhaft auf die Stellwerksankoplung in einem Multiuserbetrieb auswirken

mal so in den Raum werfend

Ralf

[Carsten Hölscher]

Der Fdl sollte dank neuer Ansätze mit wesentlich weniger Rechendampf auskommen. Sonst wäre das aber in der Tat ein sinnvoller Ansatz.

Carsten

[F(R)S-Bauer]

Ich bin ja immer noch dafür, das es zur Blockadevermeidung eine Art Scriptsprache oder Abhängigkeitslogik gibt. Dann könnte der seperate Thread wieder interessant sein.

mfg

Ralf

[Betriebsleiter]

Mehrere Prozessoren haben auch so den Vorteil, den ganzen restlichen Müll(M$-OS) der so vom OS betrieben nebenher läuft, im Zweifel eindeutig auf die weiteren Prozessoren zu verteilen, die Zusi eher nicht nutzt.
Wenn ich ich mich noch recht an alte EDV Tage erinnere, lässt sich jedes Programm einer beliebigen CPU fest zuweisen. Mit etwas Tiefenbastelei war das auch dauerhaft, also auch nach Neustart des Rechners, möglich.


Andere Frage, in diesem Thread wohl OT und mit Sicherheit war ich zu suchfaul, wie sieht das eigentlich mit Multimonitoring und Zusi 3 aus ?
Komplette Landschaft auf 3 Monitoren oder doch nur einer aber dafür die ganzen "Zusatzgeräte" im Führerstand, die ich einfach mal so zusammengefasst habe, beliebig auf weitere Monitore verteilbar ?
Oder auch beim Herstellen von Strecken, deren Baufeld sich nahezu beliebig auf mehrere Monitore erweitern lässt oder oder oder........................

[Gerald Hunker]

Gehe ich recht in der Annahme, dass Dir technische Erklärungen wenig sagen?

Hallo Roland,
danke für die "Blumen" Ich verdiene zwar meine Brötchen in der IT, bin aber kein Programmierer und schon gar kein Chip-Designer. Da gebe ich gerne Grenzen zu.
Ich gebe auch zu, dass ich allergisch reagiere auf Dinge die "man einfach weiß".
Ich habe den Großteil meines Arbeitslebens mit Technik verbracht und sage aus dieser Erfahrung ganz klar: Wer wirklich Ahnung von einer Sache hat, der kann sie meistens auch einem 5-Jährigen erklären.

(War als Ansporn gemeint )

Gruß,
Der Rote_Heuler

[Gerald Hunker]

Ist Roter Heuler Dein Name?

Wohl kaum, wenn ich mir das Avatar anschaue; so nannte man die historischen Elektrotriebwagen ET25 und ET65.

Genau! Darin haben sich wichtige Episoden meiner frühesten Kindheit zugetragen!
Eigentlich schade, dass sich diese schönen Züge noch keiner für Zusi vorgenommen hat. Wer weiß, wie lange die 3 verbliebenen Schätzchen noch fahren....

Man soll ja in Social Networks nicht zuviel von sich preisgeben.
Drum bin ich für euch erstmal der Rote_Heuler

[Hubert]

[quote="Roter_Heuler"

Man soll ja in Social Networks nicht zuviel von sich preisgeben.
Drum bin ich für euch erstmal der Rote_Heuler [/quote]

Das gilt nicht für Zusi mir sind alle sehr Sozial

Gruss
Hubert