Deutsches Simutransforum
Performanceprobleme - Druckversion

+- Deutsches Simutransforum (https://www.simutrans-forum.de/mybb)
+-- Forum: Simutrans (https://www.simutrans-forum.de/mybb/forumdisplay.php?fid=3)
+--- Forum: Bugs und Probleme (https://www.simutrans-forum.de/mybb/forumdisplay.php?fid=11)
+--- Thema: Performanceprobleme (/showthread.php?tid=6272)

Seiten: 1 2 3 4 5


- dom700 - 19-11-2011

Ich sage besser nicht wie weit mein XC Spiel ist Wink


- pETe! - 03-12-2011

Achso, ich wollte hier bezüglich des Problems noch folgendes mitteilen:
Wenn man die Prozesszugehörigkeit von Simutrans auf einen Prozessorkern festlegt und scrollspeed auf 2 stellt, lässt es sich wieder deutlich angenehmer bedienen.


- Saegge - 03-12-2011

kann pETe!s Lösung so unterschreiben. Funktioniert wirklich weitaus angenehmer


- pETe! - 03-12-2011

Zumindest der Tipp mit dem Prozessorkern kommt nicht von mir, sondern von The Transporter Wink
Weiß jemand, wie man das fest einstellen kann (per Batch-Datei oder so), dass man das nicht jedes mal im Taskmanager zuweisen muss?


- prissi - 04-12-2011

Was ist den scrollspeed? Meinst du die entsprechende Kommandozeilenoption?

Mir ist auch völlig schleierhaft, wie der Prozessorkern da was richten kann. Das scheint wirklich stark auf irgendein Lock in der SDL hinzudeuten.


- Saegge - 04-12-2011

Gerade ältere Spiele haben das auch gerne mal, dass die auf dual- oder quadcore nicht vernünftig laufen. Kann dir zwar nicht sagen woran das genau liegt, aber ich aktzeptiere das mittlerweile einfach so.
Is hier wahrscheinlich ähnlich


- pETe! - 04-12-2011

Zitat:Original von prissi
Was ist den scrollspeed? Meinst du die entsprechende Kommandozeilenoption?

Mir ist auch völlig schleierhaft, wie der Prozessorkern da was richten kann. Das scheint wirklich stark auf irgendein Lock in der SDL hinzudeuten.
Scrollgeschwindigkeit in den Anzeigeoptionen.
Ich benutze momentan allerdings die GDL-Version. Vermutlich kommt das zuckeligere Scrollen durch das hin-und-herschalten des Programms auf die beiden Prozessorkerne (Windows macht das ja ganz gerne).


- The Transporter - 04-12-2011

Windows läßt die laufenden Prozesse immer von einem zum nächsten Kern "hüpfen", dadurch geht relativ "viel" Zeit verloren. Ein Programm fest an einen Kern binden schafft da Vorteile.

Zitat:Gerade ältere Spiele haben das auch gerne mal, dass die auf dual- oder quadcore nicht vernünftig laufen.
Das hängt eigentlich nur von der Singlecore Leistung eines Prozessors ab. Ältere Programme nutzen nur einen Kern. Wenn dann der Takt vom Prozessor niedrieger liegt, als bei einem alten Singlecore, dann leidet auch die Performance solcher Programme darunter.
Auch wenn Windows die Programme durch alle Kerne schiebt, es wird immer nur einer zur Zeit genutzt, nicht 2 oder mehrere zur selben Zeit. Bei den alten Programmen helfen eigentlich nur viele (Giga)Herz.


- prissi - 05-12-2011

Für die das Kopieren eines Bildes auf den Schirm nutzt allerdings Simutrans gerade den zweiten Prozessorkern. Insofern sollte mit Bindung an einen Kern alles eher langsamer werden. Außerdem transferiert Windows Prozesse eh nur zwischen Kernen, wenn ein Systemaufruf oder der KErnelinterrupt erfolgte. In beiden Fällen muss eh der Stack und die Register wieder hergestellt werden. Das sollte egal sein (mal von Level1 Caches abgesehen) auf welchem Kern das passiert. (Die Daten sollten ja im gemeinsamen Level 2/3 cache sein.)


- pETe! - 05-12-2011

Zitat:Original von prissi
Für die das Kopieren eines Bildes auf den Schirm nutzt allerdings Simutrans gerade den zweiten Prozessorkern. Insofern sollte mit Bindung an einen Kern alles eher langsamer werden. Außerdem transferiert Windows Prozesse eh nur zwischen Kernen, wenn ein Systemaufruf oder der KErnelinterrupt erfolgte. In beiden Fällen muss eh der Stack und die Register wieder hergestellt werden. Das sollte egal sein (mal von Level1 Caches abgesehen) auf welchem Kern das passiert. (Die Daten sollten ja im gemeinsamen Level 2/3 cache sein.)
Bist du dir da sicher? Ich vermute, dass Windows nach jedem Prozesswechsel erneut entscheidet, auf welchem Kern der Thread ausgeführt wird. Natürlich hast du recht, es sollte mehr oder weniger egal sein, ob der Prozess dann auf dem ersten oder zweiten Kern aufgebaut wird, aber scheinbar versucht Windows, wenn ich einen Prozess an einen Kern binde, den ganzen Rest auf dem zweiten Kern aufzubauen, das würde dann ja das Neuaufbauen des L1-Caches und der Register ersparen (auch wenn das eigentlich verschwindend gering sein sollte, als ich noch Informatik studiert habe, hab ich in einer Vorlesung mal 100 Takte als Faustregel gehört).
Es kann aber auch sein, dass die subjektiv schlechtere Performance durch unregelmäßiges reagieren hervorgerufen wird, und das durch das Binden an einen Kern etwas stabilisiert wird.