spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Multithreading.

MfG
Check

Nur als Anmerkung, FPS sind nicht unbedingt gut dazu geeignet Laufzeitveränderungen zu analysieren.

fps versus frame time

Profiling ist ein weiteres hilfreiches Stichwort. Ein profiler analysiert waerend dein Programm laeuft, wie viel Zeit in welcher Funktion drauf geht.

Du koenntest natuerlich auch einfach selbst messen indem du die Zeit vor und nach dem ausfuehren deiner Funktion vergleichst.

Zitat von »[Anonymer Benutzer]Soft«

Generell musst du eh bei jedem Frame deine Objekte auf dem Schirm berechnen bevor es zum Rendern geht, da hilft auch kein Multithreading.

Wie meinst du das? Inwiefern sollten Multithreading-Ansätze da nicht helfen können? Je nach Situation lassen sich solche "Berechnungen" häufig gut auf verschiedene Prozessorkerne verteilen. Auch beim Aufbauen eines Frames kann ein MT getriebenes System (z.B. ein Taskgraph) deutlich die CPU Performanz verbessern. Generell sollte Parod0ntos3 natürlich erstmal die Bottlenecks identifizieren bevor überhaupt irgendwelche Tipps bzgl Optimierung gegeben werden können.

Die Arbeit muss nicht unbedingt auf mehrere Kerne verteilt werden, das ist richtig. Der Rest ist meiner Meinung nach kein Argument. Auch Multithreading ist eben wie bei allem keine Patentlösung. Man muss die Probleme eben vernünftig identifizieren und sich überlegen ob der Overhead sich lohnt. Manche Aufgaben müssen auch nicht unbedingt jeden Frame bestimmt werden sondern können über mehrere Frames verteilt werden. Da benötigt man nicht unbedingt Multithreading für, es könnte aber so gelöst werden.

Zitat von »[Anonymer Benutzer]Soft«

nur weil man multithreading betreibt heißt es nciht dass diese Threads dann auf verschiedenen Kernen laufen
da händelt die CPU alles ganz anders als du dir das wünscht.

Ja, die Probleme von präemptivem MT sind hinreichend bekannt. Trotzdem kann man Threads mit Prioritäten versehen und sein Design so gestalten 'als ob' die Threads auf verschiedenen Kernen laufen. Das MT-Systeme ihre ganz eigenen Probleme mitbringen ist klar, aber Systeme lassen sich in Hinblick darauf implementieren. Multithreading ist ja nichts neues im Spiele-Engine-Bereich, wie bereits erwähnt setzen viele moderne Engines komplett auf multithreadgetriebene Ansätze, darüber gibts auch ne Menge spannender Informationen wo darauf näher eingegangen wird.

Zitat von »[Anonymer Benutzer]Soft«

Alle Prozesse müssen eh fertig sein bevor gezeichnet wird.Und jeder Thread ist mit einem Overhead verbunden. Das Programm wird anfälliger für raceconditions etc pp.

Realistisch gesehen kommt ein System natürlich nie ohne Syncpoints aus, allerdings ist speziell das Zeichnen (bzw das Aufbauen der Cmdbuffer) und der CPU-Frame kein harter Fall an dem synchronisiert werden muss. Einige Engines z.B. interleaven Rendering und den 'Rest' des Frames (Simulation, Physik, Objektupdates, ...) indem das Rendering einen Frame hinterherläuft. So können effektiv Bubbles im Scheduling aufgefüllt werden, da die Tasks unabhängig voneinander sind. Und natürlich führt auch das zu verschiedenen Problemen, die besonders beachtet werden müssen.

Ich schlage vor erstmal zu profilen.
Es gibt bestimmt viele Dinge die man schneller machen kann (und sollte). So Dinge wie Multithreading bzw. allgemein Parallelität sind schonmal gute Ideen. (Noch ein Stichwort von mir: Cache) Dennoch ist es oft auch für sehr erfahrenere Programmierer sehr schwer, genau zu sagen, wo genau am meisten Performance verloren geht. Es ist gut möglich, dass du an einer Stelle versehentlich irgendetwas ganz ungeschickt machst und dort 90% der Zeit unnötig flöten geht. Wenn du alles andere dann optimierst, ist das zwar auch prima, würde aber maximal 10% Leistungssteigerung bringen und das Ausgangsproblem nicht lösen.

Ich empfehle einfach mal Folgenden Artikel zu Intuition-based Optimization:
http://thesmithfam.org/blog/2011/02/06/h…mize-your-code/