Threads: optimale Nutzen/Prozessorleistung-Optimierung

[Thorus]

Hallo,

ich habe einen Thread, der das tut was er soll. Das Problem ist nur, dass die Prozessorleistung immer auf 100% ist.

Code:

uses rdtsc;

procedure TMyThread.Execute;
var
  Zeit:int64;
begin
  Zeit := cpuGetTick;
  while not Terminated do
  begin
    if cpuGetMs(Zeit) > 9 then
    begin
      Zeit := cpuGetTick;
      Synchronize(TueEtwas);
    end;
  end;
end;

Dieser Thread ruft die Methode TueEtwas maximal so 100 mal in der Sekunde auf.
Ich hatte auch probiert vor "if cpuGet.." Sleep(1) zu setzen. Dies funktioniert zwar, ist aber viel zu langsam. Mit Sleep war die Prozessorbelastung aber minimal, so wie es sein sollte.
75-100 mal pro Sekunde sollten es schon sein.

Das Problem bei Sleep ist auch, dass, wenn für das auszuführende TueEtwas 10 ms verbraucht werden, dann wartet er mit Sleep trotzdem noch eine Weile, obwohl TueEtwas eigentlich sofort wieder ausgeführt werden sollte.

Wenn Sleep(1) wirklich nur 1 ms brauchen würde, wär das ja ok, aber das tut es wohl nicht.

[Luckie]

Zitat:

Zitat von Thorus

Hallo,

ich habe einen Thread, der das tut was er soll. Das Problem ist nur, dass die Prozessorleistung immer auf 100% ist.

Code:

uses rdtsc;

procedure TMyThread.Execute;
var
  Zeit:int64;
begin
  Zeit := cpuGetTick;
  while not Terminated do
  begin
    if cpuGetMs(a1) > 9 then
    begin
      Zeit := cpuGetTick;
      Synchronize(TueEtwas);
    end;
  end;
end;

Dieser Thread ruft die Methode TueEtwas maximal so 100 mal in der Sekunde auf.

Warum hast du dafür einen Thread, wenn du doch alles im Kontext des Hauptthreads deines Fensters ausführst? Dein Problem ist einfach ein Designfehler.

Zitat:

Ich hatte auch probiert vor "if cpuGet.." Sleep(1) zu setzen. Dies funktioniert zwar, ist aber viel zu langsam. Mit Sleep war die Prozessorbelastung aber minimal, so wie es sein sollte.
75-100 mal pro Sekunde sollten es schon sein.

Das Problem bei Sleep ist auch, dass, wenn für das auszuführende TueEtwas 10 ms verbraucht werden, dann wartet er mit Sleep trotzdem noch eine Weile, obwohl TueEtwas eigentlich sofort wieder ausgeführt werden sollte.

Hier fehlt wohl das Verständnis, was Sleep eiegntlcih macht. Deswegen: Sleep.

[Thorus]

Ich hatte mir einige Beiträge hier im Forum durchgelesen und das mit sleep im Thread gefunden. Wie das funktioniert, wusste ich wirklich nicht. Und in der Delphi-Hilfe hatte ich nichts gefunden.
So wie ich es bei MSDN gelesen habe, ist sleep also äußerst ungünstig dafür?

Zitat:

Warum hast du dafür einen Thread, wenn du doch alles im Kontext des Hauptthreads deines Fensters ausführst? Dein Problem ist einfach ein Designfehler.

Ich verstehe leider nicht, wieso das falsch ist, bzw wie ich es anders machen sollte. Ich habe einiges durchsucht, um das richtige zu finden, bin aber leider nicht fündig geworden. Dein Turturial hatte ich auch mal vor einiger Zeit durchgelesen und fand es sehr informativ, aber eine Delphi-Umsetzung dafür war glaube ich nicht dabei.

Im Multimedia-Forum hatte ich auch was über GameLoop und Threads gelesen. GameLoop bedeutet ja gerade, dass so eine Schleife ständig ausgeführt wird.

[jfheins]

Du führst eine Prozedur immer wieder aus, nicht mehr. Dafür sind Threads eigentlich Overkill ... ;-)
Du könntest stattdessen genausogut eine Entsprechende Schleife im Hauptthread machen, ab und zu Application.ProcessMessages und gut ist.

Du könntest auch einen Timer für diese Aufgabe nehmen, beachte aber, dass dieser nur eine Auflösung von ~20 ms hat.

[Luckie]

Zitat:

Zitat von Thorus

Ich verstehe leider nicht, wieso das falsch ist, bzw wie ich es anders machen sollte.

Na das:

Delphi-Quellcode:

