Zeit in millisec; _plattformübergreifend_

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

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?

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

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.

Winapi functionen verwenden __stcall und nicht __cdecl als Aufrufkonvention.

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

kynarion

Profiler hab ich schon probiert, aber der bringt mir seltsamer Weiser bei jedem Testlauf (ohne Programmänderung natürlich) ein anderes Ergebnis. Vielleicht sollte ich das Programm entschieden länger laufen lassen.

Aber kann man die Lösung mit Funktionszeiger nicht irgendwie übernehmen?

[EDIT] Was fällt dir ein meine Fragen zu beantworten, bevor ich sie gestellt habe [/EDIT]

Jester

Doch, kannste übernehmen. Aber wie gesagt mußte den QueryPerformanceCounter nochmal mit ner eigenen Funktion wrappen und die in den Pointer stopfen.

Ja, sonen Profiler sollte man schon länger laufen lassen, damit er nen guten Durchschnitt kriegt. Allerdings sollte Dein Programm dazu nicht mehr ganz am Anfang stehen. Profiling macht erst dann Sinn, wenn Du bereits einen Teil der rechenaufwendigen Sachen implementiert hast. Wenn nur Kleinigkeiten gemacht werden, dann gehen die alle schnell und der langsamste wird sozusagen ausgelost.

kynarion

So, hab mir deine Edits durchgelesen. Danke für Lösung & Aufmunterung an meinem Projekt weiter zu arbeiten. Aber das "Projekt" besteht im Moment daraus, ein möglichst perfektes Framework für Spiele zu erstellen (siehe meine letzten Posts). Wie kann ich jetzt nur herausfinden, ob die if - oder Funktionszeiger-Version die schnellere ist? Da bräucht ich ja nen Timer...
Naja, warscheinlich werde ich wieder zur if-Lösung zurückkehren. Die ist IMO besser lesbar als die mit Funktionzeiger.

Zum Profiling (zum Glück hab ich auf Vorschau geklickt, sonst hät's wieder ein Edit gegeben): Es ist (leider) genügend rechenintensives vorhanden. Vielleicht doch nochmal beide Versionen nach einer Stunde Profiling betrachten?

-----
Aber: Ceterum censeo Macintosh-Timer esse implemendam!

Jester

kynarion schrieb:

Zum Profiling (zum Glück hab ich auf Vorschau geklickt, sonst hät's wieder ein Edit gegeben): Es ist (leider) genügend rechenintensives vorhanden. Vielleicht doch nochmal beide Versionen nach einer Stunde Profiling betrachten?

Wenn Du schlicht wissen willst, welche Variante schneller ist solltest Du das auf jeden Fall mal machen. Das ist der sicherste (einzige?) Weg es rauszufinden. Wenn es Dir aber nur drum geht, daß Dein Framework performant ist, dann laß es einfach gut sein. Es ist mit 99,9% Sicherheit völlig egal welche Variante Du verwendest.