Wie viele Threads sollte man nutzen?

[rapso]

viele threads werden aus faulheit und bequaemlichkeit erstellt, das hat weder was mit gutem design noch mit auslastung/optimierung zu tun. gibt leute die meinen fuer input einen thread haben zu muessen oder fuer sound mehrere oder fuer netzwerk.
entsprechend gibt es auch libs die einige threads erstellen wenn man sie initialisiert, ohne dass es wirklich noetig ist.

bei den 40 threads wuerde ich mir als nichts denken, kann gut sein dass ein video codec der 99% der zeit schlaeft sich einfach mal 8threads erstellt, nur damit diese nicht erst erstellt werden muessen wenn die erste cutscene kommt.

[kralo9]

nun ja, starcraft 2 ist von blizzard und die würde ich nicht als unfähig beschreiben... :xmas1:

[hustbaer]

@kralo9
Das hat nichts mit unfähig zu tun, manchmal ist es einfach praktisch.
Speziell wenn man Libraries entwickelt kann es nötig sein bzw. die Dinge drastisch vereinfachen wenn man ein oder zwei Threads anlegt.
Wenn man dann ein paar solche Libraries verwendet hat man gleich ein Dutzend oder mehr Threads.
Ich sehe das nicht als Pfusch oder Designfehler oder sonstwas. Nur machen diese Threads trotzdem die meiste Zeit über nichts.

Davon abgesehen sind gute Spiele von grossen Firmen nicht unbedingt ein Beispiel für tolles Softwaredesign. Die müssen nämlich auch irgendwann fertig werden, und nachdem diese Spiele nicht unbedingt lange gewartet werden müssen (im Vergleich zu Businessapplikationen) zahlt es sich auch gar nicht aus das ultimative Design zu haben.

Und zuletzt: ein paar "unnötige" Threads zu verwenden mag zwar dem einen oder anderen "unsauber" erscheinen, ermöglicht aber oft ein wesentlich einfacheres Design -- daher würde ich es nicht grundsätzlich als schlecht bezeichnen. Ich verwende öfter mal Hilfsthreads die relativ wenig tun. Das System kommt gut damit klar, der Overhead ist quasi nicht messbar und sicher nicht spürbar -- wozu also eine kompliziertere Lösung implementieren?

Soll heissen: ich bin mir sicher dass von den 40 Threads die Starcraft 2 verwendet die meisten den Grossteil der Zeit über einfach heia machen.

[rapso]

kralo9 schrieb:

nun ja, starcraft 2 ist von blizzard und die würde ich nicht als unfähig beschreiben... :xmas1:

falls wir beiden die faehig als 'get shit done' und nicht als 'make code beautiful' ansehen, sind wir uns einig, sie sind faehig, sonst waere das spiel nicht raus, aber der code wunderschoen.

[Pria]

also ganz ehrlich, ich würde es bei dem ein oder anderen Spiel schon schätzen wenn die Macher mehr Threads verwenden würden. Ich denke da z.b an Skyrim. Beim Laden von neuen Mapteilen ging garnichts mehr, ausser dem Ton und das ist echt beschissen. Da merkt man garnichts mehr von "OpenWorld"

Grundsätzlich würde ich den Ansatz einmal aus einer anderen Perspektive betrachten und mich da an dem Betriebssystem orientieren. Maximal so viele Threads wie CPU Kerne und dann geschedulte Jobs (nach priority, range oder what ever) in 1-n: n=anz Threads Queues

[rapso]

einfach nur mehr threads erstellen macht nichts besser. ist wie einfach mehr raeder an einen wagen klatschen.

das OS erstellt nicht soviele threads wie CPUs, an sich erstellt das OS (also der kernel) garkeine threads, sondern stellt die moeglichkeit zur verfuegung threads zu erstellen und jeder prozess bekommt erstmal einen und die meisten erstellen sich dann noch welche, gerade treiber.

