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.