Discussion :

[Tyrendel]

Bonjour à tous, après de longues heures de réflexion et quelques poignées de cheveux en moins, je viens vous demander conseil à propos de la gestion du temps écoulé dans un programme.

Je suis en train de développer une application qui simule le comportement d'un ensemble masse-ressort. J'aimerai maintenant que l'écoulement du temps dans cette simulation semble uniforme, quelle que soit la fréquence de rafraîchissement (donc que la simulation ne semble pas ralentie avec un processeur moins costaud ou avec plus de données à traiter).

Pour cela j'ai essayé d'utiliser les fonctions clock() de ctime et glGet(GLUT_ELAPSED_TIME) de glut, mais ces deux fonctions semblent être limitées de la même manière : elle ne me renvoient le nombre de millisecondes qu'avec une précision de 15 millisecondes...

J'ai lancé le programme suivant pour le vérifier :

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
#include <cstdlib>
#include <iostream>
#include <ctime>
 
using namespace std;
static clock_t t_origine = clock();
 
int main(int argc, char *argv[])
{
    int dt;
    do{
       dt = clock() - t_origine;
       cout << dt << ", " << flush;
    } while( dt < 100 );
    system("PAUSE");
    return EXIT_SUCCESS;
}

Et le résultat concorde :
0, ..., 0, 16, ..., 16, 31, ..., 31, 47, ...

Après moultes recherches avec mon ami google je suis toujours broucouille, je ne trouve aucun fils de discussion à ce sujet...

Donc première question, est-ce un comportement normal ou est-ce que ça vient... je sais pas d'une option de compil ou autre ?

Deuxième question, vais-je devoir gérer le problème à l'envers, à savoir prendre le nombre de fps pour en déduire le pas à utiliser dans la simulation, ou existe-t'il une solution plus propre, et qui sera moins galère à mettre en place ?

merci de votre aide !

[omc24]

Bonjour,
Je te conseille de faire un thread à part pour ton calcul, le gain sera considérable et ton viewer ne sera pas "freezé"...

Ensuite à partir du thread de calcul tu peux envoyer un signal au viewer pour rafraichir l'écran tous les 100 ou 1000 pas de calcul par exemple.
Plus d'infos sur les threads:
http://matthieu-brucher.developpez.c.../boost/thread/

[Invité]

Bonjour,

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
 
#include <time.h>
#include <stdio.h>
#include <dos.h>
 
int main(void)
{
   clock_t start, end;
   start = clock();
 
   delay(2000);
 
   end = clock();
   printf("The time was: %f\n", (end - start) / CLK_TCK);
 
   return 0;
}

J'ai trouvé cet exemple dans l'aide de mon compilateur.
Je vois que la différence de deux retours de clock est ) diviser par CLK_TCK.

Description

Determines processor time.

clock can be used to determine the time interval between two events. To determine the time in seconds, the value returned by clock should be divided by the value of the macro CLK_TCK.

Peut-être ça résoudra votre problème.

[Tyrendel]

omc24 :
Oui, je compte à terme arriver à une architecture multi-threads. Du coup là je pense calculer arbitrairement 15 itérations avec un pas de 1 milliseconde, puis attendre le tic des 15 millisecondes pour afficher et recommencer. Il faudra alors que j'adapte le nombre d'itérations et le pas en fonction de l'éventuel retard que la simulation aura sur l'affichage.

Pierre :
D'après ce que j'ai compris ce CLK_TCK représente le nombre de tics composant une seconde, donc diviser le delta_temps par cette constante revient à demander le delta_temps en secondes. J'ai déjà essayé, en remultipliant le résultat par 1000.0, sans résultat.

merci à tous les deux

Par curiosité, quelqu'un sait-il ce qu'il en est de cette éventuelle limitation de la mesure de l'écoulement du temps ?

[omc24]

Je comprends pas...
Tu utilise "clock()" et tu parles de millisecondes.
Il y a confusion...
La fonction clock() te renvois le nombre de saut d'horloge du processeur (en théorie mais ce n'est pas le cas). Il faut multiplier cette valeur par la macro CLOCK_PER_SECOND pour avoir le temps en s.

De plus, dans ton programme tu fais une sortie écran "flushée" à chaque tour de boucle. Ça prend énormément de temps !
je ne pense pas que ce soit une bonne méthode pour mesurer la précision...

[Tyrendel]

Je comprends pas...
Tu utilise "clock()" et tu parles de millisecondes.
Il y a confusion...
La fonction clock() te renvois le nombre de saut d'horloge du processeur (en théorie mais ce n'est pas le cas). Il faut multiplier cette valeur par la macro CLOCK_PER_SECOND pour avoir le temps en s.