es per jobs zu machen waere schon gut, allerdings muss man das von anfang an als basis nehmen und die ganze engine etc. muss darauf aufgebaut sein, dann darf es keine "Sleep" geben wie die meisten thread-helden es machen und sofern es keine resourcen ausserhalb des job systems sind (z.b. device buffer), sollte die ownership vom job-system aufgeloest werden und keine locks/mutex/critical sections etc. dafuer verwendet werden.

aber ich glaube sowas koennen die allerwenigsten aufsetzen, dazu braucht es viel erfahrung (und die bekommt man ja durch ein paar mal versuchen und bugfixen), dafuer hat man kaum die research zeit.

[Zeitschlitzverwendung]

rapso schrieb:

bei den 40 threads wuerde ich mir als nichts denken, kann gut sein dass ein video codec der 99% der zeit schlaeft sich einfach mal 8threads erstellt, nur damit diese nicht erst erstellt werden muessen wenn die erste cutscene kommt.

Und damit bremst er dann das Spiel aus, wenn für diese 8 Threads, die nichts tun, 8 Zeitschlitze vom OS zugewiesen werden.

[Erkenner des Problems]

Pria schrieb:

also ganz ehrlich, ich würde es bei dem ein oder anderen Spiel schon schätzen wenn die Macher mehr Threads verwenden würden. Ich denke da z.b an Skyrim. Beim Laden von neuen Mapteilen ging garnichts mehr, ausser dem Ton und das ist echt beschissen. Da merkt man garnichts mehr von "OpenWorld"

So etwas passiert, wenn die Entwickler alle schon ne SSD Eingebaut haben und ungetestet bleibt, wie sich das Spiel auf Rechnern mit Festplatte verhält.

Die SSD mag einen gewaltigen Peformanceschub gebracht haben, aber dies gilt nur für alte Anwendungen die auf Festplatten hin optimiert wurden.
In Zukunft wird der Performanceschub einem einfacheren Softwaredesign zum Opfer Fallen und die Software auf Festplatten unbenutzbar werden.

Das gleiche konnte man beim RAM Bedarf beobachten.
Früher als RAM noch knapp war, wurde auf den Platzverbrauch hin optimiert, entsprechend schnell und effizient hat das Programm dann auch gearbeitet.

Aber heute begnügt sich schon ein Browser mit 700 MB und mehr und ist trotzdem nicht schneller gestartet als früher zu Netscape 3.0 Zeiten.

Dein angesprochenes Problem ist also keine Frage der Threads, sondern der Datenstruktur und Art und weise, wie die Daten auf die Festplatte gespeichert werden.

[emmmnein]

Zeitschlitzverwendung schrieb:

rapso schrieb:

bei den 40 threads wuerde ich mir als nichts denken, kann gut sein dass ein video codec der 99% der zeit schlaeft sich einfach mal 8threads erstellt, nur damit diese nicht erst erstellt werden muessen wenn die erste cutscene kommt.

Und damit bremst er dann das Spiel aus, wenn für diese 8 Threads, die nichts tun, 8 Zeitschlitze vom OS zugewiesen werden.

Wenn ein Thread schläft, dann bedeutet das, dass dieser garnicht im Scheduling einbezogen wird bis seine Bedingung (condition) ein Signal bekommt. Also keine Sorge, der Thread kann technisch nichts bremsen.
Wenn du das ausprobieren willst, kannst du ein OpenMP Program erstellen, dann siehst du im Task Manager, dass dein Program mindestens soviele Threads hat wie deine CPU gleichzeitig verarbeiten kann, jedoch wird es nur ein Core/Thread deiner CPU auslasten wenn du keine OpenMP direktiven verwendest.

[Morle]

hustbaer schrieb:

Soll heissen: ich bin mir sicher dass von den 40 Threads die Starcraft 2 verwendet die meisten den Grossteil der Zeit über einfach heia machen.

