Hallo, Am Die, 19 Okt 2010, Andre Tann schrieb:
David Haller, Dienstag 19 Oktober 2010:
Alles < 1s Gesamtlaufzeit hat kaum mehr Aussagekraft als wenn du die Laufzeiten von deinem Kater auswürfeln läßt.
Hey, was hast Du gegen meinen Kater?
Garnix. Im Gegenteil, ich liebe alle felidae :) Einer meiner IRC-Nicks ist "Amba"[1] ;) Laß ihn halt einmal über deinen Nummernblock latschen und nimm das Ergebnis als Nachkommastellen ;)
# chgrp dh /var/log/mail $ { for i in 1 2 3 4 5; do time cat /var/log/mail >/dev/null; d ; } 2>&1 | grep real real 0m0.028s real 0m0.016s real 0m0.039s real 0m0.028s real 0m0.025s
Also schauen wir mal:
# for x in 1 2 3 4 5; do time sed -n -e '/delay=/s/.*(delay[^,]*,).*/\1/gp' \ /var/log/mail > /dev/null; done 2>&1 | grep real
real 0m0.495s real 0m0.480s real 0m0.487s real 0m0.479s real 0m0.490s
Also so gut kriegt es mein Kater nicht hin.
Da machst du allerdings auch was, mir ging's oben darum, wie sehr allein das IO aus dem Cache(!) variieren kann ... (und aus solchen Unterschieden leiten andere eben "Aussagen" her). Hat also immer noch keine Aussagekraft. Ok, für nen ersten Verdacht mag sowas reichen. Und bedenke: meine Kiste ist 10 Jahre alt, auf deiner Kiste "sollten" die Schwankungen rein theoretisch viel geringer sein. Du bekommst aber trotzdem 16ms Abweichung. Und was, wenn jetzt z.B. die awk-Variante zw. 0.485s und 0.512s variiert? Wie gesagt: deine "Aufgabe" ist zu gering um aussagekräftige Daten zu bekommen. Für einen sinnvollen Benchmark müßtest du mit 'init=/bin/bash' booten und dann direkt dein Script laufen lassen. Denn beim booten werden grep und sed und (AFAIR) auch perl aufgerufen, sollten also schon im Plattencache sein. Awk wird AFAIK nicht verwendet. Oder eben, du sorgst wie ich für eine "neutrale" Umgebung (Programme + Daten komplett im RAM) und obendrein dafür, daß die Ausführung lange genug dauert. Die Nachkommastellen der Laufzeit kannst du prinzipiell "wegwerfen". Es gibt einfach zu viel Einflüsse (z.B. vom Prozess- und IO-Scheduler). Und auf Mehrkern-Kisten muß man natürlich auch beachten, auf wievielen Kernen das läuft und Kernwechsel müßte man ggfs. ausschließen (taskset?) bzw. explizit das eine auf einem, und das andere auf dem anderen Kern laufen lassen (BTW: ein grep | sed, das auf zwei Kernen läuft sollte da dann wirklich relevant schneller sein, solange es nicht eh am IO hängt ;) Es kommt also sehr darauf an, wie oft / wann dein Script aufgerufen wird, ob dann die Programme (grep, sed, awk, perl) schon im RAM sind oder nicht, ob die Daten schon im RAM sind, ob's auf zwei oder mehr Kernen laufen kann, und und und ... Beispiel: 44MiB Datei (nicht im Cache): $ time dd if=foo of=/dev/null 90102+1 records in 90102+1 records out real 0m2.607s [ist jetzt im Cache] $ time dd if=foo of=/dev/null 90102+1 records in 90102+1 records out real 0m0.573s Bei perl wird's übrigens noch komplexer, da muß man berücksichtigen, ob Module geladen werden (das finden und laden dieser, ggfs. aus mehreren Dateien bestehenden, kann durchaus relevant Zeit kosten, weil die Dateien erstmal gesucht und geladen werden müssen). Vgl. z.B.: time perl -e '1;' time perl -MDate::Parse -e '1;' time perl -MDate::Manip -e '1;' time perl -MMIME::Parser -e '1;' (jew. mehrfach aufgerufen ;) Generell kann man dennoch davon ausgehen, daß es sich im Normalfall lohnt Module in perl zu verwenden ;)
$ { time for i in $loops; do awk '/relay=/{ \ print gensub(/.*relay([^,]*).*/,"\1","g"); }' /var/log/mail >/dev/null ; done; } 2>&1 | grep real real 0m14.173s
gensub... wieder was gelernt.
'man awk' hilft ;) Und natürlich 'sed & awk' von O'Reilly :) Ich mag awk. Und sed. Und perl. Und grep. Und bash. Ganz individuell je nachdem was ich machen will :)
Wie immer: "Know thy tools!"
Ja, stimmt wohl. Mit perl hab ichs halt noch nicht so.
Meine Faustregel: ab 3-5 Programmen, die ich aufrufen muß, *kann* sich ein einmaliger Aufruf von perl "lohnen" ... Was mich nicht daran hindert dennnoch bash- (oder auch awk-) Scripte mit ggfs. dutzenden Aufrufen externer Programme zu haben. Aber wenn ich sowas wie grep ... | sed ... | sed ... | grep ... | sed ... sehe wird mir einfach nur schlecht. Beim 'dynip'-Benchmark (Script gibt's per PM ;) gab's sogar Varianten mit perl hinter ner grep/sed Orgie ... Jedenfalls mag ich prinzipiell die "natürlichsprachliche" Art von perl und daß man fast alles auf viele Arten hinschreiben kann. Für manche ist das der Horror, für mich ist das die Möglichkeit, die am besten _lesbare_ Version hinzuschreiben ;) if ( $foo && $bar ) { machwas(); } machwas() if ( $foo && $bar ); $foo && $bar and machwas(); [...] machwas() unless ! $foo && ! $bar ; Je nach Situation (was $foo und $bar und machwas() jew. sind) kann das ein oder andere "einfacher"/"logischer" in den Ablauf passen ;) Ich selber ziehe "prinzipiell" den expliziten Stil samt aller (ggfs. redundanten) Klammern (s. erstes Beispiel) vor, verwende aber durchaus gern auch die anderen Möglichkeiten, wenn die "irgendwie" besser passen / lesbarer sind ;) Und ja, diese Freiheiten bei der Formulierung können auch mißbraucht werden, bei "perlgolf" zum Spaß, aus Unwissenheit zum Gruseln aller anderen. Die Verantwortung liegt aber _immer_ beim Programmierer. Und _das_ finde ich wiederum gut so. Beispiel: $max = [$a => $b] -> [ $a <= $b ]; ## Simon Cozens Das nachzuvollziehen macht Spaß :) Achso, ggfs. nimmt man eine performantere Variante, dokumentiert aber eine besser lesbare als Kommentar ... BTST.
HTH, Tut es.
So soll's sein :) -dnh, jep, echte Zufallssig :) [1] vgl. Panthera tigris altaica[2] [2] http://de.wikipedia.org/wiki/Sibirischer_Tiger und v.a. http://en.wikipedia.org/wiki/Siberian_tiger#History ;) -- If you hack enough tentacles off perl, there will be nothing left. Other languages have tentacles; perl _is_ tentacles. -- Richard Bos -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org