Bisher hatte ich bei meiner Fahrzeugdemo (die wohl recht repräsentativ für größere Projekte sein dürfte) dass Problem die Physik richtig zu timen. Mittels Hi-Performancetimer geht das nicht (allein wegen der Tastatursteuerung und dem damit je nach FPS unterschiedlichem Drehmoment) und der Tatsache dass Newton nur in einem (was allerdings recht logisch ist) bestimmten Frameratenbereich fungiert, der besonders bei mehreren 100 FpS gesprengt wird.

Dann hab ich bereits vor längerer Zeit die Physikberechnungen in einen eigenen Thread mit einer Frequenz von 60Hz ausgelagert (Priorität = Highest), was dann in vielen Fällen dafür sorgte dass meine Physikberechnungen und Tastatursteuerung (ich mache beides in diesem Thread) konstant waren. Allerdings nicht mehr wenn das Rendern zulange dauerte (OnIdle-Event), denn dann konnte der Thread nicht mehr zeitig ausgeführt werden und die Berechnungen waren wieder inkorrekt. Bin dann heute mal hingegangen und habe auch das Rendern der Szene in einen eigenen Thread ausgelagert, momentan mit einer Frequenz von 100Hz. Dachte zuerst das wäre evtl. nicht wirklich brauchbar, aber siehe da : Egal in welcher Auflösung, egal ob das Rendern den Rechner zum Stocken bringt oder es auf recht hohen FpS abläuft, mein Physikthread (der zwei Prioritäten über dem Renderthread läuft) wird permanent mit der von mir gewählten Frequenz ausgelöst und die Physiksimulation ist damit immer stabil.


Wo die Frage bei dem Text da oben versteckt ist? Es gibt an sich keine, und die Schilderung oben war eher für alle anderen gedacht die mit dem Timing von Newton (oder anderen Physik-Engines) Problem haben. Aber nebenbei wollte ich hier Leute mit Erfahrung auf dem Gebiet mal fragen ob diese dass in ihren Anwendungen auch so tun, und/oder ob es dabei irgendwelche wichtigen Dinge gibt die man beachten sollte. An der Zahl der Threads sollte man ja kaum scheitern, und wenn man schon Threads benutzt (was in Delphi überaus bequem ist, war selbst überrascht) kann man da auch noch ein oder zwei andere für z.B. Netzwerkkommunikation dranhängen!

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ich habe für Physik ursprünglich auch Threads eingesetzt - bin davon aber wieder abgekommen, da Windows mit einer Zeitscheibe von 10ms zur Threadumschaltung arbeitet. Inzwischen halte ich es für geschickter, die Physikberechnung im Hauptthread der Anwendung zu machen, da man die Darstellung ja ohnehin mit der Physikengine koordinieren muss (ursprünglich konnte es passieren, dass Objekte irgendwo ganz kurz in der Mitte auftauchten, da sie erst im nächsten Frame dann tatsächlich vom zugehörigen "body" gesteuert wurden) - da Simulationen recht empfindlich auf variable Timesteps reagieren können, wird die Physik einfach so lange um einen konstanten Wert weitergedreht, bis die aktuelle Systemzeit wieder erreicht ist (oder umgekehrt nur alle paar Frames berechnet, je nachdem was schneller ist), das Endergebnis wird verwendet, um die dargestellten Objekte upzudaten.
Die Alternative wäre gewesen, dass der eine Thread halt wartet, bis der andere ein Ergebnis fertig hat - dies hätte meiner Meinung nach aber den Nutzen von Multithreading ad absurdum geführt, auch wenn Delphi hierbei wirklich äußerst komfortabel ist.

