Multithreading Problem

[Top-OR]

Yo, wie Krishty sagt. Wir betreiben hier Kaffesatzleserei. Wir sind uns ja noch nichtmal über die "Art des Ruckelns" einig; Werte zum Auswerten haben wir nicht.

Oder um unseren Azubi zu zitieren: "Der einzige Lüfter(!), der es sein kann, ist der auf der Grafikkarte, der auf der CPU oder im Netzteil." ;-) Tja, so einfach ist das...

Vielleicht solltest du wirklich mal mit nem HighRes-Timer Benchmarks und ein bissel Profiling machen. Unter Windows ist dazu QueryPerformanceCounter() mein Freund.

[Zudomon]

Huhu!

Also ihr habt mir ja schon sehr viel weiter geholfen... vor allem CodingCat! Ich habe bereits mit Lars gesprochen ( auch hier im Forum ), der ist ein alter Delphi-Veteran und er sagte mir, dass es wohl wirklich daran liegt, dass die Instanzen in einem Thread erzeugt werden. Vielleicht schreibt er ja auch nochmal etwas genaueres... man kann aber wohl die Create und Free Methoden in Delphi so überschreiben, dass jeder Thread einen eigenen Speicherbereich nutzt und nichts gelockt werden muss. Oder ebend in den Threads auf Erstellen verzichten...
Ich werde erstmal letzteres versuchen...

@Krishty & Top-OR
Also die Art des ruckelns ist schon ein massives Stocken im Millisekundenbreich... vor dem Profiling drück ich mich noch ein wenig. Werde mal schauen, dass gleich noch umgesetzt zu bekommen und wenn sich dann alle Probleme gelöst haben, dann kann es auch mit Motivation weiter gehen und ich habe mir das Profiling gespart. :D

[kimmi]

Kannst du denn vorab bereits die Instanzen erzeugen ( zum Beispiel über eine eigene Factory, die einen Cache für Objekte erzeugt ), damit du während des Rendern die das Kreieren sparen kannst? Damit solltest du die Last aus dem rendern heraus bekommen.

Gruß Kimmi

[mär]

Das Problem ist vermutlich nicht irgendein Konstruktor, sondern der MemoryManager. Dieser verwendet eine CriticalSection. Er lässt sich aber austauschen und es existieren auch freie Implementierungen, die damit werben, in MT-Umgebungen schneller zu sein.

[Top-OR]

Das Problem ist vermutlich nicht irgendein Konstruktor, sondern der MemoryManager. Dieser verwendet eine CriticalSection. Er lässt sich aber austauschen und es existieren auch freie Implementierungen, die damit werben, in MT-Umgebungen schneller zu sein.

Das mag sein und diese Lösung kommt sicher dem ganzen Projekt zugute, aber wäre es nicht auch eine gute Idee, in nem Render(!!)-Thread ganz auf Allocs/News/WieAuchImmerEsInDelphiHeisst zu verzichten. Sicher, der CTor ist nicht das Prob, sondern das "new".

Beim Rendern noch große Handstände (Speicher holen) zu machen ist doch sicher nicht der ideale Weg, oder?

Man sieht hin und wieder MT-Konstruktionen mit 2 Puffern: Ein Puffer ist "fertig" und wird gerendert, der andere wird gerade von nem anderen Thread mit "neuen Daten" gefüllt und fertig gemacht. Wenn es fertig ist, machst du nen "switch" und tauschst die Puffer aus. Quasi wie Double-Buffering wie wir es vom Framebuffer auf der Graka kennen ... nur eben für "Berechnungen" in deinem Prog.

[Krishty]

Afaik rendert er nicht (das stammt wohl missverständlicherweise daher, weil jemand ganz am Anfang zwischen Render-Thread und Worker-Threads unterschieden hat), sondern generiert Daten aus einem internen Format (u.a. per Subdivision). Das ist wohl leider ein bisschen mehr als bloß das Befüllen von Vertex- und Index-Buffers und momentan der Bottleneck, weshalb er es gern parallelisieren möchte.

[Top-OR]

@Krishty: Achso. Na dann:

Kannst du denn vorab bereits die Instanzen erzeugen ( zum Beispiel über eine eigene Factory, die einen Cache für Objekte erzeugt ), damit du ...

... schneller bist?

@Zudomon: Machst du Terrain-Rendering oder sowas? Da hab ich solche Späße auch hinter mir. Bei kleinen Maps (< 1024^2) ist ja alles im grünen Bereich, aber "subdivide" mal größere Maps (2048^2 oder 4096^2) pauschal bis "ganz" unten im (oc)tree. Ich sags mal so: Wir brauchen mehr Speicher!

Dann entweder vorher pauschal Speicher allocken (und RAM-Riegel mit ner Schubkarre in den Rechner kippen) oder Speicher dynamisch holen.

Hast du die Möglichkeit, den Speicher "bevor es ernst wird" schon zu holen?

[Zudomon]

Huhu!

Also ich hab es schon soweit drin, dass wirklich keine Klassen innerhalb des Workerthreads erzeugt und zerstört werden. Es ist nun zwar noch ein stocken vorhanden, aber das wird nun wohl nicht mehr an den Threads liegen, denn wenn ich die Workerthreads einfach ihre arbeit unendlich wiederholen lasse, läuft es ohne stocken. Ich denke nun, das ich nun schon um einiges weiter gekommen bin. Nocheinmal danke für eure Hilfe! :D

@Zudomon: Machst du Terrain-Rendering oder sowas? Da hab ich solche Späße auch hinter mir. Bei kleinen Maps (< 1024^2) ist ja alles im grünen Bereich, aber "subdivide" mal größere Maps (2048^2 oder 4096^2) pauschal bis "ganz" unten im (oc)tree. Ich sags mal so: Wir brauchen mehr Speicher!

Dann entweder vorher pauschal Speicher allocken (und RAM-Riegel mit ner Schubkarre in den Rechner kippen) oder Speicher dynamisch holen.

Hast du die Möglichkeit, den Speicher "bevor es ernst wird" schon zu holen?

Ja, ich baue doch an dem Stonequest-Projekt rum, und da habe ich die Landschaft. Da werden immer Abschnitte von 18^3 Voxeln erstellt, die dann noch verrauscht und subdivided werden. Das Terrain ist schon sehr dreidimensional. Und der Speicher ist extrem schnell dicht...

[Top-OR]

Freut mich, dass es klappt!