Es kommt doch drauf an, für was man das Designmittel "Thread"s einsetzt:

a) Entkoppelung
b) Performancesteigerung

Im Falle von Entkoppelung setzt man für Module, die man in ihrer Ausführungsreihenfolge unabhängig sind, unterschiedliche Threads ein. z.B. mache ich das oft um eine GUI vom eigentlichen Logik zu entkoppeln. Man möchte ja durchaus noch eine bedienbare GUI haben auch wenn man ansonsten komplizierte Berechnungen ausführt.

Im Falle von Performancesteigung verteilt man die "Arbeit" z.B. eine komplizierte Berechnung, auf mehrere Threads. Es sollte einleuchten, dass dafür mehr Threads als physikalische Kerne verhanden sind zu keiner weiteren Performancesteigerung führt. Damit das klappt, muss man seine Arbeit in "Jobs" aufteilen können, die man dann an die Threads verteilt.

Um mal aufs Spiel zurück zu kommen: Ich würde also die "AI" nicht auf einem extra dafür bestimmten Thread laufen lassen. Die AI ist nämlich etwas, was sowieso in der Gameloop bei jedem Durchlauf berechnet werden muss. Man könnte die Berechnung der AI also als Job sehen. Wenn man richtig viel AI zu berechnen hat (z.B. weil viele Gegner, man denke mal an die 1000sende Gegner und Player, die ein MMORPG Spieleserver betreuen muss), könnte man sogar den "AI Job" in weitere Subjobs aufteilen. Es gibt natürlich noch andere Jobs: Netzwerkcode, Animation, Positonsupdate, Collision-Detection, ...
Die Jobs kann man dann auf so viele Workerthreads verteilen, wie man Kerne hat und damit den Rechner optimal ausnutzen.
Damit habe ich wohl deutlich gemacht, dass ich ein Job-basiertes Design wählen würde; auch schon weil es in Zukunft eher Rechner mit mehr Kernen als höherer Taktrate geben wird.

[kralo9]

Die Taktrate hat sowieso eine obere Grenze, zumindest bei unserem momentanen Forschungsstand. Gerade deswegen weichen die Prozessorhersteller auf Multicore aus.
Kann auch sein, dass ich mich irre...

[cooky451]

Graphen.

[rapso]

wenn man 40threads zur entkoppelung nutzen wuerde, koennte man ganz schnell das gegenteil von dem erreichen was man erreichen will. wenn 40threads um die cpu kaempfen, wird es recht unkontrolliert wer wann dran kommt und da die threads voneinander abhaengen, kann es sein, dass wartende threads rennen waehrend die auf die gewartet wird schlafen. wenn man dann mit prioritaeten versucht das problem zu loesen, kann das noch schlechter werden, weil dann z.b. die UI responsiver gemacht wird, auf kosten der berechnungen die auf der UI angezeigt werden sollten, dann hat man ein sich fluessig rotierendes sanduhrechen, quasi.

[Morle]

rapso schrieb:

wenn 40threads um die cpu kaempfen, ...

Unter dieser Bedingung hat man sowieso insgesamt zu wenig Rechenleistung und man kann nur noch das Beste draus machen.

... wird es recht unkontrolliert wer wann dran kommt und da die threads voneinander abhaengen, kann es sein, dass wartende threads rennen waehrend die auf die gewartet wird schlafen.

Wie soll das gehen? Wartende Threads werden nur aktiv, wenn die Bedingung weswegen sie blockiert worden sind aufgehoben worden ist, z.B. weil eine Berechnung in einem anderen Thread fertig gestellt worden ist und dieser deswegen ein Signal gesetzt hat: d.h. immer wenn ein zuvor blockierter Thread aktiv wird, kann er auch etwas sinnvolles tun.

[bauch]

gamer8o4 schrieb:

