Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Performanceprobleme
#31
Ich habe das gerade noch mal ausprobiert: Wenn Simutrans nur auf einem Kern ausgeführt wird, wirken Drag-and-Drop-Aktionen flüssiger (also z.B. Gleisbau durch ziehen), und die kleine "Denkpause", bis beim Scrollen die Karte/das Bild bewegt wird, ist weg bzw. deutlich verkürzt.
Zitieren
#32
Ich denke mal, hier kommen wir langsam in die technische Ebene. denn ein schneller Prozessor, oder auch 2 bis 6 Kerne können nur so gut umsetzen wie es die angehangene Grafikkarte zulässt. Und vor allem auch wie schnell das jeweilige board darunter alles umsetzen kann. Ja, der Datenfluss zwischen den Units ist meist von der boardarchitektur begrezt.

anders gesagt: ein neuer rechner geht schon deshalb flüssiger weil er hardware technisch erlaubt daten wesentlich schneller zu transportieren.
ein alter rechner mit neuer CPU stösst zwangsweise an seine grenzen da ihn die zugrundeliegende architektur begrenzt.

Daher sind alle tipps für viele sehr hilfreich; für manche leider nicht :-(
sie können jedoch nicht allgemeingültig sein; dabei rede ich noch gar nicht mit wie vielen nebenprozessen so manche rechekiste sonst noch belastet wird....

PS: oh-ha, mir ist klar das dieser kommentar so das eine oder andere unbehagen auslösen wird - na dann, haut mal darauf los ;-)
Ich spiele: PAK 128. German
Zitieren
#33
Zitat:Original von BR84
Ich denke mal, hier kommen wir langsam in die technische Ebene. denn ein schneller Prozessor, oder auch 2 bis 6 Kerne können nur so gut umsetzen wie es die angehangene Grafikkarte zulässt. Und vor allem auch wie schnell das jeweilige board darunter alles umsetzen kann. Ja, der Datenfluss zwischen den Units ist meist von der boardarchitektur begrezt.

anders gesagt: ein neuer rechner geht schon deshalb flüssiger weil er hardware technisch erlaubt daten wesentlich schneller zu transportieren.
ein alter rechner mit neuer CPU stösst zwangsweise an seine grenzen da ihn die zugrundeliegende architektur begrenzt.

Daher sind alle tipps für viele sehr hilfreich; für manche leider nicht :-(
sie können jedoch nicht allgemeingültig sein; dabei rede ich noch gar nicht mit wie vielen nebenprozessen so manche rechekiste sonst noch belastet wird....

PS: oh-ha, mir ist klar das dieser kommentar so das eine oder andere unbehagen auslösen wird - na dann, haut mal darauf los ;-)
Ich würde sagen, für Simutrans ist es nahezu egal, wie schnell und gut die Grafikkarte ist und wie schnell das Mainboard irgendwelche Daten transportiert. Einzig der Prozessor zählt, da der die Simulation ausführt.
Zitieren
#34
Simutrans ist gerade darauf angewiesen, wie schnell der Speicherzugriff ist. Wir reden hier von Karten in 256 MB Größe und mehr, die im allgemeinen nicht in den Cache passen ... Außerdem muss alles vom SPeicher in die Grafikkarte befördert werden (es sei denn, da wäre ein Onboardchip). Das ist oft auch ein Flaschenhals.

Ich vermute immer noch SDL als Auslöser des Problems, speziell wenn GDI besser geht. Mal eine Allegro-Version probiert?
Zitieren
#35
Zitat:Original von prissi
Simutrans ist gerade darauf angewiesen, wie schnell der Speicherzugriff ist. Wir reden hier von Karten in 256 MB Größe und mehr, die im allgemeinen nicht in den Cache passen ... Außerdem muss alles vom SPeicher in die Grafikkarte befördert werden (es sei denn, da wäre ein Onboardchip). Das ist oft auch ein Flaschenhals.
Aber wie oft muss den jedes einzelne MB dieser Karte gelesen werden? Selbst der langsamste DDR-RAM hat eine Übertragungsrate von (im Idealfall) 1,6 GB/s...