Bei echten Dualprozessoren (oder wenigsten Hyperthreading) schaut die Sache natürlich wieder anders aus, da hier jeder Thread einen eigenen (virtuellen) Prozessor zugewiesen werden kann, und der Overhead der Threadumschaltung somit wegfällt. Allerdings müsste man dann auch sicher stellen, dass der Renderthread auf einem, der Physik Thread auf einem anderen Prozessor läuft, sonst bringt das Ganze wieder wenig (und hierfür stellt Delphi meines Wissens leider keiner Hilfsroutinen zur Verfügung).
Multithreading halte ich eher für wirklich brauchbar, wenn man zeitaufwändige Berechnungen hat, und dennoch dem Benutzer eine "flüssige" Oberfläche bieten möchte, ohne immer wieder zwischendurch die Botschaftswarteschlange abzuarbeiten, andererseits aber auch wenn man manche Sachen mit geringer Priorität laufen lassen möchte, sodass die Idle Zeit des Hauptthreads für diverse andere Dinge optimal genutzt werden kann.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Ich habe schon recht viel unter Java mit Threads gearbeitet. Bei Delphi und OpenGL habe ich das bislang vermieden, weil man ja ziemlich wegen der Synchronization aufpassen muß. Entweder man synchronisiert zu stark, dann hat man zu wenig die Leistung ausgenutzt oder man synchronisiert zu wenig und dann kommt es zu Fehlern. Ideal ist es wenn man jedem Thread seine eigenen Daten geben kann und die Threads die Aufgaben unabhängig bearbeiten können. Ich vermute mal die hast mehrere Listen mit den Matrizen und vertauschst nach einem Physik Frame dann die Zeiger, oder wie hast du das synchronisiert?
Da es ein ziemlicher Mehraufwand ist, habe ich eigentlich nie Threads benutzt, wenn es auch anders ging. Jeder schreibende Zugriff auf globale Daten muß ja faktisch synchronisiert werden.

Nein, ich muss keine extra Matrizenliste führen. Im Thread selbst rufe ich ja nur (mal abgesehen von der Aktualisierung des Tastenarrays) nur noch NewtonUpdate auf, und die Matrizen werden dann ja beim Rendern via NewtonBodyGetMatrix entnommen.

Der Vorteil an den Threads ist jetzt halt die Tatsache dass mein Physikthread alle 15ms aufgerufen wird und ich nicht "kompliziert" die Zeit ermitteln muss, denn (zumindest im aktuellen Zustand) es ist nicht sonderlich leicht Newton über herkömmliches Timing (z.B. QPC, timeGetTime) so zu timen dass es auch bei jeder Framerate gleiche Berechnungen liefert. Dadurch dass der Thread aber in festen Abständen aufgerufen wird umgehe ich diese Probleme, und da jetzt auch in nem separaten Thread gerendert wird, läuft der Physikthread auch wirklich alle 15ms. Wenn ich normal rendere (MainLoop, OnIdle, etc.) wird der Physikthread halt nich t immer in diesem Intervall aufgerufen. Von daher ist es also so wie es jetzt ist in meinen Augen die optimale Lösung, auch wenn etwas Zeit verplempert wird.

Aber so wie es Mars gesagt hat ist es u.U. auch noch eine Lösung (solange die Framerate nicht zu stark sinkt, da Newton ja momentan eine FpS-Raum hat der auch nicht zu niedrig sein darf), nämlich ähnlich wie bei D3 die Physiksimulation auf ein Maximum zu beshränken. Das könnte man mal ausprobieren, aber momentan favorisiere ich die Threadsache.

Und Threads kannst du ruhig mal ausprobieren, die sind recht schnell implementiert und das mit der Sychronisation ist auch nicht schwer. Beim Newton-Thread muss ich ja nur die NewtonWorld-Variable sowie das Tastenarray synchroniseren, das sieht dann so aus :

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ich weiß nicht wie Newton das intern macht, aber das Grundproblem, was ich meinte war folgendes: Wenn man gleichzeitig die Physik laufen läßt und rendert. Dann werden ja die Positionen von den Objekten während des Renders geändert. Dann hat man innerhalb eines gerenderten Frames Objekte von verschiedenen Physik Frames, auch wenn das Physik Update in einem Block durchgeführt wird. Da könnte es z.B. sein, daß das eine Objekt weiterbewegt wurde und das andere noch nicht und sie sich daher schneiden. Man muß ja sicherstellen, daß die Objekte die man rendert alle den gleichen Stand von der Physik her haben. Wenn man Physik und Rendern getrennt laufen läßt, dann kann es ja durchaus während des Renderns zu einem Threadwechsel kommen.

