4. Prozessorauslastung bei mehreren Threads

Prozessorauslastung bei mehreren Threads

  • J

    AndyDD schrieb:

    @hustbaer: Wie soll ich denn QueryPerformanceCounter verwenden? Wenn ich das richtig verstanden habe gibt der doch die Anzahl der Ticks wieder, die seit dem Systemstart vergangen sind.

    Das einfachste ist Du fragst vorher mittels QueryPerformanceFreuqency wie viele Ticks eine Sekunde sind 😉

    0
  • A

    Jochen Kalmbach schrieb:

    AndyDD schrieb:

    @hustbaer: Wie soll ich denn QueryPerformanceCounter verwenden? Wenn ich das richtig verstanden habe gibt der doch die Anzahl der Ticks wieder, die seit dem Systemstart vergangen sind.

    Das einfachste ist Du fragst vorher mittels QueryPerformanceFreuqency wie viele Ticks eine Sekunde sind 😉

    Also so hier:

    LONGLONG Frequency, CurrentTime, LastTime;
	double TimeElapsed, TimeScale;
	bool CounterAvailable = false;
	if (QueryPerformanceFrequency((LARGE_INTEGER*)&Frequency))
	{
		CounterAvailable = true;
		TimeScale = 1.0/Frequency;
		QueryPerformanceCounter((LARGE_INTEGER*) &LastTime);

	}
	else
	{
		LastTime = timeGetTime();
		TimeScale = 0.001;
	}

	if (CounterAvailable)
	{
		QueryPerformanceCounter((LARGE_INTEGER*) &CurrentTime);
	}
	else
		CurrentTime = timeGetTime();
	TimeElapsed = (CurrentTime-LastTime)*TimeScale;
	LastTime=CurrentTime;

    Und damit schafft man Auflösungen kleiner 1 ms? Dann könnte man ja in einer do-while-Schleife QueryPerformanceCounter und die Differenz zum ersten Wert bilden, bis eine gewisse Anzahl von Ticks erreicht worden ist. Oder man rechnet alternativ mit Zeiten. Sehe ich das so richtig?

    0
  • J

    AndyDD schrieb:

    Und damit schafft man Auflösungen kleiner 1 ms? Dann könnte man ja in einer do-while-Schleife QueryPerformanceCounter und die Differenz zum ersten Wert bilden, bis eine gewisse Anzahl von Ticks erreicht worden ist. Oder man rechnet alternativ mit Zeiten. Sehe ich das so richtig?

    Genau! Ist das nicht Toll!?
    Der Nachteil ist: Dein Rechner ist halt zu 100% ausgelastet...

    0

  • Genau. Allerdings solltest du bei QueryPerformanceCounter aufpassen. Wir hatten unlängst erst einen Thread wo jmd. geschrieben hat dass die Werte bei ihm z.T. "zurückgesprungen" sind, die gemessene Zeit sozusagen negativ war. Anscheinend kann das bei AMD Systemen unter gewissen Umständen passieren.
    Und ich selbst habe erlebt dass sogar auf Intel Systemen die Werte z.T. etwas "springen" (wenn auch nie zurück).

    Du solltest also wenn du QueryPerformanceCounter verwendest entweder zusehen dass das Programm auf "kontrollierter" Hardware läuft (=nur mit Komponenten von denen bekannt ist dass sie keine Probleme machen), und vielleicht auch nicht ganz an die Grenzen des Schrittmotors gehen, sondern ein paar Prozent Spielraum lassen.

    Weiters hab' ich in einigen Codes gesehen dass timeGetTime und QueryPerformanceCounter parallel verwendet werden. Dabei wird timeGetTime z.B. verwendet um zu checken ob das was QueryPerformanceCounter zurükliefert stimmen kann, um Probleme zu vermeiden wenn QueryPerformanceCounter von einem Moment auf den anderen einen Riesen "Sprung in der Zeit" meldet (=viel mehr als die wirklich vergangene Zeit).

    So sollte sich trotz der "unzulänglichkeiten" von QueryPerformanceCounter eine Clock basteln lassen die gut geringe Zeitspannen abdecken kann aber trotzdem nie "wild in der Gegend rumspringt".

    0
  • A

    Jochen Kalmbach schrieb:

    AndyDD schrieb:

    Und damit schafft man Auflösungen kleiner 1 ms? Dann könnte man ja in einer do-while-Schleife QueryPerformanceCounter und die Differenz zum ersten Wert bilden, bis eine gewisse Anzahl von Ticks erreicht worden ist. Oder man rechnet alternativ mit Zeiten. Sehe ich das so richtig?

    Genau! Ist das nicht Toll!?
    Der Nachteil ist: Dein Rechner ist halt zu 100% ausgelastet...

    Ja das war er ja vorher mit der Zählschleife auch. Bleibt jetzt nur noch die Frage nach der Begrenzung. Aber anscheinend gehts nicht...

    hustbaer schrieb:

    Du solltest also wenn du QueryPerformanceCounter verwendest entweder zusehen dass das Programm auf "kontrollierter" Hardware läuft (=nur mit Komponenten von denen bekannt ist dass sie keine Probleme machen), und vielleicht auch nicht ganz an die Grenzen des Schrittmotors gehen, sondern ein paar Prozent Spielraum lassen.

    Was verstehst Du denn unter kontrollierter Hardware? Ich hab in der Kiste ein Intelsystem mit einem Celeron, der dürfte ja nach Deinen Aussagen das alles mitmachen, oder?

    0

  • Ich meine damit dass dann z.B. nicht nächstes Jahr auf einmal ein AMD verwendet wird weils billiger ist, oder grad nix anderes verfügbar war.

    Kontrolliert im Sinne von "nicht einfach irgendwas".

    Unterstützt wird QueryPerformanceCounter sowieso auf allen aktuellen Systeme, bloss die Genauigkeit ist eben sehr untershiedlich, vor allem auf Systemen die die Taktfrequenz dynamisch regeln und mehrere Cores/CPUs haben.

    0
Anmelden zum Antworten