Sortowanie – Bash vs Perl benchmark

Dziś na kanale IRC znajomy szukał błędu w skrypcie bashowym. Danych dużo, skrypt wykonuje się długo (kilkadziesiąt minut). Błąd pojawiał mu się w sort, skrypt złożony. Jakoś tak stwierdził, że przepisze na Perla, będzie szybciej. Tyle tytułem wstępu, bo potem rozpoczęliśmy akademickie rozważania pt. czy sortowanie w Perlu będzie szybsze.

Postanowiłem się pobawić w praktykę. Nie ukrywam, że sporą rolę maiła tu niedawna dyskusja nt. algorytmów (i czemu zabawy z nimi są fajne) z M.[0]

Najpierw wygenerowanie sporego zestawu danych testowych [1]. 10 mln liczb z zakresu 0-99, 28999760 bajtów.

Następnie prosty sort [2]. Wyniki oscylują w granicach 16-18 sekund.

Pierwszy skrypt w Perlu[3] Jest minimalnie szybciej, bo 15 sekund.

Widać parę niepotrzebnych przepisań i da się to skrócić [4]. Po skróceniu wyniki oscylują w granicach 14,4 sekundy.

Pora na mały cheat, bo wiemy, że większość danych się powtarza. Czyli wersja z hashem – zliczamy ilości wystąpień, a na koniec sortujemy tyko klucze hasha (których jest 100) i wyświetlamy tyle razy, ile razy wystąpiły [5].

Jest dużo szybciej. Okolice 4,7 sekundy. Szczerze mówiąc nie sądziłem, że aż tyle da się urwać.

Na koniec postanowiłem sprawdzić, czy różnica wynika z powtarzających się danych. Wygenerowałem mały plik z praktycznie niepowtarzającymi się danymi [6]

Tutaj sort wykonywał się ok. 70 ms, natomiast – ku mojemu zdziwieniu – Perl nadal był szybszy i wykonywał się ok. 50 ms.

Daleki jestem od wyciągania z tego benchmarku daleko idących wniosków, nikogo też na przechodzenie wszędzie na Perla nie namawiam. Bardziej chodziło mi o pokazanie ciekawostki. Zwykle 10 sekund różnicy nie ma znaczenia, narzut na pisanie nie zwróci się nigdy, a wersja z sort jest po prostu czytelniejsza. I pewnie nadal będę używał sort. Niemniej warto wiedzieć, że w prosty sposób da się szybciej. Taki mały hack.

Inna sprawa, że IMVHO pisanie skryptów w bashu zwykle nie ma sensu i lepiej użyć Perla, Pythona itp. Szybciej, więcej można w prosty sposób zrobić, a skrypty bashowe mają tendencję do puchnięcia z elementami dziwnych rzeźb.

Uwagi: Wynik sortowania jest identyczny, choć nie to było priorytetem. Sortowanie nie jest numeryczne (jak ktoś chce, może się bawić, stawiam, że wyniki będą podobne). Skrypty są pisane mało optymalnie, mało czytelnie itd. ale tak na szybko piszę onelinery z głowy, a nie bawiłem się w upiększanie, bardziej chciałem szybko notkę zrobić. Tak, wiem nie ma close (F), w skryptach, ale nie jest tu potrzebne. Nie ma potrzeby korzystania z open, spokojnie można było robić „tradycyjne” while (<>) i czytać ze STDIN; jak sprawdziłem później nie powoduje to zauważalnej różnicy w czasie wykonania.

Ponieważ Blox wyczynia cuda z tekstami w pre podczas edycji notki, efektem czego jest znikanie większej części skryptów i tekstu, poniżej wklejka z wszystkimi poleceniami (odnośniki powyżej).

 

[0] Jest szansa, że pojawi się parę zadań z algorytmami. Ale niczego nie obiecuję. Zresztą, chyba lepiej, żeby takie rzeczy działy się na blogu jakiegoś programisty… A jak zobaczyłem, co robi Blox z groźnymi nawiasami trójkątnymi, to zupełnie odeszła mnie ochota na pisanie czegoś wymagającego fragmentów kodu tutaj.

UPDATE: Jak trafnie zauważyli czytelnicy w komentarzach, sort można przyspieszyć (analogicznie, jak przyspieszyć można grep) poprzez ustawienie LC_ALL=C lub LANG=C. Po tym zabiegu sort, dla podanych danych, działa szybciej od dotychczasowego najszybszego Perla, w okolicach 4,2 sekundy.

Software RAID i wypadnięcie dysku – HOWTO

Coś złego zaczęło dziać się z jednym z dysków w jednym z desktopów. Wygląda, jakby startował, a następnie robił restart. Głośne cyknięcie, rozkręcanie się dysku, a w tym czasie system stoi. Albo umiera zasilacz, albo dysk. Albo coś gdzieś nie styka.

Ponieważ w moje ręce wpadł inny dysk, postanowiłem podłączyć go do sprawnego komputera, zdiagnozować, wyzerować i zamienić z dyskiem w padającym desktopie.

