Jackiewiczowie

***

Kiedyś wyróżniano trzy polecania grep:

fgrep - To polecenie nie miało być szybkim grepem (fast grep), często było wręcz najwolniejsze. Zużywał za to mało pamięci, co dawniej miało znaczenie w niektórych systemach. Ludzie nie pamiętający czasów przed Linuksem kojarzą fgrep'a z rozwinięciem: "Fixed-string Global Regular Expressions Print", co ma (wg. nich) powodować jego szybsze działanie.

grep - Akronim od "Global Regular Expressions Print".

egrp - Akronim od "Extended Regular Expressions Print" . Różnice dobrze obrazuje taki przykład: `grep "+" myfile.txt` zwróci każdą linię zawierająca znak "+". Polecenie `egrep "+" myfile.txt` zwróci każdą linię, ponieważ znak "+" potraktuje jako meta znak.

Obecnie (zazwyczaj, jak w systemach CentOS, Red Hat, Debian, FreeBSD,Oracle, SUN) występuje jedno polecenie "grep", a skrypty powodują następujące akcje:
fgrep -> exec grep -F "$@"
egrep -> exec grep -E "$@"

Kodem zakończenia grep jest:
0 - jeżeli znaleziono dopasowanie
1 - jeżeli nie znaleziono dopasowania
2 - jeżeli wystąpił błąd.
Jak widać łatwo jest obsłużyć takie kody.

Program AWK również występuje w kilku wersjach, przy czym GAWK jest chyba najpopularniejszy:
AWK - oryginalny od AT&T (A. Aho, B. W. Kernighan and P. Weinberger).
NAWK - unowocześniony, również wprowadzony do Unix'a od AT&T.
GAWK - stworzony przez Free Software foundation's.

***

Powyższe testy kończą ten wpis, jednak nie kończą dalszych badań. Czy można zoptymalizować wieloprocesorowe wyszukiwanie? Tak, ale nie jest to banalne. Warto zapoznać się z wpisem: Wieloprocesorowe programy do pakowania plików - serwery Ux. Można zobaczyć jaką trudność sprawia przetwarzanie wieloprocesorowe. W kolejnych wpisach przedstawię gotowe programy służące równoległemu uruchamianiu programów jednowątkowych, oraz w spróbuję zmierzyć się z optymalizacją programów tutaj zaprezentowanych. Przy tworzeniu programów parsujących warto zwrócić uwagę na algorytmy Boyer-Moore'a i Railgun_Trolldom. Pozwala to lepiej zapoznać się z różnymi wynikami w zależności np.: od długości szukanego łańcucha. Wstępnie widzę potrzebę optymalizacji operacji dyskowych, a dalsza optymalizacja kodu wyszukującego może pójść np. w kierunku:

asm

    MOV CX, LENGTH BIGTAB

    CLD

    MOV DI,SEG BIGTAB

    MOV ES,DI

    MOV DI,OFFSET BIGTAB

P1: MOV AX,CHAR_1_2

    REPNE SCASW

    JNZ NOT_FOUND

P2: MOV DX,CHAR_3_4

    CMP WORD PTR ES:[DI],DX

    JNZ P1

multifindmaster – fork -32p	0,535	0,708
multifindmaster – ram -32p	0,697	0,691
multifindmaster – files -32p	0,702	0,714
grep	0,856	0,862
onlyfind_str	0,975	0,987
multifindmaster – ram -1p	1,469	1,468
multifindmaster – fork -1p	1,469	1,475
multifindmaster – files -1p	1,636	1,624
onlyfind_memmem	1,967	1,966
onlyfind_for	2,839	2,824
perl	5,548	5,484
java	6,084	6,14
ruby (fast)	10,763	10,755
python	22,385	22,543
ruby (slow 2)	78,234	77,708
ruby (slow 1)	78,919	78,175

Jackiewiczowie

Jak szybki jest grep? -> grep vs awk, python, rugby, java, perl, C - przeszukiwanie logów - część 11.

Zestawienie wyników:

Brak komentarzy:

Prześlij komentarz