MAIS ce n'est pas du tout ce que je perçois au terminal, au terminal
j'ai "l'impression" que ça dure 2 ou 3 seconde.
donc, est-ce un problème d'unités ?
ou est-ce que sur unix (Mac OS W 10.4.7) le printf et spoolé si bien que
le temps mis à sortir les données au term n'a pas grand chose à voir
avec le temps réel d'éxécution (c'est ce que je pense) ?
question annexe :
j'utilise la constante "CLOCKS_PER_SEC" y en a t'il une autre qui donne
le nombre de "CLOCKS" par ms ou dois-je faire la conversion moi-même (ce
que je pense) ?
j'ai regardé time.h il n'y a QUE :
#define CLOCKS_PER_SEC (__DARWIN_CLK_TCK)
Le 20/09/06 16:24, dans <1hlz0we.kvspmvwi0sykN%, « Une bévue » a écrit :
Pierre Maurette wrote:
Ça semble en effet étrange, mais je n'ai pas trop regardé. Pas de code complet, et de toutes façons sur mes diverses implémentations, clock_t est un type entier. Chez vous, un type flottant très certainement. La norme ne demande qu'un type arithmétique.
La première chose à faire est de vous procurer la norme: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
OK, merci pour la ref, je commence à regarder, le premier truc que je lis :
2 The clock function determines the processor time used. ^^^^^^^^^^^^^^^^^^^^^^^
je pense que le "CLOCKS_PER_SEC" = 100 est bon (Eric Levenez m'en a touché deux mots sur un autre fil).
ils sont curieux ces floats à 6, exactement...
À 0 sur ma machine.
bon MAIS un sleep 10 n'occupe pas le proc pendant 10s, heureusement d'ailleurs...
Tu peux voir cela en lançant :
time ./clock_test
j'imagine que le process est suspendu et réveillé au bout de 10 s, 'où un temps nul.
Oui. "system" crée un processus et se met en attente de sa fin. Le processus père ne prend pas de temps à attendre.
j'imagine AUSSI que c'est la même chose pour printf, le process file le job à un process-fils, non ?
Non, pas du tout.
(j'ai obervé, en utilisant le terminal, que les print-out se mélangeait qqfois les pinceaux
Cela n'arrive pas avec stdout. Si tu vois cela, c'est un bug.
Par contre il ne faut pas mélanger les sorties de stdout (bufferisée) et les sorties de stderr (non bufferisée). Si tu fais cela les stderr vont se mélanger dans les stdout à cause de cette bufferisation.
je veux dire que si l'on fait un long print-out, les print-out d'erreur peuvent s'y retrouver au milieu même si les erreurs viennent d'un endroit qui n'a rien à voir avec le print-out)
"print-out" ? Stdout est bufferisé et n'affiche sa sortie que sur n, buffer plein ou appelle à fflush (d'autres diront sur sortie du programme).
Pour gérer la bufferisation : setbuf / setvbuf.
ça me paraît logique.
Bin, non, le printf n'utilise ni un thread, ni un processus. Ce que tu vois n'est que la conséquence du mélange stdout et stderr.
Sous shell unix standard (pas C-shell donc) si tu lances une appli de cette façon :
./appli >stdout.txt 2>stderr.txt
Tu différencies les 2 flux. Si tu n'en veux plus qu'un :
./appli 2>&1
Mais là il vaut mieux poster tes questions sur un groupe unix.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 20/09/06 16:24, dans
<1hlz0we.kvspmvwi0sykN%pere.noel@laponie.com.invalid>, « Une bévue »
<pere.noel@laponie.com.invalid> a écrit :
Pierre Maurette <maurettepierre@wanadoo.fr> wrote:
Ça semble en effet étrange, mais je n'ai pas trop regardé. Pas de code
complet, et de toutes façons sur mes diverses implémentations, clock_t
est un type entier. Chez vous, un type flottant très certainement. La
norme ne demande qu'un type arithmétique.
La première chose à faire est de vous procurer la norme:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
OK, merci pour la ref, je commence à regarder, le premier truc que je
lis :
2 The clock function determines the processor time used.
^^^^^^^^^^^^^^^^^^^^^^^
je pense que le "CLOCKS_PER_SEC" = 100 est bon (Eric Levenez m'en a
touché deux mots sur un autre fil).
ils sont curieux ces floats à 6, exactement...
À 0 sur ma machine.
bon MAIS un sleep 10 n'occupe pas le proc pendant 10s, heureusement
d'ailleurs...
Tu peux voir cela en lançant :
time ./clock_test
j'imagine que le process est suspendu et réveillé au bout de 10 s, 'où
un temps nul.
Oui. "system" crée un processus et se met en attente de sa fin. Le processus
père ne prend pas de temps à attendre.
j'imagine AUSSI que c'est la même chose pour printf, le process file le
job à un process-fils, non ?
Non, pas du tout.
(j'ai obervé, en utilisant le terminal, que les print-out se mélangeait
qqfois les pinceaux
Cela n'arrive pas avec stdout. Si tu vois cela, c'est un bug.
Par contre il ne faut pas mélanger les sorties de stdout (bufferisée) et les
sorties de stderr (non bufferisée). Si tu fais cela les stderr vont se
mélanger dans les stdout à cause de cette bufferisation.
je veux dire que si l'on fait un long print-out, les
print-out d'erreur peuvent s'y retrouver au milieu même si les erreurs
viennent d'un endroit qui n'a rien à voir avec le print-out)
"print-out" ? Stdout est bufferisé et n'affiche sa sortie que sur n, buffer
plein ou appelle à fflush (d'autres diront sur sortie du programme).
Pour gérer la bufferisation : setbuf / setvbuf.
ça me paraît logique.
Bin, non, le printf n'utilise ni un thread, ni un processus. Ce que tu vois
n'est que la conséquence du mélange stdout et stderr.
Sous shell unix standard (pas C-shell donc) si tu lances une appli de cette
façon :
./appli >stdout.txt 2>stderr.txt
Tu différencies les 2 flux. Si tu n'en veux plus qu'un :
./appli 2>&1
Mais là il vaut mieux poster tes questions sur un groupe unix.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 20/09/06 16:24, dans <1hlz0we.kvspmvwi0sykN%, « Une bévue » a écrit :
Pierre Maurette wrote:
Ça semble en effet étrange, mais je n'ai pas trop regardé. Pas de code complet, et de toutes façons sur mes diverses implémentations, clock_t est un type entier. Chez vous, un type flottant très certainement. La norme ne demande qu'un type arithmétique.
La première chose à faire est de vous procurer la norme: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
OK, merci pour la ref, je commence à regarder, le premier truc que je lis :
2 The clock function determines the processor time used. ^^^^^^^^^^^^^^^^^^^^^^^
je pense que le "CLOCKS_PER_SEC" = 100 est bon (Eric Levenez m'en a touché deux mots sur un autre fil).
ils sont curieux ces floats à 6, exactement...
À 0 sur ma machine.
bon MAIS un sleep 10 n'occupe pas le proc pendant 10s, heureusement d'ailleurs...
Tu peux voir cela en lançant :
time ./clock_test
j'imagine que le process est suspendu et réveillé au bout de 10 s, 'où un temps nul.
Oui. "system" crée un processus et se met en attente de sa fin. Le processus père ne prend pas de temps à attendre.
j'imagine AUSSI que c'est la même chose pour printf, le process file le job à un process-fils, non ?
Non, pas du tout.
(j'ai obervé, en utilisant le terminal, que les print-out se mélangeait qqfois les pinceaux
Cela n'arrive pas avec stdout. Si tu vois cela, c'est un bug.
Par contre il ne faut pas mélanger les sorties de stdout (bufferisée) et les sorties de stderr (non bufferisée). Si tu fais cela les stderr vont se mélanger dans les stdout à cause de cette bufferisation.
je veux dire que si l'on fait un long print-out, les print-out d'erreur peuvent s'y retrouver au milieu même si les erreurs viennent d'un endroit qui n'a rien à voir avec le print-out)
"print-out" ? Stdout est bufferisé et n'affiche sa sortie que sur n, buffer plein ou appelle à fflush (d'autres diront sur sortie du programme).
Pour gérer la bufferisation : setbuf / setvbuf.
ça me paraît logique.
Bin, non, le printf n'utilise ni un thread, ni un processus. Ce que tu vois n'est que la conséquence du mélange stdout et stderr.
Sous shell unix standard (pas C-shell donc) si tu lances une appli de cette façon :
./appli >stdout.txt 2>stderr.txt
Tu différencies les 2 flux. Si tu n'en veux plus qu'un :
./appli 2>&1
Mais là il vaut mieux poster tes questions sur un groupe unix.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
pere.noel
Eric Levenez wrote:
Tu peux voir cela en lançant :
time ./clock_test
ok, merci, dans les mêmes conditions, j'obtiens :
time ./clock_test 6
6 0 100.00 0.00 0.00 ./clock_test 0.01s user 0.09s system 0% cpu 10.182 total
lè dans ce test je fais un sleep 10.
j'imagine que le process est suspendu et réveillé au bout de 10 s, 'où un temps nul.
Oui. "system" crée un processus et se met en attente de sa fin. Le processus père ne prend pas de temps à attendre.
j'imagine AUSSI que c'est la même chose pour printf, le process file le job à un process-fils, non ?
Non, pas du tout.
bon, ben alors le résultat de mon clock() n'était pas correct...
(j'ai obervé, en utilisant le terminal, que les print-out se mélangeait qqfois les pinceaux
Cela n'arrive pas avec stdout. Si tu vois cela, c'est un bug.
Par contre il ne faut pas mélanger les sorties de stdout (bufferisée) et les sorties de stderr (non bufferisée). Si tu fais cela les stderr vont se mélanger dans les stdout à cause de cette bufferisation.
ce n'étant pas en C...
-- une bévue
Eric Levenez <news@levenez.com> wrote:
Tu peux voir cela en lançant :
time ./clock_test
ok, merci, dans les mêmes conditions, j'obtiens :
time ./clock_test
6
6
0
100.00
0.00
0.00
./clock_test 0.01s user 0.09s system 0% cpu 10.182 total
lè dans ce test je fais un sleep 10.
j'imagine que le process est suspendu et réveillé au bout de 10 s, 'où
un temps nul.
Oui. "system" crée un processus et se met en attente de sa fin. Le processus
père ne prend pas de temps à attendre.
j'imagine AUSSI que c'est la même chose pour printf, le process file le
job à un process-fils, non ?
Non, pas du tout.
bon, ben alors le résultat de mon clock() n'était pas correct...
(j'ai obervé, en utilisant le terminal, que les print-out se mélangeait
qqfois les pinceaux
Cela n'arrive pas avec stdout. Si tu vois cela, c'est un bug.
Par contre il ne faut pas mélanger les sorties de stdout (bufferisée) et les
sorties de stderr (non bufferisée). Si tu fais cela les stderr vont se
mélanger dans les stdout à cause de cette bufferisation.
6 0 100.00 0.00 0.00 ./clock_test 0.01s user 0.09s system 0% cpu 10.182 total
lè dans ce test je fais un sleep 10.
j'imagine que le process est suspendu et réveillé au bout de 10 s, 'où un temps nul.
Oui. "system" crée un processus et se met en attente de sa fin. Le processus père ne prend pas de temps à attendre.
j'imagine AUSSI que c'est la même chose pour printf, le process file le job à un process-fils, non ?
Non, pas du tout.
bon, ben alors le résultat de mon clock() n'était pas correct...
(j'ai obervé, en utilisant le terminal, que les print-out se mélangeait qqfois les pinceaux
Cela n'arrive pas avec stdout. Si tu vois cela, c'est un bug.
Par contre il ne faut pas mélanger les sorties de stdout (bufferisée) et les sorties de stderr (non bufferisée). Si tu fais cela les stderr vont se mélanger dans les stdout à cause de cette bufferisation.