Ich erstelle gerade eine GameEngine (bin noch in der Planung) und frage mich was so das passende Anzahl an Threads ist, aus denen das Spiel besteht.

Wenn man noch solche Fragen stellt, sollte man noch keine Threads verwenden.

[rapso]

Morle schrieb:

rapso schrieb:

wenn 40threads um die cpu kaempfen, ...

Unter dieser Bedingung hat man sowieso insgesamt zu wenig Rechenleistung und man kann nur noch das Beste draus machen.

das ist eben der trugschluss, denn wenn man weit mehr threads erstellt als die hardware verarbeiten kann, ist man dem scheduling vom OS ausgeliefert und falls die 40threads wirklich sinnvoll arbeiten muesten z.b. auf einer dualcore maschine unter windows, kann es sein, dass der 1ms task den du in einen anderen thread ausgelagert hast, damit dein aktueller thread weiterarbeiten kann, erst in 10ms drankommt, wenn du dann darauf synchronisieren willst, wirst du erst 11ms spaeter weiterarbeiten, statt 1ms. das fuehrt dann dazu, dass, obwohl du eigentlich nur 60ms rechenarbeit hast, diese statt 30ms dann 50ms auf dem dualcore braucht und auf einem quadcore vielleicht wirklich in 15-20ms durchlief (was entgegen der normalen erwartung ist, dass programme hoeher skalieren als die core zahl).
ein system dass nur soviele threads wirklich auslastet wie cores/hw-threads vorhanden sind wuerde dieses problem nicht haben, wenn du dein scheduling selber machst.
und nein, priorities werden dir nicht zwingend helfen, windows scheduled alle 10ms falls alle cores busy sind. was zu dem weiteren problem fuehrt, kommunikation zwischen threads, wenn du 40hast aber nur 2cores, kann extrem lange latenzen aufweisen, selbst wenn du ein signal schickst und hoffst dass der andere thread gleich aufwacht.

das resultat solcher probleme ist, dass ein spiel dass zu 80% ein quadcore auslastet, es dennoch nicht schaft 100% eines dual cores auszulasten.

... wird es recht unkontrolliert wer wann dran kommt und da die threads voneinander abhaengen, kann es sein, dass wartende threads rennen waehrend die auf die gewartet wird schlafen.

Wie soll das gehen? Wartende Threads werden nur aktiv, wenn die Bedingung weswegen sie blockiert worden sind aufgehoben worden ist, z.B. weil eine Berechnung in einem anderen Thread fertig gestellt worden ist und dieser deswegen ein Signal gesetzt hat: d.h. immer wenn ein zuvor blockierter Thread aktiv wird, kann er auch etwas sinnvolles tun.

um das problem ein wenig einzudaemmen was ich im obigen absatz anriss, schlafen threads nicht sofort ein normalerweise. mutexe, signals/notifies etc. haben einen 'initialen spin'. stell dir vor du hast 2 cores und 2 threads, du implementierst eine LZH kompression (wie z.b. in zip), indem du einen core LZ komprimieren laesst, wenn der buffer voll ist, gibst du dem zweiten thread ein signal und der springt dann an und macht die H(uffman) kompression, wenn der buffer leer ist, gibt es ein signal an den ersten thread. wie du schon sagst, wird das zur "Entkoppelung" genutzt, aber hey, zwei threads, mit double buffering kannst du auch leicht doppelte performance haben. also hast du einen theoretisch zwei threads die packen, jedoch sind sie nicht synchron, einer braucht vermutlich leicht laenger als der andere. du wirst also dennoch beide threads immer wieder in den sleep state setzen wenn sie auf das signal warten. es kann sein, wenn du das hochfrequent genug machst, dass diese 100-1000 takte die windows dafuer braucht, viel mehr kosten als man durch das double-buffering usw. eigentlich sparen will. (sogar ohne double buffering hat man natuerlich dieses problem, weshalb man fuer sowas eigentlich schon immer fiber/coroutines nutzt).
aber du weisst ja, der anderer thread wird jederzeit aufwachen, das warten auf das signal ist nur synchronisierung (egal ob du das mit einem signal/notify oder exklusivem lock mittels mutex machst), bevor du also in den sleep state gehst, waere es doch schlau ein paar mal zu versuchen den zweiten buffer zu bekommen und dann erst in den sleep state zu gehen, oder?
genau das machen viele imlementierungen, gerade bei feinem threading (was bei vielen threads/jobs wahrscheinlich ist). dafuer gibt es keinen einheitlichen namen, wird "mutex with initial spin" oder "adaptive mutex" oder "hybrid lock" oder sonst wie genannt.