Synchronize(TueEtwas);

sorgt dafür das die Routine TuWas im Kontext des Hauptthreads ausfegührt wird. Was bedeutet, dass dein Thread so lange wartet bis die Routine fertig ist. Desweiteren könnte ich mir vorstellen, dass dein Hauptfenster trotz des Threads nicht mehr reagiert.

Zitat:

Dein Turturial hatte ich auch mal vor einiger Zeit durchgelesen und fand es sehr informativ, aber eine Delphi-Umsetzung dafür war glaube ich nicht dabei.

Wie so? da sind doch Demos dabei: http://tutorials.luckie-online.de

[Thorus]

Hmmm, sind die Demos die 7z-dateien? wenn ja, weiß leider nichts damit anzufangen. (hab auch nicht weiter gesucht, wo steht, was das überhaupt ist) edit: ach ups, da is ja ne zip datei bei (wie konnt ich die nur übersehen, guck ich gleich mal rein in die demons)

Das Synchronize ist auch wichtig und genau das soll es auch tun.
Das ausführen des TuEtwas dauert auch nicht sonderlich lange. Normal vielleicht so 1-2 ms. Die Prodzedur soll aber nur alle 10-15 Millisekunden ausgeführt werden. Da ist genug Zeit dazwischen, wo die Schleife unnsinnig durchlaufen wird.

Das Programm funktioniert wunderbar. Mit Priority Lower kann ich sogar ohne Abstriche in WindowsMedia Player Videos nebenbei gucken. Mit Pritority Normal is der Sound dann etwas stockend. Und Higher geht auch ohne große Probleme.

Ich habe damit auch ein fertiges Spiel programmiert, was wunderbar funktioniert. Nur, wenn ich TaskMananger aufmache sehe ich, dass CPU Auslastung 100% ist. Es stört andere Prozesse kaum, ist aber trotzdem irgendwie unsinnig, immer auf 100% laufen zu lassen.

Ich habe davon noch einen anderen Thread, weil ich zwei benötige. Eine Key-Thread, der für die Tastatur da ist und einen, der dann das Spiel berechnet und auswertet.

[Tyrael Y.]

100% CPU Auslastung ist doch nicht schlimm, wenn keine anderen Prozesse beeinträchtigt sind.

Dein Programm versucht optimal zu laufen und holt sich alle verfügbaren Resourcen, wenn ein anderer Prozess Resourcen braucht, gibt ja dein Programm welche ab.

Deshalb find ich 100%-CPU Auslastung grundsätzlich nicht schlimm, sondern nur wenn andere Prozesse beeinträchtigt werden.

mfg

[Thorus]

Von den Turitalbeispielen konnte ich die Hälfte nicht ausprobieren, weil irgendwelche Komponenten fehlen. Liegt wohl an der DelphiVersion (Delphi5)
Und von dem was ging, war nich das dabei, was ich suchte. War glaub immer 100% Auslastung.


100% CPU-Auslastung ist echt nicht schlimm?
Der Prozessor arbeitet doch dann die meiste Zeit unnötig und verbraucht bestimmt mehr Strom und wird auch bestimmt nicht sonderlich geschont, wenn er dauernd im Dauerbetrieb ist, oder?

Ich habe mal bei anderen kleinen Spielen oder ähnliches geguckt und die laufen nicht immer mit 100% und haben trotzdem ganz gute Grafik. Und auch zB der WindowsMedia Player läuft bei mir nur mit ca 10% Auslastung bei Videos und da wird sicherlich noch einige viel genauer Zeitgeber benötigt, als es bei mir der Fall ist.

Irgendwas gibt es doch bestimmt, um das zu vermeiden, nur weiß ich nicht wie.
So was wie die Sleep-Funktion würde ja funktionieren, nur ist es leider etwas zu langsam und hat eventuell sonst noch n Haken.

[Michael_Bayer]

Doofe Frage, aber was ist es denn, was nur alle 10-15 ms ausgeführt werden darf und wird?

[Thorus]

Wie ich erst schrieb. Tastaturabgfrage, was gedrückt wurde zB.
Dann ein Thread zum Berechnen des Spieles, was ich halt nur alle 15-20 ms brauchen und dann auch noch das zeichnen des Bildes, wo 50 FPS völlig ausreichen. Mehr wäre unnötig und belastet den Prozessor nur unnötig.

Noch vergessen zu sagen, das Synchronize ist auch sehr wichtig, damit die TuEtwas-Prozedur nicht parallel mehrmals ausgeführt wird. Wenn der PC sehr langsam ist, bekommt man dadurch auch nur weniger FPS hin, was auch beabsichtig ist. Nur mehr als 50-75 FPS benötige ich wie gesagt nicht und wenn es öfter berechnet wird, ist das zwar nicht falsch, aber sinnlos.

