Erklärung zu der Berechnung, Mehrkernnutzungnutzung und Wartezeit am Monatsende

Die Vergleichsmap waere natuerlich super zum Testen.

Wie hoch ist denn deine Gesammteinwohneranzahl auf der betreffenden Map? Auf meiner Performance-Testmap liegen bereits 4 Staedte ueber 1.700 Einwohnern, davon eine mit 3500EW und nur 4 Staedten unter 1.000EW.

Die Therorie der langen Linien klingt nach einem zu untersuchenden Ansatz. Zum Vergleich: ich habe auf besagter Testmap 3 'lange' Linien - a) 6 angeschlossene Staedte und 12 Zuege, b) 6 angeschlossene Staedte und 18 Zuege, c) 5 Staedte und 21 Zuege und alle Linien fahren im 2Min Takt und haben eine Kapazitaet von ca. 125 Passagieren pro Zug mit sehr hoher Auslastung. Zudem fahren auf allen Linien gemoddete Zuege. Meint ihr das macht ebenfalls viel aus bei der Monatsendabrechnung? Die Zugdarstellung duerfte hauptsaechlich Sache der Grafikkarte sein.

Ohne jetzt den Code analysiert zu haben wie @eis_os, denke ich das es die Anzahl der Simulanten und die Komplexität des Verkehrsnetzes ist. Beides erhöht den Rechenaufwand für die Simulation.
Die Nutzung der vielen, wunderbaren Fahrzeuge der Modder dürften damit nichts zu tun haben. Programmintern ist es für die Berechnung der Simulation nur eine Datenstruktur (Geschwindigkeit, Kapazität etc.), wie toll das Ding dargestellt wird interessiert an der Stelle nicht. Es müsste egal sein, ob ich das Netz mit wenigen Fahrzeugtypen oder vielen betreibe, solange die Kapazität und Komplexität des Netzes gleich sind...

Die Frage war eher, ob es einen Performance-Unterschied macht wenige lange Linien, die mehrere Staedte anfahren, oder stattdessen viele kurze Linien, die nur jeweils zwischen zwei Staedten pendeln, einzusetzen, da dadurch das Spiel unabhaengig von der Anzahl der Einwohner und Fahrzeuge zusaetzlich belastet wird.

läuft wohl aufs gleiche hinaus, auch wenn du mehrere lange Ringbahnen hast fängst du irgendwann an zu verdichten, hier noch eine S-Bahn hier noch ein RE.
Auf die Verdichtung zu verzichten um keine Wartepausen zu haben, dann kannst du das Spiel 1900 auch auf schnell stellen und die Wäsche machen

Dann klinke ich mich hier auch mal mit meinen Erfahrungen ein.
Mein Spielstand (erstellt vor der Hauptstraßenproblematik, Verbindungen sind z.T. gekappt):
32899 Einwohner, Jahr 2362
190 Fahrzeuge auf 48 Linien
60 Züge auf 18 Linien (=>eher lange Linien)
18 Trams auf 4 Linien

Auf einfacher Geschwindigkeit hab ich ne Wartezeit am Monatsende, die vielleicht 2 Sekunden dauert, meist sogar weniger.
Und das mit einem im Vergl. zu nem Core I7 eher langsamen Phenom II X4. Der einzige Unterschied ist, dass ich 3,8 Ghz Takt hab. Daher halte ich es für möglich, dass die Berechungen einfach viel mehr von einem hohen Takt profitieren als von einer besseren Prozessorarchitektur.

Ich hab mal ein bischen rumgerechnet, und bekomme ein konsistentes Bild:

