Ruckelt wieder unerträglich

Megaherzzahlen kann man in die Tonne treten. Die sagen nur wie viele Taktzyklen pro Sekunde der Prozessor schafft - das ist aber nur einer der Leistungsfaktoren, die die Gesamtleistung eines Prozessors ausmachen. Die Zahlen kann man daher kaum hernehmen, um Prozessoren verschiedener Prozessorarchitekturen zu vergleichen. Da sind eigentlich nur Benchmarks oder die theoretische Leistung in GFlops vergleichbar.

Für TrainFever ist es aber glaube egal ob AMD oder Intel-Prozessor - irgendwann kommen die Ruckler. Je nach Prozessor um verfügbarem RAM ist das das früher oder später. Bei mir geht's los, wenn in den Städten mehr als 10.000 Einwohner leben. Daraus schließe ich, dass die Berechnungen, die das Spiel macht, zu schlecht skalieren. Eigentlich hätte man das in der Entwicklung schon merken können, dass man die Engine eher auf 40.000-50.000 Einwohner hätte auslegen müssen, um im späteren Spiel noch ne brauchbare Performance zu haben. Ich hoffe echt, dass die Jungs das noch mit nem Patch hinbiegen können.

das Problem liegt daran, das TF sich nicht an die Kerne bedient sondern an einen oder zwei und die sich dann gut und gerne am Arbeitsspeicher bedienen. Mehr Leistung bedeutet die Rechenarbeit mehr auf die Kerne zu verteilen, hat unter anderem den Vorteil das die Temperatur nicht so hoch geht und zum anderen die Rechenleistung auf mehr Mikroprozessoren verteilt wird bzw. verbessert sich emens. Die GHz ist somit egal ob 1,2, 3 oder 4 Ghz, eine Steigerung heisst Parallelschaltung von Prozessoren. Solange dies nicht von TF geregelt wird, kann man sich stundenlang darüber unterhalten und es ist auch egal ob Intel oder AMD die tun sich nicht sonderlich viel, es sei denn man arbeitet mit CAD-Prgrammen,Videobearbeitung etc, dort sieht man wirklich was der jeweilige Typ vom Hersteller kann.

Neben einigen Wahrheiten schlagen auch viel Unwissenheit in diesem Thread große Wellen.

Aber eigentlich ist es auch Quarkegal woran es genau liegt... Aktuell gerät quasi jeder Prozessor ins Schwitzen wenn man sich dem Endgame nähert. Das RAM, GRAM oder auch eine beliebige andere Komponente vorher einknicken lässt sich durch Upgrades respektive niedrigere Grafik lösen, das Problem mit der CPU nicht. Da können nur die Entwickler ran.

Also ich haben folgende Konfigurationen:
Laptop (aus 2012):
Core I5 2410M // HD 6850M (Desktop äquivalent: HD 5770) // 4 GB DDR3 // HDD 5400 U/min

Rechner (in jährlicher Aufrüstung)
PH II X4 955 BE // R9 270X // 8 GB DDR3 // SSD

Und es ist halt so, dass mein Laptop im späten Spiel eine bessere Performance hinlegt als mein Rechner (gleicher Spielstand). Die CPU des Laptops hat einfach eine bessere Leistung pro Mhz. Anfangs spielen am Rechner die Grafikkarte und SSD ihre Geschwindigkeit voll aus; später wirkt sich das kaum noch aus, ein Kern des Phenom II ist voll ausgelastet. (Übrigens nutzt Trainfever bei mir - egal ob Rechner oder Laptop - nur einen Kern. Daher ist das Argument, Urban Games würde nur auf Intel optimieren, für mich hinfällig.)

Daher hab ich meinen PH II von 3,2 GHz auf 3,8 Ghz übertaktet. Und zack war es deutlich besser Spielbar.

Bei mir lastet TF definitiv zwei Kerne voll aus.

Das ist Kurios, denn es lastet bei mir definitiv nur einen Kern aus. Und das auf Intel + AMD.

Wie sieht dein System aus?

Edit: Screenshot angefügt

Nunja, ich kann nicht behaupten das mein Spiel noch flüssig läuft eher das Gegenteil ... , bin im Jahr 2228. (4. Mods, ne Lok, und zwei org. Fahrzeuge erweitert, und Gleismagnete, Texturen kann man ausschließen )

Steam mag keinen Debugger und lässt TF immer crashen, von außen kann man aber trotzdem etwas sehen.
TF hat eigentlich zwei Threads, 1. TF selber und 2. OpenAL. (Sound) (Die auch Arbeiten und nicht warten)

Am Monatsende wird ein neuer Thread erstellt.

Zwei Möglichkeiten:
a) Thread läuft, Spiel läuft weiter, Thread beendet. (Perfomance wird geringer)
b) TF bleibt mit einer harten Denkpause stehen, wenn der Thread fertig ist/geschlossen wird, geht auch TF weiter.

Wenn ich die Glaskugel nehme, würde ich auf den internen BuildingSimulator tippen, der als neuer Thread gestartet wird.
Es gibt einen Debug String in der Exe, BuildingSimulation::PrepareThreadData und nach dem hängen werden in einer Stadt meistens neue Häuser gebaut.

Zum Thema Threads. Sie sind kein Allheilmittel. Es scheint so das TF erstmal im Hauptthread Arbeitsdaten erschaffen muss. Der Hauptthread scheint nicht immer weiter arbeiten zu können, warum auch immer.
Das kann darin liegen, das ein Lock gehalten wird, es einen allgemeines Locking Problem besteht oder das Locking zu viel Zeit verbrät.

