Programm wird langsamer

volkard

Zaus schrieb:

Mir ist klar, dass dies bei einem Nicht-Echtzeitfähigen Betriebssystem nur auf 10ms genau geht und dadurch bei 1000 Aufrufen auch die ein oder andere Sekunde Abweichung auftreten kann.

Sag sowas nicht. Bei einem Extzeitfähigen Betriebssystem können noch viel größere Schwankungen auftreten.
Siehe hier zur Bedeutung von Echtzeitfähigkeit
http://www.c-plusplus.net/forum/viewtopic-var-t-is-269324-and-postdays-is-0-and-postorder-is-asc-and-start-is-0.html

Echtzeit bedeutet "nur" garantiert rechtzeitig. Das können 2ms oder 2 Sekunden oder was auch immer sein.

volkard schrieb:

Zaus schrieb:

Der Großteil der 390 Sekunden kommt durch Sleep() Befehle zustande.

Scherzkeks! Mit Sleep im Programm kannste jede Gang-Ungenauigkeit doch wieder supi auffangen. Einfach mal kürzer Sleepen, wenn es davor zu lang war. Dazu mußt Du nur jedesmal vor Sleep auf eine Uhr schauen und mitschreiben, wie lange Du bisher geschlafen haben solltest.
static_assert(CLOCKS_PER_SEC==1000,"Programmierer war doch zu faul");
int slept=0;
void TheOtherSleep(int ms)
{
   slept+=ms;
   int toSleep=slept-clock();
   if(toSleep<0)
      toSleep=0;
   Sleep(toSleep);
}

Wenn das Programm so extrem langsamer wird wie bei mir (über 20%) dann ist es für mich leider keine Alternative das nächste mal kürzer zu schlafen. Trotzdem danke für deine Mühe.
Aber das kann ja auch nicht des Rätsels Lösung sein. Wie kann ich durch die Sleep-Befehle auf einmal so einen großen Unterschied bekommen? (Im Moment tritt der Fehler übrigens nicht mehr auf) Auch das Umstellen der Priorität auf "Realtime" brachte keinen Effekt.

Ich will mich jetzt auch nicht an der "Echtzeitfähigkeit" des OS aufhängen, aber das Programm läuft später dann auf einem echzeitfähigen OS, da sollte es doch möglich sein mit der Sleep() Funktion Genauigkeiten unter 10-15ms zu bekommen oder irre ich mich da?

Nukularfüsiker

Sleep hat nun mal eine beschissene Auflösung, da wirst du wenig machen können. Wenn du Pech hast, dauert Sleep(1) einmal 5 ms und beim nächsten mal 15 ms oder noch länger. Ist auch von der Hardware abhängig und damit quasi auf jedem Rechner unterschiedlich.

Du könntest es mal mit einem Waitable Timer Object versuchen, die sind in der Regel besser aufgelöst. Aber auch da gibts natürlich keine Garantien.

volkard

Zaus schrieb:

...

*plonk*

volkard schrieb:

Zaus schrieb:

...

*plonk*

Fantastisch, jetzt ist mir geholfen.

Der Fehler tritt immer noch auf. Das kann auch keine Schwankung sein. Ersten wäre die viel zu groß und 2. kann es sein, dass es 20 mal richtig läuft beim 21. dann zu lange brauch und von da an ist es dann IMMER zu langsam, dabei aber fast immer gleich langsam.

Ok, dann raten wir mal. Also ich setzt 1000€ auf die Zeilen 149-251.

BasicMan01

Nach mehrfachen Suchen in dem Fred hier habe ich noch keine Zeile Code von einer
zentral wichtigen Stelle gefunden.
Was auch immer du tust, so hilft vielleicht eine Ausgabe in eine Datei z.B.
einzelne Zeiten an bestimmten Stellen. Eine Minute unterschied die durch Sleeps zustande kommt? ... Müssen aber viele Sleeps sein du hast nicht zufällig eine
if-Bedingung irgendwo drin mit Sleep(60000) in die er reinspringt?

SideWinder

Warum genau hast du die Sleep()-Aufrufe im Programm? Ich glaube dir fehlt für dein Vorhaben ganz einfach die Erfahrung in den Bereichen:

Verstehen von Echtzeitbetriebssystemen und deren Ablauf

Scheduling von Programmen in einem Multitasking-System

Performantes Einlesen von Dateien

Profilern, mit denen du nachsehen könntest wo genau dein Programm plötzlich länger und wo kürzer braucht

Posten in Foren (uns bleibt mangels Code ja doch nur Kartenlegen und Glaskugelraten)

Umsetzen von Vorschlägen (was genau ist an volkards Lösung für dich nun NICHT umsetzbar?)

MfG SideWinder

- Nein ich hab nirgendwo ein Sleep(60000)
- Wozu brauch ich jetzt das Wissen über Echtzeitbetriebssysteme wenn das Programm gerade nur unter Windows7 läuft
- Dass mir die Erfahrung beim Scheduling oder mit Profilern fehlt bestreite ich nicht, deshalb bitte ich ja auch um Hilfe.
- Der Vorschlag ist nicht umsetzbar weil mit dem Programm Musik erzeugt wird und es nicht aktzeptabel ist wenn 2 Noten auf einmal 50-100ms näher aufeinander folgen als sie sollen nur um die Gesamtverzögerung auszugleichen, die Sleep Befehle dienen dazu den richtigen Abstand zwischen 2 Noten einzuhalten.
- Ich hab keine Ahnung an was sowas grundsätzlich liegen könnte also bitte was für Codeteile soll ich posten? Ich bezweifel ja, dass dieser große Unterschied nur durch die Sleep-Befehle kommt aber ich weiss es nunmal nicht...
- Am Einlesen der Dateien kann es nicht liegen, da ich alle Informationen vor dem eigentlich starten in einem vector speichere und dann während der Zeitmessung nur damit arbeite
- Wie gesagt manchmal machts nen "Ruck" und das Programm ist fortan 20% langsamer, wenn ihr mir sagt welche Codeteile ich posten soll mach ich das gern.

