Selon Yves Rutschle <[EMAIL PROTECTED]>:

> 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


� mon avis si, je ne peux pas tester car je n'ai qu'une connexion ssh sous la
main mais si tu fais : time ls /usr/bin

2 fois de suite, je pense que le temps user va �tre compl�tement diff�rent....

ce qui montre que ce que le syst�me garde en cache m�moire influ sur les
perfs... et que pour fait un comparatif de programmes qui traite les m�mes
donn�es (obtenu par le m�me appel systemes, dans notre cas lecture d'un
fichier), le cache m�moire est un param�tre � prendre en compte......


M.

> 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.
> 
> 
> -- 
> Pensez � lire la FAQ de la liste avant de poser une question :
> http://wiki.debian.net/?DebianFrench
> 
> Pensez � rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
> 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
> 
> 


-- 
Emmanuel Bouthenot - Kolter
  MAIL : [EMAIL PROTECTED]
   GPG : 0x414EC36E
   WWW : http://kolter.free.fr
JABBER : [EMAIL PROTECTED]
   TEL : (+33) 06 17 29 01 91

Répondre à