Bei meinem Test war der Thread gerade irgendwo in eine Listenfunktion und die Liste scheint mit "Ist Voll" Fehlern laut Stack beschäftigt zu sein, aber ohne Debugger der auch bei mehreren Threads Probleme bereiten kann ist das immer schwierig.

-edit-
Man kann vieles mit höhere Verarbeitungsgeschwindigkeit per CPU Kern erschlagen. Und ja, Intel Core iX CPUs haben eine höhere Single Thread Performance.

Hier ist meine Auslastung....

Ich spiele da grad auf einer kleinen Map.

...große Map, alle Siedlungen an das Bahnnetz angeschlossen, mittlerweile drei Städte mit mehr als 1000 Einwohnern, 15+ Bahnlinien, 50+ Züge, jedes Kaff ÖPNV plus LKW-Linien.
System: Laptop mit I7-Proz, Nvidia GT 650 M

Das ein zweiter Thread nur für bestimmte Berechnungen geöffnet wird kann durchaus sein.
Was mich nach genauerem Beobachten etwas verwirrt: Entweder schiebt Windows die Anwendung permanent zwischen den Kernen hin und her, oder TF nutzt alle vier Kerne.

Screen ohne TF

Screen mit TF

Was auch auffällt: Je dichter man hereinzoomt, je höher die Auslastung durch die Darstellung der Menschen.

Ja die Windows Anzeige hilft einem da meist leider gar nicht, da der Scheduler die Threads auf die Kerne verteilt.

Kirsche:
Das ist Windows. TF hat bei mir fast konstant einen CPU-Anteil von 25%, das sind von den 8 Kernen zwei von TF ausgenutzte. Im zweiten Screenshot von Dir ist die CPU zu 50% beschäftigt - macht zwei von deinen vier Kernen. Das 'rumreichen über alle Kerne liegt am Windows-Scheduler.

PS: Vielleicht hilft es unter Windows ein wenig, die Prozessor-Affinität für TF im Task-Manager anzupassen (siehe https://en.wikipedia.org/wiki/Processor_affinity). Bei häufigem Wechsel von Threads/Prozessen auf einen anderen Kern ist der ganze Cache-Klapperatismus für den Eimer. Müsste mal ein Windows-Benutzer ausprobieren, ob es etwas bringt...

Tom: Bei Coretemp siehst du die derzeitige Auslastung der einzelnen Kerne.

Ich habe mal ein bisschen getestet die letzten Minuten.
Nachdem ich TF zwei feste Kerne zugeordnet hatte waren diese fast permanent zu 100% ausgelastet.

Nachdem ich einen dritten zugewiesen habe, verteilte sich die Auslastung wieder.

Wie es scheint öffnet und schließt TF permanent neue Threads.
Einen Leistungsunterschied konnte ich durch die manuelle Zuweisung allerdings nicht feststellen.

Kirsche:
Ich weiss jetzt nicht, ob TF permanent Threads erzeugt und wieder entsorgt - das wäre suboptimal. Ein Thread-Pool wäre da effektiver.
Da aber eh nur zwei Kerne ausgereizt werden, ist TF nicht "multithreaded". Bei einem Programm, das gut parallelisiert und entsprechend
mehrere Kerne nutzt, verteilt sicht die Last "gleichmäßig" über alle Kerne bzw. alle Kerne müssten bei CPU-intensiven Programmen zu 100% ausgelastet sein.

Unter dem von mir genutzten Ubuntu/Linux 14.04.1 hängt TF auch nicht permanent auf den gleichen Kernen. Es wird auch gewechselt - aber seltener
und während einer "kurzen" Beobachtung nicht über alle Kerne.

War auch nur 'ne Idee - ob das mit der Prozessor-Afinität etwas bringt, hängt vom jeweiligen Programm ab...

Ich hatte, um zu verdeutlichen, dass TF nur auf einem Kern läuft, dem Prozess "Trainfever.exe" nur 2 der 4 Kerne zugewiesen. In diesem Fall gibt es auch kein großes springen der Last, Leistungszugewinne sind aber erst mit der Änderung der Priorität des Tasks auf "Echtzeit" zu sehen.

Wenn ich so sehe, wie Trainfever bei euch auf 2 Kernen läuft, werde ich schon neidisch.

Ähm - Fussel, kann es sein, dass Du den Screenshot mit TF im Pause-Modus gemacht hast? Dann brauchts bei mir nämlich auch nur einen Kern...

Der 2. Thread wird ja wie beschrieben (offensichtlich) immer nur ein mal pro Monat angeworfen. Und wenn der durch ist, ist er halt durch. Wenn er es innerhalb des Monats nicht schafft alles abzuarbeiten hat man die schon bekannten Ruckler am Monatsende. Das ist schon seit immer so und auch leicht nachvollziehbar wenn man auf 4facher Geschwindigkeit am Monatsende warten muss, auf normaler Geschwindigkeit aber nicht. (Da Dauer der Monat ja länger.)

Wenn man in der Pause (oder auch ganz früh im Spiel) die Last ansieht, ist da natürlich viel Leerlauf.

Zitat von Tom

Ähm - Fussel, kann es sein, dass Du den Screenshot mit TF im Pause-Modus gemacht hast? Dann brauchts bei mir nämlich auch nur einen Kern...

Nee, das war ganz normal während des Spielens, der Taskmanager und CoreTemp liefen auf dem 2. Bildschirm prarallel.

Für genaue Aussagen müßte man den Code kennen und Ahnung haben.
Es ist also ohnehin nur stochern im dunkeln.