Zeit in millisec; _plattformübergreifend_

[C++ Forumbot]

Dieser Thread wurde von Moderator/in evilissimo aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

[Blue-Tiger]

kynarion schrieb:

LordJaxom schrieb:

kynarion schrieb:

Ich sehe an SDL_GetTicks(), dass es soetwas geben muss,

Sagt nicht gerade das erste L, dass auch kommerzielle Projekte gegen die SDL linken dürfen, ohne den Sourcecode offenlegen zu müssen?

Doch. Aber ich will die SDL nicht einbinden. Und ein Codeschnipsel aus der SDL rauszuziehen ist meineserachtens nicht erlaubt.

Einfach nachschauen welche Funktionen die SDL auf jeder Plattform verwendet ist sehr wohl erlaubt. Warum bitte kannst du windows.h nicht einbinden? o_0 Ohne WinAPI wirst du's unter Windows nicht zum Laufen bekommen

Im Uebrigen ist es _NICHT MOEGLICH_ auf die Millisekunde genau zu messen, sowas kann kein normales Betriebssystem. Genauer als 10 oder vielleicht sogar 100 ms wirst du's nicht hinkriegen, da technisch mit Windows/Desktop-Linux nicht moeglich.

[Lobby]

100ms?! Jetzt übertreib mal nicht. Im normalen Betrieb ist es möglich sich in einer Sekunde fast jede vergangene Millisekunde in eine Datei schreiben zu lassen.
Da hat man dann ein paar wenige übersprungene. Aber große Sprünge hat man im Normalbetrieb nicht.
Klar wenn man gerade etwas recheninensives laufen hat ist das was anderes, aber ist ja auch nicht der normalfall.

[Swordfish]

Das Problem dabei ist, dass diese hohen Auflösungen unter Multitaskingbetriebssystemen nich garantiert werden kann.

Greetz, Swordfish

[kynarion]

Blue-Tiger schrieb:

Einfach nachschauen welche Funktionen die SDL auf jeder Plattform verwendet ist sehr wohl erlaubt.

Gut, dann spitzle ich da ein bisschen.

Blue-Tiger schrieb:

Warum bitte kannst du windows.h nicht einbinden

Weil ich sonst einen ganzen Haufen Compilerfehler krieg. Es sei denn, es gibt eine Möglichkeit, die GDI nicht miteinzubinden. Da muss ich noch mal nachschaun.

Swordfish schrieb:

Das Problem dabei ist, dass diese hohen Auflösungen unter Multitaskingbetriebssystemen nich garantiert werden kann.

Ich denke, wenn ich 99 - 100% der Prozessorzeit habe, schon. Und außerdem: GetTicks() geht nun mal leider richtig...

Unter Linux wär alles so einfach (gettimeofday). Warum muss Windows wieder zicken?

[DocJunioR]

du kannst theoretisch auch die Socket API dafür nutzen. Hier gabs glaub ich auch irgendwo einen Eintrag in den FAQs

[382732341X]

QueryPerformanceCounter

[kynarion]

Ok, also danke nochmal. Ich kopier den Code jetzt noch hier rein, einerseits damit ihr was zum bemängeln habt (bitte richtig auseinandernehmen, oder auch "drüberwurschteln" ), andereseits damit ihn andere Timersuchende übernehmen können.

"globale" Headerdatei

#ifndef TIMER_HPP
#define TIMER_HPP

#include <cstdlib>

#ifdef __WIN32__ // Wir sind unter Windows? Dann Timerklasse in TimerWin benuetzen
#include "TimerWin.hpp"

#elif __unix__ || __linux__  //
#include "TimerUnx" // Gleiche Prozedur nur für Unix/Linux

#else
#include "TimerStd" // Anwender benutzt Extrawurscht-Betriebssystem, Timer mit der Funktion clock() aus time.h bauen.
//NOCH NICHT IMPLEMENTIERT!

#endif

#endif // TIMER_HPP

TimerWin.hpp

#ifndef TIMERWIN_HPP
#define TIMERWIN_HPP

#include "Singleton.hpp" //nur ein Timer benoetigt
#define NOGDI            // keine Grapfik, wer welche will, kann's weglassen
#include <windows.h>
#include <mmsystem.h>

#define gp_timer Timer::Get() //  aus Faulheit ^^

class Timer : public TSingleton<Timer>
{
	private:
			long long freq;  //Frequenz des Timers; benoetigt um die Sekunden zu errechnen
			long long cur, last;
			double resolution, elapsed; // max. Aufloesung des Timers und verstrichene Zeit in Sekunden
			bool QPCounter;

	public:
			Timer::Timer();
			void init();
			void update();
			double get_resolution(){return resolution;}
			inline double get_elapsed(){return elapsed;}
};

#endif // TIMER_HPP

TimerWin.cpp

#include "TimerWin.hpp"

Timer::Timer()
{
	last = cur = freq = 0;
	resolution = elapsed = 0.0;
	QPCounter = false;
}

void Timer::init()
{
	if(QueryPerformanceFrequency(reinterpret_cast<_LARGE_INTEGER*>(&freq))){ // Versuchen, den hochauflösenden Timer zu benuetzen
		QueryPerformanceCounter(reinterpret_cast<_LARGE_INTEGER*>(&last));
		resolution = 1.0 / freq;
		QPCounter = true;
	}

	else{  //Wenn nicht moeglich, den schlechteren, aber immer vorhandenen Timer benuetzen
		last = timeGetTime();
		resolution = 0.001;
	}
}

void Timer::update()
{
  if(QPCounter)
		QueryPerformanceCounter(reinterpret_cast<_LARGE_INTEGER*>(&cur));
	else
		cur = timeGetTime();
	elapsed = (cur - last) * resolution; //Zeitdifferenz berechnen und in Sekunden umwandeln
	last = cur;
}

TimerUnx.hpp

#ifndef TIMERUNX_HPP
#define TIMERUNX_HPP

#include "Singleton.hpp"

#define gp_timer Timer::Get()

class Timer : public TSingleton<Timer>
{
	private:
			 timeval *cur, *last;
       double resolution, elapsed;

	public:
			Timer::Timer();
			void Timer::init();
			void update();
			double get_resolution(){return resolution;}
			inline double get_elapsed(){return elapsed;}
};

#endif // TIMERUNX_HPP

TimerUnx.cpp

#include "TimerUnx.hpp"

Timer::Timer() : resolution(0.000001)
{
	elapsed = 0.0;
}

void Timer::init()
{
	gettimeofday(last, NULL);
}

void Timer::Update()
{
	gettimeofday(cur, NULL);
	elapsed = (cur.usec - last->usec) * resolution;
	last->usec = cur->usec;
}

Achtung: Der Linuxteil ist überhaupt nicht getestet.

Falls euch noch Teimer für ander Betriebssysteme kennt, bitte posten! Von einem Mac hab ich zum Beispiel nicht die geringste Ahnung, obwohl den auch recht viele hernehmen.

Also:
Top
oder
Flop?

(Ich bin Pessimist.)

[Neku]

gettimeofday ist überhaupt nicht zu empfehlen, da der Wert direkt von der Systemzeit abhängig ist und sie der Wert somit bei jeder Zeitänderung ebenfalls ändert.

Ich persönlich habe das timeGetTime() von Windows für Linux folgendermaßen erzeugt:

uint32 timeGetTime()
{
	timespec tp;
	::clock_gettime (CLOCK_MONOTONIC, &tp);

	return tp.tv_sec * 1000 + tp.tv_nsec / 1000000;
}

Getestet unter Debian AMD64.

*edit*
Die Definition von uint32 kann man sich denken, oder?

[Lolz]

Würde unter Windows auf jeden Fall den QueryPerformanceCounter verwenden, ist sehr viel genauer als die ganzen anderen time-Funktionen der winapi.

[kynarion]

@Neku
Ok, werde das entsprechend ändern. Danke!

@Lolz
Hab ich evt. schon so gemacht?!?

if(QueryPerformanceFrequency(reinterpret_cast<_LARGE_INTEGER*>(&freq))){ // Versuchen, den hochauflösenden Timer zu benuetzen
        QueryPerformanceCounter(reinterpret_cast<_LARGE_INTEGER*>(&last));
        resolution = 1.0 / freq;
        QPCounter = true;
    }

