On Fri, Mar 26, 2004 at 02:47:13PM +0100, Sylvain Sauvage wrote:
> Pas tout � fait : dans un tube, il y a deux bouts.
Qui sont compt�s en temps syst�me...
> 'time cat linux | perl ...' mesure le temps que met cat pour lire ET pour
> donner les infos � perl. Pas forc�ment celui que met perl pour lire ce qui
> vient de cat (preuve : le temps est diff�rent avec <linux). Le tube est un
> buffer qui modifie le comportement de cat ET celui de perl.
Non, le tube ne modifie que le temps syst�me et `time cat
linux | perl` mesure le temps de l'ensemble, pas du tout
simplement cat. L'execution de cat (en temps user) est bien
�videment tr�s courte:
[EMAIL PROTECTED]:yves$ (time cat linux ) | perl -ne 'print if !$l{$_}++' >
/dev/null
real 1m4.090s
user 0m0.030s
sys 0m1.620s
Le temps syst�me depend d'autres choses (buffers et swap
par exemple) et le temps r�el a �videment peu de rapports
avec notre probl�me.
> De plus, comme le disait Manu <[EMAIL PROTECTED]>, il faut
> faire attention aux buffers du syst�me. Et je pense qu'il
> faudrait m�me ignorer la premi�re (lorsque le noyau lit le
> fichier pour la premi�re fois). Une autre solution est
> d'avoir un fichier qui soit deux ou trois fois plus gros
> que la m�moire disponible : �a �liminerait le cache de
> linux.
Tout �a ne change pas le temps *user* qui est le seul � �tre
� peu pr�s pr�dictible. Qq soit la charge, il devrait
rester le m�me, m�me si tu swappes le process, m�me si tu le
fais tourner sur un portable que tu endors pendant 45 jours
avant de le reveiller pour finir.
Et donc, avec des charges CPU de plus en plus grosses:
[EMAIL PROTECTED]:yves$ time perl -ne 'print if !$l{$_}++' < linux > /dev/null
real 5m1.439s
user 0m24.810s
sys 0m5.030s
[EMAIL PROTECTED]:yves$ time perl -ne 'print if !$l{$_}++' < linux > /dev/null
real 11m1.316s
user 0m25.720s
sys 0m21.720s
Les temps users restent essentiellement les m�mes. Dans le
second cas, le temps syst�me est soudainement plus grand car
linux a commenc� � swapper (perl monte � plus de 270Mo).
>Il faut lancer chaque commande au moins trois ou
> quatre fois (une centaine pour faire de *vrais*
> statistiques).
Je suis d'accord avec �a, et je dois avouer par rapport �
mon premier mail que la diff�rence entre cat | perl et perl
< fichier se perd dans le bruit de mesure. �a montre tout de
m�me que le UUOC n'est finalement pas particuli�rement
horrible.
Y.