Laut Internet ist der Phenom II X4 etwa 75% so schnell (Single Thread Speed) wie ein i7 4890K.
Wenn ich auf dem Phenom jetzt das Spiel in Geschwindigkeit 1 laufen lasse, hat der Prozessor für einen Monat Spielzeit 30 Sekunden CPU-Zeit zur Verfügung. Dazu kommen laut Fussel 2 Sekunden Wartezeit.
Stelle ich auf dem i7 die Geschwindigkeit auf "doppelt", so dauert der Monat nur 15 Sekunden. Warte ich noch 10 Sekunden, dann bin ich bei 25 Sekunden. Das entspricht in etwa 78% der benötigten (echten) Zeit auf dem Phenom.

Nochmal in Zahlen:

(15+10) / (30+2) = 0.781

Wenn mir einer der i7 Benutzer bestätigen kann, dass er das Spiel mit Doppelter Geschwindigkeit laufen läßt, dann würde alles einen Sinn ergeben. Ich würde den Leuten dann fürs erste empfehlen, die Geschwindigkeit auf 1-fach zu stellen. Dann wartet man wahrscheinlich am Ende des Monats gar nicht mehr...

Wenn UG es dann noch schafft, die Monatsberechnung auf 4 Kerne zu verteilen, kann man das Spiel mit 4-fach-Geschwindigkeit laufen lassen, ohne am Ende des Monats zu warten (zumindest auf i7). Als AMD 8150 8-Kern User wünsche ich mir natürlich eine Verteilung auf 8 Kerne...

Am besten wärs das nicht fix zu kodieren, sondern an der Anzahl der virtuellen Kerne fest zu machen. (Ja, dank HT gibt es virtuelle Kerne...)

Es wäre interessant zu wissen, was für ein Algorithmus in dem Thread ausgeführt wird, der am Monatsende den Lag verursacht. Schliesslich lassen sich nicht alle Algorithmen parallelisieren.

wato:
Wenn ich das richtig sehe, wird im wesentlichen berechnet, welche Städte wachsen sollen und wo. Ausserdem geht es glaube ich um alle möglichen statistischen Daten.
Da es meistens mehr als eine Stadt gibt, und jede für sich wachsen kann, sollte man das parallelisieren können: mindestens Städte, die nicht aneinander grenzen, sollte man parallel berechnen können.

Auch Wegfindung kann man parallelisieren, das ist ja eigentlich nur Rumrechnen auf Graphen. Deshalb gehe ich davon aus, dass UG noch einiges rausholen kann und wird.

@Reisi:
Natürlich ist es am besten, die Anzahl der Threads irgendwie an die Anzahl der (virtuellen) CPU-Kerne anzupassen. Wenn man ganz sicher gehen will (und zu faul ist, es dynamisch zu machen), kann man aber auch einfach eine recht große Zahl von Threads losrechnen lassen, und allen Threads im Gegenzug nur eine geringe Priorität zu geben. Dann behindern sie sich nicht gegenseitig und auch nicht den Hauptthread.

Optimal ist natürlich, wenn man es irgendwie schafft, komplizierte Berechnungen auf die Grafikkarte zu verlagern. Dann hat man irgendwie zwischen 32 (i7 interne HD 4000), eta 100 (z.B. NVIDIA 640) und 1000 oder mehr Kerne (z.B. NVIDIA 9xx Serie) zur Verfügung (OpenCL ist hier eine portable Lösung, die automatisch mit den GPU-Kernen skalieren kann). Das ist toll, aber leider nicht "mal eben" gemacht. Man muss den Algorithmus dann im wesentlichen neu implementieren (Ausser, man hat sehr viel Glück). Allerdings kann man damit auch Leuten mit einer etwas älteren CPU und Grafikkarte helfen (hab ich schon selbst gemacht, das ist toll).

Gehen wir aber von CPUs aus, dann hat man heute etwa 4 (i5, Phenom II) oder 8 (i7, AMD FX 8150) Kerne. Wenn man erstmal alles auf 8 Threads verteilt, hat man eine Menge gewonnen und nichts falsch gemacht.

Wenn man Zeit hätte, könnte man ja mal das Paper von Basil Weber lesen, dass auf train-fever.com unter About verlinkt ist. Vielleicht steht da Genaueres drin