Zitat:Ich vermute immer noch SDL als Auslöser des Problems, speziell wenn GDI besser geht. Mal eine Allegro-Version probiert?
Wie ich schon sagte, ich habe bisher keinen Unterschied zwischen SDL und GDI feststellen können, aber auch noch keine näheren Vergleiche in Bezug auf die von mir hier beschriebene Lösung angestellt.
Was ist denn die Allegro-Version?
Zitieren
#36
Naja, DRAM mit 1.6 GBs gilt nur wenn man einen 256 Byte großen Bereich aus einer aktivierten Cacheline anfordert. Wenn der Bereich nicht genau so groß ist, evnt. verstreut aus dem Speicher kommt, dann ist man seit fast zehn Jahren bei 30-40ns pro Datum, also by Bytes im schlechtesten Fall bei 95 MB pro Sekunde.

Moderne Prozessoren haben auch noch mehr als einen Prozess am laufen => noch weniger Platz in den Caches => noch eher das Problem. Die Fahrzeuge in Simutrans sind z.B. in einer Liste sortiert. Das heißt, dass für pro Zugriff auf ein Fahrzeug mindestens zwei Cachemisses dabei sind.

Angehängt ist eine Allegroversion. Die Fenstergröße musst du hier vor dem Start angeben.


Angehängte Dateien
.zip   sim.zip (Größe: 991,5 KB / Downloads: 218)
Zitieren
#37
Beim Start erscheint zwar eine Meldung "Could not init Allegro", aber das Spiel startet dennoch. Bei der Grafikpak-Auswahl wird kein Mauscursor angezeigt, die Performance ist deutlich schlechter als bei GDI, beim Zoomen gibt es eine deutlich spürbare Verzögerung.
Der Mauscursor wird sehr hakelig gerendert, insgesamt nicht schön zu bedienen.

Insgesamt scheint die SDL-Version auch in bestimmten Situationen eine höhere Framerate zu bieten (in mittleren Zoomstufen), aber bei der kleinsten Zoomstufe (voll herausgezoomt) ist das Programm nahezu unbedienbar (Bildrate bei ca. 5, Simloops unter 2) (SDL scheint die Mausbedienung auch nicht seriell zu verarbeiten, wenn man sich zu einem Bedienelement "hingelaggt" und klickt, aber der Mauszeiger noch unterwegs ist, wird der Klick unterwegs registriert).
Unterschiede, ob Simutrans auf einem oder zwei Kernen ausgeführt wird, habe ich nur bei der GDI-Version bemerkt.

Vielleicht ist noch wichtig zu sagen, dass ich nur einen "einfachen" Athlon II habe, also keinen shared Cache, sondern nur 1MB L2-Cache pro Kern.
Zitieren
#38
Als ich gerade nachschaute, ob mein Prozessor wirklich keinen shared Cache hat, ist mir aufgefallen, dass Cool&Quiet an ist (automatisches Herabsetzen des Multiplikators abhängig von der Prozessorauslastung).
Ich hab das nun mal testweise abgeschaltet, und Simutrans läuft wirklich deutlich fitter, in allen Versionen (auch wenn die Allergro-Version am langsamsten ist).
Das wird vermutlich auch der Grund sein, warum es beim Binden an einen Kern besser lief, weil die beiden Threads den Kern "auf Trab" gehalten haben.

Wie ist das denn bei anderen Programmen, da habe ich solche Einbußen nicht festgestellt, melden die dem Betriebssystem, dass es den Takt oben halten soll?

Vielleicht kannst Saegge auch mal ausprobieren, ob bei ihm auch Cool and Quiet an ist, und ob es nach dem Abschalten besser wird.
Zitieren
#39
Zitat:Original von pETe!
Insgesamt scheint die SDL-Version auch in bestimmten Situationen eine höhere Framerate zu bieten (in mittleren Zoomstufen), aber bei der kleinsten Zoomstufe (voll herausgezoomt) ist das Programm nahezu unbedienbar (Bildrate bei ca. 5, Simloops unter 2)

wird es auch nicht besser wenn du nach dem Voll-Rauszoomen ein bisschen wartest?
Zitieren
#40
Der Mauszeiger bei SDL hackelt so, weil es keinen gibt, sondern Simutrans dort die Maus selbst malen muss. (Gibt schon Gründen, was Allegro nicht die Hauptversion ist.)

Das mit dem Throttln macht Sinn. Durch die Bindung an einen Kern, kann dieser Hochtakten. Das geht beim ständigen Wechsel nicht, da dann zwei Kerne aktiv sind.
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste