hallo,
ich weiß ja, dass ich mal wieder ein altes Thema aufwärme, würde aber doch ganz gern einen Status erfahren, wie's denn mit der 64Bit-Unterstützung im Moment aussieht.
Zudem kommen ja immer mehr Rechner mit DualCore oder gar QuadCore daher. Macht simutrans inzwischen irgendwo Multithreadding, sodass es von solchen Prozessoren profitiert?
Also ich fasse mal prissi's Aussagen dazu - soweit sie mir bekannt sind - zusammen:
64 Bit: Kann man auch jetzt schon so kompilieren, wäre aber wahrscheinlich deutlich langsamer als 32 Bit, da es dafür einfach nicht gemacht ist.
Multithreading: So ohne weiteres nicht möglich, da zuviele "Prozesse" (mein laienhafter Ausdruck) zeitlich exakt geregelt hintereinander folgen (müssen) was sich bei verschiedenen Threads nicht so einfach hinbekommen läst (wenn überhaupt) ohne das die Vorteile sich wieder in Luft auslösen.
Kurz gefasst: ein "nein, geht nicht / bringt nichts" für beides.
Wie gesagt: zumindest habe ich prissi's Aussagen diesbezüglich so verstanden.
Thread für euch erledigt? Soll ich ihn verschieben?
naja, die Idee war damals, Spiel und Anzeige zu trennen
Dazu wird wohl nur prissi was sagen können. Also warten wir ab und lauschen.
Sehr einfach: Es geht nicht wirklich, das die Prozesser voneinander abhängen. Zumindest nicht wirklich gut.
Die Fahrzeuge werden pro Bildschirmupdate bewegt. Wenn jetzt ein Fahrzeug an eine Kreuzung kommt, dann sieht es nach, ob die Kreuzung frei ist und fährt dann weiter. Das geht natürlich nur gut, solange nicht ein zweites Auto just eben diese Kreuzung auch ins Visir nimmt, die noch als frei seiht und ebenfalls weiterfährt.
Schlimmer noch wird die Sache bei Flugzeugen, Choose signalen usw. die dann eventuell zweimal die gleiche Auswahl treffen. Außerdem ist die Wegsuche aus Speicherverbrauchsgründen nur einmal implementiert.
Das alles könnte man zwar auch Multicore umstricken, aber vorher wäre gescheiter Netzwerksupport sinnvoller. (Und die Karte, die auch modernen Rechnern (die allein ja von sowas profitieren würden) nicht mehr vernünftig läuft, die möchte ich erst einmal sehen.
64Bit ist übrigens langsamer, da es mehr Speicher für Objekte braucht und somit öfters der Cache alle ist. Auch sind dann die Assemblerroutinen für Text und GRafik deaktiviert. Alles in allem würde ich von 64Bit abraten, wenn es nicht zwingende Gründe dafür gibt.
hmmm...
arbeitet simutrans überhaupt aligned? Ansonsten sind ja nur die Register Breiter bzw. die Datenschaufelei funktioniert breiter.
Das Thema Assembler-Routinen ist natürlich ein Punkt. Wie sieht der vergleich dabei eigentlich aus? Schliesslich benutzt die Mac-Version die doch auch nicht, oder?
Die Idee im Multithreadding war eigentlich den Bildschirmaufbau vom kompletten Step zu trennen. Ich weiss nicht, ob das wirklich was bringt. Man könnte aber beispielsweise auch über die Passenger-Generierung nachdenken.
Soweit ich weiss ist SDL intern gethreaded, d.h. das Kopieren des Puffers ins VRAM sollte in einem eigenen Thread augeführt werden. (War zumindest so mit den alten SDL Versionen unter Linux wenn ich mich richtig erinnere).
Die Fahrzeugpositionen werden nur unmittelbar vor einem Bildschirmupdate bewegt. Ansonsten hat Simutrans zwei Routinen, die eine für langsame längere Sachen, die immer mal wieder von der schnellen für eine Bildschirmupdate unterbrochen werden kann. Die langsamere macht dabei Sachen wie Be- und Entladen, Wegsuche usw. und ist die, die eigentlich am meisten Rechenkraft braucht.
Aber wie gesagt, auf Maschinen, die mehr als einen Core haben, steht es genügend Rechenleistung selbst für 2048*2048 Karten zur Verfügung, genügend Hauptspeicher vorausgesetzt (und größer ist eh nicht wirklich vollständig erschließbar, denke ich, bis ich einen Gegenbeweis gesehen habe.)
Das Problem bei 64Bit ist, dass viele Strukturen aufgeblasen werden, da ein Byte auf einer 8Byte Grenze ausgerichtet wird. Versuche es mal selbst mit "simutrans -sizes" und sieh den Unterschied zwischen 64 und 32 Bit. Das ganze mal 10^6 bzw 3*10^6 für Bäume und du wirst sehen, dass da 20% mehr Speicher durch den Cache gejagt werden muss.
Der Assembler macht weniger als 20% in der Routine bzw. 3% des gesamten Ablaufes. Das ist weniger kritisch, Rumkopieren optimiere heutige Compiler eigentlich ganz gut (weil das auch sehr einfach geht).
Zitat:Original von hellmade
...
Die Idee im Multithreadding war eigentlich den Bildschirmaufbau vom kompletten Step zu trennen. Ich weiss nicht, ob das wirklich was bringt. Man könnte aber beispielsweise auch über die Passenger-Generierung nachdenken.
Wäre es dann nicht sinnvoller, den Bildschirmaufbau in die Grafikkarte auszulagern?