wenn man wirklich 40 unabhaengige context haben will um "Entkoppelung" zu betreiben, sollte man eher auf fiber bzw couritines umstellen, denn dann hat man auf applikationsebene kontrolle was passiert (wie oben im beispiel von kompression). damit meine ich nicht browser die auf 4cores 3threads erstellen, zum laden, decoden und UI/update, sondern schon spiele, die vielleicht die CPU nicht voll ausnutzen, aber dennoch diese art von lazy entkopplung nutzen (lazy, weil es nicht noetig ist wie z.b. bei UI, aber einfacher einzubauen ist, statt es richtig zu machen).
wenn man performance haben will, sollte man ein 'worker'-thread pro hardware thread haben. bei servern, wo man tausende requests handlen muss, ist man frueh auf das problem gestossen (nennt man C10K problem). einfach pro request ein thread erstellen klingt einfach und gut, zumal die requests ja eigentlich komplett unabhaengig sind, aber alleine schon das erstellen eines threads kann mehr kosten als das behandeln des requests. da kommt man schnell auf die idee "lass uns ein paar threads parken" und denkt natuerlich "wieviele?" -> mehr als es CPUs (bzw cores heutzutage) gibt macht keinen sinn. solche server laufen nicht nur stabiler, sie verarbeiten auch wirklich mehr.

[Scorcher24]

Hab nicht alles gelesen.
Aber ich würde die Anzahl der Kerne auslesen und dann genauso viele Threads maximal zulassen. Mainthread für Rendering und alles andere was schnell ausgeführt werden muss dann einem solchen Thread zuweisen.
Der Teufel liegt aber dann im Detail mit der Priorität der einzelnen Aufgaben.

[Morle]

rapso schrieb:

Morle schrieb:

rapso schrieb:

wenn 40threads um die cpu kaempfen, ...

Unter dieser Bedingung hat man sowieso insgesamt zu wenig Rechenleistung und man kann nur noch das Beste draus machen.

das ist eben der trugschluss, denn wenn man weit mehr threads erstellt als die hardware verarbeiten kann, ist man dem scheduling vom OS ausgeliefert und falls die 40threads wirklich sinnvoll arbeiten muesten z.b. auf einer dualcore maschine unter windows, kann es sein, dass der 1ms task den du in einen anderen thread ausgelagert hast, damit dein aktueller thread weiterarbeiten kann, erst in 10ms drankommt, wenn du dann darauf synchronisieren willst, wirst du erst 11ms spaeter weiterarbeiten, statt 1ms.

Das ist richtig, aber IMHO ein Sonderfall. Es gibt eigentlich immer Situationen, die zu einem ungünstigen Ergebnis führen. Um beim Beispiel GUI Entkopplung zu bleiben: Wenn ich weiss, dass meine Logik jeweils nur 1ms rechnet, dann brauche ich nichts zu entkoppeln. Wenn die Logik aber im Mittel 100ms rechnet, dann wird sich die Entkopplung lohnen. Wenn dann noch viele kleine Arbeitspakete mit jeweils 1ms dazwischen sind, kann man sich überlegen, ob man dafür einen Sonderfall schafft und diese direkt auf dem GUI Thread rechnen lässt, oder ob man in Abwägung eines sauberen Designs die Nachteile in Kauf nimmt und sie durch sein uniformes Worker-Thread System ausführen lässt.

