Discussion :

[Lorenzo77]

j'ai essayé le code de la FAQ (QueryPerformanceCounter) pour le chrono mais il me renvoit des infos completement fausse --> + le temps reel de traitement augmente et plus le temps renvoyé par le code baisse

j'ai donc cherché un autre moyen et en fouillant la doc j'ai testé plein de choses : TXSDuration + TXSCustomDateTime + ....etc mais rien qui semble fonctionner.

vous avez une idée ?


merci

[tourlourou]

c'est louche !

montre-nous comment tu l'appelles...

[Lorenzo77]

ben j'ai fait un simple copié collé de la FAQ !

Code :

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

1
2
3
4
5
 
var
	FFrequency    : Int64    ;    // Fréquence du compteur hautes performances.
	FStart, FStop : Int64    ;    // Valeurs du compteur au début et à la fin du chrono.
	FElapsed      : Extended ;    // Durée finale, en secondes

ensuite dans la procedure a mesurer :

Code :

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

1
2
3
4
	If Not QueryPerformanceFrequency(FFrequency) Then
		Raise Exception.Create('Pas de compteur hautes performances.');
	QueryPerformanceCounter(FStart) ;
	// Insérer ici l'opération à chronométrer, ou un appel de fonction.

........ plein de code

Code :

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

1
2
3
	QueryPerformanceCounter(FStop) ;
	FElapsed := (FStop-FStart)/FFrequency ;
	showmessage(FloatToStr(FElapsed ));

je cherche donc un autre moyen plutot qu'essayer de comprendre pourquoi ce bout de code est bancal ... ca peut venir du processeur puisqu'il utilise sa frequence ...
j'ai meme des temps negatif

[tourlourou]

ça semble choquant ; et en essayant comme ça ?

Code :

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

1
2
3
4
5
6
If Not QueryPerformanceCounter(FStart) Then
 Raise Exception.Create('Pas de compteur hautes performances.');
  // code
QueryPerformanceCounter(FStop) ;
QueryPerformanceFrequency(FFrequency);
FElapsed := (FStop-FStart)/FFrequency ;

sinon, si temps très courts, il faut pê essayer avec des entiers :
(FStop-FStart)*1000 div FFrequency // -> millisecondes
pour éviter les pbs d'arrondis en float ?

[Lorenzo77]

ca y est, merci
enfin de compte c'est bien FFrequency qui fout la merde, j'ai une valeur completement aberrante

le probleme doit venir du surfrequencage du processeur ... je vois que ca
normalement c'est un amd X2 3800+ mais il tourne a la frequence d'un 4800+ donc 2600mhz a la place de 2000mhz et j'ai commme valeur 2600250000
sans compter que la frequence peut tres bien changer entre le debut du programme et la fin du programme ... donc pour finir j'ai tout simplemement viré cette valeur et j'ai des temps qui me paraissent normaux ...


il reste juste un probleme comment savoir la precision de FStop et FStart ... d'apres la FAQ c'est en nano mais ca change ...
voici ce que j'ai :
FStop := 10853840285611
FStart := 10853838458029
vu que ce sont des nombre en 10 milliards j'ai juste a diviser par 1 milliard pour avoir des secondes, mais est ce que ca risque pas de changer suivant le systeme ?

si oui, je vois une soluce qui consisterait a convertir le nombre en chaine et compter le nombre de chiffre ...
tu en penses quoi ?

[basnifo]

Sinon il y a la simple API GetTickCount qui est egalement assez précis (mais peut-etre moins, je sais plus ...)

[tourlourou]

dans ton exemple, tu obtiens 1 827 582 cycles d'horloge ;
sachant qu'elle est cadencée à 2 600 250 000 Hz, (pas d'aberration)
la division fournit 0.70 millisecondes :

ou bien c'est archi faux, même si ça a l'air cohérent...

ou bien c'est vrai !!!

pour trancher, ne peux-tu répéter le code un grand nombre (10 000 ?) de fois entre le start et le stop, et comparer ce timer et la technique moins précise mais fiable du GetTickCount ?

[Lorenzo77]

ben justement, en faisant une recherche sur google je suis tombé sur ce GetTickCount mais en cherchant dans l'aide de delphi je n'ai pas trouvé la moindre infos

je vais essayé avec un timer ... je lance le FStart par un timer et je stoppe le FStop avec un autre timer 10sec apres, en faisant la différence je vais voir si je tombe bien sur un temps proche des 10sec sans utiliser ce FFrequency.

pour infos mon processeur est un double core, peut etre que le probleme peut aussi venir de la ?


---------------
le test est fait

ce coup ci j'ai pris un nouveau projet pour faire tous les tests tranquillement et le probleme a disparu
si j'utilise pas FFrequency j'ai des temps superieur tandis qu'en l'utilisant je retombe bien sur le temps attendu

je crois qu'il est temps que je reprenne tout le code du projet qui pose probleme, y doit y avoir une interference quelque part.

merci a vous !

[cadetill]

Salut

ben justement, en faisant une recherche sur google je suis tombé sur ce GetTickCount mais en cherchant dans l'aide de delphi je n'ai pas trouvé la moindre infos