Ich habe ein wenig die Übersicht verloren, was jetzt in welchem Thread genau berechnet wird. Wartet das Spiel jetzt am Ende des Monats auf die Wegfindung oder auf den neuen "Bauplan"?
So wie ich es verstanden habe, findet die Wegfindung seit dem letzten Patch in einem separaten Thread statt und das scheint performant genug zu sein.
Was die Unabhängigkeit der Berechnung des "Bauplans" für verschiedene Städte angeht, würde ich dies mal als Spekulation verbuchen, oder gibt es dazu eine offizielle Quelle?

Was die Anzahl Threads angeht, wäre ich vorsichtig. Mit mehr Threads als logischen Kernen kann man sich schnell mal in den eigenen Fuss schiessen. Da wird der zusätzliche Koordinationsaufwand gerne auch mal grösser, als der Zeitgewinn durch die Parallelisierung. Mal ganz allgemein gesprochen.

Xanos Aussage kann ich nur bestätigen, auch bei mir sind die Monats-Lags behoben.

haha wahrscheinlich hab ich dafür jetzt monatslags gleich mal schauen

Zitat von wato

Wenn man Zeit hätte, könnte man ja mal das Paper von Basil Weber lesen, dass auf train-fever.com unter About verlinkt ist. Vielleicht steht da genaueres drin

Danke für den Tipp. Hab die Paper noch nicht gelesen, aber das eine Video sieht recht interessant aus:

Das sieht arg danach aus, als wäre in TF das gleiche Prinzip für das Stadtwachstum implementiert und auch die 3D-Darstellung im zweiten Teil kommt mir verdächtig bekannt vor. Man achte zudem auch auf die fps Zahlen am Anfang. Die schwanken schon brutal. Da wird also einiges berechnet.

Hallo Allerseits,

ich finde es natürlich gut, dass die Entwickler sich bemühen bestimmte Aufgaben in extra Threads aufzuteilen. Leider löst dies die Grundproblematik nur sehr bedingt. Nebenläufigkeit ist eine so komplexe Angelegenheit, dass sie, sofern nicht von Anfang an vorgesehen, einen Code rewrite nach sich zieht. Berechnungen beispielsweise auf einen zweimonatszyklus zu verlagern um Lags am Ende des Monats zu verhindern ist aus meiner Sicher eher ein Workaround als ein Fix.

Zudem bringt es natürlich wenig für die allgemeine Performance. Wir schreiben das Jahr 2015 und nahezu jeder (nicht-casual) Gamer besitzt einen QuadCore-PC. Wie kann ich ein Spiel entwickeln, dass sich nahezu nur auf die IPC der CPU verlässt? Das finde ich wirklich unglaublich. Den Entwicklern muss doch von Anfang an klar gewesen sein, dass wenn ich wahnsinnig große Karten von 1850 - 2050 spielen möchte, dass Berechnungen parallel stattfinden müssen und effiziente Algorithmen nötig sind.

Keine Frage, ich mag das Spiel! Hut ab vor dem, was sie geschaffen haben. Aber einige Dinge verstehe ich nicht. Und einige Features vermisse ich nach wie vor. Ein dynamischer Tag-Nacht-Rythmus beispielsweise. Man könnte diesen, beispielsweise über 3 Monate oder so laufen lassen. Innerhalb eines Spieltages geht das natürlich nicht. Aber beleuchtete Züge und Städte im Winter bei Schnee -das wäre schon etwas.

Ein Tag-Nacht-Rhythmus bringt ja dem Spiel selbst nichts. Im Spiel-Tageswechsel wäre das ein übles Geflacker, und im langsameren "so schnell, dass der Spieler das sieht - egal welche Spielzeit gerade ist" ist es ausschließlich ein optischer Effekt.