Ansonsten weitere Anregungen erwünscht.

[groovemaster]

Wieso benutzt du _LARGE_INTEGER, und nicht LARGE_INTEGER?
Und warum deklarierst du deine Member als long long, und nicht LARGE_INTEGER?

Ich würde zudem die Fallunterscheidung bei QPCounter vereinfachen. Problem dabei ist, dass du zwei unterschiedliche Aufrufe hast.

QueryPerformanceCounter(reinterpret_cast<_LARGE_INTEGER*>(&cur));
// und
cur = timeGetTime();

Das passt natürlich nicht zusammen. Da timeGetTime sowieso die "schlechtere" Wahl ist, und idR auch nie aufgerufen wird, da so gut wie jeder aktuelle Rechner über Hardware Counter verfügt, werden wir diese Funktion QueryPerformanceCounter anpassen.

// private
static BOOL timeGetTimeAlias(LARGE_INTEGER* ticks)
{
    (*ticks).QuadPart = timeGetTime();
}

Als Member kommt nun ein entsprechender Funktionszeiger zum Einsatz

// private
BOOL (*GetTicks)(LARGE_INTEGER*);

welcher im ctor entweder mit QueryPerformanceCounter oder timeGetTimeAlias initialisiert wird, abhängig davon, ob Performance Counter verfügbar sind oder nicht.
QPCounter entfällt damit, und Timer::update vereinfacht sich zu

GetTicks(reinterpret_cast<LARGE_INTEGER*>(&cur));
    elapsed = (cur - last) * resolution; //Zeitdifferenz berechnen und in Sekunden umwandeln
    last = cur;

Zudem ist es einen Wimpernschlag schneller (bei vorhandenen Performance Countern).

[In Java]

System.currentTimeMillis();

[kynarion]

*freu* Ich dachte schon, da kommt nichts mehr.

groovemaster schrieb:

Wieso benutzt du _LARGE_INTEGER, und nicht LARGE_INTEGER?

Ähm ... hm ... gute Frage...

groovemaster schrieb:

Und warum deklarierst du deine Member als long long, und nicht LARGE_INTEGER?

Um ehrlich zu sein: weil's Arbeit spart.

groovemaster schrieb:

Zudem ist es einen Wimpernschlag schneller (bei vorhandenen Performance Countern).

Schon wenns nur einen Tick schneller ist, freu ich mich.

Aber leider taucht in der neuen Version ein Fehler auf:

class Timer : public TSingleton<Timer>
{
	private:
			long long freq; // Frequenz des Timers
			long long cur, last;
			double resolution, elapsed; // max. Auflösung des Timers und verstrichene Zeit in Sekunden
            BOOL (*GetTicks)(LARGE_INTEGER*);

			static BOOL timeGetTimeAlias(LARGE_INTEGER* ticks);

	public:
			Timer::Timer();
			void init();
			void update();
			double get_resolution(){return resolution;}
			inline double get_elapsed(){return elapsed;}
};

void Timer::init()
{
	if(QueryPerformanceFrequency(reinterpret_cast<LARGE_INTEGER*>(&freq))){
		GetTicks = QueryPerformanceCounter;  //hier wird der Fehler angezeigt
		resolution = 1.0 / freq;
	}

	else{
		GetTicks = timeGetTimeAlias;
		resolution = 0.001;
	}
	GetTicks(reinterpret_cast<LARGE_INTEGER*>(&last));
}

void Timer::update()
{
	GetTicks(reinterpret_cast<LARGE_INTEGER*>(&cur));
	elapsed = (cur - last) * resolution; //Zeitdifferenz berechnen und in Sekunden umwandeln
	last = cur;
}

BOOL Timer::timeGetTimeAlias(LARGE_INTEGER* ticks)
{
	(*ticks).QuadPart = timeGetTime();
}

So sieht er aus:

error: invalid conversion from 'BOOL (*)(_LARGE_INTEGER*)' to 'BOOL (*)(LARGE_INTEGER*)'

