precision :-(

On Sun, 11 Sep 2005 12:47:37 +0200, Cyrille <cyrille@frsf.invalid>:

Un autre problème de clock(), c'est l'overflow. Sur une machine 32-bits
où CLOCKS_PER_SEC est égal à 1 million (valeur sur Posix), il revient à
zéro après 71 minutes et 34 secondes.

D'un autre côté, il me semble que la différence entre deux valeurs est
correcte (si elle est inférieure à 71 minutes évidemment -- mais c'est
sans doute le cas si on a besoin d'une telle résolution), même s'il y
a eu un passage par zéro entre-temps.

On Sun, 11 Sep 2005 12:47:37 +0200, Cyrille <cyrille@frsf.invalid>:

J'utilise
couramment l'instruction "rdtsc" sur les Pentium pour avoir le nombre de
cycles CPU écoulés dans un entier à 64 bits

Continuons allègrement dans le HS : cette valeur indique-t-elle
réellement une durée ? Je pense en particulier à certains processeurs
(Pentium-M par exemple) dont la fréquence de fonctionnement peut
varier, suivant les besoins ou la température.

Patrick 'Zener' Brunet <use.link.in.signature@ddress.invalid> wrote:

Alerte !
clock() en principe rend un temps en ticks que le système a consacré à votre
process, ce qui exclut donc le temps qu'il a consacré à toute autre chose
(les sleeps, les délais I/O, les autres processes).

Avec la valeur du tick on obtient un équivalent en secondes, mais c'est une
reflet du temps CPU consommé par le process, pas d'une durée absolue.

merci, c'etait la bonne reponse

merci a tous
--
Bruno Causse
http://perso.wanadoo.fr/othello

On Sun, 11 Sep 2005 12:47:37 +0200, Cyrille <cyrille@frsf.invalid>:

J'utilise
couramment l'instruction "rdtsc" sur les Pentium pour avoir le nombre de
cycles CPU écoulés dans un entier à 64 bits

Continuons allègrement dans le HS : cette valeur indique-t-elle
réellement une durée ? Je pense en particulier à certains processeurs
(Pentium-M par exemple) dont la fréquence de fonctionnement peut
varier, suivant les besoins ou la température.

De plus, d'après la documentation d'Intel, rdtsc n'envoie (ou n'enverra)
pas nécessairement le nombre de cycles écoulées (il peut s'agir d'un
multiple). Donc, à mon humble avis, il faut user de cette instruction
avec circonspection, en vérifiant comment elle fonctionne sur le CPU que
l'on utilise. Elle à quand même l'avantage de permettre des mesures très
fines, assez pratique pour faire certaines optimisations.
Il me semble que l'OP n'utilise pas un processeur Intel, donc rdtsc ne
marche pas chez lui.



--
Richard

Fabien LE LEZ wrote:

On Fri, 9 Sep 2005 21:02:48 +0200,
pasde.bcausse.spam@wanadoo.fr (Bruno Causse):

j'utilise <ctime> dans mon prog mais la precision n'est pas
au rendez vous, plusieurs secondes sur une minute :-(

De quoi parles-tu exactement ? De la fonction "time_t time
(time_t*)", c'est ça ?

Cette fonction a une précision égale à celle de ton PC.

Justement.

La résolution, par contre, est de une seconde.

Ce n'est pas garantie, même si c'est l'implémentation la plus
courante.

C'est-à-dire que l'erreur du code suivant ne peut pas être
supérieure à une seconde, quelle que soit la durée totale :

time_t heure_debut= time(0);
for (int i=0; i != NB_ELEMENTS; ++i)
{
f();
cout << "Durée jusqu'ici : "
<< difftime (time(0), heure_debut)
<< " seconde(s)n";
}

Alors là, tu rèves. Je ne connais pas d'implémentation où c'est
vrai. La précision des horloges sur des PC (mais aussi des
Sparcs) est lamentable, et au moins de se servir d'un démon qui
le résynchronise avec une horloge plus précis. Même sur une
journée, tu risques d'avoir plusieurs sécondes d'erreur.

n'y a t'il pas une autre api plus precise.

Une autre quoi ? Une autre fonction, ayant une meilleure
résolution ?

Tu as bien raison à signaler la distinction entre la résolution
et la précision. Mais c'est plus subtile que ça ; sous Unix, par
exemple, tu as des fonctions qui revoient l'heure en unités de
microseconde. Avec une résolution rarement superieur au
milliseconde, et une précision de rarement superieur à 5E3.
(Note que une précision n'a pas d'unités.)

En C++ standard, je ne crois pas. Sous *nix, il y a
gettimeoftheday() je crois ; sous Windows, il y a plusieurs
possibilités : timeGetTime(), GetTickCount(), etc.

gettimeofday() n'est pas Posix, mais c'est Unix (Open Systems)
et Linux. elle renvoie l'heure en unités de microsécondes, mais
rien n'est spécifié sur la résolution, et encore moins sur la
précision.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Fabien LE LEZ wrote:

On Sun, 11 Sep 2005 12:47:37 +0200, Cyrille <cyrille@frsf.invalid>:

Un autre problème de clock(), c'est l'overflow. Sur une
machine 32-bits où CLOCKS_PER_SEC est égal à 1 million
(valeur sur Posix), il revient à zéro après 71 minutes et 34
secondes.

D'un autre côté, il me semble que la différence entre deux
valeurs est correcte (si elle est inférieure à 71 minutes
évidemment -- mais c'est sans doute le cas si on a besoin
d'une telle résolution), même s'il y a eu un passage par zéro
entre-temps.

Ça dépend de l'implémentation. Si clock_t est non-signé, il
obéit aux règles de l'arithmétique non-signée de C et de C++.
S'il est signé, en revanche, le débordement représente un
comportement indéfini -- qui peut-être marche sur ta machine,
mais qui n'est pas garanti.

J'ajouterai en passant que sous Solaris, le premier appel à
clock() dans un processus renvoie toujours 0. (Et que sous
Windows, au moins avec VC++, clock() semble ne pas fonctionner
correctement. Mais je n'ai pas vérifié depuis longtemps.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

bernard tatin wrote:

j'utilise <ctime> dans mon prog mais la precision n'est pas
au rendez vous, plusieurs secondes sur une minute :-( n'y a
t'il pas une autre api plus precise.

Soit t0 = time(0) et t1 = time(0). time(0) renvoie le nombre
de secondes depuis le 01/01/1970.

C'est vrai sous Unix, mais ce n'est certainement pas universel.
Selon la norme (C, mais inclue dans la norme C++ par
référence), time_t est un « arithmetic type capable of
representing times » et time() renvoie « the current clendar
time », mais « The encoding of the value is unspecified ».

(J'avoue que je trouve déjà le concepte d'un « calendar time »
amusant. Chez moi, le calendrier donne les dates, non l'heure.)

Donc t0 et t1 sont précis à 1 seconde près.

Ce n'est pas dit. Ce n'est pas le cas sur ma machine Linux, par
exemple. Ni sur la machine Solaris ici au travail. (D'ailleurs,
la valeur renvoyée par time() ici varie de jusqu'à une trentaine
de sécondes d'une machine à l'autre. Ce qui ne va pas sans posé
de problèmes pour make -- l'heure qu'il voit sur les fichiers,
c'est l'heure du serveur de fichiers, ce qui fait qu'il trouve
souvent que la dernière modification du fichier a eu lieu dans
l'avenir.)

Correctement dit, sous Unix (et je crois sous Windows, mais pas
forcement ailleurs), time_t est un type entier (mais la norme C
permet aussi double) qui exprime l'heure et la date en unités
d'une séconde. La résolution n'est pas garantie par la norme
C/C++ ; ce n'est pas claire si elle est garantie par Posix. La
précision dépend de l'hardware qui donne l'heure, et est souvent
assez mauvaise.

Cela signifie donc que t1 - t0 est précis à deux secondes
près, quelque soit la valeur de l'intervalle.

Encore : rien ne le dit. Selon la norme C/C++, t1 - t0 peut ne
rien signifier du tout. Sous MS-Dos, au niveau du système,
l'heure se représentait sur deux entiers de 16 bits, avec les
sécondes divisées par 2 sur les 5 bits de poids faibles, les
minutes sur les 6 qui suivaient, etc. L'utilisation direct de
ces deux mots sur une longue (avec éventuellement la date sur
les poids faible, même) serait tout à fait conforme. De même
qu'un time_t sur un double, avec l'unité d'un jour (mais je n'ai
jamais entendu parler d'une telle implémentation).

Si tu veux avoir la différence entre deux heures, de façon
portable, il faut se servir de la fonction difftime().

Si la dérive sur une minute est supérieure à deux secondes,
alors il y a un problème soit avec l'horloge de la machine,
soit dans la méthode de mesure de la dérive. Il est aussi
possible que la machine soit vraiment surchargée par des
tâches de fond ou qu'elle swappe comme un PC sous Windows et
là, la mesure des intervalle et délicate, quelque soit la
méthode.

La dérive sur la plupart des systèmes que je connais est bien de
l'ordre de plusieurs secondes, voire plusieurs dizaines de
sécondes, par jour. (Il y a eu une exception, où on avait une
dérive garantie inférieur à une dizaines de picosécondes par an.
Mais on avait une carte entière pour implémenter l'horloge.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[En-tête "Followup-To:" positionné à fr.comp.sys.mac.programmation.]

Effectivement, lorsque j'ai voulu atteindre la milliseconde (la microseconde
est théoriquement possible, mais AMHA c'est comme la 10ème décimale sur une
calculette : on l'a mais elle n'est pas significative), j'ai dû passer par
les API propriétaire du système.

Sur un systeme POSIX, il y a gettimeofday() offre une granularité d'une
milliseconde.

Laurent Wacrenier wrote:

[En-tête "Followup-To:" positionné à fr.comp.sys.mac.programmation.]

J'ai passé outre, parce qu'il n'a rien à faire avec Mac OS.

Effectivement, lorsque j'ai voulu atteindre la milliseconde
(la microseconde est théoriquement possible, mais AMHA c'est
comme la 10ème décimale sur une calculette : on l'a mais
elle n'est pas significative), j'ai dû passer par les API
propriétaire du système.

Sur un systeme POSIX, il y a gettimeofday() offre une
granularité d'une milliseconde.

Je ne sais pas d'où tu as ça, mais c'est complètement fausse.
D'abord, il n'y a pas de fonction gettimeofday() en Posix ; elle
fait partie des extensions « Unix standard ». (Autant que je
sache, Mac OS est un « Unix semblable », comme Linux, et non un
véritable Unix. Mais je peux me tromper là.) Seconde, la norme
Unix standard dit explicitement que « The resolution of the
system clock is unspecified. »

La seule chose qu'on peut dire, c'est que gettimeofday() renvoie
l'heure en *unités* d'une microséconde (pas milliséconde). Ce
qui n'a rien à voir avec la granularité (qui s'apparente à la
résolution) ni encore moins avec la précision.

(Il est possible, évidemment, que cette fonction existe aussi
sous Mac OS, même si elle n'est pas réelement Unix, de même
qu'elle existe sous la plupart d'autres Unix semblables. Il est
aussi possible que sous Mac OS qu'elle ait une résolution d'une
milliseconde. Mais alors, ce sont des particularités de Mac OS,
et non de Posix ni de Unix en général.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

"kanze" <kanze@gabi-soft.fr> writes:

| Laurent Wacrenier wrote:
| > [En-tête "Followup-To:" positionné à fr.comp.sys.mac.programmation.]
|
| J'ai passé outre, parce qu'il n'a rien à faire avec Mac OS.

Vu que Wacren ne lit pas fclc++ (je crois), je ne sais pas si tu
voulais vraiment qu'il lise ta réponse...

-- Gaby