Schleife beschleunigen sinnvoll?

[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.

[Namenloser]

Polling sollte – meiner Meinung nach – möglichst nur auf unterster Ebene geschehen, also etwa durch einen Treiber. Ausnahmen wären natürlich sowas wie „Server anpingen, um zu prüfen, ob er up ist“. Da tun es dann aber in der Regel auch große Intervalle von 1s und mehr. Das finde ich dann auch wieder in Ordnung, aber sleep(1) ist für mich ein starker Indikator für einen Designfehler. Ist gewissermaßen Symptonbekämpfung statt die Ursache zu beheben...

[jaenicke]

Zitat von NamenLozer:

Polling sollte – meiner Meinung nach – möglichst nur auf unterster Ebene geschehen, also etwa durch einen Treiber. Ausnahmen wären natürlich sowas wie „Server anpingen, um zu prüfen, ob er up ist“.

Es gibt z.B. auch Hardware, die man auch oberhalb der Treiberebene nur pollen kann. Manche NFC-Reader oder Kellnerschlüssel sind Beispiele dafür.

Schnittstellen zu anderen Programmen laufen auch teilweise nur so, dass man wartet bis eine bestimmte Datei beschreibbar ist oder vorhanden ist oder oder... Ob das gutes Design ist, sei mal dahingestellt, aber angebotene Schnittstellen kann man nun einmal nicht immer beeinflussen. Und ohne eine direkte Kommunikation der Programme gibt es auch nicht so viele Möglichkeiten.

Eine Druckjobüberwachung funktioniert z.B. meines Wissens auch nur mit Pollen, zumindest habe ich noch keine Möglichkeit gefunden mich benachrichtigen zu lassen, wenn einer fertig ist.

Und da gibt es noch viel mehr Gelegenheiten, bei denen du keine andere Möglichkeit hast als zu pollen.

[EWeiss]

Zitat:

Unabhängig davon kann man natürlich auch die Priorität senken

Daran habe ich auch gedacht bzw. mir den Thread angeschaut wie er erstellt wird.
Aber selbst auf der niedrigsten Stufe bringt das nichts wenn die Schleife ohne unterbrechung läuft.
Man muss halt nur die richtige position finden an der man den Thread schlafen legt wenn auch nur eine millisekunde.

Code:

      VisualizationRunning = true;
      ThreadStart renderTs = new ThreadStart(this.RunRenderThread);
      VizRenderThread = new Thread(renderTs);
      VizRenderThread.Priority = ThreadPriority.AboveNormal; //< Hat keinen einfluss auf die auslastung der CPU
      VizRenderThread.IsBackground = true;
      VizRenderThread.Name = "VizRenderer";
      VizRenderThread.Start();

geht!

Code:

              if (VisualizationRunning)
              {
                using (Graphics g = Graphics.FromHwnd(Handle))
                {
                  // Fixed High CPU mistake
                  Thread.Sleep(1);

geht nicht!

Code:

 
              if (VisualizationRunning)
              {
                // Fixed High CPU mistake
                Thread.Sleep(1);                
                
                using (Graphics g = Graphics.FromHwnd(Handle))
                {

gruss

[Furtbichler]

Die Threadpriorität hat natürlich keine Auswirkungen auf deinen Anwendungsfall, denn Du gibst (ohne das sleep) dem OS überhaupt keine Gelegenheit, andere zum Zuge kommen zu lassen. Threads sind kooperativ, d.h. sie müssen 'Bescheid' geben, wann und wo sie unterbrochen werden können. Offensichtlich trifft das auch auf den Prozess zu, obwohl ich dachte, das Windows hier präemptives Multitasking umsetzt.

Aber offensichtlich ist es so: Du und deine Freunde teilen sich eine Pizza. Du hast großen Hunger, also gibst Du dir eine hohe Priorität. Das funktioniert dann, wenn jeder sich reihum einen Haps nimmt (alle einen gleich großen), nur Du darfst jeweils einen großen Bissen nehmen. Logisch: Wenn sich alle eine hohe Priorität geben, ist der Effekt auch = 0. Und bahnbrechend ist der Effekt eh nicht, nur du bekommst eben ein wenig mehr (weil deine Freunde mitspielen und wenig abbeißen).

Wenn Du allerdings die Pizza nicht mehr aus der Hand gibst, ist es irrelevant, ob Du eine hohe oder sehr niedrige Priorität hast, weil ja dann das verabredete Prozedere (jeder reihum abbeißen) nicht eingehalten wird. Du ißt sie also ganz alleine auf. Entweder mit kleinen Bissen (niedrige Priorität) oder mit Riesenhapsen (hohe Priorität).

Da wir nicht wissen, was Großartiges mit dem 'Graphics g' anstellst, kann man da auch nicht weiter ansetzen.

Ach: Wieso ist das eigentlich ein 'high CPU mistake'? Wenn schon ein 'mistake', dann eher von Dir bzw. dem Design.

Der Thread rennt endlos ohne Pause und rendert irgend etwas? Was rendert er? Wann ändert sich etwas bei der Darstellung? Reicht es nicht, das Rendern nur dann anzuwerfen, wenn es etwas *Neues* zu rendern gibt, d.h. wenn sich der Output ändern wird? Reicht es nicht, nur z.B. 20x pro Sekunde zu Rendern?

[Furtbichler]

Hmmm. Verstehe das Problem nicht so ganz.

Entweder habe ich verdammt viel zu rechnen und das soll schnell gehen und dann ist eine CPU zu 100% gerade gut genug.
Oder ich kann mir Zeit lassen und will daher eine CPU nicht zu 100% auslasten. Dann rechne ich in Häppchen und lasse andere (Prozesse) auch zum Zuge kommen. Dann muss ich das dem OS aber (leider) sagen.

Im Allgemeinen spielen viele Threads/Prozesse zusammen und müssen sich synchronisieren, ergo wird man dieses Problem in der Form nicht so oft haben. Und wenn doch, lässt es sich doch imho auf die eingangs genannten zwei Fälle reduzieren.

@Namenlozer: Stichwort 'Eventuell Designfehler?' - ACK, mit der Betonung auf 'eventuell'.