Archiv verlassen und diese Seite im Standarddesign anzeigen : Nachträglich Engine verändern?
BS-Virus
2005-07-21, 07:58:37
Hallo zusammen :)
Vorab möchte ich nur kurz erwähnen, daß mein bisher größter Programmiererfolg "Hello World" war. Nur damit jeder weiss wieso ich eine solche Frage überhaupt stelle. ;)
Also ich würde gerne wissen ob eine fertige Spiele-Engine nachträglich mit Support für Dual-Core bzw. mit Multithreading erweitert werden könnte?
Ist das generell Blödsinn oder ist es erschwert möglich oder eigentlich gar kein so großes Problem? :|
Danke und Grüße
v!
Ganon
2005-07-21, 08:04:44
Das hängt ganz von der Engine ab.
Eine Engine die bisher so programmiert ist, das sie >wirklich< alles in einem Thread macht, ist sicherlich schwerer anzupassen, als eine die schon in Threads geteilt ist (was ja nicht gleich "Multi-CPU-Support" bedeutet).
Monger
2005-07-21, 08:55:28
Richtig. Eine Engine die bereits Multithreading verwendet (was aber anscheinend überhaupt noch nicht weit verbreitet ist), kommt sowohl mit Hyperthreading als auch Dual Core gut zurecht.
Unter C++ (worin ja die meisten Spiele geschrieben sind), scheint das nicht ganz unkompliziert zu sein. Java und andere junge Sprachen erleichtern die Threadprogrammierung schon spürbar.
So oder so: was altes entsprechend anzupassen, halte ich für ziemlich aufwendig. ZU aufwendig. Lieber eine Engine gleich neu schreiben...
BS-Virus
2005-07-21, 09:49:25
Danke schonmal für eure Antworten! :up:
als eine die schon in Threads geteilt ist (was ja nicht gleich "Multi-CPU-Support" bedeutet).
Ööööhm, wie muss ich denn das jetzt wieder verstehen? Gibt es da noch eine spezielle Anpassung? :|
Monger
2005-07-21, 11:12:23
Danke schonmal für eure Antworten! :up:
Ööööhm, wie muss ich denn das jetzt wieder verstehen? Gibt es da noch eine spezielle Anpassung? :|
Die JAVA VM (und .NET afaik auch) verteilt die Threads automatisch auf verschiedene CPUs/Cores. Bei C++ muss man das von Hand machen.
Legolas
2005-07-21, 11:27:33
Danke schonmal für eure Antworten! :up:
Ööööhm, wie muss ich denn das jetzt wieder verstehen? Gibt es da noch eine spezielle Anpassung? :|
Wenn sich die Threads so blockieren, daß immer nur einer aus Syncronitätsgründen laufen kann, dann ist die Anwendung zwar multithreaded, aber zieht aus mehreren CPUs/Kernen keinen Nutzen, da immer nur ein Thread davon laufbereit ist.
Nur so als Beispiel. :)
BS-Virus
2005-07-21, 11:56:48
Ok. Also unterm Strich ist eine solch nachträgliche "Erweiterung" nicht so eben zu bewerkstelligen, richtig!?!
Ich hätte einfach mal gehofft, daß viele der Spieleentwickler sich einen Ruck geben und aktuelle Spiele in der Hinsicht nachträglich noch optimieren. Aber das sieht dann wohl eher nich so doll aus. :frown:
Danke für´s Erklären!
Grüße
v!
Neomi
2005-07-21, 12:07:42
Unter C++ (worin ja die meisten Spiele geschrieben sind), scheint das nicht ganz unkompliziert zu sein. Java und andere junge Sprachen erleichtern die Threadprogrammierung schon spürbar.
Multithreading ist unter C++ ebenfalls kein Problem, zumindest die Threadsteuerung (starten, beenden, synchronisieren, ...) nicht. Das, was daran so schwer ist (bzw. sein kann, mit dem richtigen Konzept lassen sich viele Probleme vermeiden), ist die logische Komponente. Welche Aufgaben lassen sich parallelisieren, welche nicht? Auf welche Daten muß von mehreren Threads aus gemeinsam zugegriffen werden? Solche Fragen sind da relevant, und die sind unabhängig von der Sprache.
So oder so: was altes entsprechend anzupassen, halte ich für ziemlich aufwendig. ZU aufwendig. Lieber eine Engine gleich neu schreiben...
Da kann ich zustimmen.
Neomi
2005-07-21, 12:15:37
Die JAVA VM (und .NET afaik auch) verteilt die Threads automatisch auf verschiedene CPUs/Cores. Bei C++ muss man das von Hand machen.
Nö, das muß man ncht von Hand machen, das ist die Aufgabe des Betriebssystems. Man kann dem Betriebssystem zwar sagen, auf welcher (logischen) CPU man den Thread gerne hätte, aber man muß es nicht tun. Die automatische Verteilung kann in manchen Situationen mindergünstig sein und die Applikation weiß am besten, was sie in absehbahrer Zeit mit den Threads machen will, deshalb gibt die Option zum manuellen Eingriff.
Neomi
2005-07-21, 12:27:05
Wenn sich die Threads so blockieren, daß immer nur einer aus Syncronitätsgründen laufen kann, dann ist die Anwendung zwar multithreaded, aber zieht aus mehreren CPUs/Kernen keinen Nutzen, da immer nur ein Thread davon laufbereit ist.
Um noch ein konkretes (und oft angewendetes) Beispiel nachzuliefern: Ladethreads.
Der Hauptthread macht nichts weiter, als immer mal wieder beim Ladethread nachzuschauen, wie weit der denn schon ist. Dann wird noch ein Fortschrittsbalken oder ein gleichmäßig (ohne separaten Thread eher schwierig) blinkendes "Loading..." angezeigt. Vielleicht kommt dazu noch die Möglichkeit, den Ladevorganz abzubrechen (bei Spielen zumindest selten), aber das war es dann auch schon. Und der Ladethread ist dann auch deutlich simpler, weil er nicht immer wieder zwischendurch auf Usereingaben reagieren muß.
Die JAVA VM (und .NET afaik auch) verteilt die Threads automatisch auf verschiedene CPUs/Cores. Bei C++ muss man das von Hand machen.Nein tut sie nicht.
Zum Thema: Mit OpenMP sollten doch die eine oder andere Optimierung nachträglich möglich sein, aber das wird sicher keinen Gewinn von 100% bringen, sondern eher 10-30%.
BS-Virus
2005-07-21, 21:24:37
sondern eher 10-30%
Wäre doch schon mal ein Anfang. :)
Gast 2005
2005-07-24, 18:11:31
Die Frage ist ja wofür das überhaupt gut ist. Denn gerade ältere bzw. heute aktuelle Spiele laufen auf den neueren DualCore-Prozessoren im Allgemeinen sowieso schon schnell genug, selbst wenn sie nur einen Core nutzen. Man hätte also kaum Gewinn durch 2 Kerne, weil ja selbst einer normalerweise locker ausreicht.
Unfug
2005-07-25, 00:29:28
Nabend,
ich denke es ist generell ein Problem eine Engine "upzudaten".
Klar kann man durch bessere Routinen mehr rausholen, aber nicht wirklich "neues".
Das Problem ist doch auch schon mit 64Bit. Das ist ja angeblich auch nicht grad mal einfach hinzuzufügen, sonst hätte man es ja öfter gemacht (z.B. per Patch).
Aber bei PC ist ja das gute, dass keine Rücksicht auf "altes" genommen wird (siehe BF2 und G4 Karten). Irgendwann wird auch nur noch 64bit und DC programmiert.
64bit ist eigentlich nur ein Recompile bei sauberem Code. Ich denke dass man es nicht macht weil man dann eine Version mehr supporten muss.
Ganon
2005-07-25, 07:34:54
Ich denke mal weil es auch relativ wenig bringen würde, im Bezug zum Aufwand. "Per Patch" kann man ja einfach sagen "kein support" (ala Quake3Altivec-Test2).
Aber man braucht erst mal einen 64bit-PC. Dann ein 64bit-System und dann muss man noch das entsprechende System einrichten und dann muss immer noch einer auf "Compilieren" klicken und ein Patch fertig machen. ;)
Nur weil Pointer und Integer danach nun 64bit groß sind, kann ich mir nicht vorstellen das da auf einmal mehr Performance bei raus kommt, solange man nicht sagt "Version kompiliert NUR für Athlon64", oder so ähnlich. Weil dann könnte man den Compiler noch optimieren lassen.
HellHorse
2005-07-25, 08:26:10
Nur weil Pointer und Integer danach nun 64bit groß sind,
Integer sollten IIRC eigentlich nicht grösser werden. Auf Windows (worauf die meisten Games ja laufen) werden nicht mal long grösser.
Ganon
2005-07-25, 09:17:25
Also soweit ich das verstanden habe (kann halt sein das es falsch ist ;)) haben "short", "int", "long int", "double" usw. keine festgelegte Größe.
Auf einem 32bit-System hat int 32bit und short 16bit und auf einem 64bit-System hat int 64bit und shot 32bit. "long int" auf einem 64bit-System sollte demnach (theoretisch) 128bit haben.
Beim GCC4.0 änderte sich ja auch die Größe von "long double" von 64/96bit (ppc/x86) auf 128bit.
Darum betreibt man ja den "Aufwand" mit "uint32" usw.
Also das, soweit ich verstanden habe.
HajottV
2005-07-25, 11:08:22
Also soweit ich das verstanden habe (kann halt sein das es falsch ist ;)) haben "short", "int", "long int", "double" usw. keine festgelegte Größe.
Auf einem 32bit-System hat int 32bit und short 16bit und auf einem 64bit-System hat int 64bit und shot 32bit. "long int" auf einem 64bit-System sollte demnach (theoretisch) 128bit haben.
Beim GCC4.0 änderte sich ja auch die Größe von "long double" von 64/96bit (ppc/x86) auf 128bit.
Darum betreibt man ja den "Aufwand" mit "uint32" usw.
Also das, soweit ich verstanden habe.
Tsk tsk ts... im zweiten Satz weiß er schon nicht mehr, was er im ersten gesagt hat. ;)
Die Größen für int, long etc. sind nicht festgelegt.
Es ist durchaus möglich - und auch sinnvoll -, daß die Zeiger 64-bittig sind, ints aber nur 32 bit haben.
Gruß
Jörg
Ganon
2005-07-25, 12:45:10
Tsk tsk ts... im zweiten Satz weiß er schon nicht mehr, was er im ersten gesagt hat. ;)
Die Größen für int, long etc. sind nicht festgelegt.
Es ist durchaus möglich - und auch sinnvoll -, daß die Zeiger 64-bittig sind, ints aber nur 32 bit haben.
Ich habe ja auch nicht gesagt das das schlecht ist. Und das die Größen nicht festgelegt sind, habe ich auch gesagt.
Danach ein Beispiel wie es sein kann.
Aber rein von meinem Verständnis zu dieser Sache ist die "64bit" doch auch auf die Integer-Einheit der CPU bezogen. Das heißt ein Integer sollte doch nun, normalerweise, 64bit groß sein. Ansonsten wäre es ja nur eine halbe Integer-Einheit. ;) Aber wenn der Compiler nun sagt "int ist 32bit", dann ist das Compiler-Sache...
Naja. Ist ja auch egal. Mir ging es ja im Endeffekt eher darum, das ein reiner recompile die Performance nicht wirklich ändert.
HellHorse
2005-07-25, 16:05:33
Aber wenn der Compiler nun sagt "int ist 32bit", dann ist das Compiler-Sache...
Aber das verhindert ja dann genau eben, dass die Integer Werte beim Umstieg auf 64 bit anwachsen.
Auf Windows x36-64 ist/blieb long 32 bit. Da kann ich mir schwer vorstellen, dass int 64 bit wird.
So gut wie alle Games laufen nun mal auf Windows und werden dass auch tun, wenn sie 64 bit sein werden.
Ergo wachsen Integer nicht beim Umstieg auf 64 bit, bloss Pointer.
Naja. Ist ja auch egal. Mir ging es ja im Endeffekt eher darum, das ein reiner recompile die Performance nicht wirklich ändert.
Kann aber durchaus sein, wenn wir von 32bit -> 64bit als x86 -> x86-64 ausgehen (schliesslich geht es um Game Engines, und so gut wie alle laufen auf x86 und 64bit bedeutet x86-64), dann haben wir auf einmal doppelt so viele GPR und zudem sollte eigentlich alle 64bit Integer Arithmetik (ja) schneller werden. Das wird in den seltensten Fällen viel an der Performance ändern, aber möglich ist es durchaus.
Nur weil Pointer und Integer danach nun 64bit groß sind, kann ich mir nicht vorstellen das da auf einmal mehr Performance bei raus kommt, solange man nicht sagt "Version kompiliert NUR für Athlon64", oder so ähnlich. Weil dann könnte man den Compiler noch optimieren lassen.x86-64 hat doppelt so viele Integer- und Multimedia-Register wie x86.
Aber rein von meinem Verständnis zu dieser Sache ist die "64bit" doch auch auf die Integer-Einheit der CPU bezogen. Das heißt ein Integer sollte doch nun, normalerweise, 64bit groß sein. Ansonsten wäre es ja nur eine halbe Integer-Einheit. Aber wenn der Compiler nun sagt "int ist 32bit", dann ist das Compiler-Sache...x86 lässt es schon immer zu Teile eines Registers zu verrechnen.
AL = low byte (1. Byte)
AH = high byte (2. Byte)
AX = word
EAX = dword (IA32)
RAX = qword (AMD64)
AMD schlägt auch vor die Integer bei 32bit zu belassen, weil 64bit-Arithmetik in den allermeisten Fällen nur mit Pointern sinnvoll ist.
Wenn ich mich richtig erinnere hatten Pentiums früher mal etwas Probleme damit z.B. AX statt EAX zu verwenden, aber beim A64 ist EAX statt RAX kostenlos wenn ich richtig informiert bin.
Das wird in den seltensten Fällen viel an der Performance ändern, aber möglich ist es durchaus.Bringt durchschittlich schon 5-10% iirc.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.