Re: [HS] lignes uniques, performances
Le 12503ième jour après Epoch, Gabriel Paubert écrivait: > On Fri, Mar 26, 2004 at 06:12:47PM +0100, François TOURDE wrote: >> Le 12503ième jour après Epoch, >> Yves Rutschle écrivait: >> >> > On Fri, Mar 26, 2004 at 12:50:20PM +0100, François TOURDE wrote: >> >> Euh... Tu es sûr que ta commande ne mesure pas simplement le temps de >> >> cat seulement ? >> > >> > Oui: >> > [EMAIL PROTECTED]:yves$ time cat linux > /dev/null >> > >> > real0m0.457s >> > user0m0.010s >> > sys 0m0.440s >> > >> > >> > J'y avais pensé :-) >> >> Je crois quand même que tu commets une erreur. time est une commande >> comme les autres, et du coup le pipe s'applique à 'time cat ...' ! >> >> En tout cas c'est ce qui devrait se passer ... >> >> si je fais 'time nfjnsdfljnsdf >/dev/null 2>&1' J'ai quand même une >> sortie sur le terminal. J'avoue ne pas comprendre :( > > C'est pourtant simple, time est un mot réservé de bash. > > Pour les détails: man bash, section SHELL GRAMMAR, paragraphe > Pipelines. Ah ben merci. 'man time' m'avait enduit d'erreur :) -- A gourmet who thinks of calories is like a tart that looks at her watch. -- James Beard
Re: [HS] lignes uniques, performances
On Fri, Mar 26, 2004 at 06:12:47PM +0100, François TOURDE wrote: > Le 12503ième jour après Epoch, > Yves Rutschle écrivait: > > > On Fri, Mar 26, 2004 at 12:50:20PM +0100, François TOURDE wrote: > >> Euh... Tu es sûr que ta commande ne mesure pas simplement le temps de > >> cat seulement ? > > > > Oui: > > [EMAIL PROTECTED]:yves$ time cat linux > /dev/null > > > > real0m0.457s > > user0m0.010s > > sys 0m0.440s > > > > > > J'y avais pensé :-) > > Je crois quand même que tu commets une erreur. time est une commande > comme les autres, et du coup le pipe s'applique à 'time cat ...' ! > > En tout cas c'est ce qui devrait se passer ... > > si je fais 'time nfjnsdfljnsdf >/dev/null 2>&1' J'ai quand même une > sortie sur le terminal. J'avoue ne pas comprendre :( C'est pourtant simple, time est un mot réservé de bash. Pour les détails: man bash, section SHELL GRAMMAR, paragraphe Pipelines. Gabriel
Re: [HS] lignes uniques, performances
Yves Rutschle a écrit, vendredi 26 mars 2004, à 11:01 : > On Fri, Mar 26, 2004 at 10:11:09AM +0100, Jacques L'helgoualc'h wrote: > > UUOP = Useless Use Of *Perl* ;) [...] > Comme dit J8, ton exemple est discutable. Bah oui, mon bench était complètement bidon --- j'avais tout de même éliminé le premier essai, trop défavorable à Perl. Cependant, ce temps de chargement serait à prendre en compte quand on analyse en ligne de commande, après tout. > Je viens donc d'essayer plusieurs choses sur un gros fichier (toutes > les sources d'un noyau linux concaténées dans un seul fichier, 6 > millions de lignes pour 173M: Là, je ne suis pas d'accord ! Quand Awk a été développé, les disques durs étaient moins gros ;) C'est normal que Perl s'en tire mieux sur des gros fichiers. Le problème initial était posé sur des fichiers de log, il faudrait alors plutôt piocher ses données dans /var/log/ ... J'ai donc réessayé sur une concaténation de /var/log/*.log mawk user0m0.150s user0m0.160s user0m0.140s gawk user0m0.210s user0m0.220s user0m0.220s perl user0m0.200s user0m0.190s user0m0.180s ...mais si je concatène 10 exemplaires de ce log d'environ 810K, le classement s'inverse complètement, Perl prend l'avantage et mawk s'effondre... mawk user0m2.160s gawk user0m1.370s perl user0m1.140s Bon, le plus long c'est de taper la ligne de commande ! -- Jacques L'helgoualc'h
Re: [HS] lignes uniques, performances
Le 12503ième jour après Epoch, Yves Rutschle écrivait: > On Fri, Mar 26, 2004 at 12:50:20PM +0100, François TOURDE wrote: >> Euh... Tu es sûr que ta commande ne mesure pas simplement le temps de >> cat seulement ? > > Oui: > [EMAIL PROTECTED]:yves$ time cat linux > /dev/null > > real0m0.457s > user0m0.010s > sys 0m0.440s > > > J'y avais pensé :-) Je crois quand même que tu commets une erreur. time est une commande comme les autres, et du coup le pipe s'applique à 'time cat ...' ! En tout cas c'est ce qui devrait se passer ... si je fais 'time nfjnsdfljnsdf >/dev/null 2>&1' J'ai quand même une sortie sur le terminal. J'avoue ne pas comprendre :( -- C is quirky, flawed, and an enormous success -- Dennis M. Ritchie
Re: [HS] lignes uniques, performances
Fri, 26 Mar 2004 15:00:33 +, 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
> > > 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
>
> real1m4.090s
> user0m0.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
>
> real5m1.439s
> user0m24.810s
> sys 0m5.030s
> [EMAIL PROTECTED]:yves$ time perl -ne 'print if !$l{$_}++' < linux > /dev/null
>
> real11m1.316s
> user0m25.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_][__
Re: [HS] lignes uniques, performances
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 > 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
>
> real1m4.090s
> user0m0.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
>
> real5m1.439s
> user0m24.810s
> sys 0m5.030s
> [EMAIL PROTECTED]:yves$ time perl -ne 'print if !$l{$_}++' < linux > /dev/null
>
> real11m1.316s
> user0m25.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
Re: [HS] lignes uniques, performances
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 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
real1m4.090s
user0m0.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
real5m1.439s
user0m24.810s
sys 0m5.030s
[EMAIL PROTECTED]:yves$ time perl -ne 'print if !$l{$_}++' < linux > /dev/null
real11m1.316s
user0m25.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.
Re: [HS] lignes uniques, performances
Fri, 26 Mar 2004 12:33:17 +, Yves Rutschle a écrit : > On Fri, Mar 26, 2004 at 12:50:20PM +0100, François TOURDE wrote: > > Euh... Tu es sûr que ta commande ne mesure pas simplement le temps de > > cat seulement ? > > Oui: > [EMAIL PROTECTED]:yves$ time cat linux > /dev/null > > real0m0.457s > user0m0.010s > sys 0m0.440s > > > J'y avais pensé :-) Pas tout à fait : dans un tube, il y a deux bouts. 'time cat linux > /dev/null' mesure le temps que met cat pour lire ET pour envoyer vers /dev/null (qui est un consommateur très rapide). '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 , il faut faire attention aux buffers du système. Il faut lancer chaque commande au moins trois ou quatre fois (une centaine pour faire de *vrais* statistiques). 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. Maintenant, il faut aussi voir : - l'utilisation que vous voulez en faire : - la taille de vos données, - le nombre d'utilisations successives envisagées ; - ce que vous préférez utiliser ;o) -- | 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_][__
Re: [HS] lignes uniques, performances
On Fri, Mar 26, 2004 at 02:16:54PM +0100, Manu wrote: > d'ailleurs dans ces comparatifs il faudrait tenir en compte que bcp de choses > sont mises en cache mémoire et que donc 2 tests quasi consécutifs s'appliquant > sur les mêmes données en entrées ne sont somme toutes pas forcément equitables > en termes de prédispositions Non, revoie la définition des temps 'user' et 'system'. Le temps 'réel' ne veut en effet rien dire, ne serait-ce que parcequ'il dépend de la charge. Deux fois de suite: [EMAIL PROTECTED]:yves$ time perl -ne 'print' < linux2 > /dev/null real0m16.417s user0m4.400s sys 0m0.790s [EMAIL PROTECTED]:yves$ time perl -ne 'print' < linux2 > /dev/null real0m4.842s user0m4.570s sys 0m0.270s Puis avec un gros process qui tourne indépendament: [EMAIL PROTECTED]:yves$ time perl -ne 'print' < linux2 > /dev/null real0m9.717s user0m4.690s sys 0m0.320s Le temps 'user' ne change pas. Le temps réel double (le processeur est partagé entre mon 'cat' et l'autre process). Y.
Re: [HS] lignes uniques, performances
Selon Yves Rutschle <[EMAIL PROTECTED]>: > On Fri, Mar 26, 2004 at 12:50:20PM +0100, François TOURDE wrote: > > Euh... Tu es sûr que ta commande ne mesure pas simplement le temps de > > cat seulement ? > > Oui: > [EMAIL PROTECTED]:yves$ time cat linux > /dev/null > > real0m0.457s > user0m0.010s > sys 0m0.440s > > > J'y avais pensé :-) > Y. > > d'ailleurs dans ces comparatifs il faudrait tenir en compte que bcp de choses sont mises en cache mémoire et que donc 2 tests quasi consécutifs s'appliquant sur les mêmes données en entrées ne sont somme toutes pas forcément equitables en termes de prédispositions M. > -- > 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
Re: [HS] lignes uniques, performances
On Fri, Mar 26, 2004 at 12:50:20PM +0100, François TOURDE wrote: > Euh... Tu es sûr que ta commande ne mesure pas simplement le temps de > cat seulement ? Oui: [EMAIL PROTECTED]:yves$ time cat linux > /dev/null real0m0.457s user0m0.010s sys 0m0.440s J'y avais pensé :-) Y.
Re: [HS] lignes uniques, performances
Le 12503ième jour après Epoch,
Yves Rutschle écrivait:
> Maintenant, pour la vraie surprise (où il faut sans doute que je précise que
> j'ai testé sous bash):
>
> [EMAIL PROTECTED]:yves$ time cat linux | perl -ne 'print if !$l{$_}++' >
> /dev/null
>
> real0m32.237s
> user0m25.640s
> sys 0m5.260s
>
> [EMAIL PROTECTED]:yves$ time cat linux | awk '!l[$0]++' > /dev/null
>
> real0m43.167s
> user0m40.080s
> sys 0m2.670s
>
>
> Il semble donc maginalement _plus_efficace_ d'utiliser cat+pipe que d'utiliser
> la redirection de bash.
Euh... Tu es sûr que ta commande ne mesure pas simplement le temps de
cat seulement ?
Auquel cas, ça deviens plus compliqué d'évaluer ce qu'il se passe
réellement :)
--
Wiker's Law:
Government expands to absorb revenue and then some.
Re: [HS] lignes uniques, performances
On Fri, Mar 26, 2004 at 10:11:09AM +0100, Jacques L'helgoualc'h wrote:
> UUOP = Useless Use Of *Perl* ;)
Voyons voir...
> lhh $ time perl -ne 'print if!$l{$_}++' /dev/null
>
> real0m0.047s
> user0m0.040s
> sys 0m0.010s
> lhh $ time awk '!l[$0]++' /dev/null
>
> real0m0.027s
> user0m0.030s
> sys 0m0.000s
Comme dit J8, ton exemple est discutable. Je viens donc d'essayer plusieurs
choses sur un gros fichier (toutes les sources d'un noyau linux concaténées
dans un seul fichier, 6 millions de lignes pour 173M:
[EMAIL PROTECTED]:yves$ wc linux ; ls -lh linux
6110997 22043218 181766643 linux
-rw-r--r--1 yves yves 173M Mar 26 10:17 linux
Où l'on s'apperçoit que les idées reçues ne sont pas particulièrement utiles:
[EMAIL PROTECTED]:yves$ time perl -ne 'print if !$l{$_}++' < linux > /dev/null
real0m36.050s
user0m26.180s
sys 0m5.610s
[EMAIL PROTECTED]:yves$ time awk '!l[$0]++' < linux > /dev/null
real0m46.300s
user0m40.690s
sys 0m3.680s
Après démarrage, Perl est _nettement_ _plus_ rapide que awk.
Maintenant, pour la vraie surprise (où il faut sans doute que je précise que
j'ai testé sous bash):
[EMAIL PROTECTED]:yves$ time cat linux | perl -ne 'print if !$l{$_}++' >
/dev/null
real0m32.237s
user0m25.640s
sys 0m5.260s
[EMAIL PROTECTED]:yves$ time cat linux | awk '!l[$0]++' > /dev/null
real0m43.167s
user0m40.080s
sys 0m2.670s
Il semble donc maginalement _plus_efficace_ d'utiliser cat+pipe que d'utiliser
la redirection de bash.
Travaux pratiques pour le weekend: comment cat et bash lisent-ils les fichiers,
et pourquoi "cat lit et bash pipe" est-il plus efficace que "bash lit et pipe"?
Y.
