Wszyscy kochamy benchmarki...

Ostatnio zwróciłem uwagę na opublikowany niedawno post na Blog-O-Sphere Haiku autorstwa Stephan Aßmus'a (aka stippi) - dobrze wszystkim znanego, bardzo aktywnego developera systemu Haiku. Postanowiłem nieco streścić jego artykuł dla tych, którzy nie czują się najmocniej w języku angielskim.

Wszyscy kochamy benchmarki - i jak tu się nie zgodzić? Dotychczas nie było okazji na porównanie wydajności systemu z innymi, bardziej znanymi konkurentami - śmiem twierdzić, że do niedawna nie było nawet sensu. Jednak teraz, zgodnie z tą maksymą, stippi postanowił w końcu sprawdzić jak system Haiku poradzi sobie w porównaniu z innymi z tym, co zazwyczaj wszystkim programistom i zwolennikom Haiku zajmuje najwięcej czasu - budowaniem Haiku ze źródeł. Dla porównania wyników czasowych przygotował kilka platform do budowania systemu Haiku: openSUSE 11.2, FreeBSD 8.0, OpenSolaris 2009.06, ZETA 1.2 i Haiku r34844. Z uwagi na brak prawdziwej działającej platformy z BeOS'em R5, w wymienionej liście znalazła się w zamian ZETA. W ten sposób stippi mógł chociaż orientacyjnie sprawdzić jak mniej więcej spisywałby się pierwowzór w tym eksperymencie.

Wszystkie testy przeprowadzane były na jednym i tym samym sprzęcie. By uniknąć dodatkowych błędów pomiarowych między systemami, każdy z nich był instalowany na tym samym dysku na tej samej partycji znajdującej się na początku nośnika. Dokładne specyfikacje sprzętu możecie znaleźć w oryginalnym poscie. Nadszedł czas na wybór systemów plików. Wybór ten jest dość ważny - chcemy, by wszystkie wybrane systemy plików były możliwie podobne. Wybór Stehpan'a kierowany był również myślą obsługi extended attributes (xattr) - możliwości dodawania ('doklejania') metadanych do plików. Budowanie Haiku z --use-xattr jest szybsze, jako że praca na metadanych doklejonych do pliku jest mniej pracochłonna dla systemu niż praca na plikach zastępujących te atrybuty. Ostatecznie, wybór padł na UFS2 dla FreeBSD, ReiserFS 3.6 dla openSUSE, ZFS dla OpenSolaris oraz BFS dla ZETA i Haiku (bez włączonego indeksowania). Dla większości systemów (GNU/Linux, FreeBSD, OpenSolaris i Haiku) podczas testów budowana była ówcześnie najświeższa rewizja - 34844. Jednak, by uniknąć problemów z systemem budowania, w przypadku ZETA stippi zdecydował budować starszą wersję źródeł - r28969 - z uwagi na porzucenie ZETA jako obsługiwanej platformy budowania Haiku w nowszych rewizjach. By benchmark dalej był wiarygodny, system Haiku i ZETA porównywane są osobno, budując tą samą, starszą rewizję. Jako kompilator wybrany został gcc 2.95.3. Przebieg testu był następujący: Stephan uruchamiał system budowania dla każdej platformy i usuwał skompilowane obiekty. Jam za pierwszym razem tworzy dużo plików cache które przyspieszają proces budowania przy następnych wywołaniach jam - dlatego pierwszy etap nie był brany pod uwagę do benchmarku. Następnie system był restartowany, uruchamiany terminal o wielkości 134x24 znaki i rozpoczynana kompilacja obrazu Haiku (jam -q -j2 haiku-image). Ten krok był powtarzany wielokrotnie, a najlepszy wynik (najkrótszy osiągnięty czas) zapisywany.

$ time jam -q -j2 haiku-image

FreeBSD 8.0:
real	11m53.918s
user	17m11.611s
sys	2m39.864s
(713.9 seconds)

Linux 2.6.31:
real	13m32.431s
user	17m10.099s
sys	2m49.717s
(812.4 seconds)

OpenSolaris 2009.06:
real	14m20.792s
user	18m36.871s
sys	5m39.549s
(860.8 seconds)

Haiku r35024:
real	17m18.436s
user	27m22.108s
sys	5m0.447s 

Z wyników widać, że najlepiej z wszystkich radzi sobie FreeBSD. Jednak to, co powinno interesować nas najbardziej, to czas uzyskany na systemie Haiku. Stephan słusznie zauważa, że ostatnio dokonane optymalizacje kernela (głównie za sprawą Ingo Weinhold'a), pozwoliły Haiku osiągać wyniki zbliżone do wiodących systemów operacyjnych. Proces budowania trwał jedynie 1.28 razy wolniej od linuksa - prawdopodobnie najpowszechniej używanej platformy do budowania Haiku. Jak dla mnie wynik rewelacyjny, tym bardziej porównując ilość osób pracujących nad takimi systemami jak GNU/Linux czy FreeBSD a niewielkim gronem developerów Haiku. Zadziwia jednak wynik ZETA w tej konfrontacji, która okazała się najsłabszym systemem w tym benchmarku. W tym momencie ciekawi mnie, czy stary dobry BeOS R5 osiągnąłby podobny wynik. Wnioski? Haiku idzie w dobrym kierunku - i robi to bardzo szybko. Nie wiem jak Was, ale mnie to bardzo cieszy. Stephan wykazał również, że BFS jest niekoniecznie wąskim gardłem systemu operacyjnego podczas kompilacji (podobno były takie opinie). Dzięki stippi! Aż chce się spróbować samemu.

http://www.haiku-os.org/blog/stippi/2010-01-12_everyone_loves_benchmarks