Witzigerweise zeigt er mir folgendes an, wenn ich alles in _LARGE_INTEGER ändere:

error: invalid conversion from 'BOOL (*)(_LARGE_INTEGER*)' to 'BOOL (*)(_LARGE_INTEGER*)'

Logisch, gell?

@In Java: WAS? Ihr habt nur ne maximale Aulösung von einer Millisekunde? Gut, dass ich C++ gelernt hab...

PS: Ich brauch dringend noch was für den Mac! Google sagt nicht viel dazu.

[helper]

Winapi functionen verwenden __stcall und nicht __cdecl als Aufrufkonvention.

[In Java]

@In Java: WAS? Ihr habt nur ne maximale Aulösung von einer Millisekunde? Gut, dass ich C++ gelernt hab...

Nö, wie kommst Du darauf? Aber es wurde nach der Zeit in Millisekunden gefragt.

Geht auch genauer:

System.nanoTime()

Aber jetzt erzählst Du mir wahrscheinlich gleich, dass eine Sprache, die Zeit nicht yokto-sekunden genau darstellen kann, für nix taugt. Keep on flaming...

[kynarion]

helper schrieb:

Winapi functionen verwenden __stcall und nicht __cdecl als Aufrufkonvention.

d.h. ich schau in die Röhre? Auf die schnelle fällt mir nicht ein, was ich da machen soll. Den Zeiger dynamisch anlegen?

[Jester]

Wie wär's, wenn Du einfach das if drinläßt? Wie oft in der Sekunde wirste Deinen Timer benutzen? Wieviele ticks werden Dir durch das if draufgehen? Ist das wirklich Dein Performance-Bottleneck?

[kynarion]

Jester schrieb:

Wie wär's, wenn Du einfach das if drinläßt? Wie oft in der Sekunde wirste Deinen Timer benutzen?

ca. 600 - 1000 mal. Oft genug, um zu optimieren, oder?

[Jester]

kynarion schrieb:

Jester schrieb:

Wie wär's, wenn Du einfach das if drinläßt? Wie oft in der Sekunde wirste Deinen Timer benutzen?

ca. 600 - 1000 mal. Oft genug, um zu optimieren, oder?

netter Joke.

Lohnt sich also noch kein Stück.
Laß doch Dein Programm einfach mal laufen und benutze nen Profiler um rauszufinden, wieviel Prozent der Zeit Du im Timer verbringst.

Es gibt da sone wichtige Regel: die 80-20 Regel (oder war's 90-10?) 20% des Codes sind für 80% der Laufzeit verantwortlich. Gilt fast immer. Also finde erst raus welche 20% es bei Dir sind. Wenn Du außer dem timen noch irgendwas anderes machst (z.B. ein Dreieck rendern), dann wird sich der Großteil außerhalb des Timers abspielen.

edit: angenommen, Du sparst Dir 5 Takte pro Timerzugriff, das macht dann 5000 Takte pro Sekunde. Das sind, wenn wir mal mit 2,5Ghz rechnen also 5000/(2,5*10^9) s Zeitersparnis, also 2/10^6 s, macht also 2 millionstel Sekunden Zeitersparnis pro Sekunde. Das lohnt sich nicht. Woanders verbrätst Du sicher mehr Deiner Zeit.

edit2: Du kannst das Problem übrigens lösen, indem Du das QueryPerformanceCounter nochmal mit ner eigenen Funktion wrappst und dann auf die zeigst. Ich bezweifle aber ehrlich gesagt, daß das überhaupt schneller ist, als mit dem if zu trennen. Einer Epic-Games hat mal irgendwo nen Vortrag gehalten und meinte, sie würden gerne 10% Performance opfern, wenn sie dafür 10% schneller beim Entwickeln wären. Und die halten sich bestimmt nicht mit solchen Kleinigkeiten auf. Sollte sich das alles doch später nachdem Du alles fertig hast und nachgemessen hast als Problem herausstellen kannst Du die Implementation ja auch leicht ändern. Deswegen ist es imho momentan sinnvoller, Du konzentrierst Dich auf Dein eigentliches Ziel und läßt DIch nicht von solchen Kleinigkeiten ablenken.