10.06.2013, 13:46
Sagen wirs mal so: Gameengines bzw. Grafikengines sind naturgemäß "nahe an der Hardware". Das hat sich durch die Abstraktion mit DirectX und OpenGL zwar etwas geändert, die richtigen "Experten" auf dem Gebiet, also diejenigen Coder, die das letzte aus einer Engine herausholen, kommen halt sehr oft aus der (nach wie vor existenten 
) Demo-Szene, bzw. kommen dann zu einer bereits lange Jahre etablierten Engine dazu, die damals von so jemandem gemacht wurde. Das Multithreading (das man für mehrere CPUs halt braucht) macht nur bei tatsächlich parallelisierbaren oder halt "im Hintergrund laufenden" Tasks überhaupt Sinn, zB wenn man einen Teil der Physik auslagert oder die KI im Hintergrund ablaufen lässt.
Aber nachdem es in der Spieleentwicklung nach wie vor üblich ist, in einem Updateloop zu laufen, weil so neumodisches Zeug wie "Ereignisorientierte Programmierung" (Anm. der Red: wurde in etwa um Windows 3.0 in den frühen 90ern eingeführt) einfach viel zu viel Verwaltung und Performance kostet, ist es halt auch schwer, Aufgaben zu finden, die wirklich parallel ablaufen. Deine Beispiele Obi-Wahn zeigen genau das Problem, die Beschleunigung in der Audio- und Videobearbeitung kommt daher, dass die Aufgaben für die Berechnung "einfach" zu parallelisieren sind, ein Video kannst du problemlos in Keyframes unterteilen, bei Audio (zB bei MP3) gibt es Chunks, die jeweils keine Daten von davor und danach benötigen, und somit "als atomare (im sinne von ungeteilt) Einheit" abgearbeitet werden können. Da machen 8 Kerne natürlich Spaß. Kompilieren ebenso, sobald du einen Abhängigkeitsbaum hast, können die einzelnen Branches natürlich parallel durchgegangen werden, ohne sich "gegenseitig zu behindern".
In den allermeisten Spielen hast du innerhalb des Update-Loops gegenseitige Abhängigkeiten, sodass die Daten aufeinander aufbauen, was Gift für die Parallelisierung ist. Und selbst wenn du Sachen gleichzeitig machen könntest, ist das Debugging paralleler Abläufe von der Komplexität eines Spiels gelinde gesagt *der Horror*. Vielleicht sagt dir der Ausdruck "Race Condition" etwas - ein Fehler tritt auf, wenn Aufgabe A VOR Aufgabe B läuft, nicht jedoch, wenn Aufgabe A NACH Aufgabe B läuft. Sowas zu finden ist ein absoluter Alptraum, weil es die klassischen "Manchmal funktionierts halt nicht"-Fehler sind. Und nachdem Spiele ohnehin schon komplex genug sind und *immer* unter Zeitdruck entstehen, meiden Spieleentwickler das Multithreading wie der Teufel das Weihwasser.
) Demo-Szene, bzw. kommen dann zu einer bereits lange Jahre etablierten Engine dazu, die damals von so jemandem gemacht wurde. Das Multithreading (das man für mehrere CPUs halt braucht) macht nur bei tatsächlich parallelisierbaren oder halt "im Hintergrund laufenden" Tasks überhaupt Sinn, zB wenn man einen Teil der Physik auslagert oder die KI im Hintergrund ablaufen lässt.Aber nachdem es in der Spieleentwicklung nach wie vor üblich ist, in einem Updateloop zu laufen, weil so neumodisches Zeug wie "Ereignisorientierte Programmierung" (Anm. der Red: wurde in etwa um Windows 3.0 in den frühen 90ern eingeführt) einfach viel zu viel Verwaltung und Performance kostet, ist es halt auch schwer, Aufgaben zu finden, die wirklich parallel ablaufen. Deine Beispiele Obi-Wahn zeigen genau das Problem, die Beschleunigung in der Audio- und Videobearbeitung kommt daher, dass die Aufgaben für die Berechnung "einfach" zu parallelisieren sind, ein Video kannst du problemlos in Keyframes unterteilen, bei Audio (zB bei MP3) gibt es Chunks, die jeweils keine Daten von davor und danach benötigen, und somit "als atomare (im sinne von ungeteilt) Einheit" abgearbeitet werden können. Da machen 8 Kerne natürlich Spaß. Kompilieren ebenso, sobald du einen Abhängigkeitsbaum hast, können die einzelnen Branches natürlich parallel durchgegangen werden, ohne sich "gegenseitig zu behindern".
In den allermeisten Spielen hast du innerhalb des Update-Loops gegenseitige Abhängigkeiten, sodass die Daten aufeinander aufbauen, was Gift für die Parallelisierung ist. Und selbst wenn du Sachen gleichzeitig machen könntest, ist das Debugging paralleler Abläufe von der Komplexität eines Spiels gelinde gesagt *der Horror*. Vielleicht sagt dir der Ausdruck "Race Condition" etwas - ein Fehler tritt auf, wenn Aufgabe A VOR Aufgabe B läuft, nicht jedoch, wenn Aufgabe A NACH Aufgabe B läuft. Sowas zu finden ist ein absoluter Alptraum, weil es die klassischen "Manchmal funktionierts halt nicht"-Fehler sind. Und nachdem Spiele ohnehin schon komplex genug sind und *immer* unter Zeitdruck entstehen, meiden Spieleentwickler das Multithreading wie der Teufel das Weihwasser
.