Nein, dass kann nich passieren da ich ja Synchronize benutze. Das sorgt dafür dass der Thread alle anderen Threads anhält, und zwar solange bis mein NewtonUpdate seine Berechnungen durchgeführt hat. Und erst danach kann z.B. der Renderthread ablaufen, in dem ich via NewtonBodyGetMatrix die Matrizen der dynamischen Objekte abrufe.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Wenn du die ganze Physikberechnung in eine Critical Section steckst, und mit Synchronize ja doch den Hauptthread die meiste Arbeit machen lässt, hast du effektiv ja wieder einen einzigen Programmablauf, bei dem sämtliche Aufgaben streng nacheinander ausgeführt werden. Critical Sections sollten möglichst kurz gehalten werden, da hierbei im schlimmsten Fall in einem Multiprozessorsystem, ein Prozessor in einer Warteschleife hängt und auf die Ergebnisse des anderen Prozessor wartet.
Auf Singleprozessorsystemen ist es natürlich egal, da die CPU ohnehin nur eine Aufgabe ausführen kann - dann entspricht das "Multithreading" aber mehr oder weniger der Methode einen Timer aufzusetzen, um halt halbwegs regelmäßig irgendwas durchzuführen, und dies mit einer Wächtervariable mitzuprotokollieren (genaugenommen ist es im konkreten Fall sogar genau das selbe, weil Multitasking Betriebsysteme auf I386 Abkömmlingen die Zeitscheibe für Singleprozessorsysteme ebenfalls mit dem Timerinterrupt generieren, und Critical Sections werden über Global Locks gelöst, die nichts anderes sind als Flags die sagen, ob auf einen bestimmten Speicherbereich zugegriffen werden darf, oder halt nicht (auf die Global Locks selbst wird entweder mit den lock Präfix oder atomaren Befehlen wie xchg zugegriffen, sodass die Änderung eines Global Locks selbst keine Synchronisationsprobleme aufwerfen kann) - alles ziemlich wenig aufregende Konzepte, aber mehr steckt tatsächlich nicht dahinter).

Wenn man es sich genau durchdenkt, ist obiger Code nicht nur auf Einprozessorsystemen nicht performanter, sondern im schlimmsten Fall bremst er auf Zwei- oder Mehrprozessorsystemen einen zweiten Prozessor aus, der ansonsten einem anderen Programm (oder einem weiteren Thread deines Programmes) zur Verfügung stünde.

Der Schwierigkeit beim Programmieren von Mehrprozessorsystemen, ist es herkömmliche Programmstrukturen so zu parallelisieren, dass sie in unabhängige Aufgaben unterteilt werden, sodass das Ganze auf mehreren Prozessoren performanter läuft (obwohl es auf Singleprozessorsystemen sogar langsamer sein kann - dann sind wieder mehrere Codepfade angesagt).
Eine praktische Anwendung für Spiele, die Singleprozessoren nicht ausbremst und von Multiprozessorsystemen profitiert, wäre etwa die Berechnung einer Entscheidungs KI im Hintergrund eines Strategiespiels, die laufend Ergebnisse liefert, und sich mit der sich ändernden Konfiguration auf dem Spielfeld auseinandersetzt. Bei der Auswertung der Entscheidungen ist es dann völlig egal, ob das Ergebnis nun andauernd abgefragt wird, oder das Ziel von Einheiten nur alle paar Sekunden "upgedated" wird, da die Berechnung selbst zwar sehr komplex sein kann, sich am tatsächlichen Zustand des Spieles aber innerhalb weniger Sekunden wenig ändert, es macht also nichts, wenn die KI mit der Berechnung des neuen Ergebnisses noch nicht fertig ist, da das alte auch halbwegs passt.

Wenn du wirklich Physik mit Multihreading optimieren möchtest (IMHO bringt es aber nichts, da 99% aller PCs ohnehin Einprozessorsysteme sind, für die sich der zusätzliche Verwaltungsaufwand nicht lohnt) solltest du es so machen, wie es Lars bereits angedeutet hat: Du renderst mit einer Liste von Matrizen, und lässt Newton (ohne critical Sections) eine weitere Liste von Matrizen für den nächsten Frame berechnen, während du den aktuellen Frame renderst, Anschließend setzt du im Newton Thread einen Flag, wartest im Renderthread bis der True ist, vertauscht im Hauptthread die Zeiger auf die Matrizenlisten (oder kopierst sie, das ist im Prinzip egal), der Newton Flag setzt den Flag vor dem Start der nächsten Berechnung wieder auf False u.s.w.
Hiermit hast du synchrone Daten, reduzierst aber stalls auf ein Minimum - wenn der Newtonthread während des Renderns und der sonstigen Berechnungen öfter aufgerufen wird, ist es egal, berechnet er halt seine Daten neu, die sind aber ohnehin unabhängig vom Renderthread - und du musst im Hauptthread maximal auf das Ergebnis der letzten Newtonberechnung warten (und kannst während des Polls sogar noch was anderes Sinnvolles tun, wenn es dir schade um die Zeit ist - da du ja jetzt selbst die Kontrolle über die Warteschleife hast)

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Es ist schon klar dass es, so wie ich es momentan mache, nicht wirklich performanter als ein eigener Mainloop ist; aber darum geht es mir im eigentlichen Sinne auch nicht. Mir ging es eher darum dass man durch zwei getrennte Threads erreichen kann dass die Newtonwelt in einem festen Intervall aktualisiert wird, und so auch z.B. das bei gedrücktem "Gaspedal" entstehende Drehmoment durch diesen Intervall immer gleich ist, denn (wenn ich nicht irre) macht es wohl einen Unterschied, ob man alle 10ms ein Drehmoment von 20Nm, oder alle 20ms ein Drehmoment von 40Nm auf einen Körper einwirken lässt.

