CPU-Auslastung mit pthreads

TdZ

Ich denke schon, daß SDL threadsicher ist, basiert doch das SDL-eigene Threadsystem soweit ich weiß auch auf pthreads. Nur möchte ich eigentlich im "Engine-Kern" kein SDL verwenden, da die Einzelkomponenten wie Input und Video recht flexibel bzw. austauschbar gehalten sind und daher SDL unverbindlich integriert ist. Davon abgesehen.. ist es eigentlich prinzipiell klug, einen so zeitkritischen Prozess wie Eingabe/Ausgabe oder grafische Darstellung mittels künstlichen Pausen zu verlangsamen?

Aber mal zu deinen Bedenken bezüglich des Designs: Kannst du das evtl. näher erläutern? Ich dachte eigentlich, die allgemeine Tendenz geht dahin, dass man mehr und mehr in Threads auslagert - hab' ich das etwas falsch verstanden?

TdZ schrieb:

Ich denke schon, daß SDL threadsicher ist, basiert doch das SDL-eigene Threadsystem soweit ich weiß auch auf pthreads.

Nicht Alles in der SDL ist Threadsicher. Das Event-Management schon. Die meinsten Video-Funktionen nicht. Du musst verdammt aufpassen.

TdZ schrieb:

Nur möchte ich eigentlich im "Engine-Kern" kein SDL verwenden, da die Einzelkomponenten wie Input und Video recht flexibel bzw. austauschbar gehalten sind und daher SDL unverbindlich integriert ist.

Welchen Sinn soll das haben? Wenn du in einer Komponente die SDL verwendest, bist du auf die SDL angewiesen. Dann kannst du sie genauso gut in allen Komponenten verwenden. Die SDL kümmert sich um die Kommunikation mit dem Betriebssystem. Und das Event-System ist da recht gut.

TdZ schrieb:

Davon abgesehen.. ist es eigentlich prinzipiell klug, einen so zeitkritischen Prozess wie Eingabe/Ausgabe oder grafische Darstellung mittels künstlichen Pausen zu verlangsamen?

Das kann man pauschal nicht beantworten.

TdZ schrieb:

Aber mal zu deinen Bedenken bezüglich des Designs: Kannst du das evtl. näher erläutern? Ich dachte eigentlich, die allgemeine Tendenz geht dahin, dass man mehr und mehr in Threads auslagert - hab' ich das etwas falsch verstanden?

Es macht nicht so viel Sinn. Wenn du deinen Sound-Mixer in einen eigenen Thread auslagerst, ist das nicht schlecht. Wenn du aber die Eingabe in einen eigenen Thread packst, ist das schon schlecht, denn die SDL bietet dir ein Event-System, dass du dann nur in einem anderen Thread abfragst. Damit ist die Hauptarbeit schon von der SDL getan. Du generierst also nur mehr Aufwand für Synchronisation.

TdZ

Welchen Sinn soll das haben? Wenn du in einer Komponente die SDL verwendest, bist du auf die SDL angewiesen. Dann kannst du sie genauso gut in allen Komponenten verwenden. Die SDL kümmert sich um die Kommunikation mit dem Betriebssystem. Und das Event-System ist da recht gut.

Ja, das ist schon ein Argument... Ich werde da auf deinen Rat hören und SDL als festen Bestandteil integrieren.

Dass das Video-System nicht threadsicher ist, habe ich leider auch gerade gemerkt. Aber nachdem Du mir da einige Zusammenhänge nähergebracht hast, ergibt es wirklich kaum einen Sinn, Input und Video in Threads auszulagern. Anders sehe ich da Dinge wie Physik z.B., da würde sich wohl ein Thread eignen. Aber bis dahin ist's sowieso noch ein weiter Weg...

Also, dann wieder den alten Weg beschreiten und die fundamentalen Dinge in den Main-Loop zurückschieben...

Vielen Dank, daß du Dir die Zeit genommen hast, hier ein, zwei Dinge zu erläutern, hat mir sehr geholfen!

simon.gysi

Anders sehe ich da Dinge wie Physik z.B., da würde sich wohl ein Thread eignen

Warum?

TdZ

