Discussion :

[salseropom]

Bonjour, je suis en train de me faire un chrono sachant que mon code doit être portable sous windows et linux.

J'ai vu qu'il existait std::clock(). C'est très bien, cela me convient. De plus je crois que boost utilise std::clock() (cf http://www.boost.org/doc/libs/1_42_0/boost/timer.hpp)

sous visual, il y a la fonction GetTickCount(). Y a-t-il un intérêt à utiliser cette fonction par rapport à std::clock() ? Sauf erreur de ma part, GetTickCount() n'est pas portable...

Alors je me suis fait une classe Chrono, qui fait qqch du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
#if defined (_WINDOWS)
utiliser GetTickCount()
#else
utiliser std::clock()
#endif

mais bon, quel intérêt y a-t-il à utiliser GetTickCount() ?

Merci d'avance

[Invité]

mais bon, quel intérêt y a-t-il à utiliser GetTickCount() ?
Merci d'avance

Pas beaucoup, quand on peut utiliser QueryPerformanceCounter.

[ram-0000]

QueryPerformanceCounter.

QueryPerformanceCounter, c'est aussi Windows, donc la portabilité :

Au fait, quelle est la précision de QueryPerformanceCounter(). Est ce que c'est réellement plus précis (en résolution réelle, pas en affichage) que GetTickCount() ?

[Laurent Gomila]

Au fait, quelle est la précision de QueryPerformanceCounter(). Est ce que c'est réellement plus précis (en résolution réelle, pas en affichage) que GetTickCount() ?

Attention de bien distinguer résolution et précision.
QueryPerformanceCounter a une excellente résolution (on est bien en dessous de la milliseconde) mais une précision horrible sur certaines plateformes (on a parfois des sauts aléatoires de plusieurs millisecondes).
En ce qui concerne GetTickCount c'est tout l'inverse : une résolution de l'ordre de plusieurs dizaines de millisecondes, mais une bonne précision.

Un bon compromis sous Windows est timeGetTime.

[Mac LAK]

QueryPerformanceCounter a une excellente résolution (on est bien en dessous de la milliseconde)

Voire bien en dessous de la NANOseconde...

mais une précision horrible sur certaines plateformes (on a parfois des sauts aléatoires de plusieurs millisecondes).

J'ai souvent constaté ce problème sur les machines "pas chères", avec des circuits "tout-en-un" à l'intérieur, qui implémentent la fonction hardware de façon un peu pourrie apparemment. On a également la farce avec les modes d'économie d'énergie qui se déclenchent pendant les mesures (merci les portables...).

Par contre, sur une machine un minimum décente, et sans fonctions d'économie d'énergie en cours, la résolution tout comme la précision sont souvent strictement celles du quartz du CPU... Donc, même s'il y a un jitter, le CPU s'est pris très exactement le même dans les dents, et cela compense la mesure.

De manière générale, si la résolution donnée par QueryPerformanceFrequency est de l'ordre de la fréquence du CPU, il y a de bonnes chances d'avoir un QPC de bonne qualité. Sinon, il vaut mieux s'en méfier et proposer une alternative.

[Klaim]

Le multicore a un impacte parceque théoriquement chaque thread peu changer de core au bon vouloir de l'OS, sauf si on précise l'affinité du thread. Les cores ayant des valeurs de ticks différents, ça pose des problemes "louches" sur la plupart des ordinateurs aujourd'hui quand on utilise QueryPerformanceCounter();

Du coup, personellement, pour me simplifier la vie, et avoir du code cross-platform et maintenu, j'utilise la classe Ogre::Timer du moteur 3D Ogre (implémentée séparément pour chaque os) qui contient déjà pas mal de code pour gérer les cas fourbes. (exemple pour la version windows : http://ogre.svn.sourceforge.net/view...48&view=markup )

Vu que Ogre est sous licence MIT maintenant (ou plutot a partir de la prochaine release), je me gène pas pour récupérer ce code.

[Klaim]

Grace a stackoverflow je suis tombé sur cette implémentation cross-platform: http://segfaulting.com/post6/cross-p...n-milliseconds

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
#ifdef WIN32
#include <Windows.h>
#else
#include <sys/time.h>
#include <ctime>
#endif
 
/* Returns the amount of milliseconds elapsed since the UNIX epoch. Works on both
 * windows and linux. */
 
int64 GetTimeMs64()
{
#ifdef WIN32
 /* Windows */
 FILETIME ft;
 LARGE_INTEGER li;
 
 /* Get the amount of 100 nano seconds intervals elapsed since January 1, 1601 (UTC) and copy it
  * to a LARGE_INTEGER structure. */
 GetSystemTimeAsFileTime(&ft);
 li.LowPart = ft.dwLowDateTime;
 li.HighPart = ft.dwHighDateTime;
 
 uint64 ret = li.QuadPart;
 ret -= 116444736000000000LL; /* Convert from file time to UNIX epoch time. */
 ret /= 10000; /* From 100 nano seconds (10^-7) to 1 millisecond (10^-3) intervals */
 
 return ret;
#else
 /* Linux */
 struct timeval tv;
 
 gettimeofday(&tv, NULL);
 
 uint64 ret = tv.tv_usec;
 /* Convert from micro seconds (10^-6) to milliseconds (10^-3) */
 ret /= 1000;
 
 /* Adds the seconds (10^0) after converting them to milliseconds (10^-3) */
 ret += (tv.tv_sec * 1000);
 
 return ret;
#endif
}

[Laurent Gomila]

A priori, la fonction GetSystemTimeAsFileTime ne serait pas meilleure que les autres fonctions de timing, malgré le fait que la doc lui donne une excellente résolution en théorie.
http://www.drdobbs.com/windows/184416651?pgno=17

[Klaim]

C'est ce que je pense aussi, mais l'auteur m'affirme le contraire. Dans le doute je continue a utiliser la solution d'Ogre.