Der hat's allerdings in sich: Man müsste zu allen Modellen noch eine passende Nacht-Ansicht erstellen, also Lampen platzieren, beleuchtete Innenraumdetails erfinden, etc. Außerdem Scheinwerfereffekte (das würde vermutlich richtig viel Grafikperformance benötigen). Und am schlimmsten wäre, wenn der Spieler durch den Tag-Nacht-Wechsel denken würde, er müsste morgens zur Rush-Hour alle Arbeiter zum Gewerbegebiet bringen und abends zurück - und das Spiel die simulierten Menschen einfach nicht pünktlich aufstehen lässt.

Natürlich würde eine gut gestaltete Nachtansicht toll aussehen. Aber sie bringt das Spiel aus Sicht der Entwickler kein Stück voran. Wenn man die Entscheidung zu treffen hat, entweder das gesamte Aussehen der Spielwelt in einem zyklischen Ablauf Tageszeiten und auch gleich noch Jahreszeiten durchlaufen zu lassen, oder alternativ den veröffentlichten Releastermin einhält - dann ist da keine Frage. Zumal man für sowas sicherlich von Anfang an schon Vorbereitungen im Code hätte treffen müssen.

Und wenn ich als Spieler nach dem Release und Kauf die Wahl habe, entweder ein komplett unperformantes, fehlerhaltiges Spiel nicht spielen zu können, während die Entwickler die Tag-Nacht-Wechsel implementieren, oder sie arbeiten alternativ daran, die Performance zu steigern, bekannte Bugs zu beheben und Features einzubauen, die relevant für die Spielmechanik sind - dann ist da auch keine Frage.

Das war auch nur *eine* Idee. Das sich die nahezu nicht in das vorhandene Spielkonzept einbetten lässt, ist mir auch klar.

Ein Schwerpunkt liegt meiner Meinung nach weiterhin darin, alles was geht an Multicoreperformance bzw. Optimierung der vorhandenen Algorithmen zu betreiben.

Dir ist aber schon klar, dass es einerseits Problemstellungen gibt, die nicht parallelisierbar sind, und dass andererseits Parallelisierung, wo sie möglich ist, eventuell keinerlei Zeitgewinne bringt, weil sie auf Microebene doch wieder seriell arbeiten muss oder auf Ergebnisse wartet.

Zitat

Den Entwicklern muss doch von Anfang an klar gewesen sein, dass wenn ich wahnsinnig große Karten von 1850 - 2050 spielen möchte, dass Berechnungen parallel stattfinden müssen und effiziente Algorithmen nötig sind.

Wieso muss es ihnen von Anfang an klar gewesen sein?

Es wurde irgendwo aus der Frühzeit um das Releasedatum im September mal gesagt, das Spiel könne so 10.000 Einwohner simulieren. Vielleicht stammt die Zahl tatsächlich von den Entwicklern, die mit ihrer Hardware und einem entsprechend fortgeschrittenen Spiel bei dieser Zahl entweder ans Ende der von ihnen als sinnvoll erachteten Spieldauer gekommen sind (wird ja auch langweilig, wenn nach 2014 keine neuen Fahrzeuge mehr erscheinen können - ohne Mods wohlgemerkt!). Und jetzt kommen Spieler, die auf großen Karten, evtl. mit Glück bei der Generierung und Geschick beim Aufbau der Linien, Einwohnerzahlen von 40.000 vorweisen können und sich über Performanceprobleme beklagen. Ich würde nicht sagen, dass man das von Anfang an hätte wissen müssen.

Das man ein Spiel entsprechend aktueller Hardware so optimieren sollte, dass es so gut wie möglich mit der Anzahl der Kerne skaliert, ist jedoch klar. Ich weiß selbst, dass Nebenläufigkeit sehr, sehr komplex ist! Andere Spiele schaffen es aber auch effektiv ein Maximum an FPS zu erreichen und zugleich alle Kerne maximal auszulasten. Ich kenne den Code von Train Fever nicht, aber ich habe das Gefühl, als gäbe es da noch eine Menge an Potenzial.