Einerseits - so dachte ich - wegen der Ressourceneinteilung bei Multikern-Prozessoren. Der zweite Grund ist natürlich absolut nicht universell, aber in vielen Spielmodi dient die Physik lediglich unterstützend zum Ambiente, also ist hier die Priorität entsprechend niedrig.

TdZ schrieb:

Einerseits - so dachte ich - wegen der Ressourceneinteilung bei Multikern-Prozessoren.

Was soll denn da verteilt werden? Deine Physik muss doch erst berechnet sein, bevor du etwas zeichnen kannst. D.h. der eine Thread muss auf den anderen warten. Nicht so toll.

Parallelisierung macht sinn, wenn du die komplette Physikberechnung (wenn diese aufwändig wird) auf meherere CPU-Cores aufteilen kannst.

TdZ schrieb:

Der zweite Grund ist natürlich absolut nicht universell, aber in vielen Spielmodi dient die Physik lediglich unterstützend zum Ambiente, also ist hier die Priorität entsprechend niedrig.

Und dann willst du den Resourcen-Verbrauch erhöhen, indem du dafür einen eigenen Thread startest, wenn du es eh kaum brauchst?

TdZ

ProgChild schrieb:

Parallelisierung macht sinn, wenn du die komplette Physikberechnung (wenn diese aufwändig wird) auf meherere CPU-Cores aufteilen kannst.

Das hab ich doch gesagt, oder nicht? Vermutlich hab ich mich ein wenig schwammig ausgedrückt, aber gemeint habe ich jedenfalls dasselbe.

C++ Forumbot

Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum Spiele-/Grafikprogrammierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

rapso

ich bin da der meinung ProgChilds. einerseits teilst du alles auf mehrere threads auf. andererseits willst du die auslastung aber runterschrauben mit sleep. mach es doch gleich nur mit einem thread, das OS wird dann die aufgabe auf alle cores recht gleichmaessig verteilen und du hast was du wolltest.

du bohrst ja auch nicht dein moped auf, dass es 100rasen kann um dann eine 25km/h drosselung einzubauen (rein symbolisch gemeint).

mad_martin

rapso schrieb:

mach es doch gleich nur mit einem thread, das OS wird dann die aufgabe auf alle cores recht gleichmaessig verteilen und du hast was du wolltest.

Bist du dir da ganz sicher? Zumindest bei Windows kann man erkennen, dass es bei Ein-Thread-Programmen eben keine Lastverteilung gibt. Oder meintest du das anders und ich verstehs nur so früh noch nicht?

rapso

mad_martin schrieb:

rapso schrieb:

mach es doch gleich nur mit einem thread, das OS wird dann die aufgabe auf alle cores recht gleichmaessig verteilen und du hast was du wolltest.

Bist du dir da ganz sicher? Zumindest bei Windows kann man erkennen, dass es bei Ein-Thread-Programmen eben keine Lastverteilung gibt. Oder meintest du das anders und ich verstehs nur so früh noch nicht?

wenn du nur einen thread hast, aber 4 cores, bekommt jeder core in etwa 25% vom thread. versucht eigentlich jedes OS. auf die schnelle konnte ich das hier fuer dich ergooglen von winrar: http://f0dder.reteam.org/gfx/dualcore_winrar.png

auf einem core laeuft so ein programm natuerlich unter 100% last, wenn nichts anderes zu tun ist, aber das verhalten ist eigentlich das gewollte. sobald es andere aufgaben gibt, wird das OS sie 'fair' verteilen. selbst 'sleep' aufzurufen um in die taskverteilung eines OS einzugreifen hat eigentlich kaum sinn. sleep funktioniert deswegen auch nicht auf ms basis, sondern hat die granularitaet von den "time-slieces" vom Sheduler vom OS, (das gilt fuer windows ) also ca 10-15ms. das hat im endeffekt die wirkung dass man keine stabilen 60fps hat, sondern mal 4frames am stueck und dann steht das ganze.

Sleep wuerde ich also so ziemlich nie verwenden. entweder
- den thread die ganze zeit laufen lassen
oder (und ich glaube das hat der threadstarter eigentlich gewollt)
- mit z.b. waitforsingleobject+events bzw. Conditions+signals die threads schlafen lassen wenn sie nichts zu tun haben und dann bei gebrauch aufwecken.

naja, ist nur meine meinung