Wszystko byłoby fajnie, ale w komputerze, w którym chciałem dokonać diagnostyki jest już software RAID. Po podłączeniu dysku do diagnostyki (IDE) system wstał, ale… tylko z jednym dyskiem (zdegradowany RAID). Podłączanego dysku też nie widział. Efekt był taki, że po odpięciu dysku do diagnostyki i uruchomieniu systemu, przywitał mnie rozjechany RAID (md0):

cat /proc/mdstat 
Personalities : [raid1]
md127 : active (auto-read-only) raid1 sda1[0]
      57584256 blocks super 1.2 [2/1] [U_]
     
md0 : active raid1 sdb2[1]
      57584256 blocks super 1.2 [2/1] [_U]

Natomiast w dmesg widoczny był wpis:

md: kicking non-fresh sda1 from array!

Wszystko jak najbardziej OK, tylko jak teraz poskładać to do kupy? TBH liczyłem, że system sam wykryje, że dysk będący częścią RAID wrócił i że ma stare dane. Czyli zrobi synchronizację. No niestety, nic nie dzieje się automagicznie. Chwila z wyszukiwarką i znalazłem rozwiązanie:

mdadm --stop /dev/md127
mdadm --add /dev/md0 /dev/sda1

Po takich komendach RAID rozpoczął synchronizację, której postęp można sprawdzić przez cat /proc/mdstat.

Tyle w kwestii podłączania dziwnych dysków do desktopa z software RAID. Przyczyną dziwnego zachowania okazało się… moje czytanie instrukcji. Nie zapakowałem dysku jak przyszedł (zlimitowany do 32GB), tylko zmieniłem zworką tryb na auto select. Znaczy tak mi się wydawało, gdyż wszystko wskazuje na to, że opis należy czytać odwrotnie. Jakichkolwiek oznaczeń gdzie dół a gdzie góra oczywiście brak.

Aktualizacja microcode procesora w Debianie Wheezy – HOWTO.

Jakiś czas temu pisałem o 3 rzeczach, których zapewne nie aktualizujesz w Debianie (piszę w Debianie, ale zapewne prawdziwe jest dla większości dystrybucji opartych na nim). Jeśli chodzi o mikrokod, było prosto, łatwo, i przyjemnie. I minęło, wraz z nadejściem Wheezy’ego.

Magiczne polecenie update-intel-microcode, o którym wówczas pisałem, niestety nie jest już obecne w Debianie poczynając od wersji Wheezy. Zamiast tego, trzeba zrobić wszystko ręcznie. Nie wnikałem, ale zapewne chodziło o kwestie licencyjno-copyrightowe – przy pobieraniu pliku z mikrokodem ze strony Intela jest pytanie o zaakceptowanie licencji. W każdym razie nie ma już narzędzia i trzeba zadbać ręcznie o aktualizację mikrokodu.

Jest za to inne narzędzie, które – wraz z bazowymi mikrokodami – znajduje się w pakiecie intel-microcode.

Po pierwsze wchodzimy na stronę Intela, skąd możemy pobrać mikrokod. Wielkiego wyboru nie widzę, ale może się zmienić – wybieramy najnowszą wersję. Akceptujemy licencję, pobieramy plik. Na dysku ląduje plik o nazwie zbliżonej do microcode-20120606-v2.tgz. Należy go rozpakować, a naszym oczom ukaże się microcode.dat. To są mikrokody, których szukacie! 😉

Po drugie, przy pomocy narzędzia iucode_tool produkujemy z niego pliki w formie strawnej dla pozostałych narzędzi. Ja zdecydowałem się na rozpakowanie ich „na boczek”, żeby ręcznie porównać:

mkdir /tmp/ucode && iucode_tool -K/tmp/ucode/ /tmp/microcode.dat

Po tym zabiegu w katalogu /tmp/ucode mamy w tym momencie całkiem sporą ilość plików, które są gotowymi do użycia mikrokodami. Aby były używane, należy je skopiować do /lib/firmware/intel-ucode. Oczywiście jest możliwość rozpakowywania bezpośrednio w domyślną systemową lokalizację, wystarczy użyć przełącznika –overwrite i nie podawać katalogu docelowego.

Pora na użycie. I tu przyznaję zaczynają się schody. O ile wcześniej bez problemu można było załadować mikrokod online, to teraz iucode_tool -vk /tmp/ucode/* niby się wykonuje (wczytując wszystkie, czyli dla różnych procesorów mikrokody – zupełnie tego nie rozumiem), ale chyba nie działa. W każdym razie śladu w dmesg żadnego… Wygląda, że mikrokod jest dodawany do initramfs. Aby dodać mikrokody znajdujące się w domyślnej systemowej lokalizacji do wszystkich zainstalowanych kerneli, popełniamy:

update-initramfs -k all -uv

Po reboocie powinniśmy działać na nowym mikrokodzie. Uwaga: domyślnie do initramfs trafiają tylko mikrokody dla procesora, na którym jest wydawane polecenie. Można to zmienić w /etc/default/intel-microcode.

Dla procesorów AMD istnieje analogiczny pakiet, ale nie mam takiego pod ręką, by przetestować.

Przy pisaniu wpisu posiłkowałem się opisem Mikrokodu na wiki Arch. Co prawda niewiele się zgadza, ale może komuś się przyda. Warto też zajrzeć na ogłoszenie dotyczące mikrokodu, które znalazłem już po napisaniu wpisu.