@CoolMaster Ich entwickle selbst Software und das nicht gerade im kleinen Maßstab. Und nein es macht einen ganz gewaltigen Unterschied ob ich nun eine Physiksimulation nun sequentiell oder parallel ausführe.
Ein gutes Beispiel für parallele Physiksimulation wäre z.B. PhysX. Das muss prinzipbedingt schon auf hunderte Threads parallelisieren, weil das sonst mit der GPU-Berechnung nichts wird. Das hat aber eben auch seinen Preis. Sollen die einzelnen Partikel nicht nur mit der Umgebung sondern auch mit sich selbst kollidieren, wird's nämlich ganz schnell haarig. Weil dann müsste Partikel A ja wissen wo Partikel B zum Zeitpunkt des aktuellen Ticks in der Simulation ist. Wenn die Bahn von Partikel B aber auf einem völlig anderen Thread zu einem überhaupt nicht garantierten Zeitpunkt berechnet wird, dann ist es praktisch nicht möglich immer den aktuellen Zustand von B zu wissen.
Deswegen unterstützten erste Versionen von PhysX die Kollision zwischen Partikeln einfach gar nicht. Das sah dann halt auch entsprechend unrealistisch aus.
Spätere Versionen unterstützen das jetzt aber dort wird zweifellos einfach getrickst und es wird für die Berechnung einfach der letzte bekannte Zustand von Partikel B genommen. Ob der jetzt schon aktuell ist oder nicht wird einfach ignoriert. Das ist aber dann eben nicht mehr deterministisch. Soll heißen wenn man zweimal die gleiche Simulation laufen lässt, kommt zweimal ein anderes Ergebnis heraus. Und das will man in einer Simulation eigentlich nicht haben. Deswegen nutzen Spiele die PhysX benutzen die PhysX Effekte meist auch nur für hübsches Beiwerk wie rumfliegende Partikel, Staub, kleine Steinbrocken die die Kugel aus der Wand rausschlägt usw (Borderlands 2 ist da ein super Beispiel für), aber eben nicht für Physikeffekte die das Gameplay beeinflussen. (wie z.b. Half Life 2 das mit Havok gemacht hat) Dafür nimmt man dann eine single Threaded Physiksimulation damit das Ergebnis deterministisch bleibt und der Spieler sich darauf verlassen kann, dass das Ergebnis seiner Handlungen auch konsistent ist.
Und sorry, aber was hat OOP mit Multithreading zu tun? Naughty Dog hat Multithreaded Code für den Cell in Assembler geschrieben. Man kann multi-threaded Code mit OOP schreiben, aber man braucht kein OOP um Multithreading zu betreiben. Sonst wäre der Linux Kernel auch irgendwie komplett angeschmiert
.
@GrooveXT
Grundsätzlich richtig, weswegen auch so gut wie kein Studio mehr seine eigenen Engines verwendet sondern größtenteils Unreal, CryEngine, Frostbite, Unity3D und co zugekauft/benutzt werden.
Dort wurde die Arbeit auf die Xbone/PS4 zu optimieren eben einmal gemacht und jetzt setzt man darauf auf.
@Zehkul
Nur dass auf den Konsolen keiner D3D11 benutzt sondern Low-Level APIs wo das mit der parallelisierung des Render Threads längst usus ist.