De plus, dans ton programme tu fais une sortie écran "flushée" à chaque tour de boucle. Ça prend énormément de temps !
je ne pense pas que ce soit une bonne méthode pour mesurer la précision...

Ma confusion vient sûrement du fait que la fonction glGet(GLUT_ELAPSED_TIME) renvoie bien le nombre de millisecondes écoulées depuis le lancement du programme ou la création de la fenêtre, et qu'elle semble donner les mêmes résultats qu'avec l'utilisation de clock().

Pour la sortie écran "flushée", il ne s'agissait que d'un test, en temps normal dans mon application je n'affiche même pas la console. Et quand bien même : si l'appel à flush est très long, cela n'a pas empêché le programme de passer une dizaine de fois dans la boucle avant chaque modification de la valeur de dt. La précision que j'ai énoncé n'est pas calculée, elle est déduite des résultats affichés : le nombre de sauts d'horloge / millisecondes n'est jamais incrémenté de moins de 15 unités. Ce nombre reste constant pendant plusieurs appels, puis augmente de 15 à 16 unités, puis redevient constant pour les quelques appels suivants, etc.

Le problème pour moi n'est pas que la mesure soit en sauts d'horloge ou en millisecondes, mais que j'ai besoin qu'une itération de simulation soit effectuée à chaque mesure. Hors cette mesure semble avoir un pas de 15 unités, alors que mon programme à une fréquence de cycle supérieure à 1 cycle pour 15 unités. A cette fréquence, soit la simulation est trop lente pour le but recherché, soit elle devient instable si on choisit d'augmenter le dt pour l'itération de simulation en cours.

[Tyrendel]

Il semble que les fonctions clock() ou glGet(GLU_ELAPSED_TIME) retournent en fait le temps processeur alloué au processus (en sauts d'horloge ou en millisecondes) depuis le début du programme ou la création de la fenêtre, et non le temps réellement écoulé.

src : http://fr.wikipedia.org/wiki/Time.h

[omc24]

J'avoue ne pas comprendre ce que tu cherches à faire... On ne peut pas maitriser grand chose sur les temps de calcul "absolus". C'est l'OS qui affecte les ressources CPU au différents processus.

Éventuellement sous Gnu/linux, tu peux prioriser les processus et il existe aussi des noyaux temps rééls qui mettent l'accent sur les temps de réponse etc....
Plus d'info : pdf

[Tyrendel]

lol décidément j'ai du mal à expliquer...
Bon alors tout d'abord, j'ai trouvé la réponse à ma première question, et les threads sont la solution à ma deuxième question. Donc je peux continuer mon développement l'esprit libre, merci :-)

Ensuite juste pour essayer clarifier la problématique :
déroulement original, rendu dépendant du framerate :
itération 1, simulation avec un pas arbitraire de 15, affichage
itération 2, simulation avec un pas arbitraire de 15, affichage
...
itération n, simulation avec un pas arbitraire de 15, affichage
En 1 seconde, pour une itération durant .005 seconde, la simulation aura avancé de 3000 unités de simulation (1 / 0.005 * 15).

tentative actuelle de rendu dépendant du temps :
itération 1, temps réel = 5ms, clock() -> 0, dt = 0, simulation avec un pas de 0, affichage
itération 2, temps réel = 10ms, clock() -> 0, dt = 0, simulation avec un pas de 0, affichage
itération 3, temps réel = 15ms, clock() -> 15, dt = 15, simulation avec un pas de 15, affichage
itération 4, temps réel = 20ms, clock() -> 15, dt = 0, simulation avec un pas de 0, affichage
...
En une seconde, toujours pour une itération durant .005 seconde la simulation aura avancé cette fois de 1000 unités de simulation (1/0.015*15).

En réalité mes itérations durent plutôt 2 millisecondes, et le rendu dépendant du temps est 7 à 8 fois plus lent que ce que je recherche.

Mais bon comme je le disais mes problèmes sont résolus, je vais faire autrement !

[Tyrendel]

Hop une autre source intéressante : http://www.pallier.org/ressources/ti...ux/timing.html
... mais même résultat avec un gettimeofday() adapté à windows :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
#ifdef WIN32
#include <time.h>
#include <sys/timeb.h>
int gettimeofday (struct timeval *tp, void *tz)
{
struct _timeb timebuffer;
_ftime (&timebuffer);
tp->tv_sec = timebuffer.time;
tp->tv_usec = timebuffer.millitm;
return 0;
}
#endif

Aaah voilà qui semble prometteur :
http://2007.pagesperso-orange.fr/Code/C/mesure.htm#us