Weiterhin ist es ein deinem Beispiel so, dass ja "jemand anderes" gerechnet hat und dadurch deine Verzögerung entstanden ist. Die Rechenleistung ist also nicht verloren gegangen. Die Latenz des Systems hat sich also erhöht, aber der Gesamtdurchsatz hat nicht zwangsläufig darunter gelitten. Daher auch hier: Wenn Du den Sonderfall hast, dass die GUI absolut bevorzugt bedient werden soll, dann müsste man dies halt im Design auf irgendeine Art und Weise berücksichtigen.

Meiner Erfahrung nach tut man gut daran seine Module so gut wie möglich zu strukturieren und abszukapseln. Wenn man jetzt irgendwann bemerkt, dass die Latenz der GUI oder eines anderen Subsystems unter wegen solchen Entkopplungen leidet, kann man immer noch entscheiden für diese irgendwo einen Sonderfall einzubauen.

[rapso]

Morle schrieb:

rapso schrieb:

Morle schrieb:

rapso schrieb:

wenn 40threads um die cpu kaempfen, ...

Unter dieser Bedingung hat man sowieso insgesamt zu wenig Rechenleistung und man kann nur noch das Beste draus machen.

das ist eben der trugschluss, denn wenn man weit mehr threads erstellt als die hardware verarbeiten kann, ist man dem scheduling vom OS ausgeliefert und falls die 40threads wirklich sinnvoll arbeiten muesten z.b. auf einer dualcore maschine unter windows, kann es sein, dass der 1ms task den du in einen anderen thread ausgelagert hast, damit dein aktueller thread weiterarbeiten kann, erst in 10ms drankommt, wenn du dann darauf synchronisieren willst, wirst du erst 11ms spaeter weiterarbeiten, statt 1ms.

Das ist richtig, aber IMHO ein Sonderfall. Es gibt eigentlich immer Situationen, die zu einem ungünstigen Ergebnis führen. Um beim Beispiel GUI Entkopplung zu bleiben: Wenn ich weiss, dass meine Logik jeweils nur 1ms rechnet, dann brauche ich nichts zu entkoppeln. Wenn die Logik aber im Mittel 100ms rechnet, dann wird sich die Entkopplung lohnen. Wenn dann noch viele kleine Arbeitspakete mit jeweils 1ms dazwischen sind, kann man sich überlegen, ob man dafür einen Sonderfall schafft und diese direkt auf dem GUI Thread rechnen lässt, oder ob man in Abwägung eines sauberen Designs die Nachteile in Kauf nimmt und sie durch sein uniformes Worker-Thread System ausführen lässt.

die idee UI in einem thread laufen zu lassen ist aber auch nur erfolgreich weil wenn es relativ wenig threads in realtion zur den cores gibt. erstellst du auf einem single core einen UI thread und hast dann noch 3threads die wirklich arbeiten muessen, wird dein UI thread unter windows alle 40ms drankommen und dann hast du nicht viel gewonnen. natuerlich, den UI thread high priority machen (was das erste zeichen von fail ist ), aber dann bekommen die arbeitenden threads viel weniger zeit, UI ist responsiv, user wartet dennoch ewig -> natuerlich, Sleeps einbauen (das zeichen an dem man sicher sein kann, man hat es falsch gemacht).

Weiterhin ist es ein deinem Beispiel so, dass ja "jemand anderes" gerechnet hat und dadurch deine Verzögerung entstanden ist. Die Rechenleistung ist also nicht verloren gegangen. Die Latenz des Systems hat sich also erhöht, aber der Gesamtdurchsatz hat nicht zwangsläufig darunter gelitten. Daher auch hier: Wenn Du den Sonderfall hast, dass die GUI absolut bevorzugt bedient werden soll, dann müsste man dies halt im Design auf irgendeine Art und Weise berücksichtigen.

