Temps de calcul sous Linux: granularité et précision

*********************** Edition originale **********************


J’utilise différents types d’horloges pour obtenir l’heure dans les systèmes LINUX:

rdtsc, gettimeofday, clock_gettime

et déjà lu divers sujets comme ceux-ci:

Quelle est la meilleure résolution de synchronisation que je peux obtenir sur Linux

Comment est obtenue la microseconde heure de linux gettimeofday () et quelle est sa précision?

Comment mesurer un intervalle de temps en C?

équivalent plus rapide de gettimeofday

Fonction de granularité dans le temps

Pourquoi clock_gettime est-il si erratique?

Mais je suis un peu confus:


Quelle est la différence entre la granularité, la résolution, la précision et la précision?


La granularité (ou résolution ou précision) et la précision ne sont pas la même chose (si j’ai raison …)

Par exemple, lors de l’utilisation de “clock_gettime”, la précision est de 10 ms lorsque je reçois:

struct timespec res; clock_getres( CLOCK_REALTIME, &res): 

et la granularité (qui est définie comme ticks par seconde) est de 100Hz (ou 10ms), comme je l’obtiens lors de l’exécution:

  long ticks_per_sec = sysconf(_SC_CLK_TCK); 

La précision est en nanoseconde, comme le suggère le code ci-dessus:

struct timespec gettime_now;

clock_gettime (CLOCK_REALTIME, & gettime_now); time_difference = gettime_now.tv_nsec – start_time;

Dans le lien ci-dessous, j’ai vu qu’il s’agissait de la définition globale de la granularité sous Linux et qu’il est préférable de ne pas la changer:

http://wwwagss.informatik.uni-kl.de/Projekte/Squirrel/da/node5.html#fig:clock:hw

Ma question est donc la suivante: si les remarques ci-dessus étaient justes et également:

a) Peut-on voir quelle est la granularité de rdtsc et de gettimeofday (avec une commande)?

b) Pouvons-nous les changer (de quelque manière que ce soit)?

Merci d’avance


*********************** Edit no2 **********************

Bonjour à tous, j’ai testé de nouvelles horloges et j’aimerai partager des infos:

a) Dans la page ci-dessous, David Terei a réalisé un excellent programme comparant différentes horloges et leurs performances:

https://github.com/dterei/Scraps/tree/master/c/time

b) J’ai aussi testé omp_get_wtime comme Raxman l’a suggéré et j’ai trouvé une précision en nsec, mais pas vraiment meilleure que “clock_gettime (comme ils l’ont fait sur ce site):

http://msdn.microsoft.com/en-us/library/t3282fe5.aspx

Je pense que c’est une fonction de temps orientée fenêtre

CLOCK_MONOTONIC donne de meilleurs résultats avec clock_gettime qu’avec CLOCK_REALTIME. C’est normal, car le premier calcule le temps de traitement et l’autre temps réel respectivement

c) J’ai aussi trouvé la fonction Intel ippGetCpuClocks , mais je ne l’ai pas testée car il est obligatoire de s’inscrire au préalable:

http://software.intel.com/en-us/articles/ipp-downloads-registration-and-licensing/

… ou vous pouvez utiliser une version d’essai

Merci à tous pour vos réponses !!!


  • La précision est la quantité d’informations, c’est-à-dire le nombre de chiffres significatifs que vous déclarez. (Par exemple, je mesure 2m, 1.8m, 1.83m, 1.8322m de hauteur. Toutes ces mesures sont précises, mais de plus en plus précises.)

  • L’exactitude est la relation entre l’information rapscope et la vérité. (Par exemple, “je mesure 1,70 m” est plus précis que “1,8 m”, mais pas vraiment.)

  • La granularité ou la résolution correspond au plus petit intervalle de temps que le minuteur puisse mesurer. Par exemple, si vous avez une granularité de 1 ms, il est inutile de signaler le résultat avec une précision de l’ordre de la nanoseconde, car il ne peut pas être précis à ce niveau de précision.

Sous Linux, les timers disponibles avec une granularité croissante sont les suivantes:

  • clock() partir de (résolution de 20ms ou 10ms?)

  • gettimeofday() partir de Posix (microsecondes)

  • clock_gettime() sur Posix (nanosecondes?)

En C ++, l’entête offre une certaine abstraction autour de cela, et std::high_resolution_clock tente de vous donner la meilleure horloge possible.