Gruß Zaus

Blackskyliner

Arbeitet das Programm mit threads? Wie sieht die Prozessorauslastung vor und nach dem "ruck" aus und wie verhält sich der Speicher?

Alles so Dinge die verantwortlich sein _könnten_, das eingrenzen musst du übernehmen... Entsprechend mal kundig-googlen was ein Profiler ist und wie man ihn verwendet. Oder aber das Programm mal durchsteppen, und schaun, ob irgendwo was gemacht wird was du nicht willst, bzw. mal alle Schleifen und Bedingungen auf Richtigkeit prüfen, etc.

Nukularfüsiker

Zaus schrieb:

- Der Vorschlag ist nicht umsetzbar weil mit dem Programm Musik erzeugt wird und es nicht aktzeptabel ist wenn 2 Noten auf einmal 50-100ms näher aufeinander folgen als sie sollen nur um die Gesamtverzögerung auszugleichen, die Sleep Befehle dienen dazu den richtigen Abstand zwischen 2 Noten einzuhalten.

Ich empfehle nochmal das mit Waitable Timer Objects umzusetzen. Die haben in der Regel eine viel bessere Auflösung.

Auf jeden Fall hat das mit C++ so ziemlich gar nichts mehr zu tun.

l'abra d'or

Es erzeugt Musik? Wie das? Schreibst du da ins Sound-Device? Kann es sein, dass es hier zu Staus kommt? Kann deine Karte Hardware-Mixing, oder läuft das über Software?
BTW. ist eine Abfolge von Noten noch nicht wirklich Musik. Die besteht üblicherweise aus parallel ablaufenden Tonfolgen, synchron an der Melodie orientiert (Homophon) bzw. eigentständig (Polyphon). Beides wird schwer zu realisieren mit deinem bisherigen Modell. Evtl. kannst du das optimieren (wenn du vor hast mehr als nur eine Melodie zu generieren).

Alsooo:
Es erzeugt in dem Sinne Musik als dass es zur rechten Zeit steuerinformationen an einen "Roboter" sendet der dann die Noten spielt.
Bis jetzt ist es testweise so dass statt den Steuerdaten einfach nur eine Bildschirmausgabe :"Press Note x..." kommt.
Ich mache also nichts mit Sound-Devices oder ähnliches. Das mit den parallelen Tonfolgen klappt schon ziemlich gut. Es wird eine MIDI-Datei eingelesen und daraus die Steuerinformationen generiert.

Ich arbeite nicht mit threads. DIe CPU Auslastung ist sowohl vor als auch nach dem "Ruck" bei ca 1% mit gelegentlich kurzen Spitzen auf bis zu 8% (Intel Q6600)
Auch beim Speicher kann kaum ein Unterschied festgestellt werden. Nach dem "Ruck" ist etwas mehr Cache belegt(1720 bzw 1580 von 4000 MB) und etwas weniger freier Arbeitsspeicher(1134 - 1284 MB) aber das sollte daran liegen, dass das System schon ne Stunde länger läuft.

Wenn man den Prozess anschaut benötigt das Programm nach dem "Ruck" 8000K Memory und vorher 7400K, ich denke das schwankt aber auch etwas.

Ich habe auch den Tipp beherzigt und bei jedem Event "Press Note" die aktuell verstrichene Zeit in ein Textfile geschrieben. Man kann erkennen, dass die Verzögerung nicht an einer Stelle auftritt sondern relativ linear über die gesamte Länge (mal etwas stärker mal etwas schwächer). Der Programmteil mit den Sleep Funktionen ist übrigens eine einzige große While-Schleife.

unskilled

Wie wärs denn, wenn du zu testzwecken mal die Sleeps rausnimmst?
Dann guckst du mal, ob das Problem noch besteht - dann ist das mit dem müsste, könnte, sollte endlich mal weg und man kann sagen: da liegt das problem oder aber das kann es nicht sein.

bb

Ohne die Sleeps braucht es vor und nach dem "Ruck" 2590 ms +-10ms. Es ist also kein Unterschied feststellbar. Könnte ja aber trotzdem an der Berechnung der "sleeptime" liegen und nicht an den Sleep(sleeptime) Befehlen an sich ?

Zaus

kann ich beiträge löschen wenn noch niemand geantwortet hat?

SideWinder

Nein, Beiträge kannst du hier nie löschen.

BTW: Kann es sein, dass nur die Ausgabe das Problem ist? Also das Ausgeben von Zeichen in der Konsole länger/kürzer dauert? Die Ausgabe wird nämlich gepuffert...

MfG SideWinder

Zaus

Danke, werde das mal überprüfen.
Habe jetzt mal Waitable Timer Objects statt Sleep() reingenommen, es sind aber keine zeitlichen Unterschiede messbar (bzw die Sleep()Version ist einige Millisekunden schneller).