[Tubos]

Zitat:

100% CPU-Auslastung ist echt nicht schlimm?
Der Prozessor arbeitet doch dann die meiste Zeit unnötig und verbraucht bestimmt mehr Strom und wird auch bestimmt nicht sonderlich geschont, wenn er dauernd im Dauerbetrieb ist, oder?

Also das ist wirklich egal ;)
Bei den meisten Spielen ist die CPU immer auf annähernd 100%.
Wenn meine CPU niemals zu 100% ausgelastet wäre, dann war sie ein Fehlkauf und ich hätte auch eine leistungsschwächere nehmen können ^^

[Michael_Bayer]

Zitat:

Zitat von Tubos

Zitat:

100% CPU-Auslastung ist echt nicht schlimm?
Der Prozessor arbeitet doch dann die meiste Zeit unnötig und verbraucht bestimmt mehr Strom und wird auch bestimmt nicht sonderlich geschont, wenn er dauernd im Dauerbetrieb ist, oder?

Also das ist wirklich egal ;)
Bei den meisten Spielen ist die CPU immer auf annähernd 100%.
Wenn meine CPU niemals zu 100% ausgelastet wäre, dann war sie ein Fehlkauf und ich hätte auch eine leistungsschwächere nehmen können ^^

Aber es ist schon ein Unterschied, ob die CPU sinnvolle oder schwachsinnige Dinge tut...

[Luckie]

Zitat:

Zitat von Thorus

Die Prodzedur soll aber nur alle 10-15 Millisekunden ausgeführt werden. Da ist genug Zeit dazwischen, wo die Schleife unnsinnig durchlaufen wird.

Na dann mach doch ein

Delphi-Quellcode:

Sleep(15)

.

[Thorus]

Sleep(15) funktioniert leider in zweilei Hinsichten nicht, wie ich oben schon geschrieben haben.

Wenn die Prozedur auf einem langsameren PC ausgeführt wird, benötigt sie vielleicht 10 ms (irgendeine ausgedachte Zahl)
Und wenn ich danach noch 15 ms warte, dann wird sie ja erst nach 25 ms wieder ausgeführt, was nicht beabsichtig ist.
Selbst auf dem langsameren PC könnte es alle 15ms ausgeführt werden. Da es aber falsch programmiert ist, geht es nicht.

Desweiteren funktionier Sleep nicht so schnell. Sleep(1) zB wartet um einiges länger als 1 ms!
Ich weiß nicht genau, wie nun der genaue Wert von Sleep ist, aber wenn ich bei mir Sleep(1) einfüge, ist es bedeutend langsamer als ohne.

[Basilikum]

um einen bestimmten Interval einhalten zu können, eignet sich CreateWaitableTimer

[Christian Seehase]

Moin Thorus,

bei Sleep steht u.a.:

Zitat:

Zitat von PSDK - Sleep - Remarks

...for at least the specified number of milliseconds,....
...Note that a ready thread is not guaranteed to run immediately.

Vielleicht wirst Du ja was mit CreateEvent und WaitForSingleObject

[Thorus]

Zitat:

Zitat von Basilikum

um einen bestimmten Interval einhalten zu können, eignet sich CreateWaitableTimer

http://www.delphipraxis.net/internal...t.php?p=149186

Code:

hClose := CreateEvent( ??? ); // Event damit der Thread sauber beendet werden kann 
  hTimer := CreateWaitableTimer(nil, false, nil); 
  SetWaitableTimer(hTimer, ???);

Dort steht, dass der Timer irgendwie gar nicht gut dafür geeignet ist. Selber ausprobiert habe ich es aber nicht.

CreateEvent hat sich dann damit auch gleich erledigt wie es scheint.

Wenn man wüsste, wie zB der MediaPlayer das macht. Aber ist ja nix Open Source *g*

[Tubos]

QueryPerformanceCounter
IMHO die beste Lösung wenn es wirklich exakt sein muss (--> bei einem Spiel).

[Basilikum]

Zitat:

Zitat von Thorus

Dort steht, dass der Timer irgendwie gar nicht gut dafür geeignet ist. Selber ausprobiert habe ich es aber nicht.

dort ging es aber meines Wissens um den Timer der per Window-Message gefeuert wird.
bei dem waitable Timer kannst Du in einem separaten Thread per WaitForSingleObject auf die Fälligkeit warten. Ist auf jeden Fall feiner als ein Sleep(), zudem wird das Problem von den unterschiedlichen Abarbeitungszeiten auf verschieden schnellen Rechnern gelöst. Gleichzeitig wird jedoch nicht mehr 100% CPU-load generiert...

