Zeit in millisec; _plattformübergreifend_
-
Hallo,
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.
-
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.
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?
-
LordJaxom schrieb:
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.
-
-
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.
-
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.
-
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.
-
Das Problem dabei ist, dass diese hohen Auflösungen unter Multitaskingbetriebssystemen nich garantiert werden kann.
Greetz, Swordfish
-
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?
-
du kannst theoretisch auch die Socket API dafür nutzen. Hier gabs glaub ich auch irgendwo einen Eintrag in den FAQs
-
QueryPerformanceCounter
-
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_HPPTimerWin.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_HPPTimerWin.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_HPPTimerUnx.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.)
-
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.
-
@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.
-
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 zuGetTicks(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();
-
*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...
