Eigenes 3D MMORPG mit Delphi möglich?

[Zudomon]

Also mein Problem bezüglich Multithreading lässt sich eigentlich sehr einfach auf den Punkt bringen:

Man benutze den Hauptthread und lässt da drin eine Endlosschleife laufen, macht vielleicht irgendwas was, in meinem Fall eben das Rendering usw. . Wenn man nun die Framedeltas als Graph anzeigen lässt, müsste es bei gleicher Last immer ziemlich ähnliche Framedeltas geben.

Nun startet man bevor die Endlosschleife ausgeführt wird, noch einen Workerthread und legt den auf einen anderen Prozessorkern, so dass man sicher sein kann, dass da nichts dazwischenfunkt...
In dem Workerthread startet man auch eine Endlosschleife...

Resultat: Alles läuft perfekt und wie gewollt... wenn man nun in dem Workerthread rechnet usw. läuft auch alles prima.

Aber erzeugt man nun im Workerthread in dieser Endlosschleife eine einzige Instanz und gibt diese wieder frei, so beginnt der Hauptthread zu stockeln. Und dafür habe ich bisher keine Lösung. Ich könnte mir vorstellen, dass es deswegen ist, weil der ganze Heapspeicher von allen Threads geteilt wird und dann bei einer Instanz sichergestellt werden muss, dass der Speicher der zugewiesen wird, nicht gerade von anderen Threads benutzt wird.

PS: Die Threads haben untereinander keine Verbindung...

[Medium]

Wie wäre es denn dann mit einem zu Programmstart vorinitialisierten Threadpool? Das wäre ein Spontaneinfall für einen schnellen Fix.

[Zudomon]

Kannst du mir das genauer erklären?

[Medium]

Du erstellst dir einfach zu Programmstart eine Hand voll Threads, wirfst die in eine Liste, und lässt die zunächst mal alle "Leerrunden" drehen. (repeat Sleep(1) until Terminated) Diese Threads bekommen noch eine Liste von "Arbeitsaufträgen", die sie, so denn was drin steht, von dem Thread abgearbeitet werden - so ein Auftrag könnte rein theoretisch sogar ein Methodenzeiger sein, so dass du beliebige Methoden von wo her auch immer im Threadkontext laufen lassen könntest. (Nur bei OS-Resourcen aufpassen, manche lassen sich nur in dem Thread verwenden, in dem sie erzeugt wurden.) Das wäre aber schon die sehr allgemeine Variante eines Workerthreadpools. Wenn die Funktion immer gleich ist, macht es ggf. mehr Sinn, Daten in den Thread zu stopfen, die der dann mit immer dem gleichen Algo durchnudelt, z.B. Kram übers Netz jagen.

Dadrüber wäre dann eine kleine Managerroutine sinnig, die das Verteilen von Aufgaben an die Threads verwaltet (z.B. dem mit der aktuell kleinsten Arbeitsliste). Und... ich würde das ja in eine hübsche, handliche Klasse kapseln :)

Damit liefen die Threads an sich also schon von Anfang an, und würden nur bei Bedarf mit Daten oder Methoden gefüttert. Wie viele man davon nachher braucht, ist von der Anwendung abhängig, und je nach Auslastung dieser spielt auch noch die Anzahl CPU Kerne mit rein. Viel mehr als 2*Kernanzahl (logische) macht eher selten wirklich Sinn.

[Zudomon]

Ja, ziemlich exakt so habe ich das in meiner Engine gemacht... und es hat fürchterlich geruckelt...
Ich habs dann soweit runtergebrochen bis ich gemerkt habe, was der Sündenbock ist... sobald in den Workerthreads Instanzen erzeugt werden, kann man es vergessen.

[Klaus01]

.. aber sollte es nicht gehen, aus dem Workerthread heraus neue Aufträge auf den Auftragsstack zu legen. Der Stack wird dann wie gewohnt von den bereits bestehenden Threads abgearbeitet.
Neue Thread müssten so nicht erzeugt werden.

Grüße
Klaus

[WladiD]

Ich hab ja bisher nicht allzuviel Code gesehen, dennoch meine Vermutung:

FastMM skaliert schlecht, wenn in mehreren Threads strings oder dynamische Arrays vergrößert bzw. instanziert werden.

Hier eine ausführliche Abhandlung darüber...

Ist es bei dir der Fall?

[Zudomon]

Ist denn dieser FastMM der Delphi Standard? Ich benutze Turbo Delphi.
Aber ich vermute auch, dass es am Memory Management liegen muss... ich denke, ich schau gleich einfach mal, ob ich ein wenig code zusammen bekommen, um das mal zu zeigen.

[Medium]

Strings oder Dyn-Arrays wären in so einem Projekt ohnehin pures Gift :shock:. Resourcen dieser Größenordnung sollten zu Anfang ein Mal erzeugt werden, und wenn dynamische Größen vorkommen, dann die größt-vorkommende Variante vorbereiten, und eine Datenlänge mitführen. Kommt zwar etwas verschwenderisch daher, aber den Preis muss man zahlen, wenn man andauerndes Allokieren nicht will.

Edit: Ja, FastMM ist Standard. Letztens war in den RSS Feeds mal ein Vergleich diverser Delphi MMs, bei dem FastMM - bis auf eben in 1-3 Spezialfällen - recht nett abschnitt. Alternativen fehlen meist einige gewohnte Features, oder sind schneckig. Der Artikel war recht interessant, ich find ihn nur grad irgendwie nicht :?

[Zudomon]

Also ohne Klassen schaff ich es ja gerade noch so, aber ohne Strings und Dyn-Arrays, das wird echt hart!!
Aber werde ich dann hinterher mal probieren... wenns nicht anders geht.

Nun dachte ich, ich könnte mal schnell eine Test-Anwendung machen, aber da bekomme ich es nun nicht reproduziert. Zumindest nicht, wenn ich nur eine Instanz in dem WorkerThread erstelle und freigebe... vielleicht muss der Hauptthread dann auch immer Speicher holen und freigeben, damit das wirklich zum Problem wird. Das einzige, was mir sonst noch einfällt, was mal abgesehen vom Projektumfang anders ist, dass ich bei meinen anderen Projekten nicht auf einer VCL-Form arbeite, sondern mit WinAPI das Fenster erzeuge. Aber würde sich das auf das Speichermanagement auswirken?