konnte man nicht zumindest im gcc das alignment komplett auf 1 stellen?
-falign-labels=n
-falign-loops=n
-falign-jumps=n
-mstack-align
-mno-stack-align
-mdata-align
-mno-data-align
-mconst-align
-mno-const-align
-m32-bit
-m16-bit
-m8-bit
-mpreferred-stack-boundary=num
Welche Standardroutinen kommen denn nicht mit:
-fpack-struct[=n]
klar?
Alle Dateiroutinen, denn die Structs dort werden vom Betriebssystem reinkopiert. Dann hätten wir das noch die Zeitverwaltung und unter Windows noch 300 weitere Structs. Hatte ich mal als Bug gemeldet für mingw, wurde aber nicht wirklich als ernst erachtet, da ja steht, dass sowas passieren kann.
Und vor allem wird Simutrans, wenn man all die Alignments ausmacht noch viel langsamer im 64Bit Modus. Und die Pointer bleiben 8 Byte, also selbst aligned sind ca. 20% mehr Speicherverbrauch nötig.
Und der Stack muss alingned bleiben, sonst gibt es mit return arge Probleme (und auch jedes this und jedes Unterprogramm schmeisst 8 Byte statt 4 auf den Stack.)
nur warum findet ein pause(2) Aufruf stat, wenn ich das Spiel verlangsamme, müssten dann nicht die Pause Zeit grösser werden?
@Speicher warten wir einfach noch 2 Jahre, dann ist Speicher in solchen Massen und Geschwindigkeiten so günstig verfügbar, das ne 64 bit Version von Simutrans eh Std ist.
Wobei sich die Spieler wohl fragen was sie mit ihren anderen 7 Cores machen sollen :-)
heisst also, dass die structs im Windows aligned sind? *bah*
naja, seis drum, brauchen wir also einen Prozessor bei dem das gesamte Programm samt Daten in den Cache passt *g*
Zitat:Original von gpmfuchs
nur warum findet ein pause(2) Aufruf stat, wenn ich das Spiel verlangsamme, müssten dann nicht die Pause Zeit grösser werden?
Wenn man knapp an der Leistungsgrenze des Prozessors ist, dann kann es vorkommen dass die Wartezeiten kleiner sind als erwartet, weil Simutrans dann imer noch versucht möglichst viel Rechenleistung zu bekommen. Wenn größreer Reserven da sind sollte die Wartezeit linear anwachsen.
Zumindest die alten Versionen liessen sich bei mir so einstellen dass ich mit etwa 30% Prozessorlast spielen konnte und noch reserven für andere Dinge hatte. Das hiess für mich allerdings auch dass 800x600 Pixel Auflösung und 128x128 Felder Kartengröße schon ziemlich am Limit waren.
Simutrans müsste die Wartezeit "idle" anzeigen, früher war das im Display-Options dialog.
Simutrans macht maximal 10ms Wartezeit, denn diese dauern bis zum 25ms (je nach Betriebssystem). D.h. bei 25 frames pro Sekunde wartet Simutrans 10,10,5 (oder entsprechend kürzer, wenn es mehr zu tun gibt.)
Und ein letztes zum Speicher. Das planquadrat besteht aus zwei pointern einem short int und zwei bytes. Macht unter 32Bit 4+4+2+1+1 = 12 Bytes. Unter 64Bit sind es 8+8+2+1+1 = 20 (bzw. auch 24 Byte je nach alignment) als im besten Falls ein plus von 66%. Somit passen 66% weniger planquadrate in den cache. Und so weiter.
D.h. unter Simutrans wird der Vergleich 64Bit zu 32 Bit immer zugunsten von 32 Bit enden (gleicher Prozessor vorausgesetzt.)
Und so bleibt Simutrans eines der wenigen Programme die mich zwingen, 32bit Unterstützung in mein System einzubauen....
Naja, wenn die Kiste schnell genug ist und genug Speicher hat und du 32735*32735-Karten Spielen willst (geschätzt ca. 36 GB Kartengröße) wirst du um 64Bit nicht herumkommen ...
hmmm...
ich habe vorhin mal versuch eine Version zu bauen. Compilieren war kein Problem, aber der folgende Absturz *g*
Es ist also mit "nur mal neu compilieren" bei simutrans nicht getan
Da im englischen Forum mehrer Personen 64Bit benutzen, muss ich den Fehler leider bei dir vermuten ... oder was meinst du?