wenn wir hier bei forumthema "spiele(programmierung) bleiben, aeussert sich die latenz entweder in
- schlechterer framerate, heisst also dass der thread der ewig gewartet hat, wenn er endlcih dran kommt, alleine laeuft und nichts mehr fuer die anderen cores zu tun ist.
- input lag, du drueckst also eine taste und es dauert ueber 100ms bis du die reaktion siehst, system ist zwar top ausgelastet, du hast 30fps, aber das spiel laeuft wie ein schwam, schau z.b. das video da an: http://www.eurogamer.net/articles/digitalfoundry-lag-factor-article
- framerate ist instabil, je nach scheduling deiner threads (die ja nicht konsistent ist), laeuft mal das ganze optimal und mal so suboptimal wie moeglich, du hast mal 60fps, mal 20fps. sowas fuehlt sich bei spielen schlechter an als durchgehend 20fps, da viele spiele die position des naechsten frames anhand der dauer des vorherigen frames bestimmen, entsprechend wartest du mal 16ms um ein fortschrit von 50ms anzuzeigen, mal 50ms um einen fortschrit von 16ms anzuzeigen.

Meiner Erfahrung nach tut man gut daran seine Module so gut wie möglich zu strukturieren und abszukapseln. Wenn man jetzt irgendwann bemerkt, dass die Latenz der GUI oder eines anderen Subsystems unter wegen solchen Entkopplungen leidet, kann man immer noch entscheiden für diese irgendwo einen Sonderfall einzubauen.

saubere kapselung ist halt der erste schritt, wenn man es durchziehst, dann kann man auch dafuer sorgen dass die UI responsiv ist.
UI in einen thread zu packen, ist eher eine notloesung, da die implementierung einer sauberen loesung im nahinein unverhaeltnis lange dauern wuerde. es verursacht oft viele bugs und unvorhersehbare dinge, zudem suggestiert es dem user ein design konzept das nicht existiert. z.b. nimmt ein user an er kann dann einfluss haben auf etwas, was im hintergrund laeuft. in z.b. visual studio, hat man dann einfach die buttons in menues ausgegraut->die UI funktioniert, hat aber keine funktionalitaet. eine saubere kooperation zwischen modulen ist halt kein programming oder engineering job, sondern architecture, quality of service und management.

[Morle]

rapso schrieb:

saubere kapselung ist halt der erste schritt, wenn man es durchziehst, dann kann man auch dafuer sorgen dass die UI responsiv ist.
UI in einen thread zu packen, ist eher eine notloesung, da die implementierung einer sauberen loesung im nahinein unverhaeltnis lange dauern wuerde.

Also vielleicht sollte man hier auch nochmal zwischen Spiel und Windows-Anwendung unterscheiden. Was bedeutet es denn eine GUI responsive zu halten?

a) In Windows-Anwendungen, dass weiterhin Windows-Nachrichten verarbeitet werden. Entweder hat man dann in seinem "Arbeites-Code" sowas schreckliches wie "ProcessMessages" oder man lagert halt die Arbeit aus, womit man dann die GUI auf einem seperaten Thread laufen hat. Von daher finde ich sowas "per Design" von vorneherein zu implementieren ist keine Notlösung.

b) Spiele. Da ist die GUI eigentlich ein Teil der normalen Spiel-Szene, die als Overlay über den Rest gerendert wird. Dies ist also Teil des Renderings und normalerweise da zu finden, wo man auch seinen restliche GameLoop bearbeitet. Wie ich das im Falle von Spielen machen würde, hatte ich ja schon geschrieben. Es gäbe da jedenfalls keinen explusiven GUI Thread.

Im Allgemeinen stimme ich Dir aber zu, dass eine vernünftige Architektur Vorraussetzung ist.