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.

Obudź sobie Linuksa

Mało kto wie, ale komputer może się sam włączyć o zadanej godzinie. Zupełnie sam, bez pomocy zewnętrznych źródeł, magic packet i Wake-On-LAN. Wykorzystać można do tego rtcwake. Można to wykorzystać do oszczędzania energii (i zużycia sprzętu), a przy tym nie musieć włączać komputera ręcznie, nie czekać na jego uruchomienie, ogólnie – mieć wrażenie, że działa on cały czas.

W szczególności można zrobić z komputera budzik (włączy się o zadanej godzinie i np. odtworzy zadany utwór albo stację radiową) czy też do maszynki przyjmującej backupy (nie musi być włączona cały czas, wystarczy włączyć ją na czas transferu backupu i wyłączyć po ich przesłaniu). Automagiczne włączanie przydać się może także w firmie, gdzie Linux pełni rolę serwera NAS i wydruku – nic nie stoi na przeszkodzie, by wyłączał się po pracy (np. 18:00), a uruchamiał przed przyjściem pierwszych pracowników (np. 7:00).

Wszystko to można osiągnąć za pomocą programu rtcwake będącego częścią util-linux z odpowiednimi parametrami.

Na początek warto jednak pamiętać, że wyłączenie wyłączeniu nierówne. Program rtcwake obsługuje m.in. następujące tryby wyłączenia (wybierane przełącznikiem -m):

  • standby – stan ACPI S1. Minimalne oszczędności energii, błyskawiczny powrót do działającego systemu. Tryb domyślny.
  • mem – stan ACPI S3 (Suspend-to-RAM). Wyłączone jest wszystko, poza pamięcią RAM. Duże oszczędności energii, bardzo szybkie wybudzanie.
  • disk – ACPI state S4 (Suspend-to-disk). Wyłączenie wszystkiego, stan maszyny zapisywany jest na dysku. Stosunkowo wolne wybudzanie z uwagi na konieczność odczytu zawartości pamięci RAM z dysku.
  • off -ACPI state S5 (Poweroff). Wyłączenie systemu. Nie jest oficjalnie wspierane prze ACPI, ale zwykle działa.

Niestety, rtcwake posiada jedną poważną wadę – nie pozwala na podanie czasu wybudzenia w „ludzki” sposób. Można jedynie podać za ile sekund ma nastąpić wybudzenie albo czas w postaci Unix time. Mało wygodne. Oczywiście można to obejść przy pomocy skryptów (patrz linki).

Ja chwalę sobie tryb mem i używam często wieczorem, żeby rano mieć włączony komputer. Przy okazji często budzę się dźwiękiem włączanego komputera (nie, nie ustawiam muzyki). Skryptów nie używam, po prostu usypiam kompa na ten sam okres czasu, osiem godzin, przy pomocy polecenia:

rtcwake -s 28800 -m mem

Da się oczywiście zrobić więcej/lepiej ale… jakoś nie mam potrzeby.

Więcej o rtcwake AKA warto przeczytać:

  1. http://czytelnia.ubuntu.pl/index.php/2012/05/23/automatycznie-wybudzanie-z-hibernacji-budzik/ – dobry opis po polsku, dobry skrypt
  2. http://blog.loleksy.pl/2014/01/28/reuse-an-old-laptop-or-netbook-as-a-vps-backup-solution/ – skrypt do backupu z wykorzystaniem rtcwake

Tails 1.1 wydany, 0day w Tails

We wtorek pojawiła się informacja o tym, że wydana została wersja 1.1 dystrybucji live Linuksa ułatwiającej zachowanie anonimowości w internecie poprzez użycie sieci Tor. Dużą zmianą jest zmiana wersji Debiana, na której Tails bazuje. Do tej pory był to Squeeze, obecnie jest to (w końcu!) Wheezy. Tradycyjnie sporo aktualizacji bezpieczeństwa. Nowy obraz iso jest większy o ok. 60 MB od poprzednika.

Skoro o aktualizacjach bezpieczeństwa mowa, to autorzy dystrybucji napisali o rzekomo odkrytych błędach 0day w dystrybucji. Wszystko wskazuje na to, że faktycznie istnieją. Błędy póki co nie zostały im ujawnione, ale ma to nastąpić w ciągu tygodnia. Otrzymali również zapewnienie, że błędy nie zostaną opublikowane, dopóki nie zdołają ich naprawić, a użytkownicy będą mieli szansę na aktualizację oprogramowania:

They informed us that they would provide us with a report within a week. We’re told they won’t disclose these vulnerabilities publicly before we have corrected it, and Tails users have had a chance to upgrade. We think that this is the right process to responsibly disclose vulnerabilities, and we’re really looking forward to read this report.

Tymczasem można pobrać wersję 1.1, która – jakkolwiek podatna – posiada naprawione inne błędy.