Discussion :

[subzero82]

Slt les gars,

voila j'ai développé un programme en C++ sous Linux (gcc)

Ça fait un petit moment que je traine sur le Web à la recherche d'une fonction qui me permettrait de calculer le temps exact d'exécution (le plus exacte possible) d'un bout de code (pas un programme en entier).

J’ai commencé avec la fonction clock(), mais elle avait une granularité trop importante (de l'ordre de la seconde) j'ai donc décidé de chercher autre chose.

Je me suis donc rabattu sur gettimeofday. Elle donne une précision assez acceptable. Le problème est que ce type de fonction donne des mesures assez biaisées. Je m'explique. gettimeofday est utilisé afin de récupérer un instant de début et un instant de fin. La différence entre les deux me donne théoriquement le temps d'exécution. Le problème est que ce temps d'exécution n'est vrai que dans le cas où un seul et unique processus s'exécute sur la machine. Ce qui n'est pas le cas. Les lapses de temps ou le sheduleur à fait tourné d'autre programme sont inclus dans la mesure. Ce qui ne m'arrange pas du tout. Ceci me donne des fluctuations de l'ordre de 3 à 10 millisecondes. Ce qui est inacceptable pour moi (même en marchant avec le minimum de processus). Je ne sais pas s’il est possible de faire en sorte qu'un fragment de code ne soit pas arrêté par le shiduleur tant qu'il n'a pas été complètement exécuté. Une sorte de bloc atomique.

Sinon peut être qu'une bibliothèque existe et qui m'a échappé !!!

Je me tourne donc vers vous (mon ultime espoir).

Le problème peut se résumer ainsi.

Peut-on obtenir le temps d'exécution d'un fragment de code uniquement lorsque ce dernier est éxecuté ou le nombre de cycles processeur qu'il a consommé ?

Merci d'avance.

[Alp]

Code :

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

time ./ton_programme

ne te convient pas ?

[subzero82]

oui,

déjà parce que j'ai besoin d'évaluer le temps d'exécution d'un fragment de code et non d'un programme en entier.

aussi, je ne suis pas sur qu'il fasse abstraction du temps ou le sheduleur lance un autres programmes. non ??!!

[HanLee]

Avec gprof tu peux pas avoir ce que tu veux ?

[getdz]

salut

www.pallier.org/ressources/timing_linux/timing.pdf

et lit la page 3, et le mieux c'est de tout lire

[r0d]

A mon avis, le plus simple et le plus efficace reste boost::timer

[subzero82]

D'abord, merci pour vos réponses.

Pour ce qui est de gprof, il est basé sur clock et gettimeofday. Les fluctuations que j'avais déjà mises en évidence réapparaitront avec.

Le document que nous a fourni getdz explique bien les choses.

... Si vous compilez cet exemple, vous réaliserez que la précision de clock n’est pas fameuse. Je soupçonne que l’information de temps CPU est gérée par l’ordonnanceur. Or ce dernier travaille sur une base temporelle de 100 Hz (10 msec). Donc, clock n’est vraisemblablement pas adéquate pour mesurer des durées de l’ordre de la milliseconde ou moins.

L’expérimentation que je veux faire s'inscrit dans des travaux scientifiques. J’ai besoin de mesurer le temps nécessaire pour l"exécution d'une requête sur une base de données (installé en local). Afin de vous donner la mesure des fluctuations avec clock, voilà ce qu'elle me retourne pour l'exécution d'une même requête sur une même base de données qui n'a subi aucun changement.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
Configuration de la requête avec:  absolu = 0, dérivation = 0
mesure de la base de données (V5000P70I0@localhost):
Temps d'exécution : 80000
Temps d'exécution : 80000
Temps d'exécution : 60000
Temps d'exécution : 90000
Temps d'exécution : 70000
Temps d'exécution : 90000
Temps d'exécution : 80000
Temps d'exécution : 80000
Temps d'exécution : 80000
Temps d'exécution : 70000

Je n'ai pas divisé par CLOCKS_PER_SEC car j'ai un processeur centrino capable de changé sa fréquence à volonté comme le dis ci bien l'écrivain du pdf. bien évidement j'ai pris soin de fixé la fréquence du processeur avant de faire mes expériences.

de plus clock ne renvoie que le temps d'execution du processus utilisateur [1]:

Even if the input sequence is large enough for the sorting algorithm to take a measurable time, the times reported may not be very accurate. Although the clock function is supposed to report only time used by the user's process, and not system time, there is inevitably some fluctuation in times reported when the processor has to attend to substantial other activity. And even on a single-user workstation, modern operating systems are often running a score or more different processes to handle network activity and other, often invisible, actions. These fluctuations severely limit the usefulness of timing experiments, unless care is taken to reduce their effect.

Je vais donc essayé la bibliothèque Bosost ::timer en espérant qu'elle saura répondre à mes besoins.

Remarque: je ne peux pas croire qu'il n'y'a pas de bibliothèque sous linux capable de faire cela. !!!

[loufoque]

Bah comment tu crois que l'outil "time" est implémenté ?
Avec la fonction sytème setitimer.

[Klaim]

Je n'ai jamais essayé, mais est-ce que boost::timer est précis et est-il "rapide"? Parceque là j'ai un doute (mais je vais jetter un oeil a la doc voir).

edit> Perdu : ça se base sur clock() qui peut dans certains cas ne pas être suffisant...

[Jean-Marc.Bourguet]

clock_gettime

[subzero82]

La fonction clock_gettime() m'a l'air très intéressante (comment j'ai pu passer à côté).

corriger moi si je me trompe :

CLOCK_PROCESS_CPUTIME_ID définie une horloge propre à mon processus qui prend en compte que le temps où mon processus est actif et ne prend pas en compte le temps où l'ordonnanceur le met en attente afin de faire tourner d'autres processus.

Par contre, CLOCK_REALTIME s'appuie sur l'horloge physique globale et donc comptabilise tout ce qui se passe entre deux appels à clock_gettime.

C’est ça ?

[Jean-Marc.Bourguet]

La fonction clock_gettime() m'a l'air très intéressante (comment j'ai pu passer à côté).

Ca fait partie de l'option real time de POSIX, moins implémentée et donc moins documentées un peu partout.

C’est ça ?

Oui.

[subzero82]

Merci pour ta réponse rapide.

je pense que clock_gettime() me suffira.

entre temps je suis tombé sur une bibliothèque intéressante qui offre une panoplie qui m'a l'air assez complète pour la mesure des performance à plusieurs niveau d'un programme. je profite de ce poste pour partager ma découvert.
C'est une bibliothèque qui s'appelle PAPI pour Performance Application Programming Interface. c'est une API portable permettant d'accéder aux compteurs matériels spécifiques aux microprocesseurs modernes (elle en supporte beaucoup). Elle est utilisé pour collecter des informations de bas niveau (telles que le nombre d'opérations en virgule flottantes FLOPS par seconde, le nombre de cache mises durant l'exécution d'un code, etc..). PAPI est interfaçé avec les systèmes d'exploitation de type UNIX/Linux.

Pour ce qui s'intéresse aux performances de leurs applications, je pense que cela devrait beaucoup les intéresser.

Le site officiel est ici.

[Esiee-Tooms]

Pour info, tu peux trouver dans des bibliothèques comme http://www.fftw.org des fonctions qui lisent le nombre de cycles d'horloge écoulés, ce qui est très pratique pour benchmarker de tous petits bouts de code. Ces fonctions sont utilisées pour benchmarker différentes versions du code et choisir la plus performante sur la machine pour laquelle on compile.

Par exemple le fichier http://www.fftw.org/cycle.h (qui se trouve aussi dans le .tar.gz de la bibliothèque) fournit une fonction qui donne cette information pour plusieurs types d'archi (en lisant le registre TimeStampCounter sur un processeur Intel, en lisant le registre TimeBase sur un PowerPC etc...).


Hope this helps.