Guten Tag,
Rednael_186 hat geschrieben:Guten Tag,
aus gegebenem Anlass sehe ich mich genötigt, zu fragen, welche Funktionen von BAHN wie viel Rechenleistung benötigen. Eine wirkliche Aufschlüsselung hat die Suche nicht zu Tage gefördert, exakt ist es wahrscheinlich auch nicht möglich, aber evtl. bei Kenntnis über die internen Abläufe im Programm abschätzbar.
Das ist schon deshalb schwierig, weil sich die einzelnen BAHN-Versionen in dieser Hinsicht sehr unterscheiden.
Es wurden im Lauf der Jahre immer mal Engpässe optimiert oder ganz anders realisiert,
sodaß manche ältere Aussage hierzu auf neuere Versionen nicht mehr zutrifft.
Rednael_186 hat geschrieben:Worum es mir geht, wäre eine Einordnung nach Rechenaufwand von zB:
- Weichen, vor allem Zufallsweichen, Wechselweichen
Bei Weichen gibt es eigentlich wenig zu rechnen. Es sind rein passive Elemente.
Hier wird also nur etwas gerechnet, wenn ein Zug eine Weiche spitz erreicht oder wenn er deren Stellung zwecks
Reservierung eines Streckenabschnitts im voraus ermitteln muß.
Ausnahme ist lediglich die Wechselweiche: Hier müssen die Rücksetzzeiten überprüft werden.
Bei der Zufallsweiche ist zwar ein vermutlich etwas aufwendiges Rechenverfahren nötig
(ich kenne den internen Aufbau der random()-Funktion nicht), aber eben nur, wenn dort ein Zug ankommt.
Rednael_186 hat geschrieben:
- Signalanlagen, nach
.- Signalanlagenelementen
Für Schaltkontakte gilt das selbe wie für Wechselweichen.
Bei Signalen kommt allerdings dazu, daß sie unterschiedliche Zustände haben, welche auch optisch dargestellt werden.
Die kosten also ein bißchen mehr Aufwand bei der Grafik.
Das gilt insbesondere für blinkende Signale oder Signale mit mehreren Phasen.
Das Blinken war einst nur ein grafischer Effekt, ähnlich zu den Animationen, und lief mit einer festen langsamen Frequenz.
Es wurde also nicht schneller, wenn die Simulation schneller wurde.
Heute läuft es aber synchron zur Simulationszeit und hat damit mehr zu rechnen, wenn alles schneller läuft.
Rednael_186 hat geschrieben:
.- Signalfunktionen / Verknüpfungen
Es gab Versionen, in denen die Simulation recht langsam wurde, wenn es tausende von Signalanlagen und -elementen gab.
Das lag an den Verknüpfungen und wurde inzwischen mehrmals erheblich beschleunigt.
Rednael_186 hat geschrieben:
.- Schaltvorgängen durch Zeitliste oder Züge
Das Überprüfen einer Zeitliste dauert immer etwas, je nach deren Länge.
Eine extrem lange Zeitliste z.B. mit Schaltungen jede Minute könnte sich bemerkbar machen, allerdings habe ich das nie nachgemessen.
Rednael_186 hat geschrieben:
- Haltestellen / Taktpunkte (ausgefallene Abfahrten?)
Haltestellen kosten eigentlich gar nichts. Sie sind genauso passiv wie Weichen.
Taktpunkte dagegen prüfen regelmäßig auf eine Abfahrt, weil sie sonst keinen Ausfall melden könnten.
Rednael_186 hat geschrieben:
- jedes Fahrzeug (zB Autos, die einfach nur Show fahren)
Die Züge sind der eigentliche Zeitfresser, und zwar konkret die fahrenden Züge.
Der Unterschied zu den anderen Elementen ist immens, weil die Züge viel häufiger in die Berechnungen eingehen.
Die Uhr der Simulationszeit läuft in Schritten von 1/100s (seit BAHN 3.85, vorher waren es nur 1/50).
In jedem dieser Schritte müssen bei fahrenden Zügen die Geschwindigkeit neu berechnet werden (aufgrund der Ist- und Sollwerte und der Beschleunigung), und ggf. der Zug auch noch ein Stück bewegt werden.
Letzteres kommt in ca. 10% der Fälle vor (wurde rein statistisch ermittelt, hängt vom Maßstab des Netzes ab und auch von den Geschwindigkeiten der Züge).
Natürlich kommt es bei einem schnelleren Zug entsprechend öfter vor als bei einem langsamen.
Wenn die Zugspitze bei der Bewegung innerhalb eines Elements bleibt, ist nicht viel zu rechnen.
Erreicht sie aber ein neues, muß dessen Funktion ausgewertet werden.
Das ist also bei jedem 8. Schritt nötig, seitdem mit 8 Schritten pro Element gefahren wird (also BAHN 3.85).
Ein fahrender Zug belastet also die CPU alle 1/100s Simzeit.
Ein schnellerer Zug bewegt sich entsprechend öfter als ein langsamer.
Grob abgeschätztes Beispiel:
Wer Flugzeuge oder andere sehr schnelle Objekte (Transrapid etc.) in seinen Netzen hat:
Ein solcher "Zug" mit 600km/h belastet die CPU so wie 6 Züge mit 100km/h oder 10 Züge mit 60km/h oder 15 Züge mit 40km/h, d.h. er braucht vielleicht die Rechenzeit einer ganzen S-Bahn- oder Straßenbahnlinie.
Die meisten Netze haben so etwas nicht. Was aber recht oft vorkommt, sind "Schaltzüge" zur Steuerung von Signalanlagen.
Man möchte hier meist eine Schaltung ohne Verzögerung haben und läßt diese Züge daher mit hohen Geschwindigkeiten fahren.
Das ist im Einzelfall zu hinterfragen, Beispiel:
Wenn so ein Zug jeweils 4 Elemente zwischen den Schaltkontakten befährt und das mit 400km/h,
dann ist es besser, die Strecke auf je 2 Elemente zu verkürzen und mit 200km/h zu fahren.
Außerdem gibt es beim Vorbild sehr viele Schaltungen, die deutliche Verzögerungen aufweisen
(z.B. Signale, Stellwerke). Es ist also gar nicht unrealistisch, so etwas nachzubilden.
Rednael_186 hat geschrieben:
Noch habe ich Hoffnung, dass durch den gezielten Ersatz besonders komplizierter Elemente die Simulationsgeschwindigkeit erhöht werden kann, die schon jetzt (bei meiner Anlage im [größtenteils] Rohbau) stark nachlässt.
Das ist eher unwahrscheinlich. Die komplizierten Dinge, z.B. logische Ausdrücke an Signalen,
werden ja nur sehr selten mal ausgewertet.
Zum Vergleich, wie oft manche Dinge angefaßt und berechnet werden:
-Fahrende Züge alle 1/100s, ca. alle 1/10s erfolgt ein wirklicher Bewegungsschritt
-Züge am Taktpunkt jede volle Sekunde (Test auf Abfahrt)
-Züge an Haltestellen dito
-Züge im Wartezustand beim Rangieren dito
-blockierte Züge jede volle Sekunde (Test, ob Strecke wieder frei ist)
Anm.: In manchen früheren Versionen wurden blockierte Züge behandelt wie fahrende.
-Alle Züge jede volle Minute (Test auf Ausrücken)
Anm.: Nicht nur eingerückte, damit ggf. eine Meldung bei falschem Ausrücken erstellt werden kann
-Alle Züge jede volle Minute (Test auf Einrücken)
-Taktpunkte jede Sekunde (Test auf Abfahrt und Rücksetzzeiten)
-Signalanlagen-Zeitlisten dito (Test auf Schalten und Rückschalten)
-Signalanlagen-Elemente dito (Test auf Rückschalten)
-Wechselweichen dito (Test auf Rücksetzzeiten)
-Automatisches Speichern des Netzes jede Sekunde
-Test auf Auto-Stop-Zeit und gemerkte Positionen mit Zeitmarke jede Sekunde
Beispiel:
Ein Netz enthält 1000 Züge, davon sind 600 unterwegs, 200 warten auf irgendwas und 200 sind eingerückt.
Dazu sind 1000 Weichen vorhanden, davon 100 Wechselweichen.
Es gibt 1000 Signale und 2000 Kontakte in 400 Signalanlagen sowie 100 Taktpunkte und 400 Haltestellen.
Dann wird in einer Minute Simulationszeit etwa folgendes ausgewertet:
600*60*100 = 3.6 Mio Zugberechnungen, dabei ca. 360000 Bewegungsschritte
200*60 = 12000 Tests auf Wartebedingungen
1000 = 1000 Tests auf Ausrücken
100*60 = 6000 Tests auf Rücksetzen von Wechselweichen
3000*60 = 180000 Tests auf Rückschalten von Signalelementen
400*60 = 24000 Tests auf Schaltzeiten von Signalanlagen
100*60 = 6000 Tests auf Abfahrt am Taktpunkt
60 Tests auf automatisches Speichern
201*60 = 12060 Tests auf Auto-Stop
Ergo: Im Vergleich zu den Zugberechnungen sind alle anderen zusammen immer noch Peanuts,
auch wenn die einzelnen Berechnungen jeweils deutlich komplizierter sind.
Diese Darstellung ist allerdings sehr vereinfacht.
So sind z.B. die an Haltestellen wartenden Züge nach der Wartezeit sortiert.
Es wird also meistens nur der erste in der Kette geprüft und gar nicht alle.
Es ist eine ausgesprochen schlechte Idee, ein großes Netz durch viele schnelle Fahrzeuge nur "zur Show" aufzupeppen.
Hie und da etwas langsames, wie ein Flußschiff oder eine Parkeisenbahn, hat dagegen kaum Auswirkungen.
Ausnahme: Das Netz selbst dient nur zur Show und man hat gar kein Interesse, es öfter mal schnell durchlaufen zu lassen.
Dann spielt diese Betrachtung keine Rolle.
Das ist auch kein spezielles Phänomen von BAHN.
In mancher Simulation werden sogar einzelne Einwohner dargestellt, und da hat man genau das selbe Problem:
Realistische Zahlen sind mit handelsüblichen Computern derzeit nicht zu beherrschen, wenn man dazu auch noch deutlich schneller simulieren will als in Echtzeit.
So hat eben eine wirklich große Stadt in VG oder CIM nicht eine Million, sondern nur ein paar 1000 Einwohner mit entsprechend weniger Fahrzeugen (jedenfalls lt. den Infos über die Spiele, ich habe es selbst nicht probiert).
Was hier bisher gar nicht betrachtet wurde, sind die Ausgabe-Effekte, d.h. Grafik und Sound.
Es ist richtig, daß man das am besten alles abschaltet, wenn man nur schnell einen längeren Zeitraum durchlaufen lassen möchte.
Abschalten =
1. Bewegte Grafik aus (Züge, Signale) (Ctrl+Z),
2. Animationen aus (Ctrl+A)
3. Tag-Nacht-Schaltung aus (Ctrl+T)
4. Sound-Effekte aus
ABER: Vieles davon erreicht man auch durch ändern der Anzeigegröße oder einfach dadurch, daß man auf ein Stück freies, d.h. unbebautes Streckennetz blättert.
Z.B. im schematischen Modus gibt es sowieso keine Animationen und keine Tag-Nacht-Schaltung, da ist es also weitgehend egal, ob sie ein oder aus sind.
Bei rein statischen Dingen, z.B. Ausgabe der Texte, ist es auch unwesentlich, wenn die dynamischen Ausgaben ohnehin ausgeschaltet sind.
ABER zweitens gilt: Je größer ein Netz ist, umso geringer ist die Wirkung dieser Abschaltungen.
Warum ist das so? Die Ausgabe betrifft immer nur den sichtbaren Teil, lediglich beim Sound noch etwas mehr Bereich außen herum.
Je größer ein Netz, umso geringer ist der Anteil des sichtbaren am Gesamtnetz.
Bei einer kleinen Modellbahn mit 10 Zügen kann es sein, daß tatsächlich alle davon gleichzeitig zu sehen sind.
Aber bei einem großen Netz mit 1000 Zügen ist es schon sehr viel, wenn 50 gleichzeitig zu sehen sind, und selbst das sind dann nur noch 5%. Die anderen 95% belasten zwar die Simulation, aber nicht die Ausgabe.
Dadurch wirkt die Grafik bei einem großen Netz nicht als entscheidender Engpaß.
Sie hat zwar noch ein zweites Problem: Auch um nur einen kleinen Bereich darzustellen, müssen diese Daten erstmal im großen Netz zusammengesucht werden. Die entsprechenden Such-Algorithmen sind aber inzwischen mehrmals verbessert worden und kommen auch mit recht hohen Datenmengen klar.
Was kritisch sein kann, ist der Sound. Für jedes laufende Geräusch erzeugt Windows einen eigenen Thread, der solange läuft, bis das Geräusch zu Ende ist (zum Begriff "Thread" siehe Wikipedia oder Google, ich kenne kein brauchbares deutsches Wort dafür). Jeder dieser Threads braucht etwas CPU-Leistung.
Man kann sich die Wirkung sehr schön anschauen, wenn man auf einem sehr kleinen Netz (z.B. dem bei Programmstart) mal mehrere Soundpunkte plaziert und die Simulation mit Geschwindigkeit 20 laufen läßt. Es dauert in der Regel nicht lange, bis der Computer nur noch mit dem Lärm beschäftigt ist. Ein Blick in den Windows-Task-Manager oder ähnliche Tools ist dabei ganz interessant.
Es mag aber im Einzelfall von den Treibern abhängen. Ich habe damit wenig Erfahrung, weil der Sound bei mir immer aus ist.
Grüße,
Jan B.
.