TpF2 Performance niedrig - Aber PC nicht ausgelastet. Wie geht das?

Ich habe ähnliches beobachtet. Auf "grössenwahnsinnig"-Karten ist mein RAM bei 34/64gb und auch die CPU und GPU Auslastung ist noch weit vom Limit. Aber: Wenn man die einzelnen Kerne der CPU beobachtet sieht man, dass einer am limit läuft und alle andern nicht, das liegt daran, dass TF2 immer nur einen Prozessor-Kern braucht. Das ist durch die Engine limitiert und die Devs haben gesagt dass sie nicht garantieren können, dass sich das mit TF3 ändern wird...
Zur GPU habe ich gesehen, dass die Auslastung in % zwar im mittleren Bereich war, aber meine 8GB VRAM immer zu mindestens 7.2GB ausgelastet waren.

Ich kann mir vorstellen, dass bei dir die CPU der Bottleneck ist weil nur ein kern gebraucht wird

Es ist wie Jony geschrieben hat, Windows zeigt halt die durchschnittliche Auslastung aller Kerne gemeinsam an.

Bei mir lastet TPF2 aber die CPU auch zu 40-50% aus. Es kommt da auch immer auf die Szenerie an, welche gerade auf dem Bildschirm läuft.

TPF2 parallelisiert schon ganz gut, nur muß eben alles auf den Hauptthread warten.

Wenn ich das mal so richtig überschlage, hast du eine Einwohnerzahl von 80-100k, da läuft jede CPU ins Limit.

Ich hatte auch mal ca. 110k Einwohner, daß war nur noch Gestotter.

Habe die Einwohnerzahl dann auf etwa 70k reduziert und es lief wieder relativ flüssig.

Die Zahl der Linien spielt jedoch auch eine entscheidende Rolle. Je mehr Linien, desto mehr Fahrtmöglichkeiten. Das muß alles berechnet werden.

Bei mir ist es mittlerweile so, jede neue Linie erhöht das Stottern merklich. Ich habe also den Spot bei dem es grade noch ohne Ruckeln läuft erreicht.

Es gibt bei den Linien natürlich auch Unterschiede. Eine Güterlinie zwischen zwei Industrien ist rechentechnisch eher zu vernachlässigen. Ein Personenlinie zwischen zwei Städten wo über andere Linein schon zig Fahrmöglichkeiten existieren, erfordern einen ganz anderen Rechenaufwand.

Hier hast du mal meine Statistik.

Zitat von Kirsche

TPF2 parallelisiert schon ganz gut, nur muß eben alles auf den Hauptthread warten.

Und genau da setzt die Windows-API ihre Grenzen. Alle Ereignisse die mit dem Spielefenster verbunden sind lassen sich nicht parallel abarbeiten. Da sind Fenster- und Ereignis-Manager außerhalb der Microsoftt-Welt besser geeignet. Aber das war auch schon bei der Einführung von Windows vor über 40 Jahren der Fall.

Die Windowsanzeige ist da sehr schwammig. Du mußt bedenken das die Threads die Kerne wechseln um eine gleichmäßige Abnutzung zu erreichen. Sonst würde irgendwann ein Kern komplett physisch abgenutzt sein, während andere wie neu sind. Daher sieht es so aus als ob alle nur wenig ausgelastet sind.

Wenn du mal das Ryzen Master Tool benutzt, da kannst du das besser sehen.

Die Threads welchseln die Kerne mitunter halt in Sekundenbruchteilen, je nachdem wie lange die Abarbeitung dauert.

Reduziere die Anzahl der Sims auf Werte bis 50-60K, da hast du mit moderner Hardware keine Probleme, auch nicht bei Grössenwahnsinnig. Alles was über diesen Wert hinausgeht, zwingt auch die beste CPU in die Knie.

TPF2:

Zwei Haupt Threads, diese verzweigen sich in weitere Threads: (Dann gibt es noch was für Sound, Stadtwachstum)

GameState 1 und GameState 2.

Einer wird zur Anzeige / Rendern benutzt, der andere errechnet gerade den nächsten Simulationsschritt, dieses ist eine sehr vereinfachte Darstellung.

Simulationsschritt:

• cmds abarbeiten, etwaigen status speichern.
• GameState berechnen:
  • Alle System ( zum Beispiel TrainMovement) werden abgearbeitet: Irgendwas::Update
    • Ein System kopiert etwaigen Status für bestimmte Sachen, macht X Threads auf, erarbeitet eine Liste was geändert werden soll
    • Warten bis alle X Threads fertig.
    • Dann wird die Liste angewendet:
      • Notify der anderen Systemen. ComponentAboutToBeChanged
      • Entity Komponente wird geändert
      • Notify der anderen Systemen: ComponentChanged
  • GameState (Simulation) LUA Script aufrufen. (read only)
• Änderungen in andere GameState kopieren

Anderer Hauptthread:

GameState rendern, UI aufbauen usw, Labels berechnen

• Warten auf neue Daten (GameState)
• ConstructionBuilder (macht einen Thread auf um die Blaupause des Bahnhofs zu bekommen)
• Cmd propagieren
• Cmds in eine Liste packen
• LUA GUI GameScript aufrufen
• Renderliste bauen

Um so mehr Arbeitsspeicher verbraucht wird (und Cache Misses passieren ) um so schwieriger wird es.

Sehr schneller stabiler Arbeitsspeicher hilft... Mehr Kerne gar nicht, schnellere um so mehr. Zwei CCDs zu haben ist kontraproduktiv...

Ein paar Sachen. LUA ist nicht nebenläufig. In Lua eine coroutine aufmachen bringt von der Geschwindigkeit gar nix.

Die LUA API für Entities dürfen keine Pointer über GameScript Funktionsgrenzen halten. Nach einem Durchlauf kann die Position im Speicher für ein Entity komplett woanders liegen, da nach einem Simulationstick die Daten ggf. geändert wurden sind...

Hab das Spiel gestern auch wiedermal angezockt auch mit einer Grössenwahnsinnig Karte allerdings mit 800 Mods.Alles mit sehr hohen Einstellungen.Nutze 64 GB DDR5-6400 Ram mit einem Ryzen 9 99....d und weiterem Schnickschnack.348.1 mittlere FPS alles schön und gut bis an error just occured auftritt mit einem Blackscreen.Andere Spiele wie ANNO,City Skylines II,Train Sim World 6 etc.funktionieren ohne Probleme.

Der Error wird aber eher an irgendeinem Mod liegen als an TPF.

Kirsche Vielen Dank,für die Antwort,dann werde ich mich mal auf die Suche machen.

mandigritsch Genaues kann man natürlich erst anhand der stdout.txt herausfinden.

Kirsche Hab den Fehler gefunden,so ein Japanischer Mod machte Ärger.

HWinfo ist auch gut, kommt in dem Fall auf die Aktualisierungsrate an.

Bei HWinfo sollte es eigentlichauch auffallen, immer wenn die Frequenz eines Kerns einsackt ist er im Idle.

Nur wurd der Zustand fast immer schneller gewechselt als die Aktualisierungsrate der Tools anzeigt.