Schleife beschleunigen sinnvoll?

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

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

[jaenicke]

Zitat:

Zitat von NamenLozer (Beitrag 1222111)

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?

[EWeiss]

Zitat:

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?

Dieser Thread prüft und verwaltet alle Aktionen welche mein wrapper zur verfügung stellt.
Er schickt also die aktuelle position im Stream das StreamHandle die gebufferten Wasapi Samples etwaige änderungen
der Bildgröße usw...

Alle 20x pro Sek. reicht da bei weitem nicht aus schließlich will ich nicht mit 10Frames in der sekunde rendern.
Das sollte schon in realzeit geschehen. Denn ein Beaterkennung die 5 Sekunden später auftritt als sie eigentlich sollte
ist sinnlos. Ist also nicht nur eine frage des Gehörs sondern auch der Augen.
Ist wie mit deiner Pizza!
Man isst nicht nur sondern schmeckt auch noch.

Zitat:

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

Von mir? NÖ wenn dann vom Developer der für den bereich Music/Listen zuständig ist.
Ah jo mein englisch ist halt unter der Gürtellinie hätte auch schreiben können 'high CPU Usage' wenn es dir mehr zusagt.

Zitat:

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

Na ja ich denke hier liegt ein Design fehler vor.
Man hätte hier nicht sleepMS definieren sollen sondern damit den Thread warten lassen..
Warum nicht anstelle von

Code:

int sleepMS = RenderVisualization(g);

Code:

Thread.Sleep(RenderVisualization(g));

Somit hätte man auch den crash entgegenwirken können wenn beim beenden der Anwendung
die Form nicht mehr existiert und dann versucht 'g' zu initialisieren.

aber das darf jetzt nicht mehr mein problem sein.

gruss

[jaenicke]

Zitat:

Zitat von Furtbichler (Beitrag 1222118)

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.

Das stimmt so nicht. Es gibt nur keine anderen, die gerade Prozessorzeit brauchen, deshalb teilt Windows diesem Thread einfach zu was da ist. Je mehr Threads mit Auslastung laufen, desto weniger Auslastung hat auch der einzelne Thread.

Solange man aber nicht kurz wartet und einfach nur alles nimmt was man bekommen kann, wird die CPU auch ausgelastet solange niemand anderes sie braucht.

[EWeiss]

Gibt es nicht doch noch ne bessere alternative als Tread.Sleep(1)
Man mag es nicht glauben aber selbst die 1 Millisekunde blockiert schon das rendern.

Also für C#..
wenn da jemand was hat wüde mich das freun ;)

gruss

[jaenicke]

Zitat:

Zitat von EWeiss (Beitrag 1222138)

Gibt es nicht doch noch ne bessere alternative als Tread.Sleep(1)
Man mag es nicht glauben aber selbst die 1 Millisekunde blockiert schon das rendern.

Naja, warum ist es denn ein Problem, wenn die CPU Auslastung dadurch steigt? Wenn schon das blockiert, bedeutet das doch, dass die Rechenzeit auch benötigt wird. Du kannst doch dann einfach die Priorität herunterstellen, damit andere Programme nicht behindert werden.

[EWeiss]

Zitat:

Zitat von jaenicke (Beitrag 1222140)

Zitat:

Zitat von EWeiss (Beitrag 1222138)

Gibt es nicht doch noch ne bessere alternative als Tread.Sleep(1)
Man mag es nicht glauben aber selbst die 1 Millisekunde blockiert schon das rendern.

Naja, warum ist es denn ein Problem, wenn die CPU Auslastung dadurch steigt? Wenn schon das blockiert, bedeutet das doch, dass die Rechenzeit auch benötigt wird. Du kannst doch dann einfach die Priorität herunterstellen, damit andere Programme nicht behindert werden.

Das habe ich doch schon gesagt das es mit der Priorität nicht funktioniert selbst wenn ich sie auf die niedrigste stufe stelle.
Ich glaube das ich für das problem einen Multimediatimer benötige da dieser auch im nano bereich arbeitet.
Die 1 Millisekunde ist einfach noch zu viel.

Beim Thread ohne Pause ist es zu schnell so das andere prozesse dadurch behindert werden.
Aber diese geschwindigkeit wäre korrekt wenn das blockieren nicht wäre.
Das ist mein problem ;)

gruss