spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Stimmt, so wie Du es beschreibst, sollte es auch gehen. Der Hauptthread gründet einen Zweitthread mit opt(Q), macht dann selber opt(P) und wenn er damit fertig ist, joint er den Zweitthread. Wenn also opt(Q) schon fertig ist, kehrt join() sofort zurück und Du müsstest effektiv P und Q parallel ausgeführt haben.

Bleibt also die Frage, warum er das nicht tut. Du hast nachgemessen und wirklich festgestellt, dass die parallele Variante länger oder gleich lang arbeitet als die kurze Variante? Und Du hast auch wirklich sichergestellt, dass P und Q in Deinem Fall wirklich beide ausgeführt werden? Und das beide Aufgaben in etwa gleich lang arbeiten? Sorry wenn das jetzt albern klingt, aber ich stochere hier im Dunkeln; und manches Mal liegt es an den albernsten Sachen, die man nur vergessen hat zu prüfen.

Und wie gesagt: es kann auch sein, dass die Funktionen, die Du da parallel auszuführen versuchst, beide jeweils einen Mutex ziehen, weil sie auf irgendnem globalen Zustand arbeiten. Prüfe das nach, indem Du mal in die Quellen der Funktionen schaust oder mit dem Debugger mal reinsteppst. Wenn das der Fall ist, kannst Du Dir nämlich jede Parallelisierung sparen.

Ok, ich habe auch übersehen das dort in dem Mainthread auch noch etwas gemacht wird. Es kann durchaus sein, dass die Optimierung gar nicht lang genug braucht das sich die Threaderstellung lohnt. Da müsstest du mal messen wie lange die einzelnen Optimierungsdurchgänge für P und Q dauern. Du sparst dabei ja auch immer nur das Minimum der beiden Zeiten.

Wie oft machst du denn diese Optimierung?
Wenn du sie öfter machst, dann könnte es sich lohnen einen Thread am laufen zu haben, der sobald es etwas zu berechnen gibt, anfängt zu rechnen und die restliche Zeit schläft.

Wenn das allerdings nur eine ms braucht, dann muss das schon sehr oft berechnet werden, damit sich ein Thread überhaupt lohnt.

Nee, was Du eher willst, ist std::condition_variable oder das boost-Äquivalent. Gib dem Thread eine Arbeitsfunktion, die in einer Schleife jeweils einen Job (std::function<void()>) aus einer Queue (boost::concurrent_queue oder so) zieht und ausführt. Wenn kein Job da ist, wartet der Thread stattdessen auf einer condition_variable. Und vom Producer Thread aus stopfst Du dann jeweils Lambdas in die Queue, die ihre Parameter per Capture mitnehmen, und weckst dann einen der Worker Threads mit condition_variable::notify_one().

Genau sowas hab ich übrigens neulich für mein Spiel geschrieben. Dickes Dankeschön an den SPPro-IRC-Kanal, insbesondere xtr1m und BlueCobold, für die interessante Diskussion. Ich habe mal wieder viel gelernt.

Es würde sich für Dich übrigens lohnen, wenn Du alle Ps und Qs gleichzeitig im Speicher hast, dann auf alle nacheinander die Optimierungen anwendest, und erst danach parallel jeweils einmal P und Q kombinierst. Das wär dann ein klassisches datenparalleles Arbeiten, das man phantastisch auf x CPU-Kerne aufteilen kann. Die wenigsten Coder haben das Glück, so freundlich parallelisierbare Aufgaben zu kriegen :-)

Das Framework vom BlobbyVolley Contest, das ich geschrieben habe, implementiert genau das, was du hier scheinbar tun willst. Der Code ist auch recht einfach gehalten. Es wird die eine KI auf dem Mainthread ausgeführt und die andere in einem Workerthread, wobei der Thread nur am Anfang gestartet wird und nicht immer wieder neu.