auch wenn das Thema nervt: Ich brauche eine Funktion, mit der ich die Zeit auf 1 Millisekunde genau messen kann. Ich hab mir dazu die Posts in den FAQs durchgelesen, aber festgestellt, dass die ganzen Lösungen plattform -, prozessor-, oder sonstwas abhängig sind (verbessert mich bitte, wenn ich mich irre). Ich brauche aber eine Funktion die sowohl auf einem Win98 Notebook als auch auf einem Kubuntu Desktopcomputer läuft. Ich sehe an SDL_GetTicks(), dass es soetwas geben muss, aber genau die Funktion darf ich (LGPL) nicht hernehmen.

Hoffe trotz des abgedroschenen Themas auf Antwort(en). Danke.

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

Ja, was glaubst Du wie die das hinbekommen haben? Indem sie die plattformabhängigen Lösungen je nach Plattform benutzen und eine Funktion anbieten, die für alle Plattformen gleich ist.

aber genau die Funktion darf ich (LGPL) nicht hernehmen.

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

kynarion schrieb:

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

Ja, was glaubst Du wie die das hinbekommen haben? Indem sie die plattformabhängigen Lösungen je nach Plattform benutzen und eine Funktion anbieten, die für alle Plattformen gleich ist.

Hm. Keine einfachere Methode um an Millisekunden zu kommen? Achja: Ich kann windows.h nicht einbinden. Damit fällt wohl die Windowsvariante in den FAQs flach.

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.

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

Dieses Posting wurde automatisch erzeugt.

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.

Greetz, Swordfish

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?

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

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

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

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.

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

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?

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

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]

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.