Fri, 26 Mar 2004 15:00:33 +0000, Yves Rutschle a �crit :
> 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
C'est presque exactement ce que je disais : il mesure le temps de cat ET
du tube (ou plut�t ce que je voulais dire, comme on peut le comprendre
avec la � preuve � que je donne, et comme on ne le comprend pas avec la
phrase que j'ai �crite). Mais le tube introduit un buffer et des E/S qui
ne sont pas g�r�s par perl ou awk. Cela modifie donc leur comportement.
> 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.
Je crois qu'il ne faut pas oublier ici que ce qui nous int�resse c'est le
traitement de fichiers et donc des E/S. Or le temps user ne donne que le
temps processeur, pas celui des attentes d'E/S (qui change beaucoup avec
la charge).
> 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).
Normal : le travail est toujours le m�me, que ce soit en perl ou en awk
(un test al�atoire dans un gros tableau).
Ce qui diff�rencie les deux, c'est la gestion de la m�moire et des E/S.
Il est donc logique que toutes les infos de time nous int�resse (y compris
le %w).
> >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.
Surtout s'il ne sert qu'une seule fois.
--
| Sylvain Sauvage, docteur [IAD & SMA] | bzz ? .o:.
| GREYC -- CNRS UMR 6072, Universit� de Caen | ` % ^..^___� o::o::
| t�l://+33 (0)2 31 56 74 31 | @ (oo) ) ::o::o
|__ http://www.info.unicaen.fr/~sauvage _______| _____`|'___WW�WW_____][__
