Schleife beschleunigen sinnvoll?

[EWeiss]

Zitat von jaenicke:

Zitat von EWeiss:

Ich weiss das sollte man nicht tun ..
Thread.Sleep(1) aber es wirkt wunder.

Im Gegenteil, im Thread ist das genau richtig.
Das wollte ich vorhin auch fragen, ob du da womöglich ne Schleife while not Terminated ohne Pause drin hast.

Hmm du sagst genau das gegenteil von jemand anderen aus dem Mediaportal Forum.
Nicht das ich dir nicht glauben würde.. aber es irritiert etwas wenn man mehrere meinungen
von einem Thema erhält und jeder sagt was anderes.

Na ja letztendlich funktioniert es so. Was die dann daraus machen lass ich mal dahin gestellt.
Auf jedenfall konnte da was nicht stimmen das ein Thread einen Kern zu 100% auslastet.
Immer wieder eine Freude anderen Quelltext zu debuggen nur um zu beweisen das es nicht
an der eigenen Arbeit(Anwendung) liegt.

Maulen können die alle

gruss

[nahpets]

Zitat von jaenicke:

Das wollte ich vorhin auch fragen, ob du da womöglich ne Schleife while not Terminated ohne Pause drin hast.

Mach' mal 'ne Schleife ala repeat until true = false; und schau auf die CPU-Last. while not Terminated dürfte den gleichen Effekt haben. Zumindest aus meiner Erfahrung macht jede Schleife ohne ein ProcessMessages, Sleep oder dergleichen keine Pause bei 100% CPU-Last. Ist die CPU-Last in so einer Schleife kleiner, dann ist da eventuell irgendwo eine andere Routine im Aufruf, die doch mal ein Päuschen einlegt (warten auf die Festplatte, laden von Daten aus 'nem Stream von 'nem Server irgendwo im weiten Netz... Dem, der dies da in dem anderen Forum schrieb

Zitat:

Hmm du sagst genau das gegenteil von jemand anderen aus dem Mediaportal Forum.

, würd' ich erstmal nix mehr glauben, jedenfalls dann, wenn es um hohe CPU-Last geht. Die bekomme ich in prinzipiell lang laufenden Schleifen nunmal nur dann runter, wenn ich dem Betriebssystem und anderen Programmen die Möglichkeit gebe, auch mal tätig zu werden. Und dazu muss ich (sporadisch) eben mal die Kontrolle abgeben, sprich: Sleep, ProcessMessages...

[EWeiss]

Zitat:

Mach' mal 'ne Schleife ala repeat until true = false; und schau auf die CPU-Last

Das ist mir schon klar.. Danke.
Ich wußte halt nur nicht das Thread.Sleep lediglich eine Pause einlegt.

Mann kann halt nicht jede Eigenart jeder Sprache kennen

gruss

[jaenicke]

Sleep im Hauptthread führt dazu, dass die GUI nicht mehr reagiert und sollte daher dort vermieden werden.
In separaten Threads jedoch möchte man ja genau, dass der Thread auch mal schläft. Und deshalb ist es dort auch sinnvoll.

[EWeiss]

Zitat von jaenicke:

Sleep im Hauptthread führt dazu, dass die GUI nicht mehr reagiert und sollte daher dort vermieden werden.
In separaten Threads jedoch möchte man ja genau, dass der Thread auch mal schläft. Und deshalb ist es dort auch sinnvoll.

Aber irgendwie will der Kerl das nicht verstehen

Zitat:

Of course it will reduce the CPU load when you add a sleep in a thread which is looping.
But it doesn't make it a proper way to do any frame scheduling or anything similar.

gruss

[Namenloser]

Zitat von jaenicke:

Zitat von EWeiss:

Ich weiss das sollte man nicht tun ..
Thread.Sleep(1) aber es wirkt wunder.

Im Gegenteil, im Thread ist das genau richtig.
Das wollte ich vorhin auch fragen, ob du da womöglich ne Schleife while not Terminated ohne Pause drin hast.

Naja, ich würde nicht sagen, dass es „richtig“ ist. Natürlich sollte man im Thread nicht einfach eine ungebremste Endlosschleife laufen lassen (außer natürlich wenn es sich um wissenschaftliche Berechnungen handelt o.ä., wo es allein auf die Rechenperformance ankommt). Aber statt Sleep sollte man blockierende Wartefunktionen verwenden wie WaitForSingleObjectEx von der WinAPI und damit gezielt auf bestimmte Ereignisse warten. Bei DirectX wäre vermutlich das naheliegenste, die vertikale Synchronisation abzuwarten.

[EWeiss]

Zitat:

Bei DirectX wäre vermutlich das naheliegenste, die vertikale Synchronisation abzuwarten.

Ah jo
Obwohl der zu wartende Thread im grunde mit DirectX nichts am Hut hat.

gruss

[jaenicke]

Zitat von NamenLozer:

Aber statt Sleep sollte man blockierende Wartefunktionen verwenden wie WaitForSingleObjectEx von der WinAPI und damit gezielt auf bestimmte Ereignisse warten.

Die Windows API möchte man nun nicht gerade immer nutzen, da man dann nicht mehr plattformunabhängig ist.
Sleep nutzt intern schon das genauere ZwDelayExecution (zumindest unter Windows 8), so dass man bei einer Millisekunde auch nicht viel länger wartet. Um genau zu sein sind es bei mir ca. 0,9 ms pro Aufruf mehr als angegeben, egal ob ich eine Millisekunde angebe oder 100.

WaitForSingleObjectEx ist da noch etwas genauer. Da wartet man bei einer Millisekunde Timeout nur 1,6 Millisekunden und bei 100 ms sind es 100,4 ms. Dafür muss man sich erst ein Handle erzeugen, auf das man warten kann. Und wenn man nur ein wenig verzögern will, ist der Unterschied nicht groß. Deshalb ist für mich der Aspekt Plattformunabhängigkeit wichtiger.

Gemessen habe ich so:

Delphi-Quellcode:

uses
  Diagnostics;

var
  i: Integer;
  Watch: TStopwatch;
  Event: THandle;
begin
  Event := CreateEvent(nil, False, False, nil);
  Watch := TStopwatch.StartNew;
  for i := 1 to 10000 do
    WaitForSingleObjectEx(Event, 1, True);
  ShowMessage(IntToStr(Watch.ElapsedMilliseconds));
  CloseHandle(Event);

Genauso mit Sleep und verschiedenen Zeiten.

[Namenloser]

Ich meinte, dass man gezielt auf bestimmte Events warten sollte (z.B. „Neue Daten da“ oder „Frame abgeschlossen“), nicht, dass man WaitForSingleObjectEx als Ersatz für Sleep verwenden soll. WaitForSingleObjectEx war auch nur ein Beispiel; wie gesagt, bei 3D-Grafik-Schnittstellen gibt es ähnliche Prinzipien, und auch auf anderen Plattformen als Windows gibt es das, nur weiß ich nicht, wie die Funktionen dort heißen...

[jaenicke]

In allen Threads, in denen ich das bisher benutzt habe, diente es nur dazu, dass nicht die CPU ausgelastet wurde. Da gab es schlicht nichts, auf das ich hätte warten können, da der Thread ja durchaus z.B. pollen sollte. Nur halt nicht so, dass die gesamte CPU Zeit benutzt wird.

Unabhängig davon kann man natürlich auch die Priorität senken um so nur freie Prozessorzeit zu konsumieren, aber das hilft nicht, wenn die Last den Takt erhöht und damit zu höherem Stromverbrauch insbesondere in Laptops führt.