[Robert_G]

Was mir auffällt...
Thorus vergisst, dass es noch einen Scheduler gibt. ;)
Wenn du sleep(15) ausführst, wird die dir zugewiese Zeitscheibe sofort abgebrochen und der nächste Thread/Prozess bekommt eine.
Der Scheduler wird dir auch mindestens die 15ms Ruhe gönnen, die du angefordert hast. Da die ganze Verwaltung aber auch etwas Zeit kostet kannst du dir sicher sein, dass du länger wartest. ;)
Es ist auch möglich, dass zwischen deiner Abgabe der CPU Zeit und einer erneuten Zuweisung mehrere andere threads ranwollen -> Du wartest also noch länger. :mrgreen:

In Luckies Thread Tutorial dürfte das erklärt werden. ;)

[SirThornberry]

dann zähl doch einfach wieviel frames du auf dem entsprechenden rechner schaffst und passe somit die parameter von sleep dynamich an bzw. lasse sleep aus

[Thorus]

Zitat:

QueryPerformanceCounter
IMHO die beste Lösung wenn es wirklich exakt sein muss (--> bei einem Spiel).

das ist doch nur ein Taktgeber, wenn ich mich nicht verguckt habe? Ein Takgeber habe ich doch einen genauen.

Zitat:

dort ging es aber meines Wissens um den Timer der per Window-Message gefeuert wird.
bei dem waitable Timer kannst Du in einem separaten Thread per WaitForSingleObject auf die Fälligkeit warten. Ist auf jeden Fall feiner als ein Sleep(), zudem wird das Problem von den unterschiedlichen Abarbeitungszeiten auf verschieden schnellen Rechnern gelöst. Gleichzeitig wird jedoch nicht mehr 100% CPU-load generiert...

Weiß nicht, wie das damit gehen soll. Mit APIs tue ich mich immer schwer und wüsste auch nicht, wie ich das überhaupt hinbekommen soll. Falls es irgendwo eine Teil-Lösung gibt, wäre es nicht schlecht.

@robert_g
aja, jetzt erinner ich mich auch wieder. Sleep sollte man wohl lieber komplett vergessen. *g*

Zitat:

dann zähl doch einfach wieviel frames du auf dem entsprechenden rechner schaffst und passe somit die parameter von sleep dynamich an bzw. lasse sleep

Das geht ja irgendwie nicht. Die Frames-Anzahlen schwanken doch bei jedem Spiele dauernd, wenn sie nicht am eingestellen Maximum sind. Je Nach Animationsaufwand. Desweiteren lass einen anderen Thread von Windows sich auf einmal starten oder sonst irgendwas, was der User im Hintergrund laufen lässt und schwups, verändert sich das alles.

Scheint wohl doch n schwierigeres Problem zu sein :(

[Christian Seehase]

Moin Thorus,

mir fallen da noch ein paar Stichworte ein:
SetThreadPriority, SetPriorityClass (mit Vorsicht zu geniessen, wenn Du auf REALTIME stellst ;-)) ausserdem könntest Du Dir mal die [msdn]"Multimedia Timers"[/msdn] anschauen.
Letztere sollen die höchste Auflösung und Genauigkeit haben.

[Thorus]

Selbst mit ThreadPriority Idle ist CPU-Auslastung 100%, weil es ja, wenn kein anderer Prozess weiter da ist, dann ja auch voll ausgeführt wird.

Multimedia Timer sieht kompliziert aus :(

Ich glaub, dann lass ich das lieber erstmal so und lass den Prozessor viel unnötige Arbeit tun. (Solange ich da nicht arbeiten muss *g*)

[Luckie]

Und wenn es nur ab Windows 2000 laufen muss: CreateTimerQueueTimer.

[Thorus]

http://www.delphipraxis.net/internal...ct.php?t=30870

letzer Post:

Zitat:

Entweder dort herunterladen oder warten bis wir das SourceForge-Projekt fertig haben. Wir stricken gerade fleissig dran.

Ist das für Delphi schon fertig? Oder war das auf den CBuilder bezogen?

erster Post:

Zitat:

In einem Demo-Projekt hab eich sie getestet und es funktioniert.

Ist das Demo-Programm zufällig irgendwo verfügbar? Habe leider kaum Ahnung, was diese Parameter alles bedeuten und ob ich sie dann auch richtig benutze.
Bei MSDN sind die Paramter irgendwie anders.

[Luckie]

Das hat mit meiner Unit nichts zu tun.