hello les gens, est ce que la plus petite durée quantifiable sous windows
lorsque l'on programme est la milliseconde ou alors on peut descendre plus
bas (idéalement j'aimerais obtenir une resolution entre 100 et 500µs)?
Je souhaite utiliser une fonction équivalente à "double difftime (time_t,
time_t)" (prototype dans time.h) mais time_t ne s'incrémente que par
milliseconde.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Thierry
Bonjour,
Mouarf a écrit :
hello les gens, est ce que la plus petite durée quantifiable sous windows lorsque l'on programme est la milliseconde ou alors on peut descendre plus bas (idéalement j'aimerais obtenir une resolution entre 100 et 500µs)?
Je souhaite utiliser une fonction équivalente à "double difftime (time_t, time_t)" (prototype dans time.h) mais time_t ne s'incrémente que par milliseconde.
Qqun aurait il une idée?
Le sujet a deja ete discuté ici. En attendant le retour des pontes tu peux deja lire ça:
http://minilien.com/?bTsNynBvIr
-- « Always look at the bright side of the life... »
Bonjour,
Mouarf a écrit :
hello les gens, est ce que la plus petite durée quantifiable sous
windows lorsque l'on programme est la milliseconde ou alors on peut
descendre plus bas (idéalement j'aimerais obtenir une resolution entre
100 et 500µs)?
Je souhaite utiliser une fonction équivalente à "double difftime
(time_t, time_t)" (prototype dans time.h) mais time_t ne s'incrémente
que par milliseconde.
Qqun aurait il une idée?
Le sujet a deja ete discuté ici. En attendant le retour des pontes tu peux
deja lire ça:
http://minilien.com/?bTsNynBvIr
--
« Always look at the bright side of the life... »
hello les gens, est ce que la plus petite durée quantifiable sous windows lorsque l'on programme est la milliseconde ou alors on peut descendre plus bas (idéalement j'aimerais obtenir une resolution entre 100 et 500µs)?
Je souhaite utiliser une fonction équivalente à "double difftime (time_t, time_t)" (prototype dans time.h) mais time_t ne s'incrémente que par milliseconde.
Qqun aurait il une idée?
Le sujet a deja ete discuté ici. En attendant le retour des pontes tu peux deja lire ça:
http://minilien.com/?bTsNynBvIr
-- « Always look at the bright side of the life... »
Mouarf
ce n'est pas exactement ce à quoi je m'attendais. En fait mon but est de pouvoir mesurer le temps écoulé lors de l'exécution d'un routine avec une précision de 100 à 500µs.
Mais bon, d'après ce que je lis aucun des timer ne peut descendre sous la miliseconde.
Merci pour ce lien. @+
"Thierry" schrieb im Newsbeitrag news:
Bonjour,
Mouarf a écrit :
hello les gens, est ce que la plus petite durée quantifiable sous windows lorsque l'on programme est la milliseconde ou alors on peut descendre plus bas (idéalement j'aimerais obtenir une resolution entre 100 et 500µs)?
Je souhaite utiliser une fonction équivalente à "double difftime (time_t, time_t)" (prototype dans time.h) mais time_t ne s'incrémente que par milliseconde.
Qqun aurait il une idée?
Le sujet a deja ete discuté ici. En attendant le retour des pontes tu peux deja lire ça:
http://minilien.com/?bTsNynBvIr
-- « Always look at the bright side of the life... »
ce n'est pas exactement ce à quoi je m'attendais. En fait mon but est de
pouvoir mesurer le temps écoulé lors de l'exécution d'un routine avec une
précision de 100 à 500µs.
Mais bon, d'après ce que je lis aucun des timer ne peut descendre sous la
miliseconde.
Merci pour ce lien.
@+
"Thierry" <yarglah@com.invalid> schrieb im Newsbeitrag
news:XnF959FA5972BF89pouletetcetc@212.27.42.77...
Bonjour,
Mouarf a écrit :
hello les gens, est ce que la plus petite durée quantifiable sous
windows lorsque l'on programme est la milliseconde ou alors on peut
descendre plus bas (idéalement j'aimerais obtenir une resolution entre
100 et 500µs)?
Je souhaite utiliser une fonction équivalente à "double difftime
(time_t, time_t)" (prototype dans time.h) mais time_t ne s'incrémente
que par milliseconde.
Qqun aurait il une idée?
Le sujet a deja ete discuté ici. En attendant le retour des pontes tu peux
deja lire ça:
http://minilien.com/?bTsNynBvIr
--
« Always look at the bright side of the life... »
ce n'est pas exactement ce à quoi je m'attendais. En fait mon but est de pouvoir mesurer le temps écoulé lors de l'exécution d'un routine avec une précision de 100 à 500µs.
Mais bon, d'après ce que je lis aucun des timer ne peut descendre sous la miliseconde.
Merci pour ce lien. @+
"Thierry" schrieb im Newsbeitrag news:
Bonjour,
Mouarf a écrit :
hello les gens, est ce que la plus petite durée quantifiable sous windows lorsque l'on programme est la milliseconde ou alors on peut descendre plus bas (idéalement j'aimerais obtenir une resolution entre 100 et 500µs)?
Je souhaite utiliser une fonction équivalente à "double difftime (time_t, time_t)" (prototype dans time.h) mais time_t ne s'incrémente que par milliseconde.
Qqun aurait il une idée?
Le sujet a deja ete discuté ici. En attendant le retour des pontes tu peux deja lire ça:
http://minilien.com/?bTsNynBvIr
-- « Always look at the bright side of the life... »
Manuel Leclerc
Thierry a écrit :
Mouarf a écrit :
> hello les gens, est ce que la plus petite durée quantifiable sous > windows lorsque l'on programme est la milliseconde ou alors on peut > descendre plus bas (idéalement j'aimerais obtenir une resolution entre > 100 et 500µs)?
Je souhaite utiliser une fonction équivalente à "double difftime (time_t, time_t)" (prototype dans time.h) mais time_t ne s'incrémente que par milliseconde.
Qqun aurait il une idée?
Le sujet a deja ete discuté ici. En attendant le retour des pontes tu peux deja lire ça:
http://minilien.com/?bTsNynBvIr
Peut être que ton lien n'a pas trop de rapport avec la question de l'OP. Voir éventuellement QueryPerformanceCounter et QueryPerformanceFrequency pour obtenir des mesures nettement en dessous de la milli-seconde.
Attention, QueryPerformanceCounter est d'un usage délicat sur certaines cartes mères (résultats fantaisistes quand le bus PCI est surchargé), et il y a aussi des précautions à prendre en SMP.
Google est ton ami.
-- When used in connection with `bar' it is generally traced to the WW II era Army slang acronym FUBAR (`Fucked Up Beyond All Repair'), later modified to foobar. --RFC 3092
Thierry a écrit :
Mouarf a écrit :
> hello les gens, est ce que la plus petite durée quantifiable sous
> windows lorsque l'on programme est la milliseconde ou alors on peut
> descendre plus bas (idéalement j'aimerais obtenir une resolution entre
> 100 et 500µs)?
Je souhaite utiliser une fonction équivalente à "double difftime
(time_t, time_t)" (prototype dans time.h) mais time_t ne s'incrémente
que par milliseconde.
Qqun aurait il une idée?
Le sujet a deja ete discuté ici. En attendant le retour des pontes
tu peux deja lire ça:
http://minilien.com/?bTsNynBvIr
Peut être que ton lien n'a pas trop de rapport avec la question
de l'OP. Voir éventuellement QueryPerformanceCounter et
QueryPerformanceFrequency pour obtenir des mesures nettement
en dessous de la milli-seconde.
Attention, QueryPerformanceCounter est d'un usage délicat sur
certaines cartes mères (résultats fantaisistes quand le bus PCI
est surchargé), et il y a aussi des précautions à prendre en SMP.
Google est ton ami.
--
When used in connection with `bar' it is generally traced to the
WW II era Army slang acronym FUBAR (`Fucked Up Beyond All Repair'),
later modified to foobar.
--RFC 3092
> hello les gens, est ce que la plus petite durée quantifiable sous > windows lorsque l'on programme est la milliseconde ou alors on peut > descendre plus bas (idéalement j'aimerais obtenir une resolution entre > 100 et 500µs)?
Je souhaite utiliser une fonction équivalente à "double difftime (time_t, time_t)" (prototype dans time.h) mais time_t ne s'incrémente que par milliseconde.
Qqun aurait il une idée?
Le sujet a deja ete discuté ici. En attendant le retour des pontes tu peux deja lire ça:
http://minilien.com/?bTsNynBvIr
Peut être que ton lien n'a pas trop de rapport avec la question de l'OP. Voir éventuellement QueryPerformanceCounter et QueryPerformanceFrequency pour obtenir des mesures nettement en dessous de la milli-seconde.
Attention, QueryPerformanceCounter est d'un usage délicat sur certaines cartes mères (résultats fantaisistes quand le bus PCI est surchargé), et il y a aussi des précautions à prendre en SMP.
Google est ton ami.
-- When used in connection with `bar' it is generally traced to the WW II era Army slang acronym FUBAR (`Fucked Up Beyond All Repair'), later modified to foobar. --RFC 3092
Vincent Burel
"Mouarf" wrote in message news:4194e1eb$0$17378$
ce n'est pas exactement ce à quoi je m'attendais. En fait mon but est de pouvoir mesurer le temps écoulé lors de l'exécution d'un routine avec une précision de 100 à 500µs.
Mais bon, d'après ce que je lis aucun des timer ne peut descendre sous la miliseconde.
Merci pour ce lien. @+
c'est possible avec les fonctions suivantes :
QueryPerformanceFrequency QueryPerformanceCounter
Mais ma recommandation est de quand même faire une mesure sur un temps plus long (plusieurs seconde) pour apprécier au mieux le temps que mets un traitement donné (par exemple en le mettant dans un boucle pour le faire durer plus longtemps et ensuite diviser le temps par le nombre de tour de boucle).
sinon sur la mesure de temps d'exécution, y'a une note chez intel , avec des compteurs de cycle... (à partir du pentium...)
VB
PS : Astor il est en vacances ou quoi !? :-)
"Mouarf" <mouarf@chezmoi.fr> wrote in message
news:4194e1eb$0$17378$626a14ce@news.free.fr...
ce n'est pas exactement ce à quoi je m'attendais. En fait mon but est de
pouvoir mesurer le temps écoulé lors de l'exécution d'un routine avec une
précision de 100 à 500µs.
Mais bon, d'après ce que je lis aucun des timer ne peut descendre sous la
miliseconde.
Merci pour ce lien.
@+
c'est possible avec les fonctions suivantes :
QueryPerformanceFrequency
QueryPerformanceCounter
Mais ma recommandation est de quand même faire une mesure sur un temps plus
long (plusieurs seconde) pour apprécier au mieux le temps que mets un
traitement donné (par exemple en le mettant dans un boucle pour le faire
durer plus longtemps et ensuite diviser le temps par le nombre de tour de
boucle).
sinon sur la mesure de temps d'exécution, y'a une note chez intel , avec des
compteurs de cycle... (à partir du pentium...)
ce n'est pas exactement ce à quoi je m'attendais. En fait mon but est de pouvoir mesurer le temps écoulé lors de l'exécution d'un routine avec une précision de 100 à 500µs.
Mais bon, d'après ce que je lis aucun des timer ne peut descendre sous la miliseconde.
Merci pour ce lien. @+
c'est possible avec les fonctions suivantes :
QueryPerformanceFrequency QueryPerformanceCounter
Mais ma recommandation est de quand même faire une mesure sur un temps plus long (plusieurs seconde) pour apprécier au mieux le temps que mets un traitement donné (par exemple en le mettant dans un boucle pour le faire durer plus longtemps et ensuite diviser le temps par le nombre de tour de boucle).
sinon sur la mesure de temps d'exécution, y'a une note chez intel , avec des compteurs de cycle... (à partir du pentium...)
VB
PS : Astor il est en vacances ou quoi !? :-)
AMcD®
Mouarf wrote:
ce n'est pas exactement ce à quoi je m'attendais. En fait mon but est de pouvoir mesurer le temps écoulé lors de l'exécution d'un routine avec une précision de 100 à 500µs.
Mais bon, d'après ce que je lis aucun des timer ne peut descendre sous la miliseconde.
Merci pour ce lien.
Un timer est quelque chose qui se déclence à intervalle fixe, comment veux-tu mesurer un temps écoulé avec ça ? Moi y en a pas comprendre...
Pour mesurer une durée écoulée, t'as 2 solutions classiques.
- RDTSC (instruction Intel, gaffe, à partir du P1 je crois). - QueryPerformanceFrequency et QueryPerformanceCounter.
Pour le premier cas, attention à bien initialiser/calibrer et il y a quelques précautions à prendre :
ce n'est pas exactement ce à quoi je m'attendais. En fait mon but est
de pouvoir mesurer le temps écoulé lors de l'exécution d'un routine
avec une précision de 100 à 500µs.
Mais bon, d'après ce que je lis aucun des timer ne peut descendre
sous la miliseconde.
Merci pour ce lien.
Un timer est quelque chose qui se déclence à intervalle fixe, comment
veux-tu mesurer un temps écoulé avec ça ? Moi y en a pas comprendre...
Pour mesurer une durée écoulée, t'as 2 solutions classiques.
- RDTSC (instruction Intel, gaffe, à partir du P1 je crois).
- QueryPerformanceFrequency et QueryPerformanceCounter.
Pour le premier cas, attention à bien initialiser/calibrer et il y a
quelques précautions à prendre :
ce n'est pas exactement ce à quoi je m'attendais. En fait mon but est de pouvoir mesurer le temps écoulé lors de l'exécution d'un routine avec une précision de 100 à 500µs.
Mais bon, d'après ce que je lis aucun des timer ne peut descendre sous la miliseconde.
Merci pour ce lien.
Un timer est quelque chose qui se déclence à intervalle fixe, comment veux-tu mesurer un temps écoulé avec ça ? Moi y en a pas comprendre...
Pour mesurer une durée écoulée, t'as 2 solutions classiques.
- RDTSC (instruction Intel, gaffe, à partir du P1 je crois). - QueryPerformanceFrequency et QueryPerformanceCounter.
Pour le premier cas, attention à bien initialiser/calibrer et il y a quelques précautions à prendre :
ce n'est pas exactement ce à quoi je m'attendais. En fait mon but est de pouvoir mesurer le temps écoulé lors de l'exécution d'un routine avec une précision de 100 à 500µs.
Mais bon, d'après ce que je lis aucun des timer ne peut descendre sous la miliseconde.
Chronométrer du code sous Windows, c'est un peu compliqué.
- La première méthode, c'est la montre bracelet. Partant du principe (pas toujours vrai, mais bon ...) qu'une optimisation non mesurable en exploitation est inutile, il suffit de tester diverses options en situation.
- On vous conseille QueryPerformanceCounter (et QueryPerformanceFrequency). Je les utilise, en fait, j'utilise RDTSC et RDPMC, instructions assembleur non privilégiées et sincèrement plus simples d'emploi que les fonctions Windows, même si on ne connait rien à l'assembleur. Le problème, c'est qu'on mesure (à la nanoseconde près ou mieux !) un temps absolu, donc le temps passé dans le noyau ou les autres applis dans un fonctionnement multitâche. La solution est de bien choisir les temps de boucle dans un premier temps et ensuite de procéder par série d'une dizaine de mesures (enchaînées par programme). Il ne faut ensuite pas faire une moyenne, mais éliminer les valeurs "hors moyenne", qui indiquent que le programme a été interrompu par l'OS.
- Il existe des instructions privilégiées (donc qui ne nous sont pas accessibles) qui me semble-t-il peuvent mesurer un tas de choses, dont le temps réellement passé dans UN processus. Je suppose que ces instructions sont utilisées par certains logiciels de profilage.
- Vous parlez de difftime(), donc de time.h. Vous avez beaucoup mieux, clock-t clock(void);. Vous accédez au moins à la milliseconde (à vous de boucler votre mesure en conséquence). Mais surtout, la norme C semble dire que le temps mesuré est celui du programme : <C99> The clock function returns the implementation’s best approximation to the processor time used by the program since the beginning of an implementation-defined era related only to the program invocation. </C99> Je ne sais pas comment fait le compilo, mais vous lisez comme moi, ce n'est pas ambigu. A part "best approximation" :-(. Je pense que c'est la voie à creuser.
Je peux vous donner des squelettes de code avec RDTSC si vous le souhaitez. -- Pierre
"Mouarf" <mouarf@chezmoi.fr> a écrit:
ce n'est pas exactement ce à quoi je m'attendais. En fait mon but est de
pouvoir mesurer le temps écoulé lors de l'exécution d'un routine avec une
précision de 100 à 500µs.
Mais bon, d'après ce que je lis aucun des timer ne peut descendre sous la
miliseconde.
Chronométrer du code sous Windows, c'est un peu compliqué.
- La première méthode, c'est la montre bracelet. Partant du principe
(pas toujours vrai, mais bon ...) qu'une optimisation non mesurable en
exploitation est inutile, il suffit de tester diverses options en
situation.
- On vous conseille QueryPerformanceCounter (et
QueryPerformanceFrequency). Je les utilise, en fait, j'utilise RDTSC
et RDPMC, instructions assembleur non privilégiées et sincèrement plus
simples d'emploi que les fonctions Windows, même si on ne connait rien
à l'assembleur. Le problème, c'est qu'on mesure (à la nanoseconde près
ou mieux !) un temps absolu, donc le temps passé dans le noyau ou les
autres applis dans un fonctionnement multitâche. La solution est de
bien choisir les temps de boucle dans un premier temps et ensuite de
procéder par série d'une dizaine de mesures (enchaînées par
programme). Il ne faut ensuite pas faire une moyenne, mais éliminer
les valeurs "hors moyenne", qui indiquent que le programme a été
interrompu par l'OS.
- Il existe des instructions privilégiées (donc qui ne nous sont pas
accessibles) qui me semble-t-il peuvent mesurer un tas de choses, dont
le temps réellement passé dans UN processus. Je suppose que ces
instructions sont utilisées par certains logiciels de profilage.
- Vous parlez de difftime(), donc de time.h. Vous avez beaucoup mieux,
clock-t clock(void);. Vous accédez au moins à la milliseconde (à vous
de boucler votre mesure en conséquence). Mais surtout, la norme C
semble dire que le temps mesuré est celui du programme :
<C99>
The clock function returns the implementation’s best approximation to
the processor time used by the program since the beginning of an
implementation-defined era related only to the program invocation.
</C99>
Je ne sais pas comment fait le compilo, mais vous lisez comme moi, ce
n'est pas ambigu. A part "best approximation" :-(. Je pense que c'est
la voie à creuser.
Je peux vous donner des squelettes de code avec RDTSC si vous le
souhaitez.
--
Pierre
ce n'est pas exactement ce à quoi je m'attendais. En fait mon but est de pouvoir mesurer le temps écoulé lors de l'exécution d'un routine avec une précision de 100 à 500µs.
Mais bon, d'après ce que je lis aucun des timer ne peut descendre sous la miliseconde.
Chronométrer du code sous Windows, c'est un peu compliqué.
- La première méthode, c'est la montre bracelet. Partant du principe (pas toujours vrai, mais bon ...) qu'une optimisation non mesurable en exploitation est inutile, il suffit de tester diverses options en situation.
- On vous conseille QueryPerformanceCounter (et QueryPerformanceFrequency). Je les utilise, en fait, j'utilise RDTSC et RDPMC, instructions assembleur non privilégiées et sincèrement plus simples d'emploi que les fonctions Windows, même si on ne connait rien à l'assembleur. Le problème, c'est qu'on mesure (à la nanoseconde près ou mieux !) un temps absolu, donc le temps passé dans le noyau ou les autres applis dans un fonctionnement multitâche. La solution est de bien choisir les temps de boucle dans un premier temps et ensuite de procéder par série d'une dizaine de mesures (enchaînées par programme). Il ne faut ensuite pas faire une moyenne, mais éliminer les valeurs "hors moyenne", qui indiquent que le programme a été interrompu par l'OS.
- Il existe des instructions privilégiées (donc qui ne nous sont pas accessibles) qui me semble-t-il peuvent mesurer un tas de choses, dont le temps réellement passé dans UN processus. Je suppose que ces instructions sont utilisées par certains logiciels de profilage.
- Vous parlez de difftime(), donc de time.h. Vous avez beaucoup mieux, clock-t clock(void);. Vous accédez au moins à la milliseconde (à vous de boucler votre mesure en conséquence). Mais surtout, la norme C semble dire que le temps mesuré est celui du programme : <C99> The clock function returns the implementation’s best approximation to the processor time used by the program since the beginning of an implementation-defined era related only to the program invocation. </C99> Je ne sais pas comment fait le compilo, mais vous lisez comme moi, ce n'est pas ambigu. A part "best approximation" :-(. Je pense que c'est la voie à creuser.
Je peux vous donner des squelettes de code avec RDTSC si vous le souhaitez. -- Pierre
Christian ASTOR
Mouarf wrote:
hello les gens, est ce que la plus petite durée quantifiable sous windows lorsque l'on programme est la milliseconde ou alors on peut descendre plus bas (idéalement j'aimerais obtenir une resolution entre 100 et 500µs)?
Je souhaite utiliser une fonction équivalente à "double difftime (time_t, time_t)" (prototype dans time.h) mais time_t ne s'incrémente que par milliseconde.
cf DoBench() http://msdn.microsoft.com/library/techart/optcode.htm + KB815668 et autres...
Mouarf wrote:
hello les gens, est ce que la plus petite durée quantifiable sous windows
lorsque l'on programme est la milliseconde ou alors on peut descendre plus
bas (idéalement j'aimerais obtenir une resolution entre 100 et 500µs)?
Je souhaite utiliser une fonction équivalente à "double difftime (time_t,
time_t)" (prototype dans time.h) mais time_t ne s'incrémente que par
milliseconde.
cf DoBench()
http://msdn.microsoft.com/library/techart/optcode.htm
+ KB815668 et autres...
hello les gens, est ce que la plus petite durée quantifiable sous windows lorsque l'on programme est la milliseconde ou alors on peut descendre plus bas (idéalement j'aimerais obtenir une resolution entre 100 et 500µs)?
Je souhaite utiliser une fonction équivalente à "double difftime (time_t, time_t)" (prototype dans time.h) mais time_t ne s'incrémente que par milliseconde.
cf DoBench() http://msdn.microsoft.com/library/techart/optcode.htm + KB815668 et autres...