Ici tu as une demo

A+

[Laurent Dardenne]

Salut,
si le code de la FAQ est faux ou à améliorer ou encore à enrichir n'hésitez pas à nous le dire.

[Lorenzo77]

Laurent : non, je crois pas que le code de la FAQ sur lequel je coince a un probleme, c'est plutot moi qui ne comprend pas quelque chose ...

cadetill : merci

--------
j'ai mis le projet ou je teste les ecarts de temps avec les timers, et des que l'ecart est inférieur a 15ms, je retombe sur des temps negatifs
j'ai mis tout le code du projet dans une archive ici :
http://complet1.free.fr/_divers/foru... et chrono.rar

[tourlourou]

j'ai cherché un peu et fait un test sur les différents compteurs des Pentium :

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
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
procedure TfrmWait.Button4Click(Sender: TObject);
const
  D32 = $66;
type
  CompStr = string[25];
		{Comps have up to 18 digits, plus commas, and sign}
function CompToStr(N: comp): CompStr;
var
  Low3: string[3];
  N1:   extended;
begin
  if N < 0
    then Result := '-' + CompToStr(-N)
    else begin
         N1 := N / 1000;
         Str(Round(Frac(N1) * 1000), Low3);
         N := Int(N1);
         if N > 0
           then begin
                while Length(Low3) < 3 do Low3 := '0' + Low3;
                Result := CompToStr(N) + ThousandSeparator + Low3;
                end
           else Result := Low3
         end;
end;
function RDTSC: comp;
var
  TimeStamp: record
             case byte of
               1: (Whole:  comp);
               2: (Lo, Hi: LongInt);
             end;
begin
  asm
	db $0F; db $31;			{BASM doesn't support RDTSC}
        {Pentium RDTSC - Read Time Stamp Counter - instruction}
{$ifdef Cpu386}
	mov	[TimeStamp.Lo],eax	// the low dword
	mov	[TimeStamp.Hi],edx	// the high dword
{$else}
	db D32
	mov	word ptr TimeStamp.Lo,AX
        {mov [TimeStamp.Lo],eax - the low dword}
	db D32
	mov	word ptr TimeStamp.Hi,DX
        {mov [TimeStamp.Hi],edx - the high dword}
{$endif}
  end;
  Result := TimeStamp.Whole;
end;
var
 ff,i1,i2: int64;
 c1,c2: comp;
 t1,t2: cardinal;
 s: string;
begin
 Beep;
 // compteur haute précision
 QueryPerformanceFrequency(ff); // fréquence du compteur
 ShowMsg(IntToStr(ff));        // pour moi, environ 1,2 MHz : 1 193 180 s-1
 QueryPerformanceCounter(i1); // résolution de 1/ff secondes (pour moi, environ 0,83 µs)
 // compteur de cycles d'horloges des Pentium
 // appel grâce aux fonctions de Jon Shemitz
 // http://www.midnightbeach.com/rdtsc.html
 c1:=RDTSC;               // résolution d'1 cycle d'horloge (pour moi, environ 1/450 µs)
 // compteur faible précision
 t1:=GetTickCount;     // résolution de l'ordre de la ms (mais pas précis en dessous de 10 ms)
 // pause d'environ 1,5 s
 Sleep(1500);
 // arrêts des compteurs
 QueryPerformanceCounter(i2);
 c2:=RDTSC;
 t2:=GetTickCount;
 // compteur haute précision
 ShowMsg(FloatToStr((i2-i1)/ff)); // 1,495567 s (1496 ms)
 // compteur de cycles
 ShowMsg(FloatToStr((c2-c1)/(i2-i1)*ff)); // donne la fréquence du processeur : 451 022 054 Hz (j'ai un PIII 450 MHz)
 // Ticks
 ShowMsg(IntToStr(t2-t1)); // j'obtiens 1500 ms
end;

essaye !

[Lorenzo77]

genial, merci

donc tous les calculs de temps sont basés sur la frequence du processeur ?
juste pour infos :
les processeurs a frequence variable pour le grand public arrive, chaque core pourra indépendamment l'un de l'autre changer sa frequence suivant la quantité de calculs qu'il aura a faire ...

donc si j'ai bien tout compris, + la frequence du processeur est elevé et + on pourra faire des chronometrage precis.
... ou est ce que j'ai foutu les bouteilles d'helium liquide ?


----------------------
j'ai testé ton code dans un autre projet, et j'ai :
1,4999911402 .....
1500
donc tout est bon car je retombe bien sur tes temps.


tu as regardé le projet que j'ai mis en lien a mon message precedent ?
si ca ce trouve ya un truc tout con que j'ai pas compris !!


----------------------
ben voila, meme avec ton code je retombe sur le MEME PROBLEME des que le temps a mesurer est inferieur a 15ms ... j'ai des temps negatif !
ca le fait pas a chaque test par contre.
la seule chose que j'ai touché a ton code c'est le sleep(1500) par un sleep(15)

[tourlourou]

pour autant que je me souvienne, ton code était sain !!!

le pb vient de la précision du GetTickCount, mauvaise en dessous de 10 ms d'après Microsoft, 16 ms d'après ce qu'on lit souvent

mais le compteur haute précision est bien meilleur (# 1000 fois plus précis)
l'aide de Microsoft (msdn) dit que la fréquence de ce compteur ne change pas entre les différents appels d'une même session

cela dit, une différence de temps négative ne devrait pas pouvoir être obtenue, puisque ce sont des compteurs...

pour remédier au pb, si le temps est court, il faut que tu testes un grand (1000*15 ms = 1,5 s) nombre d'exécutions du code (nota : la mise en cache peut accélérer le traitement entre la 1° et la 2° passe, par exemple) pour obtenir sa valeur moyenne, et précise

[tourlourou]

en testant ça :

Code :

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

1
2
 Repeat inc(t2)
 Until t2>150000;

j'obtiens 6,7 µs avec le compteur haute performance, et 0 ms au GetTickCount

l'implémentation des fonctions pose-t'elle un pb sur les procs non Intel ?

[Lorenzo77]

ca ne vient pas de delphi ?
des que le temps a mesurer est trop petit, je me retrouve avec des temps faux !
par contre GetTickCount m'affiche 0 et non pas un nombre fantaisiste.

tu as pas testé le projet pour verifié chez toi ?
celui qui est en lien dans mon message du : 24/06/2006 16h35

ben le probleme c'est que ca sert a rien de tester un grand nombre d'execution a partir du moment ou tu as des erreurs dans les temps, la moyenne sera completement faussé.

j'ai vraiment du mal a comprendre d'ou peut venir ce probleme ... la logique voudrait que :
1-soit le code qui stock le temps de fin est executé avant celui du debut.
2-ya une merde au niveau des calculs quand la différence entre les 2 nombres est inférieur a 0.015

[tourlourou]

j'ai testé ton EXE (mon D5 n'ouvre pas ta fiche en D7 !) avec succès : #55 ms en moyenne, et jamais de temps négatifs... ça colle

l'intérêt de tester un grand nombre de boucles, c'est que ton PC ne fait pas de grosses erreurs sur les temps longs : un Sleep(1500) donne bien # 1510 ms au chronométrage, alors qu'un Sleep(15) donne 0 ms au GetTickCount !

reste à comprendre pourquoi il se vautre au QueryMachin

tu peux aussi utiliser la fonction RDTSC et diviser la différence par la fréquence d'horloge (théorique, pas mesurée)

[Lorenzo77]

ah zut !
j'ai pas pensé a ca, et je peux meme pas l'exporter pour D5 ... ya pas d'options

RDTSC donne le meme temps et quasi la meme precision que les QueryPerf... ce qui est logique.

[Lorenzo77]

ca y est, je sais enfin pourquoi j'avais tout ces problemes de temps negatif, ca provient pas de delphi (pour une fois ) mais des processeurs multi-core !
il y a des problemes avec la lecture du TSC, voici un extrait du site de microsoft en esperant que ca permettra d'eviter des jours et des jours de recherche a certaines personnes :

Les ordinateurs équipés de plusieurs processeurs prenant en charge les fonctionnalités de gestion d'alimentation de processeur, telles que les états des performances du processeur Advanced Configuration and Power Interface (ACPI), nécessitent Microsoft Windows XP Service Pack 2 (SP2). Des mises à jour supplémentaires sont disponibles pour optimiser les performances et le comportement des ordinateurs Windows XP SP2. Sans ces mises à jour, les ordinateurs équipés de ces processeurs bicœurs (dual-core) mobiles à capacité de gestion de l'alimentation peuvent subir des chutes de performances ou avoir un comportement inattendu.

Synchronisation TSC correcte
Sur certains systèmes d'exploitation, le compteur TSC du processeur peut modifier la vitesse à laquelle il compte. En outre, il peut cesser de compter lorsque vous utilisez des fonctionnalités de gestion d'alimentation de processeur spécifiques. Sur les ordinateurs multiprocesseurs, le TSC est généralement l'horloge matérielle du système d'exploitation qui prend en charge les appels à la fonction KeQueryPerformanceCounter du noyau. Lorsque le TSC ne s'incrémente pas de façon uniforme, les composants système qui utilisent la fonction KeQueryPerformanceCounter du noyau peuvent ne pas fonctionner correctement. Pour corriger ce problème, Microsoft autorise l'utilisation de l'horloge de gestion de l'alimentation ACPI comme étant l'horloge du système d'exploitation qui prend en charge la fonction KeQueryPerformanceCounter du noyau. Toutefois, certains programmes peuvent accéder directement au TSC en ignorant les API d'horloge de Windows. La couche HAL (Hardware Abstraction Layer) multiprocesseur garantit que les registres TSC de tous les processeurs d'un ordinateur multiprocesseur restent parfaitement synchronisés. Par conséquent, un accès par un logiciel d'exploitation qui peut être dirigé vers différents processeurs ne retourne pas de résultats différents. Cette modification assure que la couche HAL multiprocesseur continue à synchroniser correctement les TSC sur tous les processeurs d'un ordinateur, même si l'horloge de gestion de l'alimentation ACPI est utilisée comme horloge matérielle du système d'exploitation.