Comment pourrais-je m'y prendre pour estimer le temps (en ms) nécessaire
pour l'exécution d'une certaine fonction ? Connaissez-vous une API qui donne
avec précision le temps écoulé depuis la mise en route du pc ou quelque
chose dans le genre.
Je préfère utiliser une API plutôt qu'une fonction VB style timer .
>Comment pourrais-je m'y prendre pour estimer le temps (en ms) nécessaire >pour l'exécution d'une certaine fonction ? Connaissez-vous une API qui
donne
>avec précision le temps écoulé depuis la mise en route du pc ou quelque >chose dans le genre.
rdtsc.
Tant qu'à timer, autant aller à la source directement (faut un pentium ou apparenté).
Ca lit un compteur interne 64 bits incrémenté à chaque top d'horloge. Retour dans EDX:EAX.
Ca s'implémente en 10 lignes d'assembleur dans ton code.
Donc pour avoir les secondes, il faut diviser le retour de rdtsc par la fréquence du cpu (converti en Hz, oeuf corse.)
vaut mieux pas, car on ne connais précisément pas la fréquence du CPU. donc autant garder le nombre de cycle et faire ensuite des comparaison.
VB
Vincent Burel
"Jseb" wrote in message news:
>vaut mieux pas, car on ne connais précisément pas la fréquence du CPU. >donc autant garder le nombre de cycle et faire ensuite des comparaison.
Tu as raison, c'est assez difficile de connaitre le nombre de cycles de son cpu. L'erreur à ne pas commettre, pour utiliser rdtsc, c'est de récupérer la valeur de QueryPerformanceFrequency (qui retourne un *LONGLONG). Cette valeur est à utiliser avec QueryPerformanceCounter (qui a une bonne résolution, et très peu d'overhead).
Attention également aux portables et aux P4 (à vérifier pour les P4), qui procèdent à des ajustements de leur fréquence d'horloge. Bon ,ceci est gênant quand on time la boucle d'un jeu, pour le profiling, je ne pense pas que ce soit rhédibitoire (sauf si on programme un truc qui tire beaucoup sur le proc).
Pour le problème d'ajustement de fréquence, j'imagine que QueryPerformanceCounter souffre du même problème que rdtsc.
ca n'a rien à voir. le RDTSC est interne au processor.
le performanceCounter windows interface le PIT (programmable interval timer) qui est un composant sur la carte mère indépendant du processor. QueryPerformanceFrequency renvoi la fréquence du PIT soit précisément 1.193.180 Hz
donc QueryPerformanceCounter lit la valeur du PIT, c'est précis mais vaut mieux le faire pour des temps de l'ordre de la seconde , car lire le PIT décale le PIT ... amusant... :-).
pour plus d'information faire une recherche dans google "Vincent Burel" +PIT "Vincent Burel" +RDTSC "Vincent Burel" +Timer etc... Et surtout lire la bible PC sur le PIT et le PIC.
A+ Vincent Burel
"Jseb" <jseb@alussinan.org> wrote in message
news:p2nkpv01u78q71lduem074ts1b5ith4q62@4ax.com...
>vaut mieux pas, car on ne connais précisément pas la fréquence du CPU.
>donc autant garder le nombre de cycle et faire ensuite des comparaison.
Tu as raison, c'est assez difficile de connaitre le nombre de cycles
de son cpu.
L'erreur à ne pas commettre, pour utiliser rdtsc, c'est de récupérer
la valeur de QueryPerformanceFrequency (qui retourne un *LONGLONG).
Cette valeur est à utiliser avec QueryPerformanceCounter (qui a une
bonne résolution, et très peu d'overhead).
Attention également aux portables et aux P4 (à vérifier pour les P4),
qui procèdent à des ajustements de leur fréquence d'horloge.
Bon ,ceci est gênant quand on time la boucle d'un jeu, pour le
profiling, je ne pense pas que ce soit rhédibitoire (sauf si on
programme un truc qui tire beaucoup sur le proc).
Pour le problème d'ajustement de fréquence, j'imagine que
QueryPerformanceCounter souffre du même problème que rdtsc.
ca n'a rien à voir. le RDTSC est interne au processor.
le performanceCounter windows interface le PIT (programmable interval
timer) qui est un composant sur la carte mère indépendant du processor.
QueryPerformanceFrequency renvoi la fréquence du PIT
soit précisément 1.193.180 Hz
donc QueryPerformanceCounter lit la valeur du PIT, c'est précis mais vaut
mieux le faire pour des temps de l'ordre de la seconde , car lire le PIT
décale le PIT ... amusant... :-).
pour plus d'information faire une recherche dans google
"Vincent Burel" +PIT
"Vincent Burel" +RDTSC
"Vincent Burel" +Timer
etc...
Et surtout lire la bible PC sur le PIT et le PIC.
>vaut mieux pas, car on ne connais précisément pas la fréquence du CPU. >donc autant garder le nombre de cycle et faire ensuite des comparaison.
Tu as raison, c'est assez difficile de connaitre le nombre de cycles de son cpu. L'erreur à ne pas commettre, pour utiliser rdtsc, c'est de récupérer la valeur de QueryPerformanceFrequency (qui retourne un *LONGLONG). Cette valeur est à utiliser avec QueryPerformanceCounter (qui a une bonne résolution, et très peu d'overhead).
Attention également aux portables et aux P4 (à vérifier pour les P4), qui procèdent à des ajustements de leur fréquence d'horloge. Bon ,ceci est gênant quand on time la boucle d'un jeu, pour le profiling, je ne pense pas que ce soit rhédibitoire (sauf si on programme un truc qui tire beaucoup sur le proc).
Pour le problème d'ajustement de fréquence, j'imagine que QueryPerformanceCounter souffre du même problème que rdtsc.
ca n'a rien à voir. le RDTSC est interne au processor.
le performanceCounter windows interface le PIT (programmable interval timer) qui est un composant sur la carte mère indépendant du processor. QueryPerformanceFrequency renvoi la fréquence du PIT soit précisément 1.193.180 Hz
donc QueryPerformanceCounter lit la valeur du PIT, c'est précis mais vaut mieux le faire pour des temps de l'ordre de la seconde , car lire le PIT décale le PIT ... amusant... :-).
pour plus d'information faire une recherche dans google "Vincent Burel" +PIT "Vincent Burel" +RDTSC "Vincent Burel" +Timer etc... Et surtout lire la bible PC sur le PIT et le PIC.
A+ Vincent Burel
Cyrille \cns\ Szymanski
> donc QueryPerformanceCounter lit la valeur du PIT, c'est précis mais vaut mieux le faire pour des temps de l'ordre de la seconde , car lire le PIT décale le PIT ... amusant... :-).
C'est comme en physique, difficile de faire une mesure sans modifier ce qu'on mesure.
> donc QueryPerformanceCounter lit la valeur du PIT, c'est précis mais vaut
mieux le faire pour des temps de l'ordre de la seconde , car lire le PIT
décale le PIT ... amusant... :-).
C'est comme en physique, difficile de faire une mesure sans modifier ce
qu'on mesure.
> donc QueryPerformanceCounter lit la valeur du PIT, c'est précis mais vaut mieux le faire pour des temps de l'ordre de la seconde , car lire le PIT décale le PIT ... amusant... :-).
C'est comme en physique, difficile de faire une mesure sans modifier ce qu'on mesure.
Testé sur deux PCs; mêmes valeurs: High: 0 -- Low: 3579545 Division par 3 : 1193181
Si tu as une explication, ça m'intéresse.
ben il semble que W2000/XP est capable de changer la fréquence du PIT quand la carte mère le permet...
ci-dessous le commentaire de Matt Pietreck sur la question.
On a different note, I was surprised at the results of QueryPerformanceFrequency under Windows 2000. Looking at Figure 2, notice that under Windows 2000 the timer operates at 3.57Mhz. This is exactly three times faster than the 1.19 Mhz frequency used on Windows 98. If you're a PC old-timer, you may recall that motherboards traditionally have a 1.19Mhz oscillator that drives the 8254 chip. Intrigued, I ran my tests on a Pentium Pro 200Mhz running Windows 2000 and got the 1.19Mhz frequency. I then ran LoadTimer on some dual processor machines and found that the frequency matched the CPU speed. The conclusion I've drawn from this is that Windows 2000 observes what the motherboard is capable of doing and uses the best available timer frequency for the QueryPerformanceXXX APIs. Yes, I admit to being a nerd and spending way too much time on this minor detail, but I enjoyed the experimentation and the opportunity to ponder things at the hardware level.
"Jseb" <jseb@alussinan.org> wrote in message
news:9arppvcfk4uk83abvpbiec9rus6av1l3be@4ax.com...
>tiens donc !? ca c'est nouveau. Ptete ils ont changé le PIT dans les
Testé sur deux PCs; mêmes valeurs:
High: 0 -- Low: 3579545
Division par 3 : 1193181
Si tu as une explication, ça m'intéresse.
ben il semble que W2000/XP est capable de changer la fréquence du PIT quand
la carte mère le permet...
ci-dessous le commentaire de Matt Pietreck sur la question.
On a different note, I was surprised at the results of
QueryPerformanceFrequency under Windows 2000. Looking at Figure 2, notice
that under Windows 2000 the timer operates at 3.57Mhz. This is exactly three
times faster than the 1.19 Mhz frequency used on Windows 98. If you're a PC
old-timer, you may recall that motherboards traditionally have a 1.19Mhz
oscillator that drives the 8254 chip.
Intrigued, I ran my tests on a Pentium Pro 200Mhz running
Windows 2000 and got the 1.19Mhz frequency. I then ran LoadTimer on some
dual processor machines and found that the frequency matched the CPU speed.
The conclusion I've drawn from this is that Windows 2000 observes what the
motherboard is capable of doing and uses the best available timer frequency
for the QueryPerformanceXXX APIs. Yes, I admit to being a nerd and spending
way too much time on this minor detail, but I enjoyed the experimentation
and the opportunity to ponder things at the hardware level.
Testé sur deux PCs; mêmes valeurs: High: 0 -- Low: 3579545 Division par 3 : 1193181
Si tu as une explication, ça m'intéresse.
ben il semble que W2000/XP est capable de changer la fréquence du PIT quand la carte mère le permet...
ci-dessous le commentaire de Matt Pietreck sur la question.
On a different note, I was surprised at the results of QueryPerformanceFrequency under Windows 2000. Looking at Figure 2, notice that under Windows 2000 the timer operates at 3.57Mhz. This is exactly three times faster than the 1.19 Mhz frequency used on Windows 98. If you're a PC old-timer, you may recall that motherboards traditionally have a 1.19Mhz oscillator that drives the 8254 chip. Intrigued, I ran my tests on a Pentium Pro 200Mhz running Windows 2000 and got the 1.19Mhz frequency. I then ran LoadTimer on some dual processor machines and found that the frequency matched the CPU speed. The conclusion I've drawn from this is that Windows 2000 observes what the motherboard is capable of doing and uses the best available timer frequency for the QueryPerformanceXXX APIs. Yes, I admit to being a nerd and spending way too much time on this minor detail, but I enjoyed the experimentation and the opportunity to ponder things at the hardware level.