Von daher ist die momentane Lösung zumindest aus Sicht der stabilen Physikberechnungen in meinen Augen "perfekt" (das levelliert sich allerdings wenn im Hintergrund einige andere Sachen laufen die dafür sorgen dass der Physikthread nicht mehr im korrekten Intervall läuft). Und da Newton seine Berechnungen wirklich sehr schnell ausführt (zumindest solange man nicht über die internen Limits, also z.B. 500 Kontakte, kommt) kommts eher selten vor dass der Physikthread meine Anwendung blockt.

Die Sache mit der separaten Matrizenliste ist allerdings eine recht brauchbare Idee, die zudem sehr schnell implementiert ist. Also werde ich das auf jeden Fall mal die Tage antesten.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ich denke wie folgt darüber.

Bisher habe ich meine Newton Test immer ohne Threads gemacht, halte es aber später für sehr viel schlauer die Physik sowie Netzwerkverkehr und Sound seperat in Threads laufen zu lassen.
So kommen sie sich nichts ins gehege, wenn der eine warten muss.
Gerade wenn netzwerk ins spiel kommt und man TCP nutzt ist es viel leichter mit ein Thread, da man nicht erst ein Handstand machen muss um den Blockingmode zu umgehen und Sound ist mal bei weiten nicht so wichtig wie der rest und kann dann einfach mal mit niedriger PPriorität laufen.
In hinblick auf die Zukunft ist M. Thread sowieso nötig, da Intel ihren HT schon längere Zeit draussen hat und AMD nun ihren Multi Thread fähige CPU raus bringen will.
Das bedeutet dann auch das App ist für die Zukunftigen CPUs schon ein bischen Optimiert.
Wenn man dann noch die Entwicklungsdauer eines Projekts mal mit einkalkuliert, wird es schon sehr viel mehr PCs mit Multithread fähigkeit geben als es momentan der fall ist.
In Sachen FPS beschränkung ist noch zu sagen sobald Netzwerk dazu kommt ist eine feste obergrenze sowieso mal oberwichtig.
Der Carmack hat in ein alten Artikel zu D3 gesagt das bei Q3 durch das nicht vorhanden sein von einer FPS grenze die Spieler indirekt cheaten konnten.
Personen mit niedrigen Framerates wurden von Personen mit sehr viel höheren Framerates einfach mal total unterschiedlich wargenommen, es ist auch bei HL der fall und beide schmieden haben eine Obergrenze eingefügt bei D3 liegt sie bei 60FPS und ist auch nicht wegschaltbar.
Valve hat nach meinen letzten Infos HL² mit 100FPS geschaltet also 3 mal mehr als das menschliche Auge überhaupt war nimmt.
Um nun auf Threads zurück zu kommen, wenn man ein Thread hat und man hat noch sagen wir 200FPS luft, werden die einfach mal verbraten, wenn nicht durch die render pipeline dann durch Newton,Sound oder Netzwerk.
So packt man einfach alle 4 Teile in einzelne Threads und der überfluss an Rechenleistung geht für andere Prozesse drauf wie Leerlauf.
Das hat zur folge das CPU und Graka zu mindestens in dieser App eine längere lebensdauer zu erwarten haben.
Man spart man sich die arbeit mit der Synkronisierung und braucht keine rechnungen machen um die benötigten Zeiten zu bekommen.
Fass ich mal mein Text zusammen . Threads sind einfach unausweichlich, wenn man vor hat mit der Hardware mit zu gehen.

MfG TAK2004

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Mich wuerde es wunder nehmen wie du diesen festen Intervall erzeugst? Mit einem sleep() im physik thread? Oder wartest du auf eine Mutex der ein Timer frei gibt?

Ja, ich nutze dazu ein einfaches Sleep.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

@Tak2004:
HyperThreading macht im Prinzip nur eines: den Zeitaufwand für die Threadumschaltung reduzieren, da der aktuelle Prozessorzustand auf der CPU zwischengespeichert werden kann (einmal, weswegen HT auch nur einen zweiten Prozessor simuliert). Ausführende Einheit gibt es bei einem Prozessor aber dennoch nur eine, d.h. die "Bestrafung" einer für Multithreading ausgelegte Anwendung, die auf einem Singleprozessorsystem ausgeführt wird, ist nicht ganz so groß - du musst aber nicht glauben, dass die zwei simulierten CPUs schneller sein würden, als eine einzelne - von Optimierung kann man hier nicht sprechen, solange nicht tatsächlich mehrere ausführende Einheiten vorhanden sind.
Im Prinzip entspricht Multithreading auf einer CPU der Methode einen Timer aufzusetzen, da das Betriebssystem den Threadwechsel ja ohnehin über diesen durchführt.

Interessant ist die Umsetzung einer Problemstellung auf eine Weise, dass sie tatsächlich auf mehreren Prozessoren ausgeführt werden kann (das ist aber oft gar nicht so einfach, da Synchronisation halt darauf hinausläuft, dass ein oder mehrere Prozessoren warten müssen) natürlich dennoch - zumal echte Mehrprozessorsysteme inzwischen ja auch für Heimanwender leistbar sind.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Das stimmt so nicht ganz. Aktuelle Prozessoren haben mehrere Execution Units und untersuchen den Instruktions Stream nach Instruktionen die Out of Order ausgefuehrt werden koennen und verteilt diese auf die vorhanden Execution Units. Die werden natuerlich nie voll ausgenuetzt. Hier hilft jetzt Hyperthreading und kann noch Instruktionen von einem anderen Thread einfuellen. Somit sind die Execution Units besser ausgelastet. Laut Intel soll das im idealfall 30% performance gain bringen.

Danke für die Info, so gesehen könnte HT tatsächlich etwas mehr bringen, als ich ursprünglich dachte, zumal es mehrere separate Pipelines für Integer und Fließkommabefehle gibt. In der Praxis halte ich es aber dennoch für Marketing Hype, da diese nur greifen, wenn z.B. in aufeinanderfolgenden Befehlen auf unterschiedliche Register / Speicheroperanden zugegriffen wird (in zwei Befehlen hintereinander das eax Register zu verändern bringt also nichts) - dann müssten in den Instruction Pipelines unterschiedlicher Threads gerade solche Kommandos aufeinandertreffen, die von der CPU Logik her parallel ausgeführt werden können, was durch die geringe Anzahl von allgemeinen Registern auf der I386 Architektur doch eher ein Glücksfall ist.

@Topic: wie hast du denn die Prioritäten gesetzt? Sobald das System ohne Angabe einer bestimmten Priorität unter Vollast stand, war bei mir die Physik ziemlich unregelmäßig, da das regelmäßige Ausführen nicht garantiert war (allerdings habe ich Critical Sections im Hinblick auf Mehrprozessorsysteme bewußt vermieden). Was die Physikberechnung in einer Schleife mit gleichen Zeitabständen betrifft: da kann man noch die Zeit innerhalb der Schleife mit messen, wenn das Ganze zu lange dauert, tut man so, als sei die Systemzeit bereits erreicht und bricht ab, dann wird halt die Physiksimulation langsamer - das ist aber auch schon wurscht, da die ganze Animation ohnehin schon ruckelt (ansonsten kommt man ohnehin in Teufels Küche, wenn die Systemzeit schneller voranschreitet, als man mit der Simulation "nachkommt").

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

@OffTopic
Noch zum EAX Register, das Schlagwort heisst hier Register Renaming. So ein Register entspricht nicht mehr einem physischen Register sondern die werden dynamisch zugeteilt. Wenn du zum Beispiel 2 mal hinter einander etwas im eax addierst und diese beiden Operationen haengen nicht voneinader ab, kann der Prozessor diese trotzdem auf 2 verschiedene Pipelines aufteilen. Daher gilt